Jenkins+JMeter的接口自动化测试方案落地实践

Jenkins+JMeter的接口自动化测试方案落地实践

背景：

CI/CD是很早就出现的一个模式，随着公司的发展，相信很多公司都在考虑使用这种模式，市场上也有层出不穷的平台提供服务，但是考虑到自主可控的问题，还是有很多公司想研发一套属于自己的CI/CD模式，当然网上很多文章都讲过CI/CD，也不乏CI/CD相关的工具组合，实现过程也尽不相同，面对五花八门的选择，很多人会犹豫怎么选型，才能达到以较少的技术成本实现并落实CI/CD,从而保证开发质量，提高测试效率。其实很简单，符合公司现状的技术方案就是最优方案，一般是考虑测试人员的工具基础和编码基础，以及公司使用的项目管理工具，以少数服从多数的原则进行选型。需求/项目管理的部分在此不会赘述，作为一名测试人员，仅以测试的角度给大家分享。

起初的构想：

我们工作中使用的聊天工具是企业微信，与TAPD属于一个厂商，我们之前已经实现在TAPD和jenkins的集成（集成方式比较简单网上有很多现成的资料），所以我们可以在TAPD上构建每个微服务的发布，并且在构建的同时添加Sonar扫描的功能。基于这种情况我们查看了TAPD和Jenkins的官方文档，发现接口自动化也是可以集成进去的，而且我们测试部门使用最广泛的接口工具就是Jmeter（主要原因还是因为这个工具是开源可控的），如果能把Jmeter也集成进去，那么CI/CD就成功了，基于这种构想，我们进行了探索。

探索：

探索一：
基于我们起初的构想，我们进行了进一步的探索和实践，首先Jmeter可以用于接口自动化，而且可以通过 “jmeter -n -t 脚本路径和名称 -l 日志名.txt -e -o 报告文件路径和目录名称”的方式执行测试用例，生成测试报告，然后与jenkins的流水线进行集成，然后再将测试报告展示在微信群或TAPD中，简单粗暴。
具体方式如下：
首先在服务器上安装JDK，然后安装Jmeter工具、配置环境变量（网上有很多这种教程），将Jmeter脚本文件,这里以testdemo.jmx为例，将此文件放置到Jmeter的bin目录下，然后运行 “jmeter -n -t 脚本路径和名称 -l 日志名.txt -e -o 报告文件路径和目录名称”命令，逻辑大致是，首先在bin目录下找到testdemo.jmx文件，然后运行这个文件，运行完之后会在此生成一个临时文件夹，测试报告等相关文件放在此文件夹下，但是这个方式经过测试是可以正常运行的，没有任何的报错信息，但是无法生成测试报告，在生成的测试报告里只有一个.jtl文件，如下图：

从图中可以看出，脚本正常运行，但在生成测试报告这个文件夹内，文件不全，所以我们针对这个问题寻找解决办法，首先我们尝试过修改配置文件jmeter.properties将csv改成html，将reportgenerator.properties下面的jmeter.reportgenerator.exporter.json.classname=org.apache.jmeter.report.dashboard.JsonExporter
jmeter.reportgenerator.exporter.json.property.output_dir=report-output
注释掉，以及更换jdk版本，更换jmeter版本，都不能解决这个问题。所以我们开始考虑其它方式实现。
探索二：
基于jmeter在linux环境下无法生成测试报告的情况，我们又引进了一个ant插件，步骤如下：在服务器上安装ant，配合环境变量，然后将build.xml放到jmeter的bin目录下(最好新建一个文件夹)，将jmeter-results-shanhe-me.xsl放到jmeter/extras目录下，这里需要注意的是build.xml里有需要注意的事项，
1、build.xml里不能加时间戳：${time}

<property name="ReportName" value="TestReport" />
<property name="jmeter.result.jtlName" value="${jmeter.result.jtl.dir}/${ReportName}${time}.jtl" />
<property name="jmeter.result.htmlName" value="${jmeter.result.html.dir}/${ReportName}${time}.html" />
1
2
3

2、这里必须这么写：target name=“run”

<target name="run"> <!--固有信息，无需改动-->
<antcall target="test" />
<antcall target="report" />
1
2
3

3、保证build.xml里的路径是正确的

<!-- 需要改成自己本地的 Jmeter 目录-->
<property name="jmeter.home" value="/usr/jmeter/apache-jmeter-5.5" />
<property name="report.title" value="自定义报告名称"/> <!--报告名称：可自定义-->
<!-- jmeter生成jtl格式的结果报告的路径-->
<property name="jmeter.result.jtl.dir" value="${jmeter.home}/bin/TestDemo/report/jtl" /> <!--注意格式/-->
<!-- jmeter生成html格式的结果报告的路径-->
<property name="jmeter.result.html.dir" value="${jmeter.home}/bin/TestDemo/report/html" />
1
2
3
4
5
6
7

这些配置完成后，可以在存放buildx.xml路径下执行ant run命令测试一下如图：

可以看到运行正常，成功生成测试报告
接下来：
我们就可以对此进行jenkins的流水线配置了，流水线的配置也十分简单，直接将ant运行jmeter的命令放入到流水线里即可（这里不单独讲pipline的流水线语法）如图：

最后可以将测试报告通过webhock集成到TAPD中，至此方案二的探索已经完成
可以看出配置比较复杂，需要运维人员做很多的配置，测试人员只需输出jmx脚本，将jmx脚本通过git或svn的方式放到jmeter的bin目录下即可。

探索三：
我们通过第二次的探索已经完成了我们最初的构想，让它成为了一个落地的方案，但是还是不够简便，而且对于运维人员来说配置起来比较复杂（虽然可以写成配置脚本），于是我们开始了第三次的探索。
首先：
我们的开发工具里，可以通过pom文件加入 jmeter-maven-plugin 依赖
添加JMeter支持比较简单，只需要再pom.xml文件中增加相关依赖和构建插件即可。添加完成后运行 mvn install 或mvn clean package 命令会在target目录生成jmeter文件夹，里面包含了相关测试报告。
具体步骤内容如下：

添加依赖包<!--开始jemeter-->
<dependency>
    <groupId>org.apache.jmeter</groupId>
    <artifactId>ApacheJMeter_core</artifactId>
    <version>5.0</version>
   <exclusions>
      <exclusion>
         <groupId>org.apache.logging.log4j</groupId>
         <artifactId>log4j-slf4j-impl</artifactId>
      </exclusion>
   </exclusions>
</dependency>
<dependency>
   <groupId>org.apache.jmeter</groupId>
   <artifactId>ApacheJMeter_java</artifactId>
   <version>5.0</version>
   <exclusions>
      <exclusion>
         <groupId>org.apache.logging.log4j</groupId>
         <artifactId>log4j-slf4j-impl</artifactId>
      </exclusion>
   </exclusions>
</dependency>
<dependency>
   <groupId>org.apache.jmeter</groupId>
   <artifactId>jorphan</artifactId>
   <version>5.0</version>
   <exclusions>
      <exclusion>
         <groupId>org.apache.logging.log4j</groupId>
         <artifactId>log4j-slf4j-impl</artifactId>
      </exclusion>
   </exclusions>
</dependency>
<!–结束jemeter-->
添加构建plugin(若项目中的pom.xml文件已存在build相关内容只需按xml层级追加进去即可)
           <build>
               <plugins>
                    <plugin>
                         <groupId>com.lazerycode.jmeter</groupId>
                         <artifactId>jmeter-maven-plugin</artifactId>
                         <version>2.8.0</version>
                         <executions>
                              <execution>
                                   <id>jmeter-tests</id>
                                   <phase>package</phase>
                                   <goals>
                                        <goal>jmeter</goal>
                                   </goals>
                              </execution>
                         </executions>
                   </plugin>
               </plugins>
           </build>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

而运维人员要做的就是将mvn install 或mvn clean package 命令放到流水线命令里，在构建的时候会在target目录生成jmeter文件夹，里面包含了相关测试报告，然后将测试报告通过企业微信的机器人推送出来。
测试人员此时也成为了开发中的一员，负责输出jmx脚本，通过git将测试脚本提交到服务器，用以更新测试脚本，结果如图：

可以明显看出第三次探索时，实现方式更简洁和方便，不需要运维配置安装各种环境。至此第三次探索完成，我们实现了从TAPD的需求管理-用例管理-bug管理-代码管理-自动化测试的工作流程，实现了我们公司的CI/CD模式，并针对这种模式制定相关的标准文件进行执行。

谢谢大家的捧场，后续会继续在测试的道路上奋进，希望对与我们有类似场景的兄弟公司能有所帮助。