面试题：接口自动化中假如报文返回1000个字段，怎么确保这些字段都是正确的
这是个非常经典的接口测试的问题，我先留个坑位，晚上码字
在测试过程中，有一些极为复杂的业务，比如金融产品的风控中心，查询用户数据的接口的返回值，动辄都是成千上百个字段。
如果这么多字段，全部通过人为验证，不仅费时极高，而且极易出错。但是如果写传统的自动化测试脚本，意味着要写一千个断言，这个工作量也是极大的。所以不论是功能测试的方式，还是自动化测试的方式，似乎都没有很好的方案去解决。
难度较大的原因其实就是复杂，碰到复杂的问题，一定要拆解+分级。才能一步步的做下来。
第一个问题点就是，大量的响应值信息，我们究竟是要测什么？通常不同的测试团队，不同的业务形态的测试点也是不一样的。
依照先后顺序，我们需要对这种场景的接口测试完成如下的测试。
-
响应的完整性与类型测试。
-
响应的业务正确性的测试。
响应的完整性与类型测试
响应的完整性测试的目的在于保证响应的完整度，因为字段量极大的响应报文的数据信息都是由多个业务拼接而来。比如风控的 1000 个响应字段，可能由用户模块提供了 100 个，面签模块提供了 100 个。如果响应信息不够完整，那么在前端展示的时候，就会出现展示性的 bug。
如果要完成响应信息的完整性测试，使用 JsonSchema 自动生成响应对应的模版信息，然后每次与模版进行对比即可，如果响应发生变化，也可以重新生成模板，相比与人工对比，更加的方便。而且不易出错。
响应的业务正确性的测试
其实如果响应值有 1000 个字段信息，是不可能每一个字段都发生变化的。所以如果想要做业务正确性的校验，首先要抽出其中变与不变的部分（这个要自己分析业务）。
举个例子，风控的步骤有 N 步，其中每一步都可以对数据进行更新。如果我第一步更新的是面签模块的数据，那么响应值里面，则只有面签模块发生变化才对。那这个过程中，变的部分就是面签，不变的部分，就是其他的模块。
-
变的部分，可以通过模板技术+正常编写断言的方式完成。
-
不变的部分，则需要通过 diff 技术。保证不应该改变的业务模块没有发生变化。
总结
-
首先要明确变与不变的部分。
-
变化的地方，可以通过模板技术完成响应的完整性和类型断言，以及部分比较重要的业务字段，通过正常编写断言的方式完成。
-
不变的部分，则需要通过 diff 技术。保证不应该改变的业务模块没有发生变化。
8 个赞