这个篇文章是2016年初工作时使用Jmeter时的一些经验总结，希望能对做性能测试的人员有帮助。
项目背景
- 使用webservice接口接收XML文件，并进行处理入库。
- 实现方式：webservice服务端接收到xml报文，将报文作为string类型传送给处理程序进行处理。
- webservice地址：http://192.168.1.3:8082/DataInteractonWbs/webservice/wbs?wsdl
使用SoapUI生成初始报文
给线程组添加SOAP请求
使用采样器中的SOAP Request来发送WebService请求。
- 采样器的作用就是模拟浏览器给服务器发送请求，并获取返回值。
- 采样器中的SOAP请求就是针对webservice设置的
- 通过SOAP请求就可以测试webservice了。
SOAP请求界面的填写
需要填写的内容包括：
- URL、SOAPAction、SOAP/XML-RPC Data三部分
从这三部分来看URL是开发给的，其他东西开发都没有给，那怎么办呢？
使用SoapUI这个软件就可以解决这个问题。
SOAPUI的作用
- 这个软件是专门做webservice测试用的，可以自动生成与webservice通信的报文。
- 首先新建一个SOAP项目，然后填入项目名称，webservice地址即可。
SoapUI项目界面
- 1：项目的结构；
- 2：项目地址；
- 3：自动生成的XML报文基本结构；
- 4：发送报文按钮；
- 5：显示回执。
第一次XML文件发送测试
- 把准备好的XML文件内容放入<xmlstr>中，并点发送。
- 结果如右图所示Webservice回复“意外的元素”。所以这样发送是不行的。
使用字符串传输报文时要用“<![CDATA[string]]>”把字符串框起来
- 经过和开发确认中间的内容(string)需要使用“<![CDATA[string]]>”框起来。
- 这样的原因是，在做webservice接口时，对实际内容是作为字符串解析的，因此需要以字符串的形式来传送报文。
在jmeter中调试报文
报文调试通过-在jmeter中试验
- 将调试通过的报文放入Jmeter SOAP请求的Soap/XML-RPC Data中。
- 参照SOAPUI中的地址栏，写上URL。
添加“查看结果树”和“聚合报告”
- 为了查看报文发送的结果，必须得有个查看回执的东西，这个东西就是“查看结果树”
- 测试一般要添“聚合报告”，作用是将整体响应、延时等放到这个基本报告中。
运行一下看看结果
为了测试，一般都需要运行一次看看脚本写的对不对；
因为我们只需要运行一次，所以在“线程组”中将线程数和次数都设置为“1”。
对“SUCCESS”做断言
- 因为只要有回执，无论任何回执jmeter都判断为成功。
- 这样就不能确定报文是否正确处理了。因此要对回执做断言，这里用的是“SUCCESS”
- 在线程组上点右键，添加一个“断言”中的“响应断言”
对单个请求设置断言
如右图所示方法设置断言，就可以只对某个特定的请求断言(订单)，而不会影响其他请求结果。
这样做的好处是，每个请求所需要断言的结果可能不一样，以此进行区分。
参数化
对报文做参数化
参数主要有两个做参数化的组件：
- “用户定义的变量”
- “CSV数据选择器”
报文中不停变动的参数
另外我们还有一个不停变化的号码，来使单号不重复。这时就得使用函数了。
这个Counter函数，可以在每次提交时+1，其中说明中有说参数使用FALSE的话，就是全局计数器，这样可以保证所有线程用的都是同一个计数器，不会产生重号。
用户自定义变量中的参数化
对固定的单号、webservice地址和其他的东西进行参数化。
下面将“用户定义的变量”中的名称用${ }括起来，然后在后面添加${__counter(FALSE)}就是定义好的自增变量了。
在报文中参数化的方法
- 使用${参数}在报文中写参数化的内容，比如：
- ${__ORDERIDdemo}d${__counter(FALSE)}
- 里面有两个参数化的参数。
- Orderid是参数化的id
- 中间还有个“d”作为不同类型单号区分(这个就是在单号和数字之间用d做了个分隔。
- Counter是每次运行均加1。
- 参数true是每个线程都有各自的计数器
- False是全部线程共用计数器。
增加请求头管理器
发送报文测试
报文发送后发现，在页面上显示的是乱码。但使用SoapUI发送的报文就没有问题，仔细检查发现发送的HTTP信息头是有问题的。
增加HTTP信息头管理器
在“配置元件”中找到“HTTP信息头管理器”并添加到线程组中。
增加一个名称为“Content-Type”的信息头，并填写值为“text/xml;charset=UTF-8”
添加监控
添加服务器资源监控PerfMon Metrics Collector
- 下图所示位置填写IP、端口、监控项目和监控内容。
- 上面的端口是ServerAgent使用的端口，这个端口可以进行设置。
- 可以在应用服务器和数据库服务器各部署一个，以便确认瓶颈
在服务器上部署ServerAgent
- 只有在服务器上启动了ServerAgent后，jmeter才能获取到服务器运行的相关资源情况。
- 此应用默认的端口是4444，如果需要修改，则增加以下参数即可。
- startAgent.bat --tcp-port 3401 --udp-port 3402 –sysinfo
- 运行后效果如下图
添加其他监听器
根据自己需要可以添加针对线程、相应时间、每秒事务数、每秒点击数、吞吐量等监听器。
- 这里添加了如右图几个监听器。
- 其中包括了(对于webservice这些足够了)
- 应用和数据库资源监控
- 响应时间随时间的变化
- 相应时间对应于线程的变化
- 事务吞吐量对应于线程的变化
- 每秒事务数、每秒点击数
- 聚合报告
- 查看结果树(实际测试时需要勾选“仅日志错误”，不然jmeter会崩溃)
各个监控的介绍
每秒点击数
每秒响应代码(在http测试中有些用)
响应时间随时间变化
响应时间随线程变化
每秒事务数
数据库响应时间(JDBC Request)
服务器资源监控-应用
服务器资源监控-数据库(后面因为应用性能下降造成数据库负荷降低)
聚合报告
数据库响应时间监控
我们虽然监控了数据库的资源情况，但对于数据库实际的响应时间是不清楚的。因此需要增加一个对数据库的操作，并记录其响应时间。这时就要用到以下两个工具：
- JDBC Connection Configuration(JDBC连接配置器)
- JDBC Request(JDBC请求)
添加方法：
- 在配置元件里面添加JDBC Connection Configuration
- 在sampler中添加JDBC Request
- 配置jar包：
- 将数据库服务器(我用的是Oracle)上的“ojdbc14.jar”文件复制到jmeter下的lib文件夹内。
JDBC Connection Configuration设置方法(Oracle)
如下图方法设置
- Variable Name需要和JDBC请求中的一致。
- 数据库的设置，参考右图即可。
- 其他的默认就行了。
JDBC Request编辑
JDBC Request中只要设置Variable Name和JDBC设置器一致即可。
其次要根据需要写一个select或update或insert的语句，来测试对应方法的响应时间。
- 如果只是查看select响应时间，可以使用这个语句： select * from dual(dual是Oracle中的一个公共表，可以对这个表进行很多操作，具体可以问度娘)
- 注意语句后面不能跟分号“；”，不然会出错。
也可以做复杂的select，但是要考虑是不是会对服务器产生压力。比如：
- select ceil((max(stime)-min(stime))*24*60*60) AS 耗时,
- trunc(count(*)/ceil((max(stime)-min(stime))*24*60*60),2) AS 每秒单量,
- min(stime) as 开始时间,max(stime) as 结束时间,count(*) as 总单量
- FROM TB_xxx_xxx_xxx WHERE ORDERNO like '${__ORDERIDdemo}%'
将数据库监控线程与压力线程分开
为了避免数据库监控对数据库服务器造成不必要的压力
- 应用测试的时候可能会每秒几十个线程同时发送请求，而数据库监控的请求不需要这么多
因此需要新建一个线程，然后把JDBC Request这些全部放到新线程中去。
另外还需加一个定时器，来保证每隔一定时间才会对服务器进行一次请求。
为了查看响应时间，再增加一个响应时间图表。
使用场景(JMeterPlugins中的线程组)
使用“线程组”不能满足场景测试需要，因此需要更高级的场景才行
配置单元优化
由于“变量”、“JDBC配置”和“HTTP信息头”是所有线程都要用的，所以可以将这几个配置单元移动到测试计划下面，和线程组处在同一级。
这样就可以让每个线程都共享这些配置单元了，不用每个线程都配置一遍。