搞定接口测试变态要求：海量接口返回值对比验证

上半年我给自己挖了个坑，说海量接口返回值比对是接口测试的核心要求之一，这次来说一下我是怎么做的。

做一下必要的铺垫，也顺带说一下测试的工作方式，各位看着高兴最好。

每个公司遇到的需求及问题都是不同的，大家还要因地制宜。

背景

公司最近搞了一个新项目，既实现了新的代码同时也复用了老的环境。

而复用老环境时，某核心开发因为看不下去老的代码（确实）太烂，打算借此机会重构老代码，一波上线。

开发的测试要求

希望老系统代码重构后，接口返回值没有变化。

涉及接口超过100个，几乎都是读接口。

回归测试强度，即核心业务逻辑没有改动，是代码结构的变动。仅观察返回值结构等是否一样即可。

可以提供原有环境及新环境，便于对比。

时间紧迫，要1天内搞定。

接口数量太多，影响较大，测试要认真对待。

测试的疑问

为什么现在才提重构老代码的事儿。

老代码重构和新代码上线不能混为一谈，新代码上线是雪中送炭，老代码重构是锦上添花。

无法理解为什么要一波上线，老代码重构可以慢慢搞，没必要一起上。

时间太紧迫。

接口数量太多，能否缩减范围。

开发的答复

重构老代码是某核心开发自己搞的，确实不在需求之中。

老代码重构势在必行，实在看不下去了，并且新代码上线后压力会大，担心有问题。

其实之前已经有部分重构代码上线了，但线上出了问题，所以后面的涉及重构的都需要验证测试。

新老代码混合程度较高，单独摘除老代码重构成本不小，时间消耗上摘除和一起上线差不多（反正已经上了一部分了）。

开发较自信（线上打脸了才想起来测试？），到现在还是很自信，重构没啥问题。

所以之前没测试重构，说重构了也担心不允许，那这些老代码会一直烂下去。

测试帮帮忙，相信你。

我的思考

我非常理解核心开发重构代码的动机。

这是个展现测试价值的好机会，如果你们开发能搞定就不会来找我了。

开发没办法搞定也没时间搞定了（线上bug修改等事情很多），时间紧迫。

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

我的底气

接口测试用例数据，这个是接口测试独有的，也是让这一切可执行的基础。

我开发的各种工具。

完成任务的方式

手工执行100多个接口，然后新老环境各执行一遍，之后使用beyond compare 比对一遍。（这不是让开发看笑话吗？也可能开发的预期就是这样，所以没时间搞）。

将任务1分工下去，比如测试方出5个人，开发出5个人，每人10多个接口，手工执行，比对，汇总结果。（需要牵头人，体现领导才能？但是任务会上升，牵头人未必是我）。

自动化执行100多个接口，然后手工拷贝每个接口的返回值，两次自动化后beyond compare比对。 存在的问题： 1) 接口返回值非常长，即便是软件比对，细节也看不清，返回值需要格式化。 2) 拷贝结果要执行100多次，要执行两遍，非常非常繁琐麻烦和累。如果一遍比对不成功那画面太美。 3) 如何有效执行100个多接口。

必须自动化执行。

自动化执行的方式

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

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

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

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

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

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

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

Jmeter脚本要读取数据库，获得这100多个接口的接口测试用例数据，然后可以脚本执行。这种执行可以切换新老环境，达到新老环境每个都执行一遍的基本要求。

Ant 运行Jmeter脚本后，会生成html格式的测试报告，但是需要将测试报告中的返回值格式化（JSON格式化）。

html格式的测试报告，要有一键获取所有格式化的测试结果的功能，这样才能高效的复制出来这100多个接口的返回结果，才能比对。

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

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

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

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

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

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

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

xsl我找资料查了下，是一种生成html的模板，里面包含各种函数逻辑，是可以同时有js代码和html标签结构的。

既然是js和html标签，那么我需要在网上找一个格式化JSON的js代码，将其嵌入到这个模板中就好。

我认为，hmtl文档中保存的是非格式化的数据，左侧超链接单击时，触发格式化js代码可行，这样html文件最小。

难点是，如何唯一标识每一个返回值，唯一标识后，才能单击哪个格式化哪个，才能找到数据。

然后我都搞定了。

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

找到一个触发条件，循环所有的上面已经格式化好的结果集合，找地方都存起来。

最好是一键下载，比如我打开html文件，点一下，提示我下载，最方便。可惜，由于浏览器出于对数据的保护，不允许下载，执行这种操作，生成文本都不允许。

使用console.log方式，将这些结果都打印到日志中，浏览器开发者模式下，全选拷贝出来，用于比对。

结尾

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

收到了表扬信。

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

Jmeter + Ant 可以再 + Jenkins ，这是持续集成，完全自己开发要做到这些，工作量还是有不少的。

Jmeter + Ant 已经有了，已经满足了很多要求，没必要再造轮子了。

Jmeter + Ant 最核心的Jmeter，功能太丰富了，比如正则表达式，自定义变量，参数化，性能测试，定时执行等等。 这基本满足所有复杂的接口测试要求，自开发这些工具真的比不了。

接口返回值的mock，不在此讨论之列。