上半年我给自己挖了个坑，说海量接口返回值比对是接口测试的核心要求之一，这次来说一下我是怎么做的。
做一下必要的铺垫，也顺带说一下测试的工作方式，各位看着高兴最好。
每个公司遇到的需求及问题都是不同的，大家还要因地制宜。

背景

公司最近搞了一个新项目，既实现了新的代码同时也复用了老的环境。
而复用老环境时，某核心开发因为看不下去老的代码（确实）太烂，打算借此机会重构老代码，一波上线。

开发的测试要求

希望老系统代码重构后，接口返回值没有变化。
涉及接口超过 100 个，几乎都是读接口。
回归测试强度，即核心业务逻辑没有改动，是代码结构的变动。仅观察返回值结构等是否一样即可。
可以提供原有环境及新环境，便于对比。
时间紧迫，要 1 天内搞定。
接口数量太多，影响较大，测试要认真对待。

测试的疑问

为什么现在才提重构老代码的事儿。
老代码重构和新代码上线不能混为一谈，新代码上线是雪中送炭，老代码重构是锦上添花。
无法理解为什么要一波上线，老代码重构可以慢慢搞，没必要一起上。
时间太紧迫。
接口数量太多，能否缩减范围。

开发的答复

重构老代码是某核心开发自己搞的，确实不在需求之中。
老代码重构势在必行，实在看不下去了，并且新代码上线后压力会大，担心有问题。
其实之前已经有部分重构代码上线了，但线上出了问题，所以后面的涉及重构的都需要验证测试。
新老代码混合程度较高，单独摘除老代码重构成本不小，时间消耗上摘除和一起上线差不多（反正已经上了一部分了）。
开发较自信（线上打脸了才想起来测试？），到现在还是很自信，重构没啥问题。
所以之前没测试重构，说重构了也担心不允许，那这些老代码会一直烂下去。
测试帮帮忙，相信你。

我的思考

我非常理解核心开发重构代码的动机。
这是个展现测试价值的好机会，如果你们开发能搞定就不会来找我了。
开发没办法搞定也没时间搞定了（线上 bug 修改等事情很多），时间紧迫。

此时此刻只有我才能搞定这件事儿（自带特效字带背景音乐自带慢动作）。

我的底气

接口测试用例数据，这个是接口测试独有的，也是让这一切可执行的基础。
我开发的各种工具。

完成任务的方式

1. 手工执行 100 多个接口，然后新老环境各执行一遍，之后使用 beyond compare 比对一遍。（这不是让开发看笑话吗？也可能开发的预期就是这样，所以没时间搞）。
2. 将任务 1 分工下去，比如测试方出 5 个人，开发出 5 个人，每人 10 多个接口，手工执行，比对，汇总结果。（需要牵头人，体现领导才能？但是任务会上升，牵头人未必是我）。
3. 自动化执行 100 多个接口，然后手工拷贝每个接口的返回值，两次自动化后 beyond compare 比对。 存在的问题： 1) 接口返回值非常长，即便是软件比对，细节也看不清，返回值需要格式化。 2) 拷贝结果要执行 100 多次，要执行两遍，非常非常繁琐麻烦和累。如果一遍比对不成功那画面太美。 3) 如何有效执行 100 个多接口。
4. 必须自动化执行。

自动化执行的方式

1. 完全代码实现，比如测试用例数据保存在数据库中，代码首先读取数据库，然后依次执行每个接口，将所有的返回值汇总并格式化输出成文档，一键拷贝比对即可。

2. Jmeter + Ant 再加工实现，读取数据库使用 beanshell，依次执行每个接口使用 Jmeter 自带功能即可，结合 Ant 产生测试报告文件就是测试结果文档。

3. 完全代码实现是可行的，我也实现了，但不是为了这种比对场景做的，是为了边界测试（后续可能分享挖坑）。

4. Jmeter + Ant 需要再加工，比如测试报告中结果的格式化，测试报告的文档拷贝的一键执行，我实现了这些，今天讲这些。

5. Jmeter + Ant 在此次场景下，是最方便的，因为我之前实现了很多功能，就为了这种硬仗准备的。

Jmeter + Ant 测试工具的二次开发

上面已经简述了任务要完成需要做的，再汇总一下：

1. Jmeter 脚本要读取数据库，获得这 100 多个接口的接口测试用例数据，然后可以脚本执行。这种执行可以切换新老环境，达到新老环境每个都执行一遍的基本要求。
2. Ant 运行 Jmeter 脚本后，会生成 html 格式的测试报告，但是需要将测试报告中的返回值格式化（JSON 格式化）。
3. html 格式的测试报告，要有一键获取所有格式化的测试结果的功能，这样才能高效的复制出来这 100 多个接口的返回结果，才能比对。

Jmeter 脚本如何读取数据库并执行所需要的用例

这里就口述一下了，简单贴图，毕竟详述太费劲。

1. 通过 SQL 语句，筛选获取测试用例的主键 ID 集合，比如 (100,101,102,103,104)，同时获取数量，比如总数为 5，都保存为自定义变量。

2. 使用 Jmeter 的循环控制器，循环的次数就是上面第一步获取的数量，循环 5 次。
   

3. 在每个循环中，从主键 ID 集合中从头拿 ID，比如拿到 100 这个 ID，记录数组下标为 0，保存数组下标为自定义变量，根据 100 这个 ID 获取的所有的接口测试数据定义为自定义变量。

4. 根据上面第三步获得的数据，来执行 HTTP Sampler，真正的发出请求。

html 格式的测试报告如何格式化

我改造的是最流行的 jmeter.results.shanhe.me.xsl 结果模板。
这个已经放到 CSDN 下载上去了，我上传的，代码我也就不详细贴了，毕竟说起来很麻烦，说一下当时解决的思路。

1. xsl 我找资料查了下，是一种生成 html 的模板，里面包含各种函数逻辑，是可以同时有 js 代码和 html 标签结构的。
2. 既然是 js 和 html 标签，那么我需要在网上找一个格式化 JSON 的 js 代码，将其嵌入到这个模板中就好。
3. 我认为，hmtl 文档中保存的是非格式化的数据，左侧超链接单击时，触发格式化 js 代码可行，这样 html 文件最小。
4. 难点是，如何唯一标识每一个返回值，唯一标识后，才能单击哪个格式化哪个，才能找到数据。

然后我都搞定了。

如何一键获取所有格式化的测试结果

我继续加工上面的 jmeter.results.shanhe.me.xsl 结果模板。
思路：

1. 找到一个触发条件，循环所有的上面已经格式化好的结果集合，找地方都存起来。
2. 最好是一键下载，比如我打开 html 文件，点一下，提示我下载，最方便。可惜，由于浏览器出于对数据的保护，不允许下载，执行这种操作，生成文本都不允许。
3. 使用 console.log 方式，将这些结果都打印到日志中，浏览器开发者模式下，全选拷贝出来，用于比对。

结尾

我当然解决了测试任务，并且开发再次被打脸，重构的问题还是很多的。
收到了表扬信。

讨论一下 Jmeter + Ant 和完全自己开发的优势

1. Jmeter + Ant 可以再 + Jenkins ，这是持续集成，完全自己开发要做到这些，工作量还是有不少的。
2. Jmeter + Ant 已经有了，已经满足了很多要求，没必要再造轮子了。
3. Jmeter + Ant 最核心的 Jmeter，功能太丰富了，比如正则表达式，自定义变量，参数化，性能测试，定时执行等等。 这基本满足所有复杂的接口测试要求，自开发这些工具真的比不了。
4. 接口返回值的 mock，不在此讨论之列。