theprocessofperformanceanalysis..doc

在测试场景执行完成后，很多测试工程师认为最困难的阶段到来了——性能测试结果分析。因此，本章似乎很自然地就成为了最重要的一章，但作者却认为性能测试分析并不是最难的工作。所谓“万丈高楼平地起”，也就说明性能分析的准确性同样取决于此前所做的设计与实施等“地基”是否可靠。因此可以说，性能测试分析仅仅是百米赛跑中的最后二十米而已。当然，这并不是说性能测试分析不重要，因为“最后冲刺的二十米没有跑好”，前面工作做得再好也是徒劳的。由此不难理解，性能测试分析工作开展的根基就是前面测试场景执行的结果。要想保证性能测试分析的结论是正确的，那么测试结果数据首先就应该是正确的，而这也意味着测试场景以及测试执行过程都应该是正确的。 实际上，性能测试从始至终都应该是相当严谨的一项工程，各个阶段的工作环环相扣，因此，性能测试工程师应该认真对待每一个阶段的工作。如果一味地追求找出系统瓶颈，无疑是舍本逐末的做法。 如果脱离实际应用或仅拿出某些孤立的测试结果来介绍LoadRunner的Analysis如何使用，相信很多读者将会一头雾水，仍然不能解决实际问题。因此，本章首先结合案例来讲解如何分析性能测试结果，然后探讨Analysis的具体使用细节，这也是本章不同于第3、4章的地方。 本章的主要内容如下： n? 如何分析性能测试结果 n? 如何从分析图中发现问题 n? 分析图的处理方法 n? Analysis分析报告 5.1? 如何分析性能测试结果 在Controller执行的测试场景结束后，首先要做的是判断采集到的结果数据是否真实有效。多数性能测试场景都需要迭代地进行测试，因此很多测试结果本身就不能反映真正的问题，而深入分析这样的结果纯属浪费时间。在本书中，主要探讨如何针对有效的测试结果数据进行分析。 判断测试结果是否有效，通常按下面的步骤进行： 第一步：在整个测试场景的执行过程中，测试环境是否正常。如果在测试过程中出现过异常，那么这样得出的结果往往不准确，无须进行分析。 例如，在测试执行过程中，测试机的CPU利用率经常达到100%、测试环境的网络不稳定、一些系统参数配置不正确等等，这样得出的测试结果没有必要进行分析，应该重新设置测试场景或调整测试环境，再次执行测试。 第二步：测试场景的设置是否正确、合理。测试场景的设置是否正确对测试结果有很大的影响。因此，当测试出现异常时，我们要对场景设置进行分析。 一些新手在使用Controller执行测试时，可能会同时在一台PC上加载全部虚拟用户——例如同时加载1000个虚拟用户，如果客户端来不及处理，就会有很多虚拟用户因不能初始化而失败。失败的根本原因不是被测试的应用服务器不能处理，而是压力根本没有传输过去。正确的做法是增加更多的Generator或逐步加压，使测试场景运行起来。 第三步：测试结果是否直接暴露出系统的一些问题。对测试场景的整个执行过程，没有必要对压力下系统运行正常的结果进行分析，因为这样的结果不能反映出系统的性能问题，应该进一步调整场景（比如增大压力）进行测试。在测试过程中使系统表现不正常的测试场景生成的结果则要进行深入分析。实际上，分析能够反映性能问题的测试结果才是性能分析阶段的主要工作。 测试结果直接暴露系统存在性能问题的情形很多，例如在测试过程中一些用户事务响应时间过长、系统支持的最大并发用户数过低、系统的应用服务器CPU利用率过高或内存不足等。对这类测试结果，性能测试人员需要借助Analysis对其进行深入分析，以发现一些潜在的性能问题。 本节先介绍性能测试分析的基础知识，然后介绍LoadRunner Analysis的使用基础，最后结合案例介绍如何找出并解决系统的性能问题。 5.1.1? 性能分析基础知识 性能分析的基本原则 确定测试结果有效之后，接下来就要开始对测试数据进行深入的挖掘了。面对测试工具产生的纷繁复杂的原始测试数据，如何来进行分析呢？一个普遍遵循的原则是“由外而内，由表及里，层层深入”，如图5-1所示。 图5-1? 性能分析原则示意图 对于一个应用系统，性能开始出现下降的最直接表象就是系统的响应时间变长。于是，系统响应时间成为分析性能的起点。性能分析的原则如图5-1所示，首先应该从原始测试数据中查看系统响应时间，判断它是否满足用户性能的期望。如果不能满足，则说明系统的性能出现了问题。发现系统存在问题后，就要判断系统在哪个环节出现了瓶颈。 现在的IT系统架构极其复杂，任何一个环节出现瓶颈，都会导致系统出现性能问题。要准确地判断瓶颈在什么地方，的确是一个棘手的问题。不过，任何复杂的系统都分为网络和服务器两部分。因此要考察的第二个问题就是：系统的瓶颈是出现在网络环节，还是服务器环节？ 如图5-2所示，用户从客户端发起的请求数据包经过网络，传递到应用服务器，最后到达数据库服务器，服务器处