在CONTROLLER执行的测试场景结束后,首先要判断采集到的结果数据是否真是有效。
判断测试结果是否有效,步骤如下:
第一步:在整个测试场景的执行过程中,测试环境是否正常。如果在测试过程中发生出现过异常,那么这样得出的结果往往不准确,不需要无须进行分析。
例如,在测试执行过程中,测试机的CPU利用率经常达到100%%、测试环境的网络不稳定、一些系统参数配置不正确等等,这样得出的测试结果没有必要直行分析,应该重新设置测试场景或者调整测试环境,再次执行测试。
第二步:测试场景的设置是否正确、合理。测试场景的设置是否正确对测试结果有很大的影响。因此,当测试出现异常时,需要分析是不是由于场景设置不正确引起。
一些新手在使用Controller执行测试时,可能会同时在一台PC上加载全部虚拟用户——例如同时加载1000个虚拟用户,如果客户端来不及处理,就会有很多虚拟用户因不能初始化而失败——而。失败的根本原因不是被测试的应用服务器不能处理,而是压力根本没有传输过去。正确的做法是增加更多的Generator或者逐步加压,进行不断的尝试来使测试场景运行起来。
第三步:测试结果是否直接暴露出系统的一些问题。对于测试场景的整个执行过程而言,没有必要对压力下系统运行正常的结果进行分析,因为这样的结果不能反映出系统的性能问题,应该进一步调整场景(比如增大压力)进行测试。而对于在测试过程中使系统表现不正常的测试场景生成的结果则要进行深入分析。实际上,分析能够反映性能问题的测试结果才是性能分析阶段的主要工作。
测试结果直接暴露系统存在性能问题的情形很多,例如在测试过程中一些用户事务响应时间过大长、系统支持的最大并发用户数过低、系统的应用服务器CPU利用率过高或者内存不足等。对于这类测试结果,性能测试人员需就要开始借助Analysis对其进行深入分析,以发现一些潜在的性能问题。
通用性能测试分析流程: 1.从分析summary的事务执行情况入手。用户是否全部运行,最大运行并发用户数是否与场景设计的最大运行并发用户数一致。事务的平均响应时间、90%事务最大响应时间用户是否可以接受。查看事务是否全部通过。如果一切正常,可以进行加大压力测试。如果事务失败过多,则应该降低压力继续进行测试。
2.查看负载生成器和服务器的系统资源情况。保证负载生成器在整个测试过程中其CPU、内存、带宽没有出现瓶颈,否则测试结果无效。待测试服务器,则重点分析测试过程中CPU和内存是否出现了瓶颈:CPU需要查看其利用率是否经常达到100%或平均利用率一直高居95%以上;内存需要查看是否够用以及测试过程是否存在溢出现象。 |
3.查看虚拟用户与事务的详细执行情况。 虚拟用户如有失败,则要查明原因; 如果仅有一个用户或部分用户能够正常运行,则说明测试脚本可能存在问题; 判断用户是否可以接受事务平均响应时间值以及90%用户的最大响应时间值; 正常情况下,事务平均响应时间的变化应该是不接近于平行X轴的一条直线; 服务器每秒通过的事务总数、某一事务每秒通过是否稳定,如果整个测试过程基本不变,则要分析是服务器达到了处理上线,还是GENERATOR产生的压力达到了上线; 按照迭代次数来运行场景,要分析通过的事务总数是否与设定的一致。如果不一致,则可能是测试脚本存在错误,也可能是待测试程序存在功能错误,应该在调整后再次测试;
4.查看错误发生情况。 查看错误发生曲线在整个测试过程中是否有规律变化,如果是则意味着程序在并发出了方面存在一定的缺陷。 查看错误分类统计,作为优化系统的参考,如果“超时错误”达到90%以上,可能需要提高硬件配置;如果较多的“内部服务器错误”,则可能是程序方面存在问题。
|