在一个完整的堆栈web应用程序中自动化的测试是什么？API与UI

Question

我最近加入了一个完整的堆栈自动化团队。对于前端有一些selenium测试，API还没有自动化。我的问题或思考过程是，我是否应该谨慎地选择测试用例，以避免前端selenium与基于后端的放心测试之间的任何重叠？或者在这个场景中有重叠的测试用例是很常见的。

后端API仅由web使用，没有任何移动或其他团队使用它们。

Answer 1

当涉及到测试自动化时，您应该始终小心地选择测试。:)

正如您所说的，其中一个原因是重叠(以及与之相关的执行时间和健壮性)。澄清的一个例子：

• 您的API有10个端点，每个端点可能返回几个不同的错误消息。
• 不要将每个错误作为UI测试来测试:这将占用大量的运行时，也会导致最高的维护。是的，您将与API和单元测试有功能重叠。
• 如果每个错误的逻辑都包含在单元测试中，就不要将其作为API测试进行测试。
• 一定要为一两个错误编写一个UI测试，以确保它们由前端正确显示。但是这可能是一个通用的系统，所以如果系统正常工作，它就可以处理任何错误消息。UI测试应该被看作是探测应用程序的流，并且看到用户可以完成任务，而不是对逻辑进行深入的测试。
• 为一两个错误编写API测试，以确保后端集成从请求到响应(超出单元测试的范围)发挥得很好。或者为特定的情况编写更多的测试(例如，数据库访问起作用，这将在单元测试中被模拟)。

考虑哪些情况应该自动化的另一个原因是，从长远来看，并不是每一个自动化测试都那么有用或具有成本效益。我建议您查看YouTube，以了解Angie关于“我们应该自动化哪些测试”的演示文稿--也见https://slides.com/angiejones/which-tests-should-we-automate#/20。

Answer 2

在不同的测试级别上没有重叠测试用例的概念，

两者都是完全孤立的

仅仅因为API工作得很好，就不能保证UI运行良好。

假设您的所有API测试都通过了，但是用户无法使用UI，想象一下您的所有UI都是由于缓存的信息而工作，但实际后端却失败了。

确保更低级别的覆盖范围，如单元测试和API测试，这将确保您有更快的测试执行和构建反馈。这也将确保更快的调试，因为您的测试将更加专注于组件或功能。

在用户界面测试中，实际业务流程和错误处理测试

在每个测试级别中，我们有不同的测试范围。

单元测试；

我们不测试业务流程，而是测试组件和功能

集成测试

与其他组件的集成，集成子系统的稳定性如何，能够用更高层次的组件进行扩展。与UI类似的API

系统测试

在这里，您将测试可用性、用户交互、可视化回归、业务逻辑和流程。

因此，在不同的测试级别上没有重叠测试的概念。

Answer 3

TL;DR:您将在E2E和API集成测试用例之间存在重叠，在这两个测试用例中都使用相同的端点，这是可以的--它可以帮助您找出问题所在，如果(...when)出了问题。

当使用当前没有全面自动化测试的代码库时，从E2E(/functional)测试开始。为什么？

1. 通过UI工作流实现应用程序的自动化有助于建立用户的同理心--他们用这个做什么，他们是如何做到的？
2. 这些测试允许您检查软件实际传递的值；您的用户并不关心API调用或函数！请注意，如果您的API本身是一个产品，而不仅仅是web客户端使用的，这将是不同的。
3. 从更技术性的测试角度来看，低级测试可能需要一些更改才能实现(例如引入适当的边界来测试at)；不考虑测试的代码通常很难测试。你需要更高水平的测试来给你信心，那些改变是正确的。

这可能会导致您有太多的E2E测试，其特点是测试运行时间过长，但是现在您可以开始将测试向下推到集成和单元测试。专注于维护一组关键工作流(这可能是与您团队中的产品人员进行的一次很好的交谈--每个人都知道关键工作流是什么吗？)在E2E级别，然后将不太重要的路径和重复推到较低级别的测试。

具体来说，在API测试方面，会有很多重叠；您的E2E测试用例应该至少运行每个端点一次(如果不是，请考虑是否可以删除未使用的端点)。这种重叠是很好的，因为现在如果E2E测试失败了，但是相关的API测试通过了，您已经将问题定位到UI了。但是会有一些东西很难通过UI进行测试。通常，这些都是不愉快的途径，例如：

• 您可能在UI级别上对输入进行了验证，这样可以防止在请求无效的情况下发出请求，但是您仍然应该测试服务器端验证；
• 您可能没有指向UI中缺少的资源的链接，但仍然希望测试404。

类似地，有些东西很难通过API进行测试，并且需要大量的设置和删除；在这种情况下，进一步向下推到单元测试服务/业务逻辑层(我不建议单元测试控制器/传输或存储库/持久性层；如果它们有很多逻辑，它们可能位于错误的位置)。