前置
前两篇已经写了：
第二点，需要再扩展补充，工具的选取需要考量多个方案，其中不乏定制化后进行二次封装开发。
第一点，后续需要增加多种抓包情形。
设计
1.通过抓包整理，文档展示效果如果，如果接口数及模块比较多，整个的工作量还是很费时的。
2.接口间的关系设计
a）依赖关系
其实这块在抓包的时候，大致是可以知晓的。
比如，需要登录的才能操作的接口，那么这些接口一定是依赖登录的，或者获取cookie或者session。
b）无依赖关系，但是关系微妙
例如：
接口A为添加数据功能，接口B为获取某个数据的详细信息，接口C为删除某条数据。
以上A-B-C之间是没有直接关系的。
但是，当数据库不存在数据的时候，使用接口B的时候就会返回空，接口C也无法证明接口功能是否真实实现了(正向用例)。
这时，如果先执行A，再提取A的结果，使用B去查询该条数据，最后使用C删除该添加的数据，即做到了接口验证，同时又还原了初始数据，一举两得。
c）关系确认
关系的确认其实还是要根据接口自动化测试范围来确定，只做冒烟测试那么做正向用例其实是差不多的，但是如果要对接口做压测等等这些，考量又不一样了
3.接口的验证
接口的验证比较难的点在于：验证的粒度，多大才是合适的。
比如：做接口测试要不要查询数据库！
我们从几个方面进行考量：
1）接口响应值
→接口的响应值是只返回最终成功或者失败的状态：那么不需要查询数据库，直接匹配响应值即可。（完美情况）
→接口的响应值是单纯只返回未被处理的数据：那么直接通过与请求同样的处理获取数据进行匹配即可。（完美情况）
→接口的响应值是返回被处理后的数据：那么需要通请求一样对数据进行同样格式的处理再进行匹配（完美情况）
→接口的响应值格式是无规律的：同未被处理（完美情况）
→接口的响应值返回是有类似json这样的美好格式的：同被处理（完美情况）
2）对产品的熟悉程度
→熟悉表结构
→熟悉各请求对应的表关系
→熟悉各请求对应的后端处理逻辑
BUT！
以上情况，我们很少能恰好做到。
so：
对于接口测试，建议分阶段进行处理。安排好测试计划。
是的，接口测试也要有测试计划的。
第一阶段
在不熟悉各表结构和反例的情况下，建议走正向用例。
在返回的数据比较复杂的情况下，建议在前置准备的时候，准备特性数据，校验的时候模糊匹配是否接收到对应的特性数据。
这种情况下的效果是：
优点：覆盖冒烟/回归，完成正向用例，结果准确性也能达到几近100%；
缺点：需要部分的手工干预，比如前置准备的特性数据。
第二阶段
在熟悉产品的同时，熟悉反向用例，补充完善反向用例
优点：在第一阶段的基础上，可以覆盖其他异常情况，执行本接口功能测试。
缺点：需要部分的手工干预，比如前置准备的特性数据。
第三阶段
在熟悉产品的同时，熟悉表结构等
其余阶段均是根据对产品的熟悉程度，对接口测试进行扩展扩充！
所以是否需要进行数据库查询联动，主要还是在于测试的范围，测试的粒度，测试的时间性等
......
原则上，接口自动化全程是无需手工干预的。即路径应该如下：
后续再完善。。。。