性能测试结果分析结果
在做性能测试的时候，在使用LR或者jmeter等一些性能测试工具测试执行结束后，首先要做的是判断采集到的结果数据是否真实有效。多数的性能测试场景都要迭代的进行测试，因此很多测试结果本身就不能反应问题，深入分析这样的结果没啥意义。下面说一下就有效的测试结果数据进行分析做一些思考后的见解。
1、在整个测试场景的执行的时候，你要留意测试的环境是否正常，测试的过程中是否发生异常，如果发生异常，应该立刻终止测试，应为异常的测试结果是不准确的，没有意义。
举个栗子：
你在测试的过程当中，如果你发现测试机的CPU利用率经常达到100%、测试环境的网络不稳定、系统的配置参数不正确等外部的原因导致系统出现了异常的运行，这样的测试结果没有必要进行分析。这是应该先把这些问题搞定了在重新进行测试。
2、测试场景的设置是否正确、合理。当你的测试出现异常的时候，你有分析是不是异常的原因是什么，是外界原因还是系统本身原因，外界原因有配置、网络、还有就是你的场景设置本身就有问题，这点往往是你在设计的时候考虑欠缺导致的额。
举了栗子：
比如你在测试的时候，你以上来就加载全部的虚拟用户，比如同时加载1000个虚拟用户，如果客户端都还没来得及处理，这时就会出现有很多虚拟用户因不能初始化而导致失败，失败的原因就是还没有链接应用服务器。这是压力压根就没有传过去。所以正确的做法应该是可以使用逐步加压的方式尽量的把所有的数据都加载进去。
3、分析试结果直接暴露出系统问题。测试结果中正常的，往往没有必要进行分析，因为他是正常的。这时应该进一步进行测试分析，比如加压等。在加压测试的时候能反映出的问题有很多：
例如在测试中一些常见的事务响应时间过大，并发用户过低，服务器资源利用率过高CPU、内存使用过高。对于这些问题，需要深入分析其原因。
性能分析的原则
- 观察性能表现，系统在高并发下性能表现下降的最直接的表象就是响应时间变长。所以这是需要分析系统的响应时间作为起点。
- 判断响应时间是否满足设计的期望，2S、3S、10S等。如果不满足，说明系统的性能已经出现问题了。他既然出现问题，那么问题在哪里呢？B中解释。
- 系统中与时间有关的有两个部分：服务器（应用服务器和数据库服务器）处理时间、网络传输数据时间。所以能够影响响应时间的就是这俩家伙了。所以需要最这俩进行分析。如何分析呢？C中解释。
- 首先模拟请求的过程，如下图：
这处理这个过程中，总共有两个时间段，Tn，这个是网络的响应时间；Ts，这个是服务器的处理时间，包括应用服务器和数据库服务器的响应时间。通过将这两个的时间进行对比，就能分析出性能问题是网络问题还是服务器问题了。
- 对于虚拟用户与事务分析的原则：
- 虚拟用户是否存在失败、如果有失败的话，需要定位失败的原因并写在报告中。
- 在整个测试中，所有的虚拟用户是否一直稳定运行并成功执行全部事务：如果只有部分用户能够正常运行，那么说明脚本或者场景设置可能有问题。
- 对于失败的事务，需要找出失败的原因，同时需要注意该事务的失败是否会影响到用户也失败。
- 判断平均事务响应时间以及90%用户的最大响应时间
- 观察在整个过程中，事务的平均响应时间是否出现逐步变大，正常的事务响应时间应该是平稳的（与X轴平行）
- 观察服务器每秒通过的事务总数、事务通过数是否稳定，如果整个测试过程中基本不变，这是就有分析是服务器达到出来上限还是加压到了极限
场景设计
经过分析，场景设计不必覆盖所有功能模块，只需要测试系统中使用比较频繁的功能即可。
测试场景中设计的内容主要有登录、查看、添加、删除、修改等基本操作。
测试场景详细如下：具体参考Excel表
（1）登录（如表1-1）
表1-1登录测试场景
| 功能 |
系统支持多个用户并发进行登录 |
|||
| 目的 |
测试多用户登录时系统的处理能力 |
|||
| 方法 |
模拟多个用户在客户并发进入系统的操作 |
|||
| 执行时间 |
5min/10min/15min/20min/25min/30min |
|||
| 加载方式 |
逐步加载（每秒50个） |
|||
| 并发用户数与事务执行情况 |
||||
| 并发用户数 |
平均事务响应时间 |
最大事务响应时间 |
事务成功率 |
平均流量（bit/s） |
| 500 |
|
|
|
|
| 1000 |
|
|
|
|
| 1500 |
|
|
|
|
| 2000 |
|
|
|
|
| 2500 |
|
|
|
|
| 3000 |
|
|
|
|
| 3500 |
|
|
|
|
（2）查询（如表1-2）
表1-2 查询测试场景
| 功能 |
系统支持多个用户并发进行查询 |
|||
| 目的 |
测试多用户查询设备时系统的处理能力 |
|||
| 方法 |
模拟多个用户在客户登录、然后并发查询设备的操作 |
|||
| 并发用户数与事务执行情况 |
||||
| 并发用户数 |
平均事务响应时间 |
最大事务响应时间 |
事务成功率 |
平均流量（bit/s） |
| 500 |
|
|
|
|
| 1000 |
|
|
|
|
| 1500 |
|
|
|
|
| 2000 |
|
|
|
|
| 2500 |
|
|
|
|
| 3000 |
|
|
|
|
| 3500 |
|
|
|
|
（3）查询-修改设备（混合场景）（如表1-3）
表1-3 查询-修改设备测试场景
| 功能 |
系统支持多个用户并发进行查询、然后修改设备信息 |
| 目的 |
测试多用户查询设备时系统的处理能力 |
| 方法 |
模拟多个用户在客户登录、然后并发查询设备后进行修改设备的操作 |
| 并发用户数与事务执行情况 |
||||
| 并发用户数 |
平均事务响应时间 |
最大事务响应时间 |
事务成功率 |
平均流量（bit/s） |
| 500 |
|
|
|
|
| 1000 |
|
|
|
|
| 1500 |
|
|
|
|
| 2000 |
|
|
|
|
| 2500 |
|
|
|
|
| 3000 |
|
|
|
|
| 3500 |
|
|
|
|
测试的实施
| 模拟用户数 |
测试内容 |
测试结果 |
备注 |
| 500 |
通过jmeter测试系统是否支持500用户并发访问系统 模拟用户的操作有以下： 1、登录 2、登录、查询 3、登录、查询、修改 |
通过/不通过 |
按照场景进行测试 |
| 1000 |
|
|
|
| 1500 |
|
|
|
| 2000 |
|
|
|
| 2500 |
|
|
|
| 3000 |
|
|
|
| 3500 |