背景

今天跟大伙聊聊最近在新公司接到的技术优化测试需求。

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

正文

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

那么我是怎么测的呢？

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

1. 在切换数据源前，根据测试范围尽可能地造业务数据，然后记录下调用接口的参数以及返回值。
2. 通知开发切换数据源（可能是个开关配置），切换后，使用切换数据源前已经记录下来的参数再次请求查询接口并记录下返回值。
3. 编写 Diff 脚本去输出每个相同的请求参数在切换数据源前后的接口请求返回值差异。
4. 最后分析差异，将差异点进行记录并和开发对齐结果。
5. 开发进行修复后进行脚本自动回归。
6. 循环步骤三到五，直到没有差异或者差异可被接受为止，则测试结束。

整个测试流程中比较有技术的点可能是 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. 分析结果时需要首先将问题归类总结，同样类型的问题可能是一个原因导致的，将问题归类分析后能够更好地缩短和开发扯皮的时间。

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