自动化集成测试是什么样子的？

Question

我知道测试自动化金字塔、基于单元/集成/gui的自动化测试。我的问题是，集成测试是什么样子的？我总是假设像登录场景一样，我们会使用GUI自动化来处理它，但是在更多的阅读之后，我不太确定？

选项A

• 准备WebDriver &导航到登录
• 以用户身份登录
• 断言用户已登录

选项B

• HTTP /Login
• HTTP邮政凭据
• HTTP /Index
• 断言用户已登录，也许他们的名字在响应体HTML中？

我们应该总是在这里选择备选方案B吗？在这种情况下，使用像“放心”之类的东西而根本不使用Selenium？

您如何决定通过GUI和服务/API层做哪一个，像这样？显然，API层看起来更加健壮，页面上元素的更改不会中断测试等等，但是另一方面，如何知道登录按钮本身是否正常工作呢？

Answer 1

传统的测试级别(单元/集成/系统/…)(测试)通常不声明技术实现是如何发生的。在健壮性、维护性、测试覆盖率和性能方面，选择合适的测试界面几乎都是一种权衡。

如果GUI不太复杂，我将选择选项B并对API进行测试；特别是如果GUI代码只是在GUI和API之间添加了一些粘合剂的话。您仍然可以使用Galen框架和/或硒等工具单独测试GUI。

相关的艾伦·理查森的博客文章提出了以下经验规则：

• 构建一个系统模型，这样您就可以识别集成点和“孤立的”共享功能。
• 在可能的最低点测试孤立的功能。
• 回到更高(或“对等”)的集成和抽象级别，并从集成系统的角度考虑系统。
• 在较高(或“对等”)抽象级别上寻找唯一的功能，您将需要在那里测试它们。
• 如果您孤立地使用独特的功能--通过模拟集成系统--那么您可能需要从技术风险的角度来看待这个问题，并决定在集成过程中是否需要或需要进行多少练习。

Answer 2

您可以在不同层次上测试各种组件: web服务、web GUI、数据库等:单元、集成、验收/功能。

单元测试与集成测试的主要区别在于测试运行的上下文。单元测试可以单独运行，不需要集成构成整个堆栈的任何其他组件，因此很容易直接针对代码作为构建的一部分运行。有时，它们使用模拟来模拟其他依赖组件。

集成测试专门针对组件及其依赖项之间的集成点。通常，集成测试不能直接在构建机上运行，因为它可能需要实际安装/部署的应用程序，尽管在使用诸如Docker这样的容器时，您可以在部署了应用程序并对其运行测试的容器中创建一个容器的实例，这样做的问题越来越少。与完全接受测试相比，集成测试的优点是可以更快、更低级别地进行测试--方法和代码块(类似于单元测试)。如果您将集成测试移动到直接针对UI执行，那么您实际上并没有得到任何东西，所以最好跳过它们一起调用那些验收测试。

根据您的描述和关于GUI与业务逻辑紧密集成的注释，我建议对GUI进行以下测试：

• 单元测试:测试方法中的特定方法和代码块的Javascript单元测试。
• 集成测试: Javascript测试在包含依赖组件(数据库、web服务、队列api等)的功能(或大部分是功能)应用程序的上下文中运行。
• 验收测试:针对UI运行的WebDriver测试