让用户帮我们做回归测试:一款免费的API层录制回放工具试用

引言

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

为什么试用JIterator

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

原理简述

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

、

                                                     （图片来自产品官网）

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

• 我们如何采集到用户的操作？配置成本是否很高？
• 生产系统和被测系统是否同一数据库，同一底层服务依赖？如果是怎么保证数据库不被测试系统污染，如果不是如何保证回放所依赖的数据能正常读取？
• 录制的流量随着时间变化失效怎么办？毕竟很多业务对时间本身是很严格的，如券商系统。

从产品介绍来看，它通过全自动采集流量和全自动mock能力来解决这些问题，具体实现录制回放原理图如下

                                                      （图片来自产品官网）

详细的原理在这里我就不多说了，有兴趣的可参考官网介绍：JIterator - A Powerful Tool for Java Backend System Iterative Development and Testing - JIterator docs

试用过程简述

从我之前试用过的其他产品来看，这对产品底层技术要求非常之高，否则就会产生各种各样的回放问题。因此我找了我这边的一个系统来进行初步试用验证。整体试用分为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。更复杂的系统后续再使用后再找机会分享。