浅谈接口Diff测试
转自：https://mp.weixin.qq.com/s/6H-AGaqpwf47gcxs2Sw9fQ
所有的手工CASE和自动化CASE都跑了，上线为啥还经常有问题呢？
服务端语言由PHP语言改成GO了，原来的接口逻辑我又不了解，怎么测试？
测试环境测的好好的，上线后由于开发部署的版本问题导致的事故，开发非要说是我漏测，这锅怎么甩？
别急，尝试下接口Diff测试...
接口Diff测试，简单来说就是比对相同接口在不同版本/不同环境下面的返回内容是否符合预期。对于日常迭代的接口来说，Diff测试是我们接口基本功能测试的有效补充，因为采用的是自动化的手段，它可以利用线上大量的请求日志在新旧两个版本中进行回放，而我们手工/自动化的接口回归往往只局限于少量的测试数据，很难覆盖到大量的、在生产环境真实会发生的异常请求数据。
如果你曾有过大量的接口测试实践，相信对上面的说明会深有感触，单纯的依靠有限的CASE进行接口功能覆盖，上线后或多或少还是会发现一些异常。过多的美言我们不再累述，下面我们就一起看下实现思路和主要的实现细节吧。
实现思路
其实呢，整体思路比较简单，见下图：
用Unittest做过接口自动化的同学看上图是不是感觉很熟悉？没错！接口Diff测试和接口自动化用的就是同一套东东。区别在于，Diff测试需要同时向两套环境发相同的接口请求，拿到返回后进行比较（上图中的“主要函数：json递归比较”就是实现比较功能的）；另外，优化了常用的HtmlTestRunner测试报告，采用了更加美观的BeautifulReport报告模板。
主要实现细节
项目的目录结构
-
config—接口请求地址维护
-
data--接口请求数据（线上回放日志存放）
-
logs--项目日志文件
-
testCase—unittest组织的接口CASE
-
testReport—测试报告存放
-
utils—工具、公用方法存放
测试报告
我们从测试报告往回说。一份“美观、清晰”的测试报告，往往会让测试工作显得更加专业。因此，项目中报告部分采用了BeautifulReport（html模板及部分细节有改动）,BeautifulReport是一套开放源码的报告工具，此部分有以下几点说明：
1. BeautifulReport可从https://github.com/TesterlifeRaymond/BeautifulReport 上面下载
2. 建议把该工具放到项目目录下进行调用，方便维护和扩展，例如我就放到了util目录下。
3.BeautifulReport在代码中调用类似HtmlTestRunner,需要传入待执行的测试用例集，如下图
4. 对于失败的CASE，对应的结果下面也有清晰的错误原因，方便问题定位。
测试用例组织
测试用例部分需要说明的：
1. 建议每个接口单独一个.py文件，这样加上多线程可以支持同时跑，提高效率
2. 用例采用的是数据驱动方式，数据放在csv文件中（关于数据驱动网上有很多例子）
3. Diff测试有一项重要的工作就是两个接口返回值的比对，现在多数http接口数据格式都采用json。因此，需要实现个简单的json比对的方法，部分代码如下（当然JSON比较网上也有很多例子可以参考）
4. 上面代码中带有HTML标签的提示信息，完全是为了优化测试报告中的错误信息。否则比对结果看起来比较杂乱。
其它细节
拿到线上接口请求日志，用脚本简单处理下，只保留请求参数部分。
其它，其它….就没什么了。
是不是很简单？即使作为一个新手，只要有一定的python基础。熟悉下uinittest、request，网上load下BeautifulReport，找一个json比对算法，基本上就搞定了。
总结
我们来回答下开头的三个问题：
第一个，设计CASE时考虑的异常与实际线上大量的请求数据比，难免会有想不到的。无论是功能还是性能测试，最接近实际用户场景的测试，才是最好的测试。
第二个，系统那么庞大，没有人能把细节都了如指掌，更何况你可能还是团队的新人、抑或项目之前没有任何资料积累。这种情况下，diff测试效果更明显，起码更高效。
第三个，把CASE数据、日志、报告亮出来，让开发把锅取走.
