Jmeter性能测试实战-零基础-从需求到监控结果分析
来源：书籍 零成本实现Web性能测试345页
适用人群：性能测试小白
一、测试背景和测试目标
性能测试对象是某世界500强保险公司的电话销售系统。该系统支持数万销售人员同时在线工作，销售人员会电话联系客户并推销保险产品。该系统为典型Web应用系统。
测试背景：保险公司的电话销售人员上下班时间大体一致，也就是说每天上班时，销售人员会在很短一段时间内集体登录电话销售系统。这种风暴式登录会对系统带来很大的压力，严重时会导致部分用户无法及时登录系统。而且随着公司电话销售业绩的快速提升，同时在线的销售人员会大幅增长，也就是说登录风暴会越来越严重。
测试目标：协助开发人员分析登录系统的流程中，哪一步骤存在瓶颈，并给予改进建议。
二、分析确定性能测试指标
如上表所示为IT部门对业务部门承诺的关键功能（登录系统）的性能指标。
如何将宽泛的IT承诺指标转换为测试人员可以使用的性能测试指标，有一定的技巧。原书作者所在测试部门总结出了一套转换模型，以下简要介绍。不一定适用于其他测试组织，但存在一定的通用性。
1、如何确定性能测试的并发虚拟用户数
测试环境平均并发数=（高峰段用户数*10%）/n
n是生产环境和测试环境服务器配置折算比，例如n=公倍数（（生产Web服务器数/测试Web服务器数），（生产APP服务器数/测试APP服务器数））*（生产服务器内存/测试服务器数内存）
一般算下来n=4（仅为经验值）
10%的含义是我们假定所有用户中，只有10%的用户在同一时刻做同一件事情，例如登录系统。（10%仅为经验值）
2、如何确定性能测试的持续时长
系统可用时段为8:00-21:00，那登录操作是否平均分布在此时段？当然不是，通过调研实际用户，发现登录操作集中发生在8:50-9:20这半个小时以内。
因此我们可以将性能测试的持续时长，确定为半个小时；
3、如何确定性能测试的存量数据
准备性能测试的存量数据是一件复杂而具有挑战性的工作。且并无通用模型可供参考，只能凭借测试人员经验，它需要测试人员对系统架构非常熟悉才行。
本例中的存量数据就是23000个测试账号，即数据库用户表中应该有23000条以上的记录，而测试人员不需要保证这23000条记录每一条都能真实完成系统登录。
4、如何确定测试人员重点观察的性能指标
本例中测试人员应重点关注4项Jmeter监听器的统计指标：
1）平均响应时长（Jmeter聚合报告）<4s
2）90%阈值（Jmeter聚合报告）<=7s
3）吞吐率，应该是先逐渐攀升最后趋于平稳的一条曲线
4）错误率，趋近于0，如果不为0，应该认真分析
另外还应该注意
5）数据库监控记录，如Top Sql
6）Jmeter运行日志和待测系统服务器的日志记录
三、录制创建性能测试脚本
1、录制脚本（可以用Jmeter或Badboy录制）
2、添加3个配置元件：HTTP Cookie Manager（HTTP cookie管理器）、User Defined Variables（用户定义变量）、HTTP Header Manager（HTTP 信息头管理器）
其中HTTP Cookie Manager是必须的，HTTP Header Manager一般来说所有请求也只有一份，因此最好增加，User Defined Variables根据实际情况判断是否增加；
3、参数化--将登录的账号/密码进行参数化
添加CSV Data Set Config配置元件，具体用法此处不详述；
账号/密码组合应该尽可能多提供，这样才能真实模拟用户登录操作；
4、添加事务控制器（逻辑控制器）“登录”和“退出”，以便衡量整个登录流程所需的时长；（事务控制器如何使用不会）
5、添加监听器“聚合报告”，以便统计和分析性能测试结果；
6、最后一项关键工作，修改线程组的各项参数
线程数=（高峰段用户数*10%）/n=23000*0.1/23=100（n取23，原因在于测试环境的web和应用服务器不是独享，需要与其他应用系统共用）
Ramp-up Period参数设置为750秒，即750秒内启动所有并发线程。
这里使用调度器，设置总时长为30分钟。
四、运行性能测试脚本
1、Jmeter有多种运行方式，包括：GUI模式、非GUI模式、远程模式。
GUI模式适用于并发线程数较少，且需要实时观察监听器统计数据变化的场景；
非GUI模式适用于并发线程数较多，无须实时观察监听器统计数据变化的场景；
远程模式适用于并发线程数很多，单台Jmeter执行机无法支持的场景；
2、本例中并发100个，采用GUI模式对Jmeter执行机的性能要求较高，一般情况下选择非GUI模式来运行Jmeter，如果还不能满足需求，可使用远程模式。
在测试期间应该观察Jmeter执行机的CPU和内存占用情况，甚至于本地网络内的负载情况，以免影响测试结论。
tips：采用GUI模式，JMeter在压力较大的情况，可能会报告“Out of heap”错误。（此问题可以通过修改jmeter配置属性缓解）
运行过程：目前还不太明白如何非GUI模式运行Jmeter；
五、分析性能测试结果
1、确认性能测试脚本已经执行完毕；本例中执行时间大概在33分钟左右，整个测试时长略长于30分钟，符合预期；
2、以GUI模式启动Jmeter并通过监听器“聚合报告”来分析Jmeter收集的性能测试数据，如下图:
分析需要关心的几个重要数据：
1）登录的平均响应时长为4273ms（约4.3s），超过对用户承诺的4s时长，但超出幅度不大，也就是说对此需要加以改善；
2）登录的90%阈值为2975ms（约3s），远远小于对用户承诺的可接受最长响应时长7s，是符合预期的。
不过需要注意的是，Jmeter统计的最大响应时长（Max）高达20s，远远超过了对用户承诺的7s。总结一下，系统对90%的用户响应很快，但是对个别用户存在系统缓慢的情况，对此需要提醒开发加以注意。
3）登录的错误率高达5.27%需要引起高度关注，其中几个请求的错误率均不为0，可以发现一个规律，错误集中在平均响应时间最长的几个URL上，由此初步怀疑系统在压力较大的情况下，无法及时处理某些请求，当然只是初步怀疑，需要其他证据来加以佐证。
再看日志文件，存在大量HTTP500错误。导致HTTP500错误的原因很多，这里几乎可以断定是性能缺陷，因为将并发数设为10，再次运行发现日志中无HTTP500错误，同时对比Web服务器日志，发现其中的记录可以支持这一结论；
tips：分析性能测试数据时，测试人员需要综合参考Jmeter运行日志和待测系统服务器的日志记录；
3、查看应用系统对应数据库的历史统计信息，发现数据库并未承受太大压力，在前10条Top Sql中未发现与登录功能相关的语句。证明系统瓶颈并不在数据库上，可以缩减定位问题的范围。
tips：可进行数据库监控；
4、查看应用系统的Web服务器、APP服务器日志和监控记录，可以发现Web服务器日志中存在较多错误记录。测试人员应该将这些错误记录作为软件缺陷的一部分提交开发人员进行分析；
tips：由于原作者担心泄漏公司商业秘密，隐去了Web服务器日志；
六、上报性能测试缺陷
以下总结应该如何描述缺陷。