【前言】自动化测试算是近几年比较火热的一个话题，当然更是未来软件测试的一个发展趋势。在当前互联网产品迭代频繁的背景下，回归测试的时间越来越少，很难在每个迭代都对所有功能做完整回归。但接口API（Application Programming Interface）自动化测试因其实现简单、维护成本低，容易提高覆盖率等特点，越来越显得重要，这篇文章我们就说说接口测试以及接口自动化的那些事。
– 【接口测试的必要性和意义】 –
接口测试实施在多系统的平台架构下，有着极为高效的成本收益比（当然，单元测试收益更高，但实施单元测试的成本投入更大，技术要求更高，所以选择更适合自身才是最好的方案）。
接口测试天生为高复杂性的平台带来高效的缺陷检测和质量监督能力，平台越复杂，系统越庞大，接口测试的效果越明显。
总的来说，接口测试是保证高复杂性系统质量的内在要求和低成本的经济利益驱动作用下的最佳方案，主要体现在如下三个方面：
1. 节省了测试成本
根据数据模型推算，底层的一个程序BUG可能引发上层的8个左右BUG，而且底层的BUG更容易引起全网的死机；接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。
2、接口测试不同于单元测试
接口测试是站在用户的角度对系统接口进行全面高效持续的检测。
3、效益更高
将接口测试实现为自动化和持续集成，当系统复杂度和体积越大，接口测试的成本就越低，相对应的，效益产出就越高。
– 【接口自动化测试】 –
那么问题来了，既然接口测试这么优秀，那还要接口自动化测试做什么？
首先现在的互联网环境版本迭代是相当频繁的，留给测试时间本来就不多，如果想靠人工去做回归测试是不可能做到的。所以这个时候就需要引入接口自动化测试，来提高测试效率，提升用户体验，降低产品研发成本。同时接口测试可以保证系统的正确和稳定，而持续集成是接口测试的关键，否则接口测试带来的工作量会成指数级增长。
接口自动化测试的流程主要是：
1. 自动化框架
什么是框架？你可以理解为一个完整的环，也可以理解为让接口测试脚本运行的一整套环境，平台等。目前我使用的测试框架是：
bootstrap+springboot+Jenkins+maven+jmeter
系统的架构图大致如下：
2. 执行过程
a. 编写测试用例，测试用例分为两种：单接口测试用例、流程测试用例。单接口测试用例有一套固定的模板，记录在csv文件中，如果测试接口有改动只需要修改csv文件即可；流程测试用例记录在jmx文件中。
b. 把测试用例提交到git，然后jenkins脚本会把用例自动同步到测试平台。
c. 登陆大数据测试平台（之前在直击拍拍贷可视化测试平台中已介绍过），选择被测项目->选择测试用例，执行测试。PS：把接口自动化功能集成到大数据测试平台可以方便开发或者其他部门的小伙伴进行自测、联调等。
d. 测试过程中可查看执行日志，方便知道执行进度和错误情况等。
e. 查看测试报告，如果执行过程中有用例报错，会在报告里记录对应的请求url、请求参数、响应结果以及失败原因。
– 【总结】 –
这套框架的好处有以下几点：
1. 把回归测试的用例做成了可视化界面，并且做了权限控制，可以移交给开发进行自测、联调等。
2. 把单接口测试用例做成模板化，测试小伙伴只需要在csv文件里面添加一行记录就可以把造测试数据、发送接口请求、对接口返回的数据进行校验、对接口请求后数据库里新增或变更的数据进行校验这些繁杂的步骤统统完成，同时测试平台也支持流程性测试用例。
所谓流程性测试用例就是执行过程中某个接口的请求参数是前面一个或者几个接口的返回值，而且请求的参数和这些返回值之间还可能存在某种逻辑关系，对于这样的情况我们用jmx文件去处理的，直接利用jmeter自身的功能可以免去不少繁杂的工作。
3. 对测试结果进行了模板化、可视化输出。不管是单接口测试用例，还是流程性测试用例执行完成后都会生成一个xml文件，我们把这个xml文件根据统一的xsl样式表进行解析生成html文件。
4. 可以对服务器进行监控，只要服务器上有代码变更就自动执行回归测试，并且发送测试报告。
黄清