Jmeter+maven+Jenkins构建云性能测试平台（mark 推荐）

转自：http://www.cnblogs.com/victorcai0922/archive/2012/06/20/2555502.html

Jmeter+maven+Jenkins构建云性能测试平台(一)

最近在利用Jmeter来作一套自动化性能测试框架，作自动化性能测试框架的目的 是但愿可以针对系统作一个benchmark的性能测试，可以快速的在每一个版本发布后，对该版本进行benchmark性能测试，以比较与上一个版本的性 能是否发生变化，若发生变化即可以快速的通知开发人员以肯定性能发生变化的模块或者代码。同时测试或者开发能够上传性能测试脚本到测试平台,测试平台接到 测试脚本后就能够进行性能测试并返回测试结果.基于这一点的考虑是,通常的测试工程师(特别想功能测试工程师)和开发工程师可能没有相关的性能测试环境供 他们使用,所以创建这样的平台就是但愿可以让每一个人都能快速的进行性能测试,而不须要关注性能测试环境(每每配置一个性能环境可能须要很长的时候).

1.框架简要介绍

选择Jmeter来搭建这样一个平台是基于Jmeter自己的Open source, 而且是用纯JAVA开发的测试工具，方便与其余的工具的集成和扩展。最重要的是，你能够看到源码。

这套框架基本的执行流程和逻辑其实很简单，利用Jenkins的CI功能，实时检查脚本库，如有变动便调用JMeter来执行脚本，并将测试结果经过邮件或其余方式通知相关人员。主要逻辑图以下所示：

2. Maven执行Jmeter

MAVEN是一个很是优秀的项目管理工具，关于Maven和Ant的主要区别能够去网上查询，咱们在这里主要介绍一下用MAVEN如何去运行 JMeter， JMeter支持多种运行方式，有GUI方式和NONGUI方式，各有优点，咱们在自动化性能测试平台的搭建中采用NonGUI方式来运行测试脚 本，NonGuI方式其实也就是经过Command命令来运行，那么如何经过Maven来调用呢，不用慌张，已经有Jmeter-maven- plugin这样一个Maven插件来运行Jmeter了，若是看过Jmeter源码的话，能够看到在Jmeter中有这样一个Class，叫作 NewDriver.class，这个类是Jmeter的入口，咱们能够看一下这个类的Main方法：

看到try模块中的最后几行能够看到，经过Java反射机制，JMeter.start()方法被调用到，而且将相关的参数传递给该方法。所以咱们 能够想象到JMeter-maven插件中确定也是经过调用这个方法来启动JMeter的，咱们来看一下JMeter-maven-plugin这个插件 （关于如何开发maven插件在这里不具体讲，能够参考网上资料）中的主要调用代码：

重点参考TestManager这个类，这个类是主要用来启动Jmeter的，咱们能够参考这个类中的executeSingleTest(File test)这个方法：

这个方法验证了咱们刚才这个猜测。在完成经过MAVEN启动Jmeter的分析事后，咱们所要作的事情就是如何解析Jmeter运行后所获得的测试结果，并将这个测试结果以相关的格式展示出来。

关于如何具体解析Jmeter执行结果将在下篇Blog中具体阐述。

 

Jmeter+maven+Jenkins构建云性能测试平台(二)

继上篇Blog，本篇将重点介绍利用Maven并开发插件解析Jmeter生成的 报告，因而就有Jmeter-analysis-maven-plugin这个插件，这个插件是由Aren Franka开发的，可是当你使用这个插件的时候会发现，它只能解析Http request请求的报告，不能解析如Webservice request请求的报告以及其余请求的报告，这是因为这个插件的代码中存在一个bug，因而本身动手修改了这个bug，由于经过Nongui生成的 Jmeter报告是以.jtl结尾的相似于xml的文件，所以在Jmeter-analysis-maven-plugin这个插件中会采用SAX来解析 报告文件。具体来看一下Jmeter报告文件的格式：

 

<?xml version="1.0" encoding="UTF-8"?> <testResults version="1.2"> <sample t="49" lt="0" ts="1339404299860" s="true" lb="PoscPaymentServiceImplService" rc="200" rm="OK" tn="posc 1-1" dt="text" by="713"/> <sample t="45" lt="0" ts="1339404301064" s="true" lb="PoscPaymentServiceImplService" rc="200" rm="OK" tn="posc 1-13" dt="text" by="713"/> <sample t="45" lt="0" ts="1339404301166" s="true" lb="PoscPaymentServiceImplService" rc="200" rm="OK" tn="posc 1-14" dt="text" by="713"/> <sample t="53" lt="0" ts="1339404301266" s="true" lb="PoscPaymentServiceImplService" rc="200" rm="OK" tn="posc 1-15" dt="text" by="713"/> <sample t="49" lt="0" ts="1339404301362" s="true" lb="PoscPaymentServiceImplService" rc="200" rm="OK" tn="posc 1-16" dt="text" by="713"/> <sample t="129" lt="0" ts="1339404301465" s="true" lb="PoscPaymentServiceImplService" rc="200" rm="OK" tn="posc 1-17" dt="text" by="713"/> <sample t="51" lt="0" ts="1339404301564" s="true" lb="PoscPaymentServiceImplService" rc="200" rm="OK" tn="posc 1-18" dt="text" by="713"/> <sample t="55" lt="0" ts="1339404301665" s="true" lb="PoscPaymentServiceImplService" rc="200" rm="OK" tn="posc 1-19" dt="text" by="713"/> <sample t="53" lt="0" ts="1339404301764" s="true" lb="PoscPaymentServiceImplService" rc="200" rm="OK" tn="posc 1-20" dt="text" by="713"/> </testResults>

 

 

这是一个webservice请求所获得的测试结果，因此每一个请求都是以sample开始的，若是是http请求的话，会以httpsample开 始，你们能够在个人代码中看到我用了一个hashset将这两种element都放在里面，而后经过判断是否存在相关的element来解析报告，原代码 中只考虑了http这种状况，不过我已经email给aren，他已经修复了这个bug。下面咱们具体看一下每一个属性的含义，其中ts表示每一个样本结束的 Timestamp，s表示请求的状态，成功为true，失败为false，lb表示请求的名称，rc表示请求的response code, rm表示response message，tn表示thread name，dt表示data type, dy表示data byte。经过解析这个xml文本咱们能够生成这样一个请求结果：

经过解析能够获得response time, tps等，还能够生成图表以下所示：

这个能够看到是请求的表现图。

Aren在开发Jmeter-analysis-maven-plugin这个插件的时候已经提供了，生成html,cvs, chart几种方式，我在代码中增长了一种方式就是将测试结果存入数据库。

具体你们能够看我后续在github上上传的代码。Aren在开发该插件的时候没有将Tps, VUser这些数据放在报告中，我也在代码中作了一些修改来展现这些数据。

总而言之使用这个插件能够很方便的来进行性能测试，咱们只须要将上一篇blog所提到的关于Jmeter-maven-plugin结合本篇文章所 提到的Jmeter-analysis-maven-plugin结合起来使用即可以方便的构建各类测试场景，咱们只须要在pom.xml中进行以下配 置：

 

<plugin> <groupId>${project.groupId}</groupId> <artifactId>jmeter-maven-plugin</artifactId> <version>${project.version}</version> <!-- configure different executions of the plugin --> <executions> <execution> <!-- 1) first test run warms up the webserver. Used to fill caches. With a different set of properties since it runs much shorter than a normal test and also the rate of requests/second may be much lower. Maybe also use a different URL set. --> <id>warmup</id> <phase>integration-test</phase> <goals> <goal>jmeter</goal> </goals> <configuration> <propertiesUser> <!--Accesses urls for warmup (compiles JSPs, fills caches, ...)--> <threadgroup00.name>warmup</threadgroup00.name> <!--number of threads to use--> <threadgroup00.numberOfThreads>1</threadgroup00.numberOfThreads> <!--delay of the test in seconds--> <threadgroup00.scheduledDelay>0</threadgroup00.scheduledDelay> <!--duration of the test in seconds--> <threadgroup00.scheduledDuration>30</threadgroup00.scheduledDuration> <!--how long till all threads are up and running in seconds--> <threadgroup00.rampUp>1</threadgroup00.rampUp> <!--target throughput of all threads of the group per minute--> <!-- <threadgroup00.throughput>100000000</threadgroup00.throughput>--> <!-- use uris from given file --> <!-- <threadgroup00.dataFile>${webapp.uris}</threadgroup00.dataFile> --> </propertiesUser> </configuration> </execution> <execution> <!-- 2) Performance test --> <id>test</id> <phase>integration-test</phase> <goals> <goal>jmeter</goal> </goals> <configuration> <propertiesUser> <!--A user which accesses all URLs--> <threadgroup00.name>posc</threadgroup00.name> <!--number of threads to use--> <threadgroup00.numberOfThreads>30</threadgroup00.numberOfThreads> <!--number of loops--> <threadgroup00.numberOfLoops>2</threadgroup00.numberOfLoops> <!--delay of the test in seconds--> <threadgroup00.scheduledDelay>0</threadgroup00.scheduledDelay> <!--duration of the test in seconds--> <threadgroup00.scheduledDuration>30</threadgroup00.scheduledDuration> <!--how long till all threads are up and running in seconds--> <threadgroup00.rampUp>2</threadgroup00.rampUp> <!--target throughput of all threads of the group per minute--> <!-- <threadgroup00.throughput>100000000</threadgroup00.throughput>--> <!-- use uris from given file --> <!-- <threadgroup00.dataFile>${webapp.uris}</threadgroup00.dataFile>--> </propertiesUser> </configuration> </execution> </executions> <!-- general configuration for all executions --> <configuration> <!-- configure which testplans to use --> <testFilesIncluded> <testFilesIncluded>PoscPaymentServiceImplService.jmx</testFilesIncluded> </testFilesIncluded> <!-- protocol, server and port of tested webapp --> <propertiesUser> <protocol>${webapp.protocol}</protocol> <server>${webapp.host}</server> <port>${webapp.port}</port> </propertiesUser> </configuration> </plugin> <plugin> <groupId>${project.groupId}</groupId> <artifactId>jmeter-analysis-maven-plugin</artifactId> <version>${jmeter.analysis.maven.plugin.version}</version> <executions> <execution> <goals> <goal>analyze</goal> </goals> <phase>post-integration-test</phase> <configuration> <!-- source file that contains jmeter result data. Needs to be XML format or a GZIPed XML format --> <source>${project.build.directory}/jmeter/results/PoscPaymentServiceImplService-120613.jtl</source> <!-- directory where to store analysis report files. At least a file "summary.txt" will be stored here. --> <targetDirectory>${project.build.directory}/reports</targetDirectory> <!-- Defines groups of requests by URL patterns, e.g. URIs starting with /mock/page are associated with group "pages". All analysis results are If there is no such mapping then the threadgroups from the jmeter.xml are used. --> <!--<requestGroups>--> <!--<test>/en-US/firefox/**</test>--> <!--</requestGroups>--> <!-- If set to true, additional files "<category>-sizes.csv" and "<category>-durations.csv" will be stored. These files contain detailed information for response size and response durations for every URI. --> <generateCSVs>true</generateCSVs> <!-- If set to true, additional chart files "<category>-durations.png" will be created. --> <generateCharts>true</generateCharts> <!-- The database configuration --> <userName>xxx</userName> <passWord>xxx</passWord> <dataBase>xxx</dataBase> <host>xxx.xxx.xxx.xxx:3306</host> <!-- Mapping from resource URL to file name. Every resource will be downloaded and stored in 'targetDirectory' with the given filename. Tokens "_FROM_" and "_TO_" can be used as placeholders. These placeholders will be replaced by timestamps of execution interval (formatted as ISO8601, e.g. '20111216T145509+0100'). --> <!--<remoteResources>--> <!--<property>--> <!--<name>http://yourhost/path?from=_FROM_&amp;to=_TO_</name>--> <!--<value>my_resource.txt</value>--> <!--</property>--> <!--</remoteResources>--> </configuration> </execution> </executions> </plugin>

 

 

 

即可以完成一个测试场景，关于具体每个element，这里不作详细解释，由于在注解中已经写的很详细了。关于如何配合CI构建云测试平台将在下一篇blog中继续阐述。

 

Jmeter+maven+Jenkins构建云性能测试平台(三)

继上篇blog，本篇咱们具体讨论一下，如何利用Jenkins作持续的性能测 试，前面咱们说过由于互联网软件发布频繁，须要作到小步快跑，快速反馈，咱们在自动化，接口测试的时候已经可以作到快速反馈，因此但愿性能测试一样可以快 速反馈，咱们但愿的是可以构建一个云性能测试平台，这样可以让开发工程师，功能测试工程师都参与到性能测试中来，而不只仅是由性能测试工程师在功能测试之 后再进行性能测试，总之快速反馈问题是互联网软件测试的宗旨。

下面具体谈一下咱们是如何利用Jenkins来执行性能测试的，关于Jenkins的具体设置再也不这里作介绍.

首先咱们利用了git来作咱们的脚本库，关于为何选择git而不是subversion,你们能够去网上搜一下git和svn的区别。

其次持续性能测试有两个触发条件，第一个条件是当开发提交并发布新的版本的时候。第二个条件是性能测试脚本库脚本发生提交或者更新事件。

最后咱们来配置咱们的Jenkins build Job:

1.源码管理：

2.构建触发器：

3.构建后操做：

第三步解释一下,jenkins自己有一个Jmeter插件能够用来显示jmeter的一些执行结果.可是显示的结果有点粗糙.

如下这个图是咱们本身解析后产生的结果:

从上面两个图中能够看到具体性能指标信息.

固然这里尚未包括服务器性能指标的收集,这个性能指标为的是快速的可以将一些基本的信息,如TPS，RESPONSE TIME,Standard devitation反馈给开发人员。

开发人员和测试人员能够将本身的测试脚本上传到脚本库里面，并在Jenkins里面配置好job，即可以利用Jenkins去调度和执行性能测试，并反馈测试报告。这个过程

相似云平台，解决了开发工程师和功能测试工程师没有具体的性能测试环境，也解决了性能测试及时性的问题，将性能测试前置到应用开发的各个阶段，而所须要的仅仅是

上传一个测试脚本，数据在云端已经帮你准备好。这就是所谓的云测试平台。

 

TPS这块的代码是做者本身加上去的，源码地址：https://github.com/victorcai0922/JmeterRunner

https://github.com/victorcai0922/JmeterAnalysis这两个工程要配合适用由于是有pom互相依赖的，JemterAnalysis有一个缺陷，个人工程中有修复的代码。