跳到主要内容

接口回归测试利器：AREX

· 阅读需 20 分钟
Haibing Wang

AREX 结合了 Postman + Mock + 比对测试，实现了从接口调试到接口数据 Mock，再到接口自动化测试和接口回归测试的闭环工作流。借助 AREX，开发和测试人员可以各取所需，协同合作，实现更高效的软件开发和测试。

背景​

在整个软件开发生命周期中，软件测试工作始终贯穿其中，包括开发过程中、代码合并前的集成测试以及上线后的持续集成测试。为保证软件质量的全面性和稳定性，开发和测试人员都需要不断重复执行以下测试任务：

  • 接口调试

接口调试是开发人员在完成开发后进行快速自测的一种有效方式，通常可以使用一些接口调试工具，如 Postman、ApiFox 等向接口发送请求并观察返回结果，调试和解决接口实现中出现的问题。

  • 接口自动化测试

由测试人员准备测试数据、编写测试用例并使用 JMeter 等工具编写自动化测试脚本，自动化执行测试用例，以确保代码的质量和稳定性。

  • 接口数据 Mock

Mock 在英文中含有模仿的意思，顾名思义，数据 Mock 就是通过构造假数据来达到测试的目的。采用 MockJS 等工具 Mock 接口数据，可以节省数据构造的时间，这对后期进行回归测试工作的效率提升至关重要。

  • 接口回归测试

回归测试旨在确保软件在经过修改、添加新功能、优化性能等后仍然能够正常工作，在软件的快速迭代开发中尤为关键。在接口回归测试中，通常需要构造数据、维护数据、测试用例及接入 CI/CD 流程。

对于一个产研团队来说，若要实现上述研发过程中所有环节的需求，至少需要使用四五种不同的工具才能满足，在实际工作中带来的问题也可想而知：

  1. 复杂性增加：使用多个工具可能会导致研发流程变得更加复杂，需要更多的时间和精力来协调和管理，团队无法在同一套系统中进行协作，导致各种沟通不及时、配合低效。

  2. 高风险：使用多个工具也意味着需要将数据从一个工具同步到另一个工具，这可能会增加出错的风险。

  3. 高成本：每个工具都有自己的使用方法和特点，需要花费时间来学习和掌握，后期也需要花费更多的时间来维护和更新工具，特别是在长期的项目中。

  4. 回归测试复杂度增加：对于需要快速迭代的复杂系统，需要频繁地维护数据和用例，无论是脚本化维护还是手工维护，都需要花费大量的精力。业务复杂度高时，回归测试的复杂度可能会日益增高，这可能需要更多的时间和资源来完成。

  5. “自动化”测试侧重于“自动化”执行，但维护工作依旧是“手工”，工作量非常大。

试想一下，如果有一款工具可以实现上述所有功能，那不是可以大大简化研发流程，提高测试效率，降低维护成本和出错率？今天我们要介绍的就是这样一个工具：AREX。

什么是 AREX​

AREX 是一款开源的基于流量录制回放的自动化测试平台（项目地址：https://github.com/arextest），结合了 Postman + Mock + 比对测试，不仅提供了接口测试功能，更是通过 Java Agent 字节码注入技术，在生产环境录制和存储请求、应答数据，在测试环境回放请求和注入 Mock 数据，并存储新的应答，以此来达到自动录制、自动回放、自动比对，为接口回归测试提供便利，实现了从接口调试到接口数据 Mock，再到接口自动化测试和接口回归测试的闭环工作流。借助 AREX，开发和测试人员可以各取所需，协同合作，实现更高效的软件开发和测试。

自动化回归测试平台 AREX 架构图

接口调试（Postman）​

AREX 不仅能支持 Postman 大部分的接口调试功能，还提供了强大的接口用例功能。

接口测试

接口用例功能​

AREX 可以为同一个接口请求保存多个场景下的接口用例，每个用例都将自动继承当前接口请求下的配置，如 URL、请求方式及 Parameters、Header、Body 及前置脚本（Pre-request Script）等。通过继承父节点的接口请求配置，测试用例不需要一一重新定义接口的请求参数及前置脚本，后续再次调试时可直接运行接口用例，从而减少测试用例编写的工作量和时间。

AREX 还提供了测试用例管理功能。目前可以对测试用例添加标签（Add Tag）进行分类，后期将增加通过标签搜索用例的功能，方便管理。另外可以为用例添加描述，提高用例可读性，让协作者更容易理解测试用例的目的和预期结果，并且能更好地把握测试内容。

导入、导出用例（开发中）​

各个测试团队都有自己的测试习惯，强制迁移到一个新的测试工具，有很大的迁移成本。AREX 后续将陆续支持各种格式的测试用例导入、导出，届时旧工具中的众多用例可以一键迁移到 AREX，无需再次新建项目，同时也可以将 AREX 录制到的用例导出，帮助测试团队降低迁移成本。

目前 AREX 正在支持 Postman 导出的用例导入，如需支持其他格式的用例导入，可以在 Github 上提交 Issue，与社区共建。

固化的测试用例也支持导出，目前支持 Postman 格式的用例（JSON格式）。

接口回归测试（流量录制回放 + Mock + 比对测试）​

AREX 采用 Java 的 instrument 技术实现了无代码侵入的数据采集和自动化 Mock，在进行回放时会使用录制过程中采集到的数据进行 Mock，代替真正的数据访问，并不会产生真正的外部交互（如 DB 的写入、其他第三方服务的调用），避免了回放测试中脏数据的写入。同时支持各种主流技术框架的自动数据采集和 Mock，包括数据库 redis 等，并且支持了本地时间、缓存等数据的 Mock，回归测试时可以在测试环境完美还原生产执行时的数据环境。

如果用户对 Mock 的数据需要进一步了解，可以在回放界面找到指定的用例，查看 Mock 数据和修改 Mock 数据。

接口回归测试，不需要准备测试用例、测试数据、接口 ASSERT，只需安装 AREX Agent，就可以全部从生产环境获取最新的请求，最新的数据，使用比对差异来验证最新的代码：

  • 支持录制生产请求应答
  • 支持录制接口的外部请求和应答，包括http请求、数据请求、redis 请求等
  • 支持自动比对接口应答的差异，外部请求的请求差异
  • 支持回放请求和 MOCK 外部请求

步骤一：安装 AREX 服务。

git clone https://github.com/arextest/deployments.git
cd deployments
docker-compose up -d

步骤二：将你的被测试应用生产环境的运行方式修改成如下的命令

java -javaagent:/path/to/arex-agent-0.1.0.jar -Darex.service.name=your-service-name -Darex.storage.service.host=[storage.service.host:port](storage.service.host:port) -jar your-application.jar

其中：

  • /path/to/arex-agent-0.1.0.jar 需要修改为 arex-agent-0.1.0.jar 文件在你服务器中的实际路径
  • your-service-name 需要修改为你被测应用的名称
  • [storage.service.host:port] 需要修改为数据存储服务的地址和端口号
  • your-application.jar 需要修改为应用程序的 jar 包文件名

或者在环境修改环境变量

export JAVA_OPTS="-javaagent:/path/to/arex-agent-0.1.0.jar -Darex.config.path=/path/to/arex.agent.conf"

步骤三：访问 AREX 前端页面，在 Replay 模块，选择到刚才搭载过 AREX Agent 的服务（即上文的 your-service-name）。

步骤四：选择回放，输入你测试环境的接口地址，开始执行所有录制的接口测试用例。

回放完成后，会生成详尽的回放报告，可以很直观地看到回放通过率、接口通过率，以及每个接口下的详情。

流量回放测试报告

出现回放失败的接口可以点击查看该接口下回放失败用例的比对结果，AREX 在最新版本中将比对结果进行了可视化展示，方便定位问题。

录制回放比对结果

还有一种更简单的方式，不用安装 AREX 各种繁琐的服务组件，只需通过 ArexCli 启动本地模式：

git clone https://github.com/arextest/arex-agent-java.git 
cd arex-agent-java 
mvn clean install  
java -jar "./arex-cli-parent/arex-cli/target/arex-cli.jar"

运行后进入如下界面

支持的命令如下:

  • ls：查看录制的所有case。

    • [option: -o/--operation] view all cases under the specified operation

  • replay：回放录制好的数据并对比差异。

    • [option: -n/--num] replay numbers, default the latest 10
    • [option: -r/--recordId] single replay available for local debug

  • watch：查看回放结果及差异。

    • [option: -r/--replayId] replay id, multiple are separated by spaces

需要注意的是，在本地模式中，AREX 使用 H2 作为本地存储保存测试数据，不再依赖配置服务和存储服务。同时，你将无法使用 AREX 的前端界面。

接口自动化测试​

AREX 的自动化测试实际上就是通过将多个接口测试用例有序地组合在一起后进行批量运行，以测试一个完整的业务流程。

接口自动化测试

利用 AREX 工具进行接口自动化测试的一大优势在于，无需手动编写大量的测试用例，海量的线上真实请求即可轻松满足覆盖率，你可以选择直接固化已经录制好的接口用例，或通过强制录制的方式固化你所需要的接口用例。

AREX 固化用例​

AREX 可以将搭载过 AREX Agent 的应用在线上真实发生的请求，包括其 Mock 数据通过一定的采样频率进行录制。如果需要将某些重要用例固化下来，作为之后回归测试必须执行的项目，只需在回放报告中，找到需要的用例，点击保存，选择目标目录，即可将用例固化下来，表现为常规的测试用例（区别在于报文头里边有arex-record-id标识）。

AREX 强制录制​

如果某些重要的测试用例没有录制下来，则可以通过手动强制录制来完成固化。

在 AREX 接口测试界面中，点击 action.record 图标，在请求 Header 中添加 Key: arex-force-record，Value: true，点击 Send 发送请求。返回报文的 Header 中会生成 Record ID，Key:arex-record-id，Value:录制 ID。点击 Save 即可保存该条录制用例。

强制录制流量

通过 AREX 录制或强制录制固化下来的测试用例，相较普通的测试用例会多一个 Mock 数据的模块，即 AREX 在录制过程中 Mock 到的所有数据（左侧是 Mock 到的主接口及外部调用的请求报文，右侧是对应的响应报文）。

Mock 数据修改

AREX 现在支持对 Mock 数据进行编辑修改。比如你需要验证本地环境下开发的新功能，如果对 Mock 的数据不满意，则可以手动修改以满足新功能的需求。

自动化测试 Pipeline​

CI/CD 是现在测试团队的标配， 支持接入 CI/CD 是必须的功能。AREX 支持放出 WEB Hook 接口，由外部系统（比如 Jenkins）触发执行。

  1. 在 AREX 中创建一个测试任务，创建测试用例和测试环境，确保测试任务能够在 AREX 中正常运行。

  2. 在 Jenkins 中创建一个新的 Job（任务），用于触发 AREX 测试任务。

  3. 在 Jenkins 的 Job 配置中，添加一个 “Execute shell” 步骤，用于执行 CURL 命令，调用 AREX 的 Web Hook 接口。CURL 命令可以通过以下方式来构造：

curl -H "Content-Type: application/json" -X POST -d '{"test_id": "test_task_id"}' https://arex-webhook-url

其中，arex-webhook-url 是 AREX 的 Web Hook 接口 URL，可以在 AREX 点击 Start replay 开启回放测试时获取。

自动化测试 Pipiline

  1. 配置 Jenkins Job 的触发器，使得 Job 可以在特定的条件下自动运行。例如，可以设置为每次提交代码到源代码仓库时触发。

  2. 运行 Jenkins Job，检查测试任务是否被触发，并且测试结果是否正常。

通过上述步骤，我们可以将 AREX 集成到 Jenkins 中，实现自动化测试和持续集成。

接口测试左移​

传统软件测试流程通常包括需求评审、编写测试用例、准备测试脚本、开发提测后执行测试、提交问题、回归测试等步骤。这种流程存在的问题在于，测试人员处于非常被动的状态，往往需要等待开发人员完成代码开发、正式提测后才能开展测试工作，从而影响整个开发流程。

特别是在敏捷开发和持续交付等开发模式广泛应用的时代，互联网产品的迭代周期变得更短、速度更快、频次更高，这也为传统软件测试带来了更大的时间压力。

为解决这一问题，测试左移成为一种更加主动的测试策略。测试左移的主要思想是，通过在代码开发的早期阶段进行测试，让测试人员更有主动权，能够更早地发现和解决问题，从而减少错误和故障对于后期开发工作的影响。这样，测试人员就不会因为质量差或风险高而每次都推迟上线，同时也能保证产品在线上的质量。

在软件开发中，开发人员通过触发 CI 流程，使用 AREX 进行代码签入前的测试。这样做的目的是为了在代码 CheckIn 之前，提前发现并解决问题，减少对于后期开发工作的影响。如果在问题验证过程中确定是 BUG，开发人员会进行修复。如果变化是由于代码变更导致的正常结果，开发人员会将差异标识为忽略。测试团队能够看到被标识为忽略的节点及其变化，从而同步获知代码变化的影响面。这样做可以让开发人员更加主动地处理问题，同时也可以提高软件的质量和稳定性。