API测试单层

Question

我想开始为我们的一个API编写一些API测试，但是我们看到其他API的稳定性存在很多问题，我不太确定如何处理这个问题。

为了澄清，我有一个API A，它使用API B、C、D等等。目前，我花了很多时间才发现大多数bug不是因为A，而是因为其他API的输出。最好是停止这种类型的调试，因为它会阻塞我自己的工作流程。也就是说，除非我的测试有效，否则我无法继续工作，除非其他API的另一个团队修复了它们的错误，它们才能工作。

所以我想问题是:有没有人经历过类似的情况，你是如何解决的？

我想出的一个解决方案是实现一个代理，以某种方式存储先前的响应。然后，它可以在与前面的响应进行测试检查期间，查看我们的API A是否仍然有效，然后对底层API进行新的调用，并检查它们是否仍然工作。如果它们是，那么它应该存储该响应，否则将其丢弃并发出警告。问题是，如果它还不存在，那么它的构建成本可能会很高。

Answer 1

我们有类似的设置，您的A就是我们所称的Gateway API。它调用其他API，并且可能(或不可能)添加一些附加逻辑。

如果底层API不是您的团队的责任，并且您在那里发现了缺陷，那么基本上，由于依赖第三方(从最广泛的意义上说)，您会遇到一些障碍。

至于存储响应，是的，我们这样做的所有API测试(目前几乎1000)。简而言之:我们通过C#测试方法调用API，并将json与实际响应进行比较(使用NewtonSoft JSON的DeepEquals方法)。所以我们可以在几分钟内进行1000次测试。

至于你遇到问题的情况，这有点取决于：

• 你有没有报告过你领导的测试失败(障碍)？反应如何？其他球队会优先解决这个问题吗？
• 根据以上所述，对于您的度量标准，每次执行导致失败的测试会有用吗？因为这是一个已知的缺陷。
• 你的团队会对最终的产品质量进行核算吗？也就是说，虽然底层API并不是您的责任，但您可能仍然希望对它们进行测试，以确保您的产品至少得到了高质量的输入。

编辑(澄清)：

如果您没有时间来自动化API测试，那么您所能做的就是再次正式介绍您的情况，并且清楚地表明，从长远来看，不使它们自动化将花费更多的时间。例如:手工测试每个版本需要花费50天的时间。自动化这些情况(包括设置)也需要50天，比如说每年10天的维护。所以在五年的时间里，你可以得到250天，而不是100天。别忘了，设置是最难的部分。一旦有了框架，添加测试就很容易了。因此，如果增加更多的功能，利润就会更大。

第二，扩展我们的API测试。我们有一个用C#编写的框架，可以轻松地发送请求和存储响应。因此，首先我们手动检查API结果(请求X应该总是返回响应Y)，并存储文件中使用的JSON。然后使用这些JSON文件编写一个测试方法，每次生成相同的请求，从而验证响应是否与保存响应时完全相同。

第三，如果没有自动测试，您实际上每次都要花费大量的时间来测试所有的API，看看错误来自何处。问题是，你需要对这个问题做一个根本原因的分析吗？再一次，向你的经理表明，你在类似的问题上浪费了很多时间。

Answer 2

我在一个相当相似的堆栈上工作，我会考虑从“最低”层开始，然后继续测试A。

因此，在这种情况下，我的目标是测试B、C和D，前提是您正在对另一个组API进行一些测试，但是如果您不负责B、C和D，只需设计测试，就可以充分保证您值得在A上运行测试。

至于检查以前的响应，像SoapUi这样的工具允许您将当前响应存储为预期的结果，然后在以后运行测试时重用。

Answer 3

很好，我想停止这种调试。

你是个测试师。您不应该进行任何调试，并调查测试失败的根本原因(唯一可接受的调试类型是手动再现测试流，以确保测试代码中没有逻辑错误)。这是开发人员的工作。而且你在做黑匣子测试。您不应该关心当前测试的"box“(API A)的具体实现是什么。

除非我的测试有效，否则我无法前进。

这是一种相当糟糕的做法。你有API。您应该有API规范。因此，拥有API规范(特别是如果我们讨论的是REST，根据您的问题是如何标记的)使得编写没有任何工作服务的测试变得非常容易。因此，只需编写测试，就像服务正常工作一样，一旦测试在测试环境中失败，就会引发bug。