Jmeter 接口自动化框架 (一) 框架综述

本系列文章,除了总结自动化框架在部署和实践中的一些经验教训,也把自己的想法和经验做汇总,作为之后工作的一些参考,文章主要包括 Jmeter 工程的创建与配置,Jenkins 的安装与配置,Jmeter 测试结果持久化和测试报告的优化,脱离 Jenkins 并平台化几个主要内容组成。

背景

在上家公司的时候部署过一套基于git+maven+jenkins+jmeter的自动化框架给组内的接口自动化测试用,感觉该有的都有了,因为自己的主职还是性能测试,并没有具体参与到接口自动化的工作。今年初换了工作,入职后除了负责公司产品的性能测试外,也要负责自动化框架的搭建与完善,同时面试的时候也了解到公司已经有几个人在开发公司自己的接口自动框架,已经初具运行能力,两者并行有些对比的味道在里面。

已有工具集成 VS 自研工具开发

在面试时 CTO 有问过这个问题,我当时的回答是各有优缺点,自研工具可能更适合公司自己的项目,但大部分测试人员开发出的工具缺乏深度,因代码能力不佳使整个测试框架的完成度都不高,后续开发和扩展能力都不佳；而开发人员开发的自动化框架，因缺少对应的测试思想和实践，常常实际应用起来并没有那么顺手，一些新的测试需求并不能快速实现。现有工具集成也有不少问题，因功能都是现成的，缺少与具体公司的契合度，一些功能仍然需要二次开发才能解决，但更利用快速实现和使用业界相对来说已经比较成熟的功能。其实在面试的时候我是想进那个正在开发自动化框架的小组进行框架的开发工作的,但了解到现开发的框架是 PHP 开发的,想想就算了,重拾起 PHP 开发一套仅仅是接口自动化框架还是有些得不偿失的；Python 这两年流行起来，现在业界比较主要的还是用 Python 开发自动化接口框架，各种方案开发的测试框架，在之前的一篇博客的有提到优缺点，这里就不做对比了，我个人还是趋向于 Jmeter 的二次开发的，并且可以通用于本来的性能测试，于是建意用 Jmeter 集成的方案，用两套方案并行的方法，给公司对比选择及试错。

Jmeter 自动化框架的优缺点

Jmeter 是相当成熟的一个测试工具了，这个工具本来是用来做性能测试的，因服务器性能测试一般也是操作接口，所以也有不少公司拿来做接口测试。之前做性能测试主要用 Loadrunner，Jmeter 只是接触过一些，没有深入去用，不过二两思想还是差不多的，入职之前撸了遍 Jmeter 的源码，工作原理和核心组件算是基本有个了解。Jmeter 因为是开源的，更利于二次开发，也更适合集成，好像 Loadrunner 除了 HP 的那套 PC（性能测试中心）也可以算成 Loadrunner 持续集成框架，但因是商业作品，很多人接触的并不多，并且 PC 用起来貌似也并不怎么好用。Jmeter 的缺点和 Loadrunner 一样，都是缺乏对测试脚本的管理和维护，经常是触一发而动全身，一个接口或测试组件的改动往往要修改全部脚本中相关接口，维护成本比较高昂。

Jmeter 自动化持续集成方案

用 Jmeter 做自动化的持续集成如果不进行大规模二次开发的话，没并有过多的方案去选择，主要是利用 Ant 或 Maven 来执行 Jmeter 的脚本，用 Jenkins 来触发构建任务，用 git 或 SVN 来管理脚本,用几个 Jenkins 的插件来显示报告和邮件通知。我这里主要是选择的git+maven+jenkins+jmeter这一套方案，后续再对此框架进行逐步二次开发和优化，其功能组件和知识点如下表。

同时还需要一些插件,在操作过程会具体细说。整个框架的大概流程扩通俗点的执行流程来描述大致是触发jenkins构建-->触发git插件拉取源码-->触发maven开始构建-->交给jmeter-maven-plugin插件解析命令-->执行对应的脚本执行命令-->交给Jenkins的报告解析插件—来完成页面解析和保存-->交给Jenkins的邮件插件来完成邮件通知功能.，先完成这个框架后再针对框架的各个缺点再慢慢进行改进。

下章主要内容

下单主要是创建本地 JAVA 工程及 Jmeter 如何高效引用 JAVA 方法等工程相关的创建及配置。