序言
接口测试的流程就相当于一个程序（交互式的程序)；而程序开发前，得先确定需求，所以我们先来聊聊需求，即当有了接口测试脚本和框架时，怎么用(执行)的问题。
讨论要点：
1.前期准备
2.执行步骤
3.提BUG
前期准备
搭建本地测试环境本身是件很麻烦的事，但用docker的话就少了很多麻烦专注于测试本职工作
（1）搭建环境：
在docker设置中添加的镜像源路径，docker-compose.yml文件目录有用于构建mysql镜像的文件时，在该目录下执行：
docker-compose up -d 部署镜像（当没有对应镜像，就会拉取镜像源（包括本地）的镜像）
（2）更新表结构：
每次后台的数据库表结构有更新时（同时更新migration）,就需要更新本地的表结构；
先更新用于构建本地镜像的sql文件（resotre）,再构建新镜像部署
docker-compose stop mysql
docker-compose rm -f -v mysql
svn up mysql && docker-compose up -d --build mysql
最后需要进行数据初始化，因为数据库光有基础数据还不够，还需要一些常用数据：比如账号数据。（可以通过写SQL脚本或者接口测试脚本达到初始化的效果）
（3）更新代码
先需要更新最新的代码镜像（jenkins更新测试环境代码），再执行
docker-compose pull 服务名
docker-compose up -d
（4）其他常用
日志查看 ： docker-compose logs --tail 200 -f 服务名
执行计划任务服务：
docker-compose exec schedule bash '' 对应修改计划任务配置的脚本''
docker-compose restart schedule
当然这些前期准备的命令最好使用jenkins执行脚本的方式，来方便执行，提高执行效率。
执行步骤
（1）接口第一轮测试
这种都是在后台代码完成后，前端和接口联调前执行的
为了编写和调试方便，所以是在IDE上命令行执行脚本；
要点：
1、独立的python运行环境
2、对应的路径下跑有不同效果，可以是测试集跑（suit）、测试用例（case）下跑
3、出现非接口的报错需调试时，可以在对应函数加上异常处理，或者在打印到测试报告中（这些处理最好是在写脚本时就有准备）
（2）接口第二轮测试
这种就是在功能测试时，需要做接口回归测试时跑
为了执行的方便，所以在jenkins上跑脚本（一般测试集的跑）
要点：
1、测试报告输出到jenkins日志上
2、支持修改配置跑不同的地方
提BUG
（1）确定是否为BUG
用例验证接口一般两种：接口的返回验证、数据库字段验证。
所以要点是明确期望和执行步骤，这执行步骤包括：造数据前请求的接口、测试对象接口的请求参数；
这些都是在脚本上已经确定好了的，所以很好明确
（2）定位BUG
根据步骤流程上数据产生来定位，比如：可以由错误的返回字段推导出是生成了错误数据的原因，从而找出产生错误数据的接口
（接口分类无非是增删改查）
（3）开发有疑问时
1、让开发通过访问本地数据库来调试代码
2、让开发在代码上加上日志，再跑一次脚本，查看日志
