java - 如何测试重定向样式API

Question

我有一个要自动测试的API。我目前正在用Java执行此操作，但我认为问题与语言无关

一些上下文：

主要思想是以类似于this demo的方式与支付系统集成。

主要流程如下：


您结帐购物车，然后点击付款按钮
您的网络应用将使用付款api发起交易，您会获得一个参考号。现在，该参考号将用作该付款的查询参数，您将被重定向到该网站。
客户付款后，您将被重定向回Webapp，您可以在其中检索交易并显示结果


我的主要问题是如何针对这种情况进行自动化集成测试？我的主要想法是：


将存根或嘲笑用于事务引用和响应。但这更符合单元测试而不是集成测试。我不介意这样做，但是我想先探讨一下集成测试。
也许我应该尝试某种自动填写表格的方法。因此，在检查重定向网站的工作之后，我将对重定向url进行curl类型的请求，并对curl类型的post请求进行请求。
使用某种Web测试工具（例如硒）或类似工具。

Answer 1

我认为答案取决于集成测试的目标和范围，以及适用于集成测试的合适平台的可用性。这里有一些想法可能会帮助您做出决定，首先将重点放在确定测试目标上，然后再针对适当的测试工具提出任何建议。

（我假设您在运行测试时不希望实际使用支付服务的生产版本）

测试使用“真实”支付服务的集成：最强大的集成测试形式是您实际调用真实支付服务作为测试的一部分，因为这将测试应用程序中的代码，支付服务中的代码，以及两者之间的交流。但是，这要求您具有始终运行的付款服务测试版本，并且可用性越低，测试变得越脆弱。

如果付款服务是由您的团队/部门/公司所有，那么这可能还不错，因为您具有必要的控制权以确保始终可进行测试。但是，如果是供应商系统，假设他们控制服务的测试版本，那么如果他们不能有效地维护该测试服务以提供高级别的可用性，那么您将面临脆弱性问题。经验，他们通常不会这样做，经常会出现问题，例如服务没有足够频繁地升级，或者他们的支持团队不会注意到服务是否出现故障）。

您可能会遇到的一种情况是，供应商可能会提供始终在运行其软件的预发行版本的测试服务，以便其客户可以在其软件的新版本发布到生产环境之前对其进行测试并标记任何内容。整合问题。如果他们这样做，那肯定会影响您的决定。

使用“假”支付服务测试集成：一种替代方法是构建一个伪造的服务版本，在与真实服务相似的环境中运行，并使用相同的API进行集成测试。可以根据您的喜好简单或复杂，范围从仅对每个请求返回一个固定响应的超薄服务，到可以返回一系列不同响应（成功，失败，未找到服务等）的服务。 。），具体取决于您的测试目标是什么。

这样做的好处是不那么脆弱-因为它在您的控制之下，因此可能具有更高的可用性，并且它也将更容易保证从测试中寻找的服务的响应。而且，它可以更轻松地构建更智能的测试用例（即，用于测试如果服务不可用或代码报告服务负载过重且无​​法处理您的事务时代码如何响应的测试）。缺点是可能需要进行更多工作，并且在运行单元测试时没有在真实支付服务中使用代码。

什么是测试服务的最佳方法是什么？：这是高度特定于上下文的，但是在平衡测试有效与服务的集成以及最大程度地降低风险之间达成平衡的基础上，我认为这是一种理想的测试方法。通过脆弱的测试影响开发人员的生产力。


如果供应商提供了其服务的测试版本，请编写一个小型测试套件，以验证您是否从其服务中获得了预期的响应，并每天运行一次。这将带来验证您自己关于服务行为的假设的好处，而不会在其余测试中引入脆弱性。适当的工具将是完成这项工作的最简单工具（即使是可以通过电子邮件将任何问题发送给您的shell脚本，在这里也绝对可以），只要它是可维护的，到最后，这些都不是开发人员的测试预计将定期运行。
对于我的端到端测试套件（即一个部署系统的测试版本并对其进行端到端测试的套件），我将构建可与该测试系统一起部署的伪造的支付服务版本，并使用该版本供测试用。这使您可以使用稳定的支付服务端点完全端对端地测试自己的系统。这些端到端测试应包括无法找到服务，报告失败等情况。鉴于这是端到端测试，因此Selenium之类的工具将适合通过Web UI驱动的测试。
对于其余的自动测试，我将模拟对支付服务的调用。一种非常简单的方法是将所有对支付服务的调用封装在系统的单个组件中，在测试过程中可以轻松地将其替换为模拟版本（例如，使用依赖注入）。