接口自动化测试新思维
由于系统复杂，接口太多，资源有限，因此不希望花过多时间去为每条CASE编写或修改脚本，也不希望花过多时间关注接口具体有哪些参数，更不希望单纯的测试接口入参出参和返回数据是否正常，但又想把自动化落地，于是便参考了很多接口自动化的实现方案，都感觉不太合适，便抽时间重新做了一个测试框架，支持WEB\APP\WX 等名种请求自动测试，支持被测系统同时登录多种不同角色交叉自动对业务流程测试。
实现原理：
1、通过抓包把请求抓取出来，每个请求认为是一条接口CASE，把每个请求串联起来就是一系列的业务流，按顺序自动执行测试，再针对返回结果对数据做各种验证检查，最后输出测试报告。
2、抓取的请求里可能会有很多参数，参数里都带有真实的业务数据，只需把整个请求直接输入保存，各个参数从请求里自动获取，自动识别是POST还是GET请求，然后把各个接口上下文串联起来，设置好检查点便可以正常执行自动测试。如果CASE量很多，需要一条一条请求这样录入还是会比较麻烦，通过批量导入CASE数据一批一批导入，再简单设置便能执行测试，这样可以简化录入的操作，只要维护好CASE数据便能把自动化落地。
3、检查点分两种，一种是对请求返回的数据检查，另一种是直接检查数据库的业务数据，尽量做通用检查，无须为每条CASE去再编写测试代码，那样太耗时，除非特殊情况。
4、一条测试计划会有多条CASE组成，只要批量执行多条测试计划，便能轻易自动执行大量用例。
5、测试报告展示，测试报告是展示测试结果的地方，前面做的所有事情都是为了能输出测试报告。当然并不是为了出报告而出报告，这样没意义，从测试报告要能看到测试了哪些CASE，覆盖了哪些功能，在接口这一层面有没有出现问题，被测系统是否正常，也可以进一步分析测试结果，要从测试报告体现出自动化测试的价值，让测试变得是可靠的。（邮件报告部份截图示例，报告页面比较简单）
6、笔者认为自动化测试应该在技术的基础上，重心放在业务CASE设计和执行跟踪分析上，这是让自动化落地的根本，技术层面也需要持续优化做支撑。
以上仅代表个人观点（原创），转载或引用请标注来源，感兴趣可交流，QQ 280547241
