软件测试和质量管理——实验5：性能测试

《软件测试和质量管理》实验报告五

一、目的和要求

（1）了解 Jmeter 性能测试工具的用途和简单的操作。

（2）掌握 Jmeter 性能测试工具测试过程。

（3）能够使用 Jmeter 进行负载测试。

 

二、实验背景知识

见云班课发布的指导文件。

 

三、实验设备

主流PC机一套，windows操作系统；

测试工具：Jmeter、BadBoy2.2.5；

被测程序：Mtours 航空网站订票系统；

 

四、实验内容

使用 Jmeter 对 MercuryTours 程序进行负载测试。要求：

（1）熟悉 Jmeter 程序的功能，为登录、购买机票功能设计测试用例；

（2）利用 Jmeter 实施负载测试；

（3）分析测试结果；

五、实验过程

5.1 安装BadBoy和Jmeter

安装完毕，BadBoy和Jmeter主界面如下图所示。其中，Jmeter需要运行安装路径所在目录下的“bin”文件中的“jmeter.bat”打开。另外还需要用到实验四中的MTours航空公司订票系统项目。

 图1  BadBoy主界面

图2  Jmeter主界面

5.2 Mtours航空网站服务启动

图3  Mtours航空项目服务启动

5.3 使用BadBoy录制脚本

打开安装好的BadBoy工具，并在URL地址栏中输入http://localhost:8080/Mtours，BadBoy会录制用户的一系列操作，根据用户的一些操作行为，将这些操作转换为指令集存储下来，记录为一个个Script脚本标签，并保留每一个POST/GET请求相关的参数传递，如下图所示。

图4  BadBoy脚本录制完成

5.4 导出及导入录制脚本

点击BadBoy的File选项导出脚本为Script.jmx文件，以便后续在Jmeter打开。

  

图5  导出录制脚本                   图6  导入录制脚本

将Script.jmx文件导入到Jmeter打开，根据需求添加事务控制器、定时器、聚合报告等相关的控制器、监听器，具体内容将在下面详细介绍。

5.5 添加控制器

将所有的操作所发送的请求归类（BadBoy中我进行一次订票业务流程是顺序执行，故从上到下分别就是注册、登录、订票），找到相关的GET/POST请求，添加事务控制器（包括注册事务、登录事务、订票事务），方便后续负载测试一次性发送一个事务。

图7  添加控制器

整个个环节，由于从BadBoy导出的Jmx文件中已经嵌套了循环控制器（即Step1），意味着之后在负载测试进行时，其目录下的内容会不断循环压测模拟多用户并发的情况。

图8  循环控制器

5.6 添加正则表达式提取器

针对注册事务中的POST请求填写表单注册这一请求，添加正则表达式提取器。此处我模仿指导书的例子，设置引用名称为“phone”，正则表达式为name=“phone”value=“/^(13[0-9]|14[01456879]|15[0-35-9]|16[2567]|17[0-8]|18[0-9]|19[0-35-9])\d{8}$/”。该正则表达式符合移动、电信、联通所有手机号的标准，目的是获取POST请求中提交的表单中的用户手机号这一栏信息，如下图所示。

图9  注册事务的POST请求填写表单注册信息

图10  添加正则表达式提取器

5.7 添加同步定时器

为了实现绝对的并发效果，我们在脚本中添加同步点定时器，模拟40个用户组，并设置释放线程的策略，即超时5000ms没有反馈则释放该线程。

图11  添加同步定时器

5.8 添加监听器

为了让负载压力测试结果更加直观，在这里根据实验要求添加聚合报告、图形结果、结果树、用表格查看结果等监视器。

图12  添加监听器

其中，聚合报告是查看整个事务和其他请求的总体数据性能；图形结果起辅助作用，动态可视化地观看每一个数据走势；结果树能够看到每一个GET/POST请求的详细信息；表格可以看到从jmeter发出，一直到客户端发到服务端接收到请求的详细时间。

5.9 性能测试用例

测试5个、10个、20个、50个用户并发操作的负载模式。

标识码	1	优先级		高	执行时间	1分钟
用例名称	Mtours航空网站订票系统——订票流程
测试目的	负载压力测试订票流程的最高并发量
环境要求	Windows10操作系统、Chrome浏览器
测试工具	Jmeter、BadBoy2.2.5
前提条件	用户在Mtours航空网站有注册信息
负载模式和负载量			期望达到的性能指标				备注
5个用户并发操作			能够在2秒内完成，且系统平稳运行				/
10个用户并发操作			能够在4秒内完成，且系统平稳运行				/
20个用户并发操作			能够在8秒内完成，且系统平稳运行				/
50个用户并发操作			能够在10秒内完成，且系统平稳运行				/

5.10 测试脚本

根据实验需求动态设置线程数、启动时间、循环次数，分别代表并发的用户数，线程要在多少时间内启动完毕，并且可以设置循环启动而不是一次性启动如此多的线程。点击运行脚本按钮，分别测试5个、10个、20个、50个用户并发操作的负载模式。

通常我们所说的多少并发，指1秒内多少个线程*循环次数，即并发数=线程数*循环次数/启动时间。

（1）5个用户并发操作

 图13  设置5并发

图14  5并发的聚合报告

图15  5并发的图形结果

图16  5并发的表格结果

图17  5并发的结果树

（2）10个用户并发操作

 图18  设置10并发

图19  10并发的聚合报告

图20  10并发的图形结果

图21  10并发的表格查看结果

（3）20个用户并发操作

图22  设置20并发

图23  20并发的聚合报告

图24  20并发的图形结果

图25  并发用户数20的表格查看结果

（4）50个用户并发操作

图26  设置50并发

图27  50并发的聚合报告

图28  50并发的图形结果

图29  50并发的表格查看结果

六、实验结果分析

针对负载测试情况，从5个用户并发操作逐渐增加至10个、20个、50个用户并发，系统能够安稳运行。

（1）关于线程组的分析

本次测试中我们导入的是Thread group线程组，一个线程组可以看作一个虚拟用户组，线程组中的每一个线程可以理解为我们模拟的一个虚拟用户。

在线程组中取样器如果发生错误我们选择“继续”，如果取样器里的执行出现错误和失败的情况，订票相关的请求不会停止，继续进行。

在最关键的线程属性中，通常我们所说的多少并发，指1秒内多少个线程*循环次数，即并发数=线程数*循环次数/启动时间。以50并发负载测试为例，我设置线程数50、启动时间10秒、循环次数10次，表示50个线程，每个线程启动延迟10s，前一个线程启动后10秒后启动，每个线程执行10次循环，即1秒并发50次请求，总共请求500次。

（2）关于图形结果的分析

以5个用户并发逐渐提升到50用户并发操作，通过观察图形结果可以发现TPS（吞吐量）有一个明显的上升再下降的过程，说明系统在增加并发量的过程中吞吐量逐渐升高，能够充分利用CPU的性能；而后面当50并发都发送完请求后，系统支撑不住这么高的并发量，一些请求等待时间过长，吞吐量下降。

而后续我试图将并发量提高到300并发时，后台服务支撑不住压力，马上宕机。这说明该系统只适用于中小型环境，无法支持像双十一或者春运订票等的高并发环境。

（3）关于聚合报告的分析

以5个用户并发逐渐提升到50用户并发操作可以看到聚合报告中，平均值逐渐升高。代表单个请求的平均响应时间逐渐升高到70ms；中位数Median代表抽取50%用户的响应时间也有总计21ms；90%百分位、95%百分位、99%百分位代表90%用户、95%用户、99%用户的响应时间，分别是158、259、294。在这里为什么需要有各个百分比用户的响应时间是因为在评估一次测试的结果时，仅仅有平均事物响应时间是不够的。

综上，该系统的负载并发能力不是很好，只能接受中小型的用户量，如果发生“大量用户抢购机票”的秒杀情况，系统容易支撑不住并发，可能会发生超卖乃至宕机的情况。

六、心得与体会

本次实验，我们主要学习了新的脚本录制工具BadBoy和性能测试工具Jmeter。

与传统的Web系统测试对比，我使用Jmeter是逐个输入URL和配置相关参数、GET/POST请求等来测试，但BadBoy录制脚本一键导出Jmx文件十分便捷，大大提高了Jmeter负载测试前的准备工作的效率。

另外，我还了解了Jmeter的测试方法和负载测试的相关参数分析，主要是针对之前录制好的业务流程进行模拟高并发的负载测试。因为通过白盒、黑盒、边界值、功能测试，我们可以发现一个系统在代码、功能点都没有问题的话，实际投入到生产环境中，就需要考虑整个系统在真实环境下是否可以支撑住高并发的情况。主要学习了如何使用工具和针对结果树、聚合报告、图形进行分析该系统的并发能力和负载能力。

综上所述，通过从白盒测试、黑盒测试、功能测试到系统性能测试，我逐渐提高自己的软件测试能力，真正了解在一个项目开发到结束时，每一个环节需要的测试内容和对应的文档说明书。