如何看Analysis分析图

面对Analysis提供的几十个测试结果分析图，很多人会感到无所适从。实际上，性能测试分析要求执行人员更加细心和谨慎，不要放过任何一个缺陷，尤其是要学会深入系统内部来进行分析。同时，在分析结果时还应该学会借助Analysis以外的各种分析工具。例如，可以借助Oracle提供的监控与分析工具，也可以借助WebLogic提供的监控与分析工具，要想尽一切办法来发现系统瓶颈。

下面介绍一些通用的性能测试分析流程。

第一步：从分析Summary的事务执行情况入手。

查看Summary主要是判定事务的响应时间与执行情况是否合理。如果发现问题，则需要进一步分析。通常情况下，如果事务执行存在失败或者相应时间过长等情况，都需要进行深入分析。

下面是查看分析概要时的一些原则。

（1）用户是否全部运行、最大运行并发用户数（Maximum Running Vusers）是否与场景设计的最大运行并发用户数一致。如果没有，则需要打开与虚拟用户相关的分析图，进一步分析虚拟用户不能正常运行的详细原因。

（2）事务的平均相应时间、90%事务最大响应时间是否是用户可以接受的时间。如果事务响应时间过长，则要打开与事务相关的各类分析图，深入地分析事务的执行情况。

（3）查看事务是否全部通过，如果有事务失败，则需要深入分析原因。很多时候，事务不能正常执行意味着出现了系统瓶颈。

（4）如果一切正常，则本次测试没用必要进行深入分析，需要加大压力来进行测试。

（5）如果事务失败过多，则应该降低压力继续进行测试，使结果分析更容易进行。

上面这些原则都是分析Summary分一些常见方法，读者应该灵活使用并不断地进行总结与完善，尤其是要注意结合实际情况，不能墨守成规。

第二步：查看负载发生器和服务器的系统资源情况。

查看分析概要后，接下来要查看负载发生器和待测服务器的系统资源使用情况：重点要查看CPU的利用率和内存使用情况，尤其是注意查看是否存在内存泄漏问题。这样做的原因是很多时候系统出现瓶颈的直接表现是CPU利用率过高或者内存不足。

对于负载发生器，应该保证其整个测试过程中CPU、内存、带宽没有出现瓶颈，否则测试结果无效。对于待测试服务器，则重点分析测试过程中CPU和内存是否出现了瓶颈：CPU需要查看其利用率是否经常达到100%或者平均利用率一致居高95%以上；内存需要查看是否够用，以及测试过程是否存在溢出现象（对于一些中间件服务器要查看对其分配的内存是否够用）。

第三步：查看虚拟用户与事务的详细执行情况。

经过前两步确定了测试场景的执行情况基本正常后，接下来就要查看虚拟用户与事务的执行情况。对于虚拟用户，主要查看在整个测试过程是都运行正常，如果有较多用户不能正常运行，则需要重新设计场景或者调整用户加载与退出方式再次进行测试。对于事务，重点关注整个过程的事务响应时间是否逐渐变长以及是否存在不能正常执行的事务。

总之，对于任何用户或者事务的执行细节都应该认真分析，不可以轻易忽略。图4-7所示的就是一个性能逐步下降的服务器，需要进一步分析其性能下降的原因，例如查找是否存在内存泄漏问题；图4-8则是一个性能相对稳定的服务器，但是影响时间偏大，这时需要分析程序算法是否存在缺陷，或者服务器参数的配置是否合理。

下面是虚拟用户与事务分析的常用准则。

（1）虚拟用户是否存在失败，如有失败，则要定位原因。

（2）在整个测试过程中，所有的虚拟用户是否一直稳定运行并成功执行全部事务：如过仅有一个用户或者部分用户能够正常运行，则说明测试脚本可能存在的问题。

（3）对于失败的事务首先要分析其失败的原因，接着要查看事务的失败是否导致了用户失败。

（4）判断用户是否可以接受事务平均相应时间值以及90%用户的最大响应时间值。

（5）查看整个测试过程中的事务平均相应时间是否逐步变大，正常情况下，事务平均相应时间应该是趋近于平行X轴的直线。

（6）事务响应时间是否在整个测试过程中随着用户的增加而线性下降.正常的情况应该是，在一定范围内的用户并发时，事务响应时间不会有太大变化。

（7）服务器每秒通过的事务总数、某一事务每秒通过数是否稳定，如果整个测试过程基本不变，则要分析是服务器达到了处理上限，还是Generator产生的压力达到了上限。

（8）对于按照迭代次数来运行的场景，要分析通过的事务总数是否与设定的一致。如果存在不一致，则可能是测试脚本存在的错误，也可能是待测试程序存在功能错误，应该调整后再次进行测试。

Analysis 对虚拟用户和事务提供了非常强大的跟踪功能，可以跟踪每一个用户及其相关事务的执行情况。这些内容可以在Analysis菜单“Reports>Crystal Report”下找到。

第四步：查看错误发生情况

整个测试过程中错误的发生情况也应该是分析的重点。下面是查看错误发生情况的常用准则。

（1）查看错误发生曲线在整个测试过程中是否有规律变化的，如果有规律，通常意味着程序在并发处理方面存在一定的缺陷。图4-9所示的每秒缺陷数量曲线十分有规律，这是因为服务器定期生成缓存文件导致用户不能正常访问而产生的错误。

（2）查看错误分类统计，作为优化系统的参考。例如对于Web性能测试，当出现瓶颈时往往需要查看服务器的错误统计信息结果：如果“超时错误”占到90%以上，可能需要提高硬件配置；如果较多的“内部服务器错误”，则可能是程序方面存在问题。

第五步：查看Web资源与细分网页

本步骤仅适用于Web性能测试。查看Web资源图时,往往结合前面对虚拟用户以及事务响应时间的分析结果，重点分析服务器的稳定性。对于网页细分功能则遵循如下原则：首先分析从用户发出请求到收到第一个缓冲为止，哪些环节比较耗时；其次找出页面哪些组成部分对用户响应时间影响较大；当对页面的性能问题定位后，就可以采取相关的解决方案。