2

在你跳到答案之前，让我们定义我的意思（注意你可能有不同的定义，这是问题的一部分，但这是我正在使用的）

模拟测试又名基于行为的测试——测试代码是否正确，即测试验证行为。所有合作者都被嘲笑。

单元测试--- 专注于系统的一小部分（如类）的低级测试。当我们使用模拟测试时，协作者会被模拟。

集成测试---测试系统的两个或多个部分（如两个类）的交互。被测组件不会被模拟。

系统测试--- 将系统作为“黑匣子”进行测试，即从无权访问系统内部的用户的角度进行测试。使用真实组件（数据库、http 等）

我慢慢意识到，当以这种方式完成单元测试时，您可能不需要集成测试。

  • 基于行为的单元测试应该验证组件之间是否正确通信
  • 系统测试应该捕捉到使用真实组件的错误

当系统测试失败时，集成测试成为可选的故障排除工具（因为它们更细粒度）。（但是，您可能会争辩说，除了偶尔出现的边缘情况外，具有良好日志记录的系统测试就足够了。）

我错过了什么？

更新：“足够”是指这些单元测试+系统测试将捕获单元+集成+系统测试会发现的所有错误。

更新：“足够”是指单元+集成+系统测试会发现单元+系统测试找不到的错误吗？我真正在寻找的是一个显示集成测试是必要的示例。

4

3 回答 3

0

这是一个可能的答案。（老实说，我认为这是一个复杂的问题，真正的答案是“取决于”）。根据这个视频的答案是不需要集成测试（嗯，有点......标题具有误导性）：

“JB Rainsberger - 综合测试是个骗局”

http://vimeo.com/80533536

这个答案背后的原因是

  • 孤立的单元测试（模拟协作者的单元测试）实际上应该是协作/合同测试。
  • 在协作测试部分，您 1) 验证期望，2) 验证组件是否正确处理来自其协作者的答案。

例如：被测对象是一个地址簿，它使用一个特殊的地址收集对象来存储地址列表。（好吧，这是一个非常愚蠢的例子。）在 1）中，您需要验证地址簿是否在应该（期望）时调用了集合。在 2) 中，您需要验证地址簿在不同的收集状态下工作——无地址、1 个地址、一些地址、许多地址等。（实际上，您可能会将这些限制为业务用例。）这是基于状态的测试，通常使用协作者的存根。

  • 在合同测试部分，您为每个协作测试添加测试。被测对象现在是地址收集对象。对于1），期望，它可以回答问题吗？对于2），答案处理，它可以正确回答吗？

  • 每个对象都有针对其合作者的协作测试。每个协作者都有匹配的合同测试，但也有自己的协作测试集。这形成了架构的“环形模型”。“外层”与外部服务（数据库、http 等）对话。您对这些使用集成测试。

所以要回答我的问题，简短的回答是“不”。集成测试很脆弱，而且通常很复杂。然而，与其完全消除它们，更好的策略似乎是将它们最小化。

另外：这种协作/合同测试方法可能有其自身的一系列问题。匹配测试是耦合在一起的——一个变化需要另一个变化。使用存根会导致误报。直观地说，这种类型的测试似乎具有不小的维护成本。

于 2015-01-01T19:24:12.843 回答
0

我慢慢意识到，当以这种方式完成单元测试时，您可能不需要集成测试。

通常，系统测试（如您定义的那样）在自动化时会比集成测试运行得慢得多。如果您有自动化集成测试来验证与自动化系统测试相同的内容，那么集成测试应该会更快地失败（或成功）。

所以这取决于你对“需要”的定义。不同类别的测试之间有重叠不会造成伤害，并且如果它们可以帮助您更快地发现错误，则可以提供价值。这取决于我认为的价值大小（两者的投资回报率是多少）。

于 2015-01-01T01:07:35.360 回答
0

首先，我看不出您所描述的单元测试和模拟测试之间的区别。

正如@danludwig 建议的那样，这取决于您的投资回报率。如果您正在编写从 youtube 的播放列表中下载所有电影的简短脚本，那么您可能根本不需要任何测试。当您在全球范围内购买飞机控制系统时，您提到的绝对是不够的（降级测试，故障测试，可能还有更多）。

根据我在统计 Web 应用程序方面的经验，如果您有很多单元测试，那么您不需要很多集成测试。有时您会预见到潜在的集成问题并编写所需的测试，有时您的测试人员会在 UAT 上发现问题，然后您将添加所需的测试。但集成测试的数量仍将远远少于单元测试

关于黑盒测试：如果您的应用程序与人类交互，那么您必须有测试人员进行手动测试（css、pdf 渲染等）。他们还将发现测试单元之间的通信错误（对于新的集成测试）

要记住的事情：

  • 黑盒测试的重要部分也是渗透测试
  • 并记住性能测试
于 2015-01-03T21:05:07.810 回答