最近有些同学一直在问一些概念和设计接口自动化的一些问题。
比如，需不需要验证数据库是否正确？
这里还是跟你公司，跟你所在团队，跟你所在的测试方法或策略有关的。
为什么这么说？
因为在我之前的那家公司，因为上市公司，很厉害的。
所以测试根本没有数据库权限，你别说想看数据了，可能你要连接数据库的那个权限都需要领导层层申请。
当时设计的自动化测试框架比较简单，只是自动校验json格式是否正确。
所以，你看到了，团队不允许，你就不能数据库验证。
那么如果有条件，或者测试可以有测试环境的权限的话：我强烈建议验证数据库！
下边说一下我的观点：
1. 一般前后台数据交互都是通过json数据进行，那么json数据是从数据库中得来的。这里就涉及到json数据的校验。
那么格式校验是格式校验，字段值是否正确是字段值正确校验。
那么对字段值的校验最合适的方式就是查询数据库。
2. 在特殊情况下，我调用了一个删除数据的接口，有没有真的删除一条数据，我可以调用查询数据的接口啊！查不出来刚才删除的数据，不就证明刚才的删除接口操作是ok的了。另一种方式就是查询数据库中是否存在我的数据，如果没有就是删除了。
关键是什么？关键是有些删除操作之后，还会有连带的关联数据进行删除(如果大家对业务不了解，或者表结构不了解，需要问一下开发)。那么是不是把关联数据删除掉了？那么是不是要验证数据库？
3. 对于测试来说，请求一个接口之后，需要知道这个接口在背后做了哪些事情(其实无非就是对数据库的增删改查操作)，了解逻辑，对于多接口的测试，它背后更加复杂的逻辑更需要详细清楚。表结构，关联方式，字段参数变化，含义等。不光开发清楚，测试也要烂熟于胸。
我觉得或许做到以上几点才能算得上是"基于业务功能的接口测试，不是耍流氓"。
那么要做到以上几点需要：
1. 接口流程需要烂熟于胸，接口功能，每个字段含义需要清楚，需要知道参数的变化。响应数据的变化，比如我们公司有开发同学定义的yapi接口定义文档(各公司接口文档可能平台不一，但大体相同)。需要测试同学耐心一点，仔细看看~~
2. 需要了解数据库字段、数据库关系、表之间的关系等等，你要清楚比如字段代表的含义，如何修改？逻辑对应接口中哪些字段？可能有时还需要到redis中去获取缓存数据，那可能就有点稍微复杂了。
怎么样，你看完之后，觉得我们在做接口自动化测试时，需要验证数据库吗？
