接口测试的那些事(四)接口自动化diff

接口diff的定义

接口diff即接口对比，就是对接口的返回结果进行对比，找出结果的差异之处。广泛意义上说，接口diff不局限于接口的个数(1/2/3/4/...个接口)，也不局限于接口的返回形式(json/string/xml....) ，当然也不局限与接口的请求方式(http/https/thirft等等)。接口diff基本类似于如git中的代码diff，根本目的在于找出差异。

项目测试中的接口对比，则往往有这样的应用场景：代码做了修改，需要回归之前的众多接口是否被“改坏”。此时，采用的一种回归形式就是接口diff。基本接口diff的步骤如下：

1）在服务器A上部署原代码/线上代码（定为接口版本1）；

2）在服务器B上部署修改的代码（定为接口版本2）；

3） 确保服务器A，B的差异仅仅在于代码的不同，即使用的DB，依赖的上游服务等等相同；

4） 对比接口版本1，接口版本2的差异

5） 验证对比结果（如果接口版本1，接口版本2无差异，认为接口正常，无字段被改坏，或误删的可能；反之，确认二者的差异是否是代码原因）

ps: 对于接口数量少，接口返回字段少的场景下，步骤4）是可以通过人工进行检查的。当然，不建议人工检查，毕竟对于之后的多次回归就有点浪费时间了。

接口diff的用途

1）高效率进行接口的回归。尤其当接口众多时，接口的返回字段众多时，此时[人工]检查接口，效率太低了。

例如，项目中已经发现的问题包括：

某个接口比之前少了一个关键字段（该字段在页面需要展示的）；

某个接口中的字段值错误（字段值计算的内部逻辑被改错了）；

2）快速发现接口修改前和修改后的差异。因为大部分代码的修改体现在接口返回的变化上，因而使用接口的变化来反向验证 代码的修改影响。

3）快速验证某些场景下的测试。

例如，曾经一个项目，变更了DB中的几张表，但要求接口返回的字段只多不少（就是原来接口中含有的字段，修改使用表后一定要有，可以有多余的字段）。此时使用 两个版本代码中的接口 直接diff 是不是很easy了。

接口自动化diff

通过接口diff平台进行接口自动化diff。接口自动化diff平台满足如下功能：

1）多个项目同时diff;

2)   一个项目中多个环境时，可根据输入参数选择环境diff;

3)   一个接口，可仅仅diff某些参数（其他参数忽略diff）；

4） 一个接口，可忽略某些参数diff

5)   可忽略列表的顺序diff（例如，认为列表[1,2,3] 与 列表[1,3,2]无差异）

6） diff次数（diff次数控制一个接口一共对比的次数。一个接口的返回数据可能是定时更新的，为了减少此种场景的误判，可以将diff次数设置大于1，比如设置为3，会将每个接口diff 3次）

通常http接口返回(json形式)的经验

1）需要根据接口的具体情况来配置接口。

场景1：接口中的某些时间字段实时变动的，不需要比较，且类似字段较少，可采用 忽略这些参数的方式；

场景2：接口中的某些时间字段实时变动的，不需要比较，但类似字段太多了，可采用  仅仅比较这些参数之外的其他参数的方式；

场景3：根据某个字段筛选时，列表可能返回1，2，3，也可能返回3，2，1，但认为二者无差异时，可采用忽略列表返回顺序的方式比较；

2）接口json中，具体到某个字段时，兼容性比较。

比如，相等时比较 ： 一个返回300，另一个返回300.00,应该认为无差异；

3）接口diff耗时

一般来说，耗时受接口个数，接口返回json的字段数和深度，接口本身响应时间，线程数，diff次数，忽略参数等等因素影响。为了减少diff耗时：

增加线程数；

尽量减少diff次数；

尽量配置diff时需要忽略的参数；

4）接口本身的覆盖

接口覆盖：为了更全面对接口进行diff回归，每次接口增加/修改后，都要及时添加到diff项目中；

接口参数组合覆盖：当接口有多个参数可组合筛选时，近可能的多组合参数，防止某一个筛选项筛选的fail；

5） 对“写”接口进行接口diff时需谨慎判断是否真的需要

当有如下场景时，可以考虑对“写”接口diff:

“写”接口的返回json很多，无法人工判断；

测试时没有时间对“写”接口全面回归；

接口diff 不会涉及线上环境；

ps : 无论如何，当选择对“写”接口diff时，都要考虑对 线上数据是否产生污染。

接口diff测试的局限性

接口diff测试成立的依据在于：存在一个版本的接口是正确的。这个条件也说明了接口diff测试本身的局限性：

1）不能对新增接口检查。

2） 和接口覆盖度有关。如果一个接口有A,B两个参数，你只用了A，B分别做diff,没有使用A,B组合做diff,而bug正好出现在A,B组合的点，此时的对比是发现不了问题的。例如，项目中一个接口的参数在40+的时候，可能bug隐藏更深了。

3） 被当做标准的接口本身就有点问题时，可能diff就变得“将错就错”了。其实diff测试时，无论如何，都要防止此类情况的发生。所以，就diff测试本身来说，还需要其他的手工测试/自动化测试来辅助。

4)  "写"接口diff时，存在漏洞，当测试代码写入的数据，不能被读出时，此时会遗漏掉这个bug.

项目中应用经验

1） diff的关键问题，在于接口的覆盖度。因而应用diff进行测试时，最好由QA来控制接口的录入，减少接口遗漏的可能性。

2） diff与传统的接口测试方法（手工检查接口/专门写自动机脚本检查）相辅相成，补充了传统方法的不足。diff的应用场景：

• 接口的升级。比如要求接口的字段只多不少，即接口可能返回新的字段，但原来字段不能受影响；
• 批量接口的回归。比如一个线下系统，总共100+个接口，如何快速回归，确保接口逻辑正确；
• 频繁迭代上线。针对上线十分频繁的项目，减少回归时间，进而将更多精力放到新功能测试上；

3） diff测试对“读”接口可以很好的回归测试，但对“写”接口可能仍然需要传统的测试方法辅助。

写接口后需要使用读接口读数据来验证，因而，读数据的验证就需要额外的验证方法了。