对 Jenkins+ANT+Jmeter 接口测试的实践

转载地址：https://testerhome.com/topics/5262

1、前言

最近感觉大家都在讲Jenkins+jmeter+ant或maven的使用，但没有说到具体怎么投入到项目使用，只有比较基本的流程说说，所以我今天要说的就是我是怎么将这个方案投入到实际中使用的，先说明一下，本人是今年4月份才开始学jmeter和ant，之前做性能测试是用loadrunner，接口测试使用RobotFramework+Request来做的，loadrunner用来做简单接口测试太笨重而且成效不高，RobotFramework+Request虽然可以使用数据驱动模式，但测试报告就会显示很鸡肋，因为基本是一个测试用例在循环，所以后面使用了Jenkins+jmeter+ant的方案

2、框架与数据准备

在做接口测试框架之前，我研究了一下jmeter工具特征和本身项目接口的特征，jmeter是以请求为单位，不是以脚本或测试用例为单位，既然这样，我就可以每次循环获取接口或对应数据进行测试了，加上之前在testerhome上看到一些大神写的接口测试框架，其实框架是死的，思想是活的，利用这个活的特点，后面就想了一套比较简单的框架，可以看下图

是的，我的测试数据是用Excel管理的，Excel的测试数据可看下图

从数据格式可以看出，做了用例的执行标识，选中为YES时才执行，NO时不执行，这是一个用例选择执行的简单设计，还有请求的方法也是可以选择的，目前项目中的主要用POST和GET，除此之外之后要获取的还有用例名，调用的接口和具体的测试请求数据，这就是使用excel管理测试用例的模块
数据准备好以后做一些全局或初始的配置，一般就是改jmeter.properties里面对应的配置

是的，里面这行本来是默认指定为user.properties，但有自己个性化的需求，例如服务器和测试账号

配置基本完成，之后就是项目的目录架构,conf就是放配置文件的，如myuser.properties，jmx就是对应的脚本，report是输出的测试报告路径，res是一些上传文件所用的测试资源等，test_data是为后期性能测试作准备的，现在先忽略，test_suite就是放excel表格的，build.xml就不多说了，就是ant的执行文件

3、脚本设计

好吧，接下来就是jmx脚本的设计，如下图，这是一些变量的设置

还有上文提到用myuser.properties配置的，这些在jmeter中作为变量来使用

然后对于读取数据，我是用了beanshell写了简单的java读取excel的脚本构建起与测试数据的连接，首先是先获取测试用例数，用于设置执行循环请求的次数，这里是用前置处理器的方式获取数据的，前置处理器需要sampler紧接着在其后使用，不然是不会执行的，所有我把它放在了登录的请求里面

具体的代码：

String filename=vars.get("test_data");

String [] datalist=new String[20];

String content;

InputStream openfile = new FileInputStream(filename);

Workbook wb = Workbook.getWorkbook(openfile);

Sheet FirstSheet = wb.getSheet(0);

int totalRows=FirstSheet.getRows();

int rows=totalRows-1;    //减1是因为我标题行不取，为了后面从第二行开始取

String data=rows.toString();

vars.put("row",data);   //用例行数

wb.close();

然后获取正常的测试数据是用beanshell sampler，这个有个大坑，就是用sampler来获取数据的话到时在测试报告会显示出来，但实际上其不是测试用例，后面会说我目前是怎么破的，反正取数据的操作最好就是不要显示在测试报告的统计上,这里就是取到刚才所说的测试用到的值，执行标识load，用例名称testcase，调用接口inter，请求方法method，请求数据request以及预期结果断言response，之前就将他们作为变量传到脚本当中

具体的代码（补充说明一下，取excel我是用jxl.jar去读的，但有部分小伙伴喜欢用POI去读，反正原理都是一样的，像在平时编写代码那样导入包就好了）：

    int i;

    int k=0;

    String [] datalist=new String[20];

    String content;

    String filename=vars.get("test_data");

    String str=vars.get("rownum");

    int row = Integer.parseInt(str);

    InputStream openfile = new FileInputStream(filename);

        Workbook wb = Workbook.getWorkbook(openfile);

        Sheet FirstSheet = wb.getSheet(0);

        for(i=1;i<9;i++){                    //9是因为我表格就是9列的

            if (i!=5&&i!=6){            //表格中白色的两行不取

            Cell oCell= FirstSheet.getCell(i,row);

            content=oCell.getContents();

            datalist[k]=content;

            k++;

            }

        }

            vars.put("load",datalist[0]);     //标识

            vars.put("testcase",datalist[1]);   //用例名称

            vars.put("inter",datalist[2]);     //接口

            vars.put("method",datalist[3]);    //请求方法

            vars.put("request",datalist[4]);      //请求数据

            vars.put("response",datalist[5]);   ///断言校验

        return content;

执行的效果如下图，开始在登录完之后拿到测试用例的数量，作为循环的次数，做个计数器用来excel行的遍历，使用if控制器判断执行方法，如果是YES的话才执行请求，如果method是POST就是执行POST请求的http sampler，GET就执行GET请求的http sampler，然后输出的请求结果会有对应的用例名称，最后在响应断言中填上response变量，基本的脚本设计就完成了

具体http请求也是很简单的

4、整理测试报告

脚本设计完以后，用ant去执行jmx就可以了，至于怎么用ant去执行我就不多说了，去网上搜一下大把的教程，我这里是同时输出了两份测试报告，一份是作简单的统计用，就是jmeter-results-detail-report_21.xsl那份

还有是查看测试数据详情用的，就是jmeter-results-shanhe-me.xsl，两份报告之间做了一个比较简单的跳转，方便查看

其实在这里我是用了比较取巧的方法把之前取数据的sampler过滤掉了，不输出到html测试报告，打开输出的jtl看一下你就懂了

所以两份测试报告我也做了一些手脚，但这个不是明智的方法，只不过是没有办法中的办法，就是去改上文的两个xsl
统计的

查看数据的

其实这些也是我之后要优化的地方，只是目前太急要出个方案罢了

说了那么多，还没说到jenkins，至于怎么使用，可以看我之前写的文章：https://testerhome.com/topics/5099，大同小异，就是这样用就好

5、结束语

目前我所说的设计耗时不到两天，因为时间比较紧，就只能想出目前这个方案了，大家可以也留意到其实有很多地方是可以优化的，不过目前时间实在有点紧，所以目前只能在接口自动化测试的过程中不断地去优化框架，优化设计，毕竟目前对jmeter的使用也不是非常熟悉，才用了2个月，也希望大家多给我建议，让我可以用更好地方法去实践接口自动化测试，我只是个工作不到一年的新人，很多东西想不全是会有的，这里有很多大牛，都很值得我去学习，最后还是说那句，工具是死的，思想是活的，利用工具把自己的思想实例化为框架投入到实际应用中，这才是根本的道理，1000个人对jmeter可能有1000种用法，反正结合自己的思想和实际，总可以找到工具的价值，好，欢迎大家卖力地吐槽我，让我能好好反思一下设计上的问题，继续优化

=======================================================================================================================

是的，我感觉自己写也是会好一些，但写了还要自己维护，而且只有两天时间，写的话不仅是脚本，还有测试报告数据关联等东西要考虑，既然都做接口测试了，为何不把性能测试也留个切入点，如果能用两天把unittest和multi_mechanize或locust结合起来做接口性能测试框架的话，那也是可以的呀，但考虑的东西就没那么简单了，有时候工具能用就直接用了，没必要去搞那么多耗成本的，工具弄出来还不是自己用的，要结合自己项目实际和team的实际考虑，有现成的，还是先用着吧