LoadRunner自动化测试结果分析及感想篇(大结局)

MILY: 宋体; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: 宋体; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-ascii-font-family: Calibri; mso-hansi-font-family: Calibri">导读

经过前面的测试，我们通过了测试并得到了测试数据。此时，可以通过LR的Analysis模块进行操作。Analysis是一个独立的模块，它可以将测试结果和监控数据转化为数据库数据，以利于分析处理。测试人员可以在分析器中选择感兴趣的图表，通过合并图，交叉图和自动关联等手段，对测试结果和监控数据进行分析处理。以确定性能瓶颈及其产生的原因。最后，可以选择有价值的部分图，自动生成HTML和Word格式报告， 这些报告可以作为附件和测试测试报告一起提交，提供性能参考。

详细分析

场景运行 结束后，必须手动打开Analysis，Analysis启动时，会自动收集本地计算机上的结果数据，如果压力产生器在远端机器上，又没有选择自动收集数据，则会先收集测试结果数据。打开后如下图所示:

在上图中，带红点的是打开自动生成的图表，没有红点的则是通过合并图，筛选等手段添加上的。Analysis上图形主要分为四大类，分别是Vusers，事务，Web资源，网页分析。通过不同的需要选择不同的图来分析。下面主要讲几个重要的图及相关操作。

一，相关图的解说

1， Vuser图，如下图所示：

此图是经过筛选操作后得到的Vuser图，显示了所有Vuser在测试期间的每一秒内，执行Vuser脚本的Vuser的数量及它们的状态。如果想了解单独一个Vuser的状态，也可以将筛选条件设置您想了解的VuserID。具体操作步骤是：在Vuser图内单击鼠标右键，选择菜单中的“设置筛选器/分组方式”，在弹出的设置框中进行设置即可。如下图所示：

用筛选方式可以搜索到特定的Vuser在不同时刻的数据，方便性能分析，初学者要好好掌握。此方法可以运用到对其它图的操作上，以后对筛选的操作就不再具体描述了。

2， 事务图。事务图主要包括平均事务响应时间图，每秒事务数图，每秒事务总数，事务概要图，事务性能概要图，事务响应时间（负载下）图，事务响应时间（百分比）图，事务响应时间（分布）图。

这里就拿事务响应时间（百分比）图来分析。它可以帮助测试人员分析在给定时间范围内执行的事务的百分比和确定合适的事务百分比，以判断是否满足系统的性能标准，通常情况下，您需要在可接受的响应时间范围内，确定事务百分比，最大响应时间可能非常长，但如果大多数事务具有可以接受的响应时间，则整个系统还是适用的。来看看具体的图：

上图是所有用户的全部事务的响应时间百分比，可以通过筛选功能，筛选出具体的用户和事务进行分析；用向下搜索功能提炼出更加精确的数据，以便好地进行性能分析，定位系统的性能瓶颈，此操作在相应的图中单击鼠标右键，选择“向下搜索”，在弹出的设置框中设置相应选项就可以了。我这里就用Vuser9分析

经过LR的筛选功能可以得到更多精确的图，就可以很清晰很方便地分析出系统是否存在性能问题了。用性能下降曲线分析法，从上图可以看到，发布博文事务曲线非常平滑，最大响应时间为0.999秒，是属于非常好的现象，其它事务随着负载用户数量的增大，出现相应的波动，从而可以分析性能问题所在。从图中可以看到，一条曲线可以分为以下几个部分：

（1）性能平坦区——在不进行更多性能调优情况下所能期望达到的最佳性能。这个区域可被用作基线或是benchmark。

（2）压力区域——应用“轻微下降”的地方。典型的、最大的建议用户负载是压力区域的开始。

（3）性能拐点——性能开始“急剧下降”的点。

这几个区域实际上明确标识了系统性能最优秀的区间，系统性能开始变坏的区间，以及系统性能出现急剧下降的点。对性能测试来说，找到这些区间和拐点，也就可以找到性能瓶颈产生的地方。因此，对性能下降曲线分析法来说，主要关注的是性能下降曲线上的各个区间和相应的拐点，通过识别不同的区间和拐点，从而为性能瓶颈识别和性能调优提供依据。

在其它图中，还可以使用LoadRunner中的自动关联确定造成服务器或网络瓶颈的原因。自动关联功能应用高级统计信息算法来确定哪些度量对事务的响应时间影响最大。操作步骤是：单击“关联选项”选项卡，选择要将哪些图的数据与相应事务关联，如下图所示：

除了上述操作外，还可以进行其它操作，如比较不同场景的结果，如果你执行了多个场景的话。最后根据用户选择感兴趣的图表，生成HTML或Word格式及其它格式的报告。此次测试的报告我已经上传到博客上了，感兴趣的朋友可以下载看看，谢谢大家的支持。根据测试结果分析数据与事先设计好的测试用例或需求说明书对比，验证测试是否通过，不通过则分析系统性能瓶颈出在哪里。OK，图表就分析到这了。 

二，相应服务器性能分析

1， tomcat分析

我这里用的是Lambda Probe来实现的，来看看在运行场景时，tomcat的性能，如下图：

从图中两个表中可以看出，要相同的时间内。每30秒的用户数和执行的事务数整体上是一致的，并没有影响系统整体性能，数据库中也成功在插入了相应数据，如下图：

在脚本运行设置中，我设置了6个迭代，这里也成功插入了6条数据，再结合事务响应时间（最大为0.999秒），说明这块的性能是通过测试的。这里想加一句，一个没有发现bug的测试，算不上是一个成功的测试。因为软件测试的目的就是要找到bug，如果有条件，尽量把并发的Vuser设多，能把系统搞崩溃最好，这样就可以提取更有价值的数据，从而分析出系统的瓶颈，解决性能问题。

2， MySQL数据库服务器分析

MySQL数据库服务器性能主要参考tomcat中的status可以获得相应数据，只要tomcat用户管理文件配置成功，就可以走入了，地址为：http://localhost:8080/manager/status  如下图:

在运行场景中，这里会记录所有数据插入的信息，通过这些信息，分析其性能。

如果出现性能问题或现在的性能不符合需求规格说明书上所需求的，则超需要进行性能调优了。针对不同性能问题，实施不同的策略，如存储空间不足，则可以增加大容量硬盘；内存不足就补内存；服务器问题则可以采用集群等等，但每种都不是单独考虑，要考虑到成本，风险等问题。不能说存储空间不足，就恶补大容量硬盘，这种方法不完全正确的。

此次测试的感想

         做性能测试比做功能测试是难很多的。

第一，  如果系统应用复杂，功能众多的话，就需要进行大量的测试工作，工作量庞大，试想我这里只是测试了登录和发博文两个功能，还有其它功能都还没有测试呢。

第二，  Web脚本如何开发。不想认为仅仅通过录制就可以解决脚本问题，在一些特定的环境下，要测试人员开发大量的脚本，涉及高级算法，语言等知识。

第三，  场景数据出来后，如何分析。分析测试数据是一个很头痛的问题，其它涉及到的东西且不说，光是那庞大的数据量就可能让你窒息了。像阿里巴巴，淘宝这样的网站，数据都是海量级别的。

第四，  性能问题不仅仅关系到软件本身，还与服务器，网络，存储空间，I/O等等有关。

…………

性能测试工程师职位是具体有挑战性的，如果你想成为一个优秀的性能测试工程师，必须有牢固的开发测试基础，广阔的知识面，良好的分析问题和解决问题的能力，等等。上下不断求索吧。

OK，关于LoadRunner自动化测试就到这了。LoadRunner中自带有一个测试web项目，地址是http://127.0.0.1:1080/mercuryWebTours  开启服务器后，用注册用户名和密码进入。大家可以自己动手试试，尽量整出点性能问题来，学IT，很多时候BUG和异常可能成为你技术提高的源泉。谢谢大家的支持，不足之处，请大家谅解和提示。

响应时间百分比