如何为面向组件的软件平台编写集成测试
初始情况：
我们正在开发一个软件平台，可以通过配置不同的组件和添加附加的组件来生成产品。该平台由一个小型开发团队开发了几年。现在这个平台被越来越多的人使用，我们有了新的开发人员和测试人员。我们目前正在为开发人员开发一个概念。原因是，我们对组件没有太多的开发人员测试。
测试团队使用自动化UI测试工具来测试平台发出的产品。
我们的目标：
我们希望激励我们的团队成员编写更多的测试来实现。
- 缩短反馈周期
- 减少新特性的bug计数
- 减少回归
问题：
我们想要开始找出易碎的成分。在我们找到它们之后，我们希望为描述预期特性的组件编写集成测试。现在我们有了以下问题:我们可以自己测试组件，并模拟所有依赖于其他组件的组件。我们可以用所有直接依赖的组件来测试组件。我们可以用它的完全依赖结构来测试组件-因此它的依赖关系和它们的依赖关系.我们可以在不同产品配置的上下文中测试组件。
实现我们的目标，同时最小化团队成员配置测试所需的努力，哪一个是最好的？
回答 1
Software Engineering用户
发布于 2013-06-03 13:59:29
你可能需要两者兼而有之。
集成测试是针对实际依赖关系的。它们通常更容易编写，但需要更多的时间和资源来运行。有些bug只能通过集成测试才能找到，因为您将受到依赖关系的实际bug的影响，并且您在嘲笑时永远不会想到相同的bug。它们还测试了所有涉及到的组件，因此对下游组件的测试很少会给您带来很大的覆盖率。
单元测试是针对模拟的。编写模拟需要时间，但是测试比运行速度更快，这是测试对各种故障的鲁棒性的唯一方法，因为无论您怎么想，都无法使真正的依赖关系失败。它们也更易于调试。
我建议您从集成测试开始。创建一些脚本来设置所有必要的测试数据，这样很容易运行。从大的，现实的设置开始。这应该可以帮助你识别出易碎的成分。您可以创建更小的设置来缩小问题的来源。而不是创建模拟和单元测试，主要是作为工具，使您在集成测试中发现的错误更容易调试。并把它们作为回归测试。
https://softwareengineering.stackexchange.com/questions/200273
复制相似问题
腾讯云开发者
