引言

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

为什么试用 JIterator

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

原理简述

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

                    (图片来自产品官网)

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

                    (图片来自产品官网)

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

试用过程简述

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

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

步骤一:登录试用地址

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

步骤二:基础配置

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

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

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

步骤三:流量录制

步骤四:测试回放

步骤五:结果分析与优化

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

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

步骤六:集成与自动化

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

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

在前一步试用的基础上,我们定义了第二部分的目标:验证 JIterator 能否准确识别出我们故意构造的 Bug。主要模拟 3 类 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 即可。

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

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

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

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

试用结论

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

写在最后

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


↙↙↙阅读原文可查看相关链接,并与作者交流