从表面上你看到的是返回的业务结果，其实他覆盖了你的函数流程。
接口测试，你可以用正确的输入 + 正确的结果来验证，也可以用错误的输入和预期的结果去做验证。
意图是覆盖你接口的所有可能的路径和输入输出，保证基本的接口级的功能不出问题。接口级不出基本问题，才能再往上保证场景、应用，越早发现问题修改越小

你想想手工测试的时候是怎么测接口的,关注哪些点,怎么验证数据真实性然后吧这些写点进用例里面
我是这样测的,状态码,code,响应时间,返回参数,返回参数需要连接数据库写 sql 进行断言

1. 开发是否有提供接口文档？根据接口文档来判断所测试接口应该返回哪些值？
2. 根据具体的业务场景，判断这个接口的目的是啥？比如获取某个值，那么正确的返回中就应该有所期望的值。
3. 判断无非就是期望值和输出值的比较而已，要确定你的期望值，然后从输出值中提取需要的值，和期望值比较。

另外：值判断返回值肯定是不可以的，有很多接口，即便是错误的，返回的状态码也是 200. 另外的 json 串中会提示错误信息。

自动化测试是你手工测试的代码体现啊。你手工测试就看 code 么。。。

不知道你为什么会只断言返回码。 测接口说白了也是黑盒，你之前手工测试的时候，肯定也会关注数据返回的一些关键点吧，返回值是否正确

我是直接用 pytest+requests 直接自己写，直接在 json 文件里面把每个用例的数据还有预期结果写好，到时直接读 json 数据，断言，直接全判断。根据开发文档，包含状态码、返回数据，看与 json 文件里面的预期结果是否一致。如果涉及数据库的还会自动插入，删除、查询数据。感觉纠结的是查询接口，有时我都想，我要写个查询算法？

我没有只断言 code ，比如创建接口，我取返回的唯一 id 去编辑，做其他的操作，也是整个流程啊

正确的输入和正确的结果去判断比对吗？每个接口都需要去数据库查询一下接口生成的数据是否正确吗？仅通过业务流程去判断不行吗？比如创建用户接口返回了用户唯一标示，我通过这个唯一标示去编辑，查询等操作，这样呢

把自己的身份换成前端，你就知道什么样的返回是正确且你需要的了。

去了解一下开发的代码逻辑，业务的实现不仅仅是你看到的 “接口”，稍微往深了一步了解，知道内部 service 的的调用，你就进了一层，接近灰盒了。我也就刚刚摸个门道，楼上没说错，你只是做这个层次的接口测试的话跟黑盒区别不大，哪怕是有接口文档，你不了解业务，完全信任接口文档的东西也是不行的，因为开发很可能在业务实现的时候就有了遗漏和偏差，那接口文档本身就带有 bug，你测了接口文档里的所有异常逻辑不代表产品是没有问题的。不同项目的业务复杂程度各异，有的涉及到上游下游的系统交叉调用，QA 都需要尽可能地了解，首先了解业务，再看代码逻辑实现，再想里面的测试点。而不仅仅是拿来接口文档去模拟调用验证返回值，那是不够的

我们是数据驱动的方式

手工测试怎么测， 自动化代码就得实现啥。 像我这边都得做到入参动态化，出参基本所有字段都得校验，list 的条目数也得校验。校验的方式就很多了，可能跟数据库可能调用别的 api 等等。

可以结合与数据库中的结果、jsonSchema、正则表达式、jsonPath 等方式进行校验。仅仅通过返回的 code 或者 success、false 等真的可能会出现覆盖不全的情况呢