回放测试

回放测试 | AREX https://doc.arextest.com/zh-Hans/docs/chapter3/Traffic%20Replay%20Test/

回放测试

流量录制回放是通过录制生产环境的高保真数据，并快速地在测试环境中进行回放比对接口返回值和中间链路的验证，以减少繁杂的回归测试、用例维护的重复性劳动，提升回归测试效率。

提示

不建议在生产环境回放，一般来说生产环境只录制流量，回放在测试环境或本地操作。

  1. 请先确认生产环境中用于录制的应用在配置 AREX Agent 后是否有流量请求，如果没有，则录制内容为空，无法进行回放。
  2. 测试环境中的被测应用也需要搭载 Agent，才能进行回放，回放过程对主接口将产生真实调用，而对外部第三方依赖（如数据库、Redis 等）则不会产生真实的调用，如果子调用入参与录制子调用的入参相同，则直接返回录制的数据。

查看应用​

应用注册完成后，通过浏览器访问 AREX 前端页面，点击 Replay，即可在左侧菜单栏中看到已配置好的被测应用。

录制应用列表

默认情况下，应用在搭载 Agent 后，AREX 将自动开启录制该应用所有时间段内的线上真实请求流量。你也可以通过录制回放设置，根据自己的需要设定录制任务。

查看录制详情​

当应用产生请求流量并被录制后，可以在回放任务列表上方查看录制详情。（此处显示的是基于当天往前的 4 天内录制到的所有用例）

流量录制详情

提示

目前数据库中默认只保存 4 天内的录制用例，超期后用例会被自动删除。如果需要长时间保留，可以在 docker-compose.yml 文件的 arex-storage-service 配置项中增加一条：

arex-storage-service:
    image: arexadmin01/arex-storage-serive:$AREX_VERSION
    container_name: arex-storage
    restart: always
    ports:
      - '8093:8080'
    volumes:
      - ./arex-logs/arex-storage:/usr/local/tomcat/logs
    environment:
      - TZ=Asia/Shanghai
      - JAVA_OPTS=-Darex.storage.mongo.host=mongodb://arex:iLoveArex@mongodb:27017/arex_storage_db 
        -Darex.storage.cache.url=redis://redis:6379/ 
        -Darex.report.service.api=http://arex-report-service:8080
        -Darex.storage.defaultExpirationDuration=1000000000
    depends_on:
      - mongodb
      - redis
 

仅对修改配置并重启 AREX 之后录制的用例生效。

如下列出了录制到的所有接口，展开接口，下方是该接口所录制到的所有用例。

流量录制详情

点击某条用例，查看该条用例录制详情，左侧为录制过程中一些动态类及外部调用的第三方依赖（比如数据库等）的请求内容，以及主接口的请求。右侧为对应的响应体：

用例录制详情

部分录制的请求体/响应体是经过 base64 压缩的格式，需要自行解压查看。

开始回放​

应用录制并设置完成后，可以进行回放操作。

提示
  1. 请先确认生产环境中用于录制的应用在配置 AREX Agent 后是否有流量请求，如果没有，则录制内容为空，无法进行回放。
  2. 测试环境中的被测应用也需要搭载 Agent，才能进行回放，否则将对外部依赖（如数据库、Redis 等）产生真实调用，产生脏数据。

点击需要进行回放测试的应用，进入回放测试页面。点击右上角 Start replay，即可进行回放。

流量回放页面

在跳转出的窗口中依次填入本地/测试环境中需要进行回放测试的端口地址（Target Host），即搭载了 Agent 的机器/被测机器的端口地址。

选择回放用例范围（Case range），对该日期区间内录制到的线上请求进行回放。

录制应用列表
提示

完整的 目标回放地址（Target Host） 应该是协议+域名+端口号（默认的 80 端口也需要手动输入），如下所示：

Target Host
  • 报告名（Name）：自定义报告名称，默认命名规则是 <应用名+创建时间>。
  • 回放路径（Paths）：中可以选择本次测试中需要进行回放的路径，如没有设定，则默认回放所有路径下的用例。
  • 最大回放用例数（Case Count Limit）：设定单个接口最大回放用例数，默认单个接口单次回放最大用例上限是 1000 个/接口。
  • Webhook：用于创建定时回放任务，参考>>定时回放。

回放报告​

回放报告

回放任务进行时，可以点击报告右上方的 Terminate 中断回放。

回放完成后，点击回放记录，可以查看详细的回放报告。

详细说明如下：

  • Terminate：中断该回放报告。Delete：删除该回放报告。点击 Rerun 可以重新进行回放。

  • Execution Logs：查看回放日志。

    回放报告

  • Pass Rate：回放用例测试通过率。(录制回放返回结果无差异视为通过)

  • API Pass Rate：接口测试通过率。

  • API：录制及回放中访问的所有接口列表。

  • State：接口测试状态，

    • running 表示正在运行中。
    • done 表示回放完成。
    • interrupted 表示回放中断，将光标移动至 interrupted，会具体显示中断原因，排查问题后可点击 Rerun 按钮重新运行测试。

回放中断

  • Time consumed(s)：该接口回放测试的执行时间，单位为“s”。

  • Total Cases：该接口下测试用例的个数。

  • Passed、Failed、Invalid、Blocked：分表表示回放通过、失败、无效、中断的测试用例个数。

分析报文差异​

接口用例中出现 Failed 说明回放与录制返回报文出现差异，点击右侧的 DiffScenes，查看差异。

录制应用列表

在实际使用过程中，对于一个复杂的线上应用，业务场景复杂，录制及回放的用例数量巨大，大大增加了排查问题的难度。

为了减轻使用者分析差异时的工作量，AREX 对存在相同差异的场景和差异点进行了聚合处理。

差异场景聚合逻辑​

在进行流量回放测试时，针对可能出现的用例数量较大的情况，AREX 会通过一些聚合的操作，将相似的用例进行合并，以减少差异点的数量，便于用户对数据进行分析。如下图所示，聚合相似差异场景后，每个差异场景下仅选取一条用例作为展示。

在 AREX 中，一个用例通常由多个步骤组成，每个步骤包含了一个请求和一个响应。请求可以是主入口，也可以是外部调用（包括 DB、Redis 等）。在每个步骤中，都会记录请求的参数和响应结果等信息，用于后续的对比。如果录制与回放时的主入口响应，以及外部依赖的请求均无差异，则视为该用例回放通过。

这里的主入口和外部调用我们称之为 Mock 的类型。

Mock 差异类型​

每个 Mock 类型的对比差异类型会被分为三种情况：

  • new call：这种差异类型表示该主入口或外部调用的 Mock 在录制时不存在，但在回放时存在，即新增了调用，通常是因为有新功能的迭代。
  • call missing：表示在录制时存在，但在回放时缺失了调用，通常是因为项目进行了优化，移除了某些不必要的调用关系。
  • value diff：表示在录制和回放时都存在，但在对比过程中某些节点有差异。后续章节中会具体介绍如何分析这些差异。

报文差异

差异用例场景聚合是为了将具有相同 Mock 类型和差异类型的用例聚合在一起形成一个场景，从而帮助用户更快速地了解整个场景中的用例情况，减少用户需要分析的用例数量，提高分析用例的效率。

首先，根据 Mock 的类型和差异类型的组合，AREX 会生成一个唯一的键，将所有用例分类聚合到这些键中，形成一个大分类。如上图中标注的 ①大分类。

其次，每个大分类中的用例都会再根据具体的 Mock 和差异类型的排列生成一个子唯一键，进一步对用例进行分类。这样做的目的是为了更加细致地分类，以便更快速地分析差异用例， 具体可见上图中 ②小分类 的示例。每个小分类中有多少个用例数量会标记在该分类的最前面。

差异点聚合逻辑​

在每个差异场景中，AREX 对相似的差异节点也进行了聚合展示。

在某些大报文的场景下，有些大数组中的差异点会非常多，一方面不利于前端展示，另一方面增加了使用者分析差异点的复杂度。

为了解决这个问题，AREX 将差异点按照模糊路径进行聚合。这里的模糊路径指的是不带数组下标的 JSON 节点路径。例如，一个 JSON 对象中有一个名为 “items” 的数组，数组中有多个元素 “items[0]”、“items[1]”、“items[2]” 等。在模糊路径中，这些路径会被合并为 “items”，从而实现聚合。

报文差异

差异点差异类型​

  • Additional node：录制或回放后的返回报文中多出的节点。如有，差异点会在报文中以橙色高亮显示。

  • Difference node：录制及回放后的返回报文中不同的节点。如有，差异点会在报文中以蓝色高亮显示。

定时回放​

可以参考以下步骤设立定时回放任务。

  1. 在回放界面上，点击创建回放，并填入目标服务的主机地址。然后会自动生成一个用于创建回放的接口调用链接（HTTP GET请求）。Case 的时间范围是从调用时间点开始往前的 24 小时。

报文差异

  1. 获取到创建回放的调用链接后，需要一个触发创建的介质：

  • 以 Linux 自带的 Crontab 工具为例

    1. 创建一个名为 "routine" 的文件，写入 0 5 * * * /usr/bin/curl [第一步中复制的创建地址]（其中"0 5 * * *"是标准 Linux cron 表达式，表示每天的 5 点执行一次）

    2. 使用命令 crontab routine 加载上一步中配置的定时任务

    3. 使用命令 crontab -l 查看是否成功写入定时任务

  • 以 GitLab CI/CD 为例

    1. 建立一个类似的流水线（pipeline）

    pipeline

    1. 在 ArexTest Job 脚本中使用 curl 调用 1 中复制的链接

    2. 在仓库-> CI/CD -> Schedules 中创建定时任务来执行流水线

    pipeline

回放结果回调使用指南​

回放结果回调是指在回放计划完成后，系统会通过调用用户自行配置的回调函数接口，将回放计划的相关信息以 POST 方式传递给用户。用户可以根据这些信息进行相应的处理，如监控和报警、统计和分析、自动化流程触发等。

配置​

在系统设置中配置 ReplayCallbackUrl，当回放计划完成时，系统会以 POST 方式调用该 URL：

pipeline

实现​

为了实现这个功能，需要用户自己实现一个回调函数接口，入参如下：

public class CallbackInformRequestType {

  private String appId;  // 应用ID
  private String appName;  // 应用名称
  private String planName;  // 计划名称
  private Integer status;  // 回放状态
  private Integer totalCaseCount;  // 总用例数
  private Integer successCaseCount;  // 成功用例数
  private Integer failCaseCount;  // 失败用例数
  private Integer errorCaseCount;  // 错误用例数
  private Integer waitCaseCount;  // 等待用例数
  private Double passRate;  // 通过率
  private Long elapsedMillSeconds;  // 耗时（毫秒）
  private String creator;  // 创建者
}
 
 

 

 

 

 

 

posted @ 2024-08-23 11:35  papering  阅读(37)  评论(0)  编辑  收藏  举报