API 测试 - 采用的最佳策略

Question

我有几个问题要问你。在我提出问题之前，让我提供一些细节。

最近我参与了 Rest api 测试自动化。 我们有一个单独的 api 来获取资源，（这个 api 基本上用于我们的 web 应用程序 UI 中，用于不同的业务工作流程来获取数据） 尽管它是相同的资源 api，但实际端点会因不同情况而有所不同 .即在 api url 中传递的查询参数会根据业务工作流程而有所不同。

例如像

`./getListOfUsers?criteria=agedLessThanTen ../getListOfUsers?criteria=agedBetweenTenAndTwenty ../getListOfUsers?criteria=agedBetweenTwentyAndThirty 等

由于只有一个 api，并且业务流程不需要它，因此我们没有在 api 之间链接请求 因此，测试只是针对单个端点并验证响应内容。 响应根据提供的测试数据进行验证。因此，测试数据文件具有在每个特定端点上命中时期望的用户列表。 即测试文件就像一个静态内容，每次我们点击它时都将用于检查响应内容...... 如果从服务器获取的实际响应与我们提供的测试数据有偏差，这将是一个失败。 （也有没有内容响应的测试，没有身份验证等）

此测试可以确认端点是否正常工作以及响应内容是否良好。

我的实际问题是这里的测试策略或业务覆盖，

1. 这样在api端点上的单次点击是否足够......

2. 或者相同的端点是否应该在其他情况下再次被击中，尤其是当上面给出的端点示例实际上相互补充时 以及可能发生的回归问题，可以在其中任何一个中捕获吗？

3. 如果 api 端点相互补充，添加更多测试，这是否只是重复测试/更多维护/以及以后的其他问题，我们应该避免它吗？ 如果它没有给出价值？
4. 关于覆盖范围的 API 自动化的总体趋势是什么？ .我相信它应该被用来测试业务集成流程，如果需要的话，还有场景 但是对于这种情况，真的需要吗
5. 我们也应该牢记这一点吗？自动化不是要取代手动测试，而只是补充它。 并尝试自动化所有可能的场景不会带来价值，只会在以后给维护带来麻烦？

谢谢

Answer 1

这样在api端点上的单次点击是否足够......

可能不是，对于每一个你想要验证各种边缘情况（例如最低和最高值、最长字符串）、负面测试（例如只允许正面的负数）和其他测试根据业务和 实现逻辑。

关于覆盖范围的 API 自动化的总体趋势是什么？ ... 自动化不是要取代手动测试，而只是补充它。并尝试自动化所有可能的场景不会带来价值，只会在以后给维护带来麻烦？

如果您以模块化方式构建测试，那么维护就不再是一个问题，无论如何您都需要实现每个 API，并且上面的逻辑和测试数据应该是测试系统中不太复杂的部分。

确实，您通常希望有一个包含许多单元测试、一些集成测试和较少端到端测试的测试金字塔，但在这种情况下，由于不涉及 UI，最终用户只是另一个软件模块，并且执行时间对于 REST API 相对较短且稳定性相对较好，那么拥有更广泛的端到端测试层可能是可以接受的。

我在上面使用了很多条件，因为只有你可以根据真实系统评估情况。

如果可能，请考虑动态生成测试数据，而不是使用文件中的硬编码值，这将需要在测试中实现并行逻辑，但会使维护和覆盖变得更容易。