同时进行集成和验收测试的效率缺陷(自动化)

Question

单元测试的优点对我来说是显而易见的，它们是由开发人员自己完成的(无论是测试还是代码优先)，并且是自动化的。

我有点不确定的是，当团队已经由一个专门的测试人员组成时，开发人员是否也应该进行集成测试，该测试人员会尽可能地自动化，并对整个系统进行黑箱测试(端到端测试或更常见的所谓验收测试)。

关于简短的背景信息，更多细节：

示例集成测试(MVC webapp)

• 安装程序:在测试安装过程中，只有控制器本身和控制器下面的层被引导。没有什么是被嘲弄的。
• 测试条目:裸控制器，大多数情况下控制器入口点是带有参数的方法(例如Spring )，可以本地执行。在测试夹具期间不涉及浏览器。
• 断言目标:模型数据和视图名称被断言为直接输出。间接产出(例如写入数据库的数据)也可以断言。呈现的有效负载(通常是HTML)被完全忽略。

示例验收测试(MVC webapp)

• 安装程序:整个webapp都是引导的(就像从最终用户那里看到的一样)。
• 测试条目: HTTP调用本身。浏览器可以作为测试执行器(例如硒)使用。
• 断言目标:测试输出是完整的呈现响应(HTML和其他工件，如javascript)。数据库中的断言(例如，插入的数据)也可以包括在内。

双重测试(集成+验收)

当包含这两种测试样式时，我看到了主要问题：

• 控制器测试接近一般的系统行为(例如提交登录表单、密码验证、成功登录)。这与验收测试的效果非常接近。最终，“双重测试”可能会发生，这是非常低效的。
• 控制器是比较白盒的测试，并且往往很脆弱，因为它们依赖于较低层的许多依赖项(与非常细粒度的单元测试不同)。由于这种设置维护控制器测试的工作量很大，因此，将整个应用程序作为黑匣子启动的验收测试更简单，而且更接近于生产。

以上两点得出的结论是，如果您的测试人员具有良好的自动化策略，那么您应该跳过由开发人员完成的集成测试。他们应该更加关注单元测试。

你认为如何？你能解释一下你的测试策略吗？你有好/坏的经验，包括这两种测试风格吗？

(谢谢你阅读我的长篇问题;)

编辑:作为端到端的术语，验收测试似乎是比较常见的术语，所以我改变了术语。

Answer 1

我们在我的工作中接受TDD。

当我第一次开始工作的时候，我被告知我可以执行我想要的任何政策，只要这项工作能够以及时和可预测的方式完成。在过去做过单元测试之后，我意识到我们经常遇到的问题之一就是集成错误。有些可能需要相当长的时间才能修复，而且常常是个惊喜。在扩展应用程序的功能时，我们会遇到一些微妙的bug。

我决定通过更多地关注我们应该交付的最终结果特性来避免那些我在过去遇到的问题。我们将编写测试验收行为的测试，不仅在单元级别，而且在整个系统级别。我想这样做是因为在一天结束的时候，我不关心这个单元的正常工作，我关心的是整个系统的正常工作。我们发现进行自动验收测试有以下好处。

• 我们从不让恢复最终用户的功能，因为它是显式测试的。
• Refactor更容易，因为我们不需要更新大量的单元测试。我们只需要确保我们的验收测试还能通过。
• “单位”的整合被隐含地包括在内。
• 这些测试成为所需最终用户功能的非常清晰的定义。
• 集成问题暴露得更早，不太令人惊讶。

以这种方式做这件事的一些取舍

• 测试在使用模拟、存根、夹具等方面可能更加复杂。
• 测试对于缩小哪一个“单元”有缺陷不太有用。

我们还使我们的测试套件可以通过一个连续集成服务器运行，该服务器标记和部署包。它在每次提交时运行，就像在大多数CI设置中一样。

关于你们的观点/关切：

安装程序:整个webapp都是引导的(就像从最终用户那里看到的一样)。

我们倾向于做出的妥协之一是在相同的进程空间ala单元测试中运行测试。我们的入口点是应用程序栈的顶部。我们不用费心去尝试作为服务器运行这个应用程序，因为这增加了复杂性，也没有增加太多的覆盖率。

测试条目: HTTP调用本身。可以使用浏览器作为测试执行器(例如Selenium)。

我们所有的自动化测试都是由模拟HTTP、POST、PUT或DELETE驱动的。不过，我们实际上并不使用浏览器，而是像特定HTTP调用在工作中映射的方式那样，调用到应用程序堆栈的顶部。

断言目标:测试输出是完整的呈现响应(HTML和其他工件，如javascript)。数据库中的断言(例如，插入的数据)也可以包括在内。

我认为这是自动验收测试真正闪耀的地方。您断言的是要保证您正在实现的最终用户功能。

控制器测试接近一般的系统行为(例如提交登录表单、密码验证、成功登录)。这与端到端测试的效果非常接近。最终，“双重测试”可能会发生，这是非常低效的。

实际上，我们很少进行单元测试，而且几乎完全依赖于我们的自动化验收测试。因此，我们没有太多的双重测试方式。

控制器是比较白盒的测试，并且往往很脆弱，因为它们依赖于较低层的许多依赖项(与非常细粒度的单元测试不同)。由于这种设置，维护控制器测试是高难度的，端到端测试，其中整个应用程序是作为黑匣子启动的，更简单，而且更接近于生产。

它们可能有更多的依赖关系，但这些依赖可以通过使用模拟和固定来减轻。我们通常还使用两种执行模式来实现我们的测试。非托管模式(其中测试完全连接到网络、dbs等)和托管模式(测试与非托管资源一起运行)。尽管您的断言是正确的，即测试可以进行更多的努力来创建和维护。

Answer 2

开发人员应该对他更改/实现的部分进行集成测试。在集成测试中，我的意思是他们应该看看他们实现的功能是否真的像预期的那样工作。如果你不这样做，你怎么知道你刚刚完成的工作真的有效？单元测试本身并不是最终目标--重要的是产品。

应该这样做，以加快错误的发现。毕竟，集成测试需要很长时间才能执行(至少在我的公司，因为复杂性，执行所有集成测试需要1-2天)。越早发现bug越好。

Answer 3

具有集成测试(实际上也包括单元测试)的测试行为也是由系统测试测试的，通过缩小缺陷的位置来帮助调试。如果您的系统有组件a并且失败了系统测试用例，但是程序集a通过了类似的集成测试用例，那么缺陷可能在组件C中。