对于接口返回参数，除 response 有返回期望的结果值之外，还有很多其他的参数，那额外的参数需要验证吗？有人认为每个返回值的参数都得验证；也有人认为只验证需要关注的部分，其他不验证；也有人认为需要验证期望值 + 页面展示的值，基于这些该我们该采用哪种才合适呢？
我认为的是
1.接口状态码
2.本身测试的接口的 ErrorCode
3.返回值的验证（POST+GEIT）的组合
4.针对金额，数值等重要接口做前端二次验证
对于查询的接口，只需要验证状态码，返回 body 里面的重要字段。对于修改，插入等有数据修改的接口，不仅要验证返回 code 和 body，还需要从数据库级别验证数据的变化。
1、http 状态码；
2、响应首部的 conten-type；
3、响应正文结构，一般包括：业务处理状态码、业务处理描述、业务数据（每个公司的接口规范不一样）；
4、业务数据，只校验重要字段值；
这个要分情况 如果返回的参数要用到,就肯定要验证的
有的接口会返回很多参数，但实际用到只有那么几个，建议验证需要用到的参数就好；如果采用接口测试，页面测试占比可以小一点，只要最后看看页面展示就行，毕竟采用接口测试是为了与前端展示分离，减少页面的操作步骤，已到达测试的目的
结合业务做决定 返回码和返回值都是基本验证 返回值每个值是否都需要深入验证要看项目 同样返回体里面的 包括一些 cookies 缓存、安全性能等等 都是取决于业务形态 不是全部都验证就好 测试的度也是需要平衡测试时间和质量产出的
只看返回码和必要的业务字段，其他的返回信息那么多，逐个验证太耗时间了吧，一般都是拉着开发确认哪些字段有改动
1、status 正确
2、分页类的无重复数据
3、返回主要数据结构正确
4、数据关联正确
5、必须返回数据的字段校验
6、link 可以访问
7、db 方式
。。。也差不多了，其他的就看经验了
我工作中写接口自动化是按照业务逻辑的思路去写，所以在每一个 case 中都会有一个或几个字段有预期结果，返回参数中针对这几个字段进行断言校验就可以满足了
一般迭代快就做接口测试比较好
前端 ui 改动小，程序稳定了可以吧 ui 做起来
我们是验证 http 状态码=>验证添加在 response 里的状态码=>验证 response 中需要关注的数据。
例如，某接口返回一个表格的数据和样式，只需验证其中的表格数据部分，样式参数不作验证。如果需要对样式参数作验证，应当设计新的测试用例，专门针对样式。如果全部参数都进行验证，用例量大了以后，难以维护。而且每条用例针对的功能不专一，通过测试报告难以快速发现缺陷所在。