引言

在快节奏的软件开发周期中，自动化测试是确保产品质量的关键。但传统的自动化测试往往面临维护成本高、覆盖率不足等问题。本文将介绍一种新的自动化测试工具——JIterator，它以用户实际操作为驱动，颠覆了传统的测试模式。但它和 UI 录制回放自动化工具是不一样的工具。UI 录制回放是需要测试人员操作界面来录制，而且随着界面的调整测试用例容易失效，不推荐使用。而 JIterator 是 API 层面的录制回放，任何用户的系统操作行为均可被录制下来作为测试脚本进行自动化测试，非常方便易用。本篇文章记录了对 JIterator 的试用过程记录，并模拟了 3 类 bug 来验证这款产品发现 bug 的能力，希望能对大家理解 API 层面录制回放有点帮助。

为什么试用 JIterator

现有的自动化测试工具虽然在一定程度上提高了测试效率，但往往需要投入大量精力创建和维护测试脚本，特别是一些特殊 API 往往包含复杂难以构建的参数，或者需要维护大量的测试数据。之前也有尝试过其他类似工具，但上手成本都很高，在逛 Product Hunt 的时候发现了这款产品也试用了一番，发现还不错，所以写篇文章分享下。

原理简述

‘让用户为我们做回归测试’ 这句话听起来就很矛盾，我们希望给用户带来稳定可靠的产品，但要给用户带来稳定可靠产品有必须经过严格测试才能提供给用户，因此听起来是不可能的。但录制回放提供了这种可能，将用户的操作回放到被测系统中去发现 bug，原理如下：

                    (图片来自产品官网）

显而易见，但要实现把操作回放到被测系统牵涉到很多问题，例如

• 我们如何采集到用户的操作？配置成本是否很高？
• 生产系统和被测系统是否同一数据库，同一底层服务依赖？如果是怎么保证数据库不被测试系统污染，如果不是如何保证回放所依赖的数据能正常读取？
• 录制的流量随着时间变化失效怎么办？毕竟很多业务对时间本身是很严格的，如券商系统。 从产品介绍来看，它通过全自动采集流量和全自动 mock 能力来解决这些问题，具体实现录制回放原理图如下

                    (图片来自产品官网）

详细的原理在这里我就不多说了，有兴趣的可参考官网介绍：JIterator 介绍

试用过程简述

从我之前试用过的其他产品来看，这对产品底层技术要求非常之高，否则就会产生各种各样的回放问题。因此我找了我这边的一个系统来进行初步试用验证。整体试用分为 2 个部分：

• 第一部分：基线录制回放
  • 找一个功能正常的系统接入，验证其是否能自动采集流量和正常回放，并沉淀测试用。
• 第二部分：模拟 BUG 测试验证
  • 手工模拟几类 bug，将上一个部分沉淀的用例用于测试，验证效果。

第一部分：基线录制回放试用

步骤一：登录试用地址

访问：JIterator 完成账号注册即可开始使用。当然也可以自己搭建一套 JIterator 服务来使用，安装过程也比较简单，执行一个 docker 命令即可，参考 部署 JIterator 服务 。

步骤二：基础配置

在 JIterator 中，添加了一个测试项目，我准备直接通过启动 Idea 来部署测试应用来完成接入测试。从官方文档了解到一个 Agent 可以同时支持录制和回放，因此我只需要启动一个应用实例即可。首先在 JIterator 平台中找到 Agents 管理页面，，并进入到默认生成的一个环境中，然后点击添加 Agent，如下图所示，用默认的接入选项，我们得到了一个 Agent 的下载地址和 Agent 的部署参数如下图所示。

下载好 bootstrap.jar 后放到了我的用户目录，并按提示在 idea 中添加了 javaagent 的启动参数，启动参数是放到 VM Options 配置中如下图所示，然后运行项目。

等项目运行成功后观察了下 Agent 列表，发现 Agent 正在启动中，过一会儿启动成功后就可以开始录制和回放了。

步骤三：流量录制

• 创建录制任务： 选择刚才添加 Agent 的那个 Agent group，测试环境下采样率设置 100%，生产环境建议就不能设置这么高了。创建项目时自动初始化了 Default 数据集，任务关联默认创建的数据集即可。

• 启动录制任务：任务创建好后任务状态是未运行状态，因此需要启动录制任务才可以。点击任务右上角的启动任务即可。

• 查看录制数据： 在启动好任务后我们触发一些请求，然后就可以进入数据集查看录制的数据了，观察数据我们发现一些不需要做测试的流量进来了，可以先在任务管理中过滤掉这些请求录制。
  

• 设置流量过滤规则，排除特殊流量
  

步骤四：测试回放

• 进入任务管理页，添加一个回放任务，为简化试用直接用刚才部署 Agent 的环境来回放，所以环境选择 Test Env 环境。
  

• 启动回放任务，此时选择了只回放最新录制的流量，如下图所示。如果需要回放已录制流量，数据范围选择 ‘已录制’ 即可，如果需要持续回放，可以选择 ‘仅新增’ 或者 ‘已录制及新增’。
  

步骤五：结果分析与优化

JIterator 提供了直观的测试结果分析工具，通过官方使用文档 对一些回放噪音就进行过滤后得到了一批稳定运行的测试用例。试用阶段只录制了少量用例，正式使用的时候可以先采集内部用户数据来回放，生产录制则在后面确认采集没有任何问题后再考虑。

对于每条流量的录制和回放都能查看详细记录的日志和数据

步骤六：集成与自动化

咨询了下官方客服，工具可以提供测试调度的 API，后续可以集成到 CI/CD 流程中，在测试项目中挂载上 Agent，就可以调用 API 实现自动化测试了。

第二部分：模拟 BUG 测试验证

在前一步试用的基础上，我们定义了第二部分的目标：验证 JIterator 能否准确识别出我们故意构造的 Bug。主要模拟 3 类 bug。

• API 返回值不符合预期
  • 这是常见且容易发现的 bug，毕竟如果 api 返回结果出问题了用户会立即发现。
• 数据库数据未写入
  • 这类问题相对隐蔽，也不好通过常规测试发现，因为这涉及到更长的流程的联合验证。
• 写入数据库数据不正确
  • 和上一类问题类似

步骤一：手动构造 Bug

为了模拟真实世界的测试环境，我们在系统中故意引入了一些 Bug。列表如下：

• 模拟代码 bug 导致返回结果有差异场景。
• 模拟代码 bug 导致本应写入数据库的数据未写入场景。
• 模拟代码 bug 导致写入数据库数据错误场景。

将代码修改后使用 idea 的代码热部署功能快速让代码生效。

P.S. idea 的热部署功能可能有些同学不了解简单介绍下：如果是 idea DEBUG 运行的程序，修改代码后点击菜单栏的 compolie 编辑单个文件即可让改动立即生效。如果是远程部署的程序，在开通 DEBUG 端口的情况下可以通过 idea 远程 DBUG 上，再执行 compile 单个修改文件即可。只适用于修改方法内部代码，方法签名变化或者类名变化则不支持。

步骤二：执行测试任务

通过 JIterator 预先建立的回放测试任务，启动任务，此时选择已录制的选项，将任务关联的测试集运行完毕任务就结束了。

步骤三：监控测试过程

在测试执行过程中，我们通过 JIterator 页面可以查看测试状态，确保测试按预期进行。

步骤四：查看整体运行结果

先整体看下测试运行情况，不模拟 bug 时成功率是 100%，在模拟 bug 代码生效后出现了失败，成功率是 91%，说明发现了 bug。

步骤五：验证 Bug 检测能力

接着，我们通过点击 ‘详情’ 按钮逐个分析失败案例，验证它是否能够准确识别出我们构造的 Bug。由于我们使用了默认 Assert 规则，即只要有任何 Diff 就认为 Assert 失败，因此只需要看 Diff 即可。

• 模拟代码 bug 导致返回结果有差异场景。
  

• 模拟代码 bug 导致本应写入数据库的数据未写入场景。
  

• 模拟代码 bug 导致写入数据库数据错误场景。
  

通过是按案例的分析，3 类错误分别对应了 3 个模拟的 bug，因此发现 bug 的能力验证无误。

步骤六：修复问题并再一次验证

将修改代码回滚，同样采用 idea 的热部署能力，快速将代码回滚，可以将失败的案例重新回放一次。

最后的运行结果正常，模拟 bug 得以修复

试用结论

试用结果显示，JIterator 的使用还是很方便的，能 mock 数据层，redis 的调用，因为我们 session 是存入 redis，因此也不用担心 session 失效问题，从多次回放来来稳定性很好，运行速度也不慢。JIterator 在 bug 发现能力也是符合预期的，相比于人工编写 assert 脚本容易漏测问题，JIterator 提供的全数据 DIFF 能力保证了测试脚本的有效性。后续会继续跟进尝试引入生产流量来提升测试覆盖率。

写在最后

引入用户真实流量做测试是一个大胆而新颖的思路，对一些底层系统来说价值毋庸置疑，但也面临很多挑战，例如学习成本，数据安全等等问题。JIterator 这个工具从整体试用来看，易用性非常优秀，推荐大家尝试。但目前我找的试用系统是一个相对简单的系统，底层仅涉及到了数据库，redis。更复杂的系统，如何解决数据安全问题等后续再使用后再找机会分享。