API测试-采纳的最佳策略

Question

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

最近，我参与了Rest api测试自动化。 我们只有一个Rest API来获取资源（该API基本上在我们的Web应用程序UI中用于不同的业务工作流来获取数据） 尽管使用相同的资源api，但实际端点在不同情况下也会相应变化  。即，根据业务工作流程，在api网址中传递的查询参数会有所不同。

例如

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

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

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

我的实际问题是关于测试策略或业务范围的，

1. 在api端点上单击一次是否足够？

2. 或同一端点是否应在其他情况下再次命中，尤其是当以上给定的端点示例实际上相互补充时 还有可能发生的回归问题？

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

谢谢

Answer 1

  

在api端点上单击一次是否足够？

可能不是，您可能希望根据业务和针对每种情况验证各种边缘情况（例如，最低和最高价，最长的字符串），否定测试（例如，负数仅允许使用正数）和其他测试实施逻辑。

  

关于Covergae的API自动化的总体趋势是什么？   ...    自动化并不是要取代手动测试，而只是为了补充它。并试图使每种可能的方案自动化都不会带来价值，只会在以后给维修带来麻烦吗？

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

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

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

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