web项目测试实战性能测试结果分析样章报告.pdfVIP

5 。4 。2 测试结果分析 LoadRunner 性能测试结果分析是个复杂的过程，通常可以从结果摘要、并发数、平均 事务响应时间、每秒点击数、业务成功率、系统资源、网页细分图、Web 服务器资源、数 据库服务器资源等几个方面分析，如图5— 1 所示。性能测试结果分析的一个重要的原则是 以性能测试的需求指标为导向。我们回顾一下本次性能测试的目的 ,正如错误!未找到引用 源。 所列的指标，本次测试的要求是验证在30 分钟内完成2000 次用户登录系统，然后进 行考勤业务，最后退出，在业务操作过程中页面的响应时间不超过3 秒,并且服务器的CPU 使用率、内存使用率分别不超过 75 ％、70%,那么按照所示的流程，我们开始分析，看看本 次测试是否达到了预期的性能指标，其中又有哪些性能隐患,该如何解决。 图5— 1 性能测试结果分析流程图 结果摘要 LoadRunner 进行场景测试结果收集后，首先显示的该结果的一个摘要信息,如图 5— 1 所示。概要中列出了场景执行情况、“Statistics Summary （统计信息摘要) ”、“Transaction Summary （事务摘要) ”以及“HTTP Responses Summary （HTTP 响应摘要）”等。以简要 的信息列出本次测试结果。 图5— 1 性能测试结果摘要图 场景执行情况 该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如图5— 错误! 未定义书签。所示。从该图我们知道，本次测试从15：58：40 开始,到 16：29 ：42 结束， 共历时31 分2 秒。与我们场景执行计划中设计的时间基本吻合. 图5— 错误!未定义书签。场景执行情况描述图 Statistics Summary （统计信息摘要） 该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每 秒请求数的统计值，如图5- 错误!未定义书签。所示。从该图我们得知，本次测试运行的最 大并发数为7 ，总吞吐量为842，037,409 字节，平均每秒的吞吐量为451,979 字节,总的请求 数为211，974，平均每秒的请求为113。781,对于吞吐量，单位时间内吞吐量越大，说明服 务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量一般是成正比 关系。 图5- 错误!未定义书签。统计信息摘要图 Transaction Summary （事务摘要） 该部分给出了场景执行结束后相关Action 的平均响应时间、通过率等情况，如图5- 2 所示。从该图我们得到每个Action 的平均响应时间与业务成功率. 注意： 因为在场景的“Run—time Settings”的“Miscellaneous”选项中将每 一个 Action 当成了一个事务执行，故这里的事务其实就是脚本中的 Action 。 图5- 2 事务摘要图 HTTP Responses Summary （HTTP 响应摘要） 该部分显示在场景执行过程中，每次HTTP 请求发出去的状态，是成功还是失败，都在 这里体现，如图5— 2 所示。从图中可以看到,在本次测试过程中LoadRunner 共模拟发出了 211974 次请求（与“统计信息摘要”中的“Total Hits一致），其中“HTTP 200 ”的是209811 次,而“HTTP 404 ”则有2163,说明在本次过程中，经过发出的请求大部分都能正确响应了， 但还是有部分失败了,但未影响测试结果，“HTTP 200 ”表示请求被正确响应，而“HTTP 404 ” 表示文件或者目录未能找到.有朋友可能会问,这里出现了404 的错误，为什么结果还都通过 了。出现这样问题的原因是脚本有些页面的请求内容并非关键点，比如可能请求先前的 cookie 信息，如果没有就重新获取，所以不会影响最终的测试结果。 图5— 2 HTTP 响应摘要 常用的HTTP 状态代码如下： 400 无法解析此请求。 401 。