接口响应内容与数据库内容对比的意义？

提问区
1

背景

我经常看到别人：做接口自动化时，把 response body 中的某个值与数据库中查询出来的值进行比较。

疑问

这样做有什么意义吗？
开发返回的值，本来就是从数据库中查询拿到的；
如果程序本身的数据处理逻辑就存在问题，我们证明body返回值等于数据库中的值并无意义。
我们构造测试用例的时候，对返回结果是有明确预期的，而不是从数据库取的。

引申

如果是另一种情况，我们的操作会产生中间数据，这个数据会落库，但是不会在response body中返回，这个时候，我们可以去数据库中查询数据，来验证
1，是否为预期值
2，作为下一个操作（比如接口调用）的输入数据

求大佬解答，我这样想思路是对的吗？欢迎交流

2

你写的sql和开发写的sql并不一致，你怎么去验证开发返回的内容是否正常呢

4

测试用例三要素：输入、步骤、明确的预期。
既然预期是明确的，那么我们自然知道开发返回的内容是否正确。正所谓无标准不测试。

测试与开发的sql是否一致并无关系，本意是不应该用“开发的输出”作为测试标准。
也就是说，用“开发同学处理的数据库中的数据”去验证“开发同学处理的接口返回值的数据”。

5

我觉得其实这个问题要结合业务和研发的设计来分析。

  1. 优先级，优先校验哪部分内容。这个毫无疑问一定是接口返回值。所以大部分的CURD业务，通过接口校验就可以满足需求。
  2. 考虑一下是不是会有一部分业务在某些接口变动之后，除了对应的逻辑会受到影响，其他业务模块的逻辑是不是也会受到影响。举个:chestnut:，我之前公司是做金融业务的，金融业务中，风控是非常重要的一个环节。风控受各种数据的影响，比如用户模块的某个字段发生变化，就会影响风控的结果。因为这个过程的牵涉到的底层逻辑较多，可能接口只会返回True 或 False。但是我们还要去校验数据的变化不一定通过接口会体现出来，这种情况就需要通过数据库辅助验证了。

总结一下就是，绝大部分业务场景，通过接口校验是最合理的方式。部分复杂的业务场景，需要结合数据库辅助验证