前言
我前后在公司呆过多个项目，接触过各种测试团队，前后调研并落地过多款接口自动化框架，如：
- （java）HttpClient + Junit + Maven
- （java）HttpREST Assured + TestNG + Maven
- （Python）Robot Framework + Requests
在各个框架使用的过程中，也遇到了各种各样的问题：
-
纯代码自主研发的框架：
（1）优点在于非常的灵活，新增功能方便快捷。
（2）缺点是稳定性和可维护性较差；组内会代码的人较少，日常编写接口自动化的人也较少，不熟悉代码也没法深入的编写用例；接口较多时，维护成本也较高，长时间没人维护后，形同虚设。 -
现有工具搭建的框架：
（1）优点在于易上手，组内接受度普遍较高。
（2）缺点是限制较多，增加功能需要较长的时间去改动原框架，或者用其他方式完成。
那么是否有一套框架能够兼顾稳定，易上手，可维护性方便的接口自动化框架呢？
答案当然是：有，使用JMeter来作为接口自动化的框架的核心部分。如果你没有任何搭建接口自动化框架的建议，推荐你使用JMeter来搭建框架，一方面会让你熟悉整体的架构流程，另一方面，搭建起来非常方便，在网上也能找到很多的参考资料解决问题。
JMeter作为一款成熟的接口测试工具，有着如下优点：
- 稳定性非常好，而且支持多种不同类型的协议，技能做Http接口测试，还能测试Double接口。
- 支持丰富的断言，而且支持内嵌你自定义脚本，在做接口测试的同时，还能直连DB检查数据。
- 易用性好，带图形界面，几乎组内接触过接口测试的都会使用JMeter；
- 开源，无限的可能性。
当然，JMeter也不是完美的，在使用过程中，也遇到了缺点：
- beanshell调试不方便。
- 用例较多时，看用例不是很一目了然。
那么下面的章节，就为大家介绍一下怎么用JMeter搭建一套适合自己项目接口自动化框架。
整体架构图
整套框架主要分为以下几个部分：
- JMeter：接口用例的编写。
- Ant：执行接口测试，并生成报告。
- Jenkins：定时构建，分析并归档报告，邮件预警。
- Caddy：展示测试报告。
- Gitlab：接口用例多人协作和版本管理。
最终可以有两个地方可以查看测试结果：
- 静态页面展示：
- 邮件报警提示：
当然，也可以使用企业微信来做提示。
架构知识体系图
整套框架的知识体系重点还是在JMeter工具的使用。
JMeter目录结构图
设计思路：
目录结构：
- 为了更好的复用和管理用例，在编写测试用例的时候，需要对用例的层次进行一些划分。
- 为了部署时更加灵活，脚本中互相引用的文件需要使用相对路径。但JMeter支持不太好，默认的跟目录是bin，所以最简单的做法是将整个用例放在其中。
API（接口层）
- 放置单次接口请求，为整体架构的最底层结构
Function（功能层）
- 功能层用例是复用的基础，里面包含了对单接口的调用，建议用Test Fragment来组织。
- 可以将多个功能用例组装成一个场景用例，使用单独一个sampler或者多个sampler组合，而且一般会使用Transaction controller（事物控制器）包含，如果sampler里面的变量需要传递使用vars.get方法获取。
- 为了接口测试严谨性，一般功能层，会跟随sampler绑定这个接口的必填参数测试的简单控制器，方便阅读。
（Testcase）用例层
- 所有用例的最上层，是由线程组通过Include Controller调用Test Fragment的测试用例（功能层）来直接运行的，也是最后输出的报告展示结果。
- 用例层中的用例没有依赖关系，是独立存在的，可以顺序或者乱序组合，互不干扰。
- JMeter对线程组，不需要勾选【独立运行每个线程组】，如果勾选会导致用例串联运行速度比较慢。
（Config）配置层
- 所有用例都需要使用的变量可以通过调用config里面的配置文件。
总结
一款好的接口自动化框架需要满足如下条件：
- 稳定性好：不会因工具本身导致用例执行异常或失败。
- 扩展性高：不仅能能支持各种接口协议，也能很好的对DB，Redis进行数据验证。
- 易用性好：使用门槛低，可以让更多的人参与进来。
- 可维护性好：在不断的版本迭代中，遇到重大的接口变更，不需要花费很长的时间去更新即可使用。
- 支持多平台：mac os，windows，linux均支持，便于各种环境下编写部署测试用例。
- 结果展示：有完善的接口失败报警和测试报告展示界面。
除了技术层面，自动化执行的过程中还有几个建议值得考虑：
- 一定要强挂钩到测试和发布的环节。如果不希望自动化测试成为花瓶，必须要这样做。如果自动化不能实际地在项目中发挥效果，就很容易被荒废。目前来看最合适的点是在每次自动部署后快速地把自动化用例执行一遍，这要在手工测试开始之前。这也是持续集成的思路，可以快速地发挥自动化的价值。
- 报告也需要自动化的发出来，并且邮件抄送给相关的开发人员，测试人员和团队负责人。这样可以让大家快速地关注到结果。
- 非100％成功的都要跟进。宁愿少而精，就像“破窗理论”指出的，如果能容忍一个用例失败，就会有2个、3个，也会让自动化慢慢失去意义。我们的做法是只要有失败，对应系统的测试负责人员需要进行定位并邮件回复出问题原因和处理措施。
- 需要关注用例的细节。测试团队的负责人需要去关注用例的质量，而不只是用例的数量和执行情况，比如断言做到什么程度，哪些自动化数据是写死的，哪些参数化了，功能之间的复用情况，这些都是影响整个自动化的稳定性和可维护性的具体方面。