【问题标题】:Automated Debugging of failed API test cases自动调试失败的 API 测试用例
【发布时间】:2018-10-16 10:54:18
【问题描述】:

我们的应用程序有 35 个网络服务器和大约 100 个不同的 API 在上面执行。

这些 API 在内部相互调用并独立执行。 我们有大约 30 个 API 的自动化测试用例,但我们的一些测试失败了,因为被测试的 API 所依赖的其他 API 失败。

那么我们如何通过我们的自动化测试用例知道每次测试失败的原因呢?

示例场景:

我们有一个测试用例来验证获取用户银行账户余额的 API。

现在我们通过 rest Assured 访问这个 API 并尝试断言预期的输出。该请求首先到达账本服务器,该服务器进一步在内部命中 auth 服务器以验证请求的真实性,然后命中,然后命中计数器服务器以记录 fetchBalance 请求,然后命中其他几个服务器以获取用户的正确余额,然后响应我们的要求。

但问题是这可能会在任何情况下中断,如果它中断,分类帐服务器总是返回相同的错误字符串 - “Something failed underhood”。现在调试成为一个挑战。我们必须去每个服务器,必须搜索日志才能知道实际原因。

我想编写一个解决方案,可以跟踪此请求的完整生命周期并报告它实际失败的位置。

【问题讨论】:

  • 你能分享一个 API 测试的例子吗?测试失败的原因是什么?您是否收到意外的响应代码?
  • 示例添加到说明中。请看一下

标签: testing automated-tests


【解决方案1】:

对于这个问题,您应该了解最常见的故障原因。然后你可以根据失败的原因实施策略。

示例:如果您向服务器发送了一个请求,API 可能会有一些安全验证和一些处理步骤以及与不同组件的集成。 如果您可以识别一些故障点并可以针对它实施检查点。

  1. 请求在安全验证时失败。您有可能的错误代码,然后根据该代码编写逻辑
  2. 您的处理步骤失败,可能有原因
  3. 如果集成点出现故障,那么也一定有一些错误代码。您可以围绕它们实现逻辑

【讨论】:

    【解决方案2】:

    在每次与服务器交互之前验证数据的状态。例如

    assert expression1 : expression2
    

    如果expression1 失败,expression2 将被执行。 (这是一个 Groovy 示例,但您可以根据需要对其进行修改。)

    expression2 消息示例可能类似于:“尝试发送 '某某' 请求时发生故障!”。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-05-22
      • 1970-01-01
      • 2014-02-02
      • 2011-03-29
      • 2018-12-02
      • 1970-01-01
      • 1970-01-01
      • 2022-10-07
      相关资源
      最近更新 更多