浅谈接口Diff测试

Posted 2021-01-23 zzgblg

浅谈接口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数据、日志、报告亮出来，让开发把锅取走.