开发同学最近变更了部分业务查询接口底层的数据源，希望测试同学能够针对这些接口进行一些回归验证，校验底层数据源更新前后业务查询接口返回的一致性，保证更新后对正常业务没有影响。

这个回归测试和一般接口测试有所区别，不仅仅需要回归接口本身业务的正确性，更需要对比并输出优化前后的接口返回值差异，最后给到开发做为修复缺陷的参考依据。

那么我是怎么测的呢？

在与开发对齐测试需求后，我理出了这样一套测试流程：

1、在切换数据源前，根据测试范围尽可能地造业务数据，然后记录下调用接口的参数以及返回值。

2、通知开发切换数据源（可能是个开关配置），切换后，使用切换数据源前已经记录下来的参数再次请求查询接口并记录下返回值。

3、编写 Diff 脚本去输出每个相同的请求参数在切换数据源前后的接口请求返回值差异。

4、最后分析差异，将差异点进行记录并和开发对齐结果。

5、开发进行修复后进行脚本自动回归。

6、循环步骤三到五，直到没有差异或者差异可被接受为止，则测试结束。

如何编写 Diff 脚本？

整个测试流程中比较有技术的点可能是 Diff 脚本编写，我使用的是 Python 里的 DeepDiff 库，他可以很好的对比两个数据之间的差异，比如:

from deepdiff import DeepDiff

ddiff = DeepDiff(dict(a=1, b=2), dict(a=2, b=2))
print(ddiff)

输出是：

{'values_changed': {"root['a']": {'new_value': 2, 'old_value': 1}}}
Process finished with exit code 0

可以看到输出的是两个 dict 中 key 为 a 的值存在差异的部分，旧的 a 值是 1，而新的 a 值是 2。

将 DeepDiff 带入到整个测试流程中，最终呈现出来的测试结果是这样的：

自己分析一下 diff_result 结果后就可以愉快地和开发去扯皮了。

最后

从接到需求到完成第一次测试结果输出，我花了大概一天半的时间。整个过程比较顺利，但在真正实践过程中，也遇到了一些需要思考的点。

比如：

1、造业务数据时，很难遍历到所有查询条件集合，那么这时候，至少需要保证主业务完全覆盖。

2、如何高效输出差异对比结果，比如只有存在差异时才输出请求参数、响应和差异点，让结果更好地被分析。

3、分析结果时需要首先将问题归类总结，同样类型的问题可能是一个原因导致的，将问题归类分析后能够更好地缩短和开发扯皮的时间。

最后，希望我这段测试经历能够启发到测试小伙伴，用技术去解决测试问题。

实战案例

光学理论是没用的，要学会跟着一起敲，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。

如果对你有帮助的话，点个赞收个藏，给作者一个鼓励。也方便你下次能够快速查找。

如有不懂还要咨询下方小卡片，博主也希望和志同道合的测试人员一起学习进步

在适当的年龄，选择适当的岗位，尽量去发挥好自己的优势。

我的自动化测试开发之路，一路走来都离不每个阶段的计划，因为自己喜欢规划和总结，

自动化测试视频教程、学习笔记领取传送门！！！