背景：在测试的接口为公司提供给其他有合作关系的公司调用，为了种种原因，必须得跟数据库校验，此为背景；
问题：
- 每个接口返回一大堆信息，类似于淘宝的商品查询，比如你查询篮球，可能返回不同的店铺的不同品牌的不同价格等等相关的信息，每个店铺为一个字典元素放入列表中，字典的 keys 都是确定的，请问，假设我只返回两个店铺的篮球信息，我如何验证这 2 个店铺的信息是正确的？
目前验证方式：
- 目前我们的方式是通过脚本从数据库中将上述信息提取出来，然后再按照接口返回信息的格式重新组装，最后与接口返回的值对比，但是这样的话，无非是按照开发的逻辑将 sql 重新写了一次；
- 最近想通过另外一种方式，因为返回的字典元素 keys 都是确定的，也即返回的所有信息都是同样的 keys，我想直接从返回值中提取同样的 key 的值，然后放到一个列表中，然后在与数据库对比，这样的好处是不需要重复开发的组合逻辑，直接一个 key 一个 key 的验证，但是这样做的弊端是显而易见的，就是，店铺的所有信息都是有关联的，就算是相关的 key 验证没有问题，也有可能牛头不对马嘴；
请问各位有没有相对比较好的验证方式呢
@seveniruby @ycwdaaaa @Lihuazhang
王理发修车铺
回复
如果交易接口在你这，你直接调动交易接口作为查询前置，接口查询的数据可以通过交易数据结合业务规则换算出来，比方说贷款 12 万，分 12 期，每期偿还的本金就是 1 万，那查询接口里当期还款本金就是 1 万。要测不同的查询规则，就提供不同的交易前置数据，额，我这边反正是这么干的
之前做过一个按 key 列表来进行对比的方式， 可以参考一下
总感觉拿后端从数据库里查出来返回的数据再和数据库里的数据做全量对比有点奇怪。。
我觉得拿接口获取的结果，再去跟数据库查询的结果对比，这种验证本身就得不偿失，投入远远大于产出了。
推荐只验证结果的取值是否合法（类型、范围等）即可。
Jerry li
回复
但是我感觉这样不好，因为一个字典元素里面的值都是有关联的，强行拆开验证就算没有问题，但是也不能保证这个接口返回了正确的值：
假设接口返回了 [{"a":1,"b":2},{"a":11,"b":22}]，我按照 Keys 再组装成{"a":[1,11],"b":[2,22]}，那么，可能数据库返回了 [{"a":1,"b":22},{"a":11,"b":2}]，这样实际上是不对的，但是测试通过了；
edsion
回复
但是不与数据库对比的话怎么保证返回数据的正确性呢？曾经就有一个 bug，就是返回的一个价格都是一样的，对比数据库之后发现了，目前我们有返回值的 schema 验证，不知道各位大佬有什么更好的验证方式；
王理发修车铺
回复
我对你实际的测试场景不是很清楚，我觉得奇怪的原因是这种单查询，比对接口和数据库数据是否就已经脱离了业务。要做这种查询校验我个人觉得需要从数据源头来，如果是交易造的数据，可使用前置来造，然后根据业务来判定返回的值是什么，这样接口数据直接就可以根据业务知道。如果是文件导入，那可以从文件里解析再和查询结果比对等等。我并不了解你那边的实际情况，可能你脚本查询数据库数据时就已经包含了业务规则的过滤，如果说错了勿见怪。我再说下我这边现在处理这种接口的方式，我这边有一个场景是贷款分 12 期，查询的结果是 list 里有 12 个 dict，框架的处理是设定特殊写法，直白点的写法类似：字段 A（字段 B=B 值）=A 值，通过 B 值来循环确定字段 A 所在 dict，字段 B 可以为当前分期数，然后拿到 A 字段值和期望值 A 值做对比。你那是不是可以考虑根据某个或某几个字段来确定 dict，然后再进行 dict 对比。最后我不是大佬
独缺
回复
哈哈，我这个可以理解为交易造的数据，在查询数据的时候会根据业务作出相应的过滤；如果按照大佬的意思，期望值 A 值怎么来的呢？查数据库？fake 数据？
王理发修车铺
回复
如果交易接口在你这，你直接调动交易接口作为查询前置，接口查询的数据可以通过交易数据结合业务规则换算出来，比方说贷款 12 万，分 12 期，每期偿还的本金就是 1 万，那查询接口里当期还款本金就是 1 万。要测不同的查询规则，就提供不同的交易前置数据，额，我这边反正是这么干的
我觉得接口测试的校验应该是对接口返回值的校验,以查询类商品为例,我查询篮球, 校验返回数据量, 返回数据中商品 type 等来验证这个接口是否正常,而不是去数据库用 sql 拿数据再做全量对比, 如果这样做的话我感觉可以归类为单元测试了,对开发写的 sql,逻辑处理函数进行测试。
而对于一些 post 类操作, 比如下订单, 我们可以通过接口串联来判断接口是否正常, 例如下单接口 ok 把订单 id 拿到,调用订单详情接口,再看订单详情页接口是否正常这样将业务串联起来。
另外, 也主要看你要把接口测试应用到什么阶段, 如果是回归测试阶段, 我觉得应该以提高测试覆盖率,提高回归测试效率为主,而不是细致到数据的全量对比, 如果是开发前期接口测试介入, 那可以做的细致一点
一点想法, 仅供参考
独缺
回复
我明白你的意思了，你的意思就是相当于传参是特殊构造的，然后根据传参可以直接通过业务逻辑 “计算” 出期望值，从而避免了从数据库中查找再组装数据，这个针对简单的业务来说应该是比较好的方式了，我再想想哈，谢谢了哈
说白了不就是为了避免调用接口后返回的数据量或者字段的值有错么，跟从表里查出来的不同，但返回的值在业务逻辑上都会有个预期值的，所以一般校验数量，类型即可吧