从用例角度，是否要判断里面数据对不对是要根据被测服务逻辑决定的。但从框架角度，这个功能有比没有好。

可以先看下用平台的项目一般接口返回要验证什么，然后再决定这个功能是不是一开始就需要具备，需要具备到什么程度？（最简单可以直接一个是否包含特定字符串，写到 excel 里最后一列就行了；复杂的可以做到允许自定义函数进行断言）

接口自动化作为回归测试的一种最为重要的手段，参数的校验我觉得是有必要的，理由是：如果开发改了某块算法，但是接口仍然能够调通，仅仅是返回的数据发生了变化，而这种变化是不允许的。以你这里为例：开始时间与结束时间，原本的需求如果是左开右闭区间，开发迭代过程中不小心改成了左闭右开，如果仅仅校验接口 OK or not OK，是检测不出来的，必须要加上数据的验证，才有可能发现此类问题。
如何做数据校验？我所在的项目是这么做的：保证数据库数据不会被随意更改的情况下，校验特定时间区间段的特定数据即可。比如你选择 2020-01-01---2020-01-31 这个区间，再选择其他条件，发出请求后把响应里的 data 取出，放在 excel 或者 yaml 文件中；然后接口自动化用例还是以上面相同的条件去写，把 response 里的 data 通过格式转换等，与存放的数据进行对比。一旦开发修改到相关逻辑，接口返回的数据与原来存储的数据不一致了再进行分析。

最近正好在思考数据校验的问题，你的方法也是一种思路，受教了

为你的动手赞一个，这里有个现成的轮子 https://metersphere.io/
对于条件组合类型，可以考虑一下 pict 或者 allpairs，后者是个 python 库。
希望对你有帮助。

别这样，每个帖子都刷。。。

谢谢大佬提供的思路 ，虽然我用的是二楼大佬的解决方案，但是还是感谢！！！

看了后真的好有启发，但是我还是有个问题：2.第一次请求和第二次请求应该分成 2 个函数来写吧，第一次是获取标准结果，第二次取得结果和第一次比较，那如果 2 个函数同时执行，结果不就永远一样吗？

接口校验的原则是不走数据库，为什么呢。因为你可能有测试环境和预发布环境的操作权限，但是线上是一定没有的。所以必须用接口去验接口。所有接口分为 2 类，操作接口和查询接口，查询接口一定是根据操作接口的信息做反馈的。
那么你查询接口的时候与你操作接口的参数不一致怎么办，一般我的做法是拼 json，从所有你能获取的上文中取值拼 json，取值的维度是避免从查询接口取。脚本设计最好是单例模式，这样你的上下文逻辑就非常清晰，还有校验对时间字段不做重点校验，因为操作时间和数据库时间存在一定误差

如果按这种方式，获取标准结果的脚本并不是每次测试都执行的吧，只需要执行一次，获取到结果后人工确认是否正确，以后在回归的时候再用产出的测试数据和标准结果对比就行了，这跟我在前公司做的思路差不多

是的

我没有理解，具体做法应该怎么做呀，能说的具体点吗

好的，之后一定注意，看到这篇内容觉得 MS 适合这个场景，代码方式的话也推荐 pict 或者 allpairs，我们也有在用的。

这个原则个人持保留意见，要看具体业务。不见得每个操作都会有对应的查询接口暴露，查数据库是最直接的手段。

至于多环境权限这个，不见得每个用例都要每个环境都跑吧，线上跑的用例我们一般都是筛选过，不会做增删改的才会放上去。

查询数据库虽然有效
但不是真实的校验手段，
最终我们对外暴露的是提供给用户的接口，
表里查出来的结果不一定是接口反映的结果，
我觉得接口校验是理想结果，数据库校验是手段

表里查出来的结果不一定是接口反映的结果

这个认同，确实会有这种情况。不过确实有的业务操作后存储的数据不会有对应查询接口的，这类数据可能通过其他手段和其他系统交互（比如直接过来取数/通过 MQ 之类的直接发消息）。还是具体情况具体分析吧，上升到 “原则” 感觉有点过了。