逐步分析，Web项目性能测试实战

点击上方头像关注我，每周上午 09:00准时推送，每月不定期赠送技术书籍，小窗口回复“资源”、“测试工具包”领取测试资源。

一

性能测试指标

性能测试目标

软件性能测试的目的主要有以下3点：

评价系统当前性能，判断系统是否满足预期的性能需求。

寻找软件系统可能存在的性能问题，定位性能瓶颈并解决问题。

判定软件系统的性能表现，预见系统负载压力，在应用部署之前，评估系统性能。

而对于用户来说，则最关注的是当前系统：

是否满足上线性能要求？

系统极限承载如何？

系统稳定性如何？

性能测试关键指标

资源指标

CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。

内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。

磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。

络带宽：一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断 络连接速度是否是瓶颈，可以用该计数器的值和目前 络的带宽比较。

系统指标

并发用户数：某一物理时刻同时向系统提交请求的用户数。

在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。

平均响应时间：系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。

事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务

超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率。

二

性能结果分析

测试结果分析

LoadRunner性能测试结果分析是个复杂的过程，通常可以从结果摘要、并发数、平均事务响应时间、每秒点击数、业务成功率、系统资源、 页细分图、Web服务器资源、数据库服务器资源等几个方面分析，如图1- 1所示。

性能测试结果分析的一个重要的原则是以性能测试的需求指标为导向。我们回顾一下本次性能测试的目的，正如 所列的指标，本次测试的要求是验证在30分钟内完成2000次用户登录系统，然后进行考勤业务，最后退出，在业务操作过程中页面的响应时间不超过3秒，并且服务器的CPU使用率、内存使用率分别不超过75%、70%；

那么按照所示的流程，我们开始分析，看看本次测试是否达到了预期的性能指标，其中又有哪些性能隐患，该如何解决？

图1- 1性能测试结果分析流程图

结果摘要

LoadRunner进行场景测试结果收集后，首先显示的该结果的一个摘要信息，如图1- 2所示。

(1) 测试概要

场景执行情况

Statistics Summary（统计信息摘要）

Transaction Summary（事务摘要）

HTTP Responses Summary（HTTP响应摘要）

以简要的信息列出本次测试结果。

图1- 2 性能测试结果摘要图

(2)场景执行情况

该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如图1- 3所示。

从该图我们知道，本次测试从15:58:40开始，到16:29:42结束，共历时31分2秒。与我们场景执行计划中设计的时间基本吻合。

图1- 3场景执行情况描述图

(3) Statistics Summary（统计信息摘要）

该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图1- 4所示。

从该图我们得知，本次测试运行的最大并发数为7，总吞吐量为842,037,409字节，平均每秒的吞吐量为451,979字节，总的请求数为211,974，平均每秒的请求为113.781，对于吞吐量，单位时间内吞吐量越大，说明服务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量一般是成正比关系。

(4) Transaction Summary（事务摘要）

该部分给出了场景执行结束后相关Action的平均响应时间、通过率等情况，如图1- 5所示。

从该图我们得到每个Action的平均响应时间与业务成功率。

注意：因为在场景的“Run-time Settings”的“Miscellaneous”选项中将每一个Action当成了一个事务执行，故这里的事务其实就是脚本中的Action。

图1- 5 事务摘要图

(5) HTTP Responses Summary（HTTP响应摘要）

该部分显示在场景执行过程中，每次HTTP请求发出去的状态，是成功还是失败，都在这里体现，如图1- 6所示。

从图中可以看到，在本次测试过程中LoadRunner共模拟发出了211974次请求（与“统计信息摘要”中的“Total Hits”一致），其中“HTTP 200”的是209811次，而“HTTP 404”则有2163，说明在本次过程中，经过发出的请求大部分都能正确响应了，但还是有部分失败了，但未影响测试结果

“HTTP 200”表示请求被正确响应，

“HTTP 404”表示文件或者目录未能找到。

有朋友可能会问，这里出现了404的错误，为什么结果还都通过了。出现这样问题的原因是脚本有些页面的请求内容并非关键点，比如可能请求先前的cookie信息，如果没有就重新获取，所以不会影响最终的测试结果。

图1- 6 HTTP响应摘要

三

性能指标分析

并发数分析

“Running Vusers（运行的并发数）”显示了在场景执行过程中并发数的执行情况。它们显示Vuser的状态、完成脚本的Vuser的数量以及集合统计信息，将这些图与事务图结合使用可以确定Vuser的数量对事务响应时间产生的影响。

图1- 7显示了在OA系统考勤业务性能测试过程中Vusers运行情况，从图中我们可以看到，Vusers的运行趋势与我们场景执行计划中的设置是一样，表明在场景执行过程中，Vusers是按照我们预期的设置运行的，没有Vuser出现运行错误，这样从另一个侧面说明我们的参数化设置是正确的，因为使用唯一数进行参数化设置，如果设置不正确，将会导致Vuser运行错误。在脚本中我们加入了这样一段代码：

上述代码的意思是说，如果登录失败了，就退出脚本的迭代；

那么什么原因可能会导致登录失败呢？就是我们前面参数化的设置，一旦Vuser分配不到正确的登录账 ，就可能导致登录失败，从而引起Vuser停止运行。所以，从图1- 7的表现，可以认为参数化是没有问题的。

图1- 7 运行的并发数图

测试脚本中我们还使用了集合点，那么这里还可以看看集合点在场景执行过程中的表现，点击左边的“New Graph”，出现图1- 8，展开“Vusers”前的加 ，双击“Rendezvous”，出现集合点的图形后，点击【Close】，关闭添加新图界面图

1- 8 添加集合点统计图

集合点的图形如图1- 9所示，从图中可以看到，所有用户到达集合点后，立刻就释放了。与之前设定的集合点策略设置“所有运行用户到达后释放“是一致的。假设这样的一种情况，Running的Vusers有10个，集合点策略设置是“所有运行用户到达后释放”，而集合点图形显示的最大释放Vusers是7个，那么就表示有些Vuser超时了，引起超时的原因可能是Vuser得到的响应超时了，可以结合平均事务响应时间再详细分析原因。

图1- 9 集合点状态图

我们本次测试Running Vusers与集合点是一致，说明整个场景执行过程中，并发数用户的执行正确，OA系统测试服务器能够应付7个并发用户的业务操作。

响应时间

在性能测试要求中我们知道，有一项指标是要求登录、考勤业务操作的页面响应时间不超过3秒，那么本次测试是否达到了这个要求呢？我们先来看“Average Transaction Response Time（平均事务响应时间图）”（图1- 10），这张图是平均事务响应时间与结果摘要中的“Transaction Summary”合成的。

图1- 10 平均事务响应时间图

从图形下部我们可以看到，登录部分对应的Action是“submit_login”，考勤业务提交对应的Action是“submit_sign”，他们的“Average Time（平均响应时间为）”分别是4.425秒与0.848秒，从这两个数值来看，考勤业务的事务响应时间0.848秒小于预期的3秒，达到了要求，而登录是4.425秒，大于预期的3秒，不符合要求。这样的结果是不正确的。

因为在统计的登录业务的时候，我们没有去除思考时间，所以，登录功能的实际事务时间应该是4.425秒-3秒=1.425秒，小于预期的3秒，故登录业务的事务响应时间也达到了我们的要求。在平时的性能测试活动中，统计结果的时候需要去掉思考时间，加上思考时间是为了真实的模拟用户环境，统计结果中除去思考时间是为了更真实的反映服务器的处理能力，两者并不矛盾。

看完了“Average Time”，我们再看“90 Percent Time”，这个时间从某种程度来说，更准确衡量了测试过程中各个事务的真实情况，表示90%的事务，服务器的响应都维持在某个值附近，“Average Time”值对于平均事务响应时间变动趋势很大的情况统计就不准确了，比如有三个时间：1秒、5秒、12秒，则平均时间为6秒，而另外一种情况：5秒、6秒、7秒，平均时间也为6秒，显然第二种比第一种要稳定多了。

所以，我们在查看平均事务响应时间的时候，先看整体曲线走势，如果整体趋势比较平滑，没有忽上忽下的波动情况，取“Average Time”与“90 Percent Time”都可以，如果整体趋势毫无规律，波动非常大，我们就不用“Average Time”而使用“90 Percent Time”可能更真实些。

从图1-10可以看出，所有Action平均事务响应时间的趋势都非常平滑，所以使用“Average Time”与“90 Percent Time”差别不是很大，用哪个都可以。这里是使用最常用的统计方法“90 Percent Time”。登录业务的“90 Percent Time”是5.298秒-3秒（思考时间）=2.298秒，考勤业务的“90 Percent Time”是1.469秒，没有思考时间，那么就是实打实的啦。根据上面的计算，本次测试结果记录如下图所示。

每秒点击数

“Hits per Second（每秒点击数）”反映了客户端每秒钟向服务器端提交的请求数量，如果客户端发出的请求数量越多，与之相对的“Average Throughput (bytes/second)”也应该越大，并且发出的请求越多会对平均事务响应时间造成影响，所以在测试过程中往往将这三者结合起来分析。