web项目测试实战性能测试结果分析样章报告Word格式文档下载.docx
《web项目测试实战性能测试结果分析样章报告Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《web项目测试实战性能测试结果分析样章报告Word格式文档下载.docx（17页珍藏版）》请在冰豆网上搜索。
图5-5事务摘要图
HTTPResponsesSummary（HTTP响应摘要）
该部分显示在场景执行过程中，每次HTTP请求发出去的状态，是成功还是失败，都在这里体现，如图5-6所示。
从图中可以看到，在本次测试过程中LoadRunner共模拟发出了211974次请求（与“统计信息摘要”中的“TotalHits”一致），其中“HTTP200”的是209811次，而“HTTP404”则有2163，说明在本次过程中，经过发出的请求大部分都能正确响应了，但还是有部分失败了，但未影响测试结果，“HTTP200”表示请求被正确响应，而“HTTP404”表示文件或者目录未能找到。
有朋友可能会问，这里出现了404的错误，为什么结果还都通过了。
出现这样问题的原因是脚本有些页面的请求内容并非关键点，比如可能请求先前的cookie信息，如果没有就重新获取，所以不会影响最终的测试结果。
图5-6HTTP响应摘要
常用的HTTP状态代码如下：
400无法解析此请求。
401.1XX：
访问由于凭据无效被拒绝。
401.2XX:
访问由于服务器配置倾向使用替代身份验证方法而被拒绝。
401.3XX：
访问由于ACL对所请求资源的设置被拒绝。
401.4XX：
Web服务器上安装的筛选器授权失败。
401.5XX：
ISAPI/CGI应用程序授权失败。
401.7XX：
由于Web服务器上的URL授权策略而拒绝访问。
403禁止访问：
访问被拒绝。
403.1禁止访问：
执行访问被拒绝。
403.2禁止访问：
读取访问被拒绝。
403.3禁止访问：
写入访问被拒绝。
403.4禁止访问：
需要使用SSL查看该资源。
403.5禁止访问：
需要使用SSL128查看该资源。
403.6禁止访问：
客户端的IP地址被拒绝。
403.7禁止访问：
需要SSL客户端证书。
403.8禁止访问：
客户端的DNS名称被拒绝。
403.9禁止访问：
太多客户端试图连接到Web服务器。
403.10禁止访问：
Web服务器配置为拒绝执行访问。
403.11禁止访问：
密码已更改。
403.12禁止访问：
服务器证书映射器拒绝了客户端证书访问。
403.13禁止访问：
客户端证书已在Web服务器上吊销。
403.14禁止访问：
在Web服务器上已拒绝目录列表。
403.15禁止访问：
Web服务器已超过客户端访问许可证限制。
403.16禁止访问：
客户端证书格式错误或未被Web服务器信任。
403.17禁止访问：
客户端证书已经到期或者尚未生效。
403.18禁止访问：
无法在当前应用程序池中执行请求的URL。
403.19禁止访问：
无法在该应用程序池中为客户端执行CGI。
403.20禁止访问：
Passport登录失败。
404找不到文件或目录。
404.1文件或目录未找到：
网站无法在所请求的端口访问。
需要注意的是404.1错误只会出现在具有多个IP地址的计算机上。
如果在特定IP地址/端口组合上收到客户端请求，而且没有将IP地址配置为在该特定的端口上侦听，则IIS返回404.1HTTP错误。
例如，如果一台计算机有两个IP地址，而只将其中一个IP地址配置为在端口80上侦听，则另一个IP地址从端口80收到的任何请求都将导致IIS返回404.1错误。
只应在此服务级别设置该错误，因为只有当服务器上使用多个IP地址时才会将它返回给客户端。
404.2文件或目录无法找到：
锁定策略禁止该请求。
404.3文件或目录无法找到：
MIME映射策略禁止该请求。
405用于访问该页的HTTP动作未被许可。
406客户端浏览器不接受所请求页面的MIME类型。
407Web服务器需要初始的代理验证。
410文件已删除。
412客户端设置的前提条件在Web服务器上评估时失败。
414请求URL太大，因此在Web服务器上不接受该URL。
500服务器内部错误。
500.11服务器错误：
Web服务器上的应用程序正在关闭。
500.12服务器错误：
Web服务器上的应用程序正在重新启动。
500.13服务器错误：
Web服务器太忙。
500.14服务器错误：
服务器上的无效应用程序配置。
500.15服务器错误：
不允许直接请求GLOBAL.ASA。
500.16服务器错误：
UNC授权凭据不正确。
500.17服务器错误：
URL授权存储无法找到。
500.18服务器错误：
URL授权存储无法打开。
500.19服务器错误：
该文件的数据在配置数据库中配置不正确。
500.20服务器错误：
URL授权域无法找到。
500100内部服务器错误：
ASP错误。
501标题值指定的配置没有执行。
502Web服务器作为网关或代理服务器时收到无效的响应。
并发数分析
“RunningVusers（运行的并发数）”显示了在场景执行过程中并发数的执行情况。
它们显示Vuser的状态、完成脚本的Vuser的数量以及集合统计信息，将这些图与事务图结合使用可以确定Vuser的数量对事务响应时间产生的影响。
图5-7显示了在OA系统考勤业务性能测试过程中Vusers运行情况，从图中我们可以看到，Vusers的运行趋势与我们场景执行计划中的设置是一样，表明在场景执行过程中，Vusers是按照我们预期的设置运行的，没有Vuser出现运行错误，这样从另一个侧面说明我们的参数化设置是正确的，因为使用唯一数进行参数化设置，如果设置不正确，将会导致Vuser运行错误。
在脚本中我们加入了这样一段代码：
if（atoi（lr_eval_string（"
{num}"
））>
0）{
lr_output_message（"
登录成功，继续执行."
）;
}
else{
lr_error_message（"
登录失败，退出测试"
return-1;
}
上述代码的意思是说，如果登录失败了，就退出脚本的迭代，那么什么原因可能会导致登录失败呢？
就是我们前面参数化的设置，一旦Vuser分配不到正确的登录账号，就可能导致登录失败，从而引起Vuser停止运行。
所以，从图5-7的表现，可以认为参数化是没有问题的。
图5-7运行的并发数图
测试脚本中我们还使用了集合点，那么这里还可以看看集合点在场景执行过程中的表现，点击左边的“NewGraph”，出现图5-8，展开“Vusers”前的加号，双击“Rendezvous”，出现集合点的图形后，点击【Close】，关闭添加新图界面。
图5-8添加集合点统计图
集合点的图形如图5-9所示，从图中可以看到，所有用户到达集合点后，立刻就释放了。
与之前设定的集合点策略设置“所有运行用户到达后释放“是一致的。
假设这样的一种情况，Running的Vusers有10个，集合点策略设置是“所有运行用户到达后释放”，而集合点图形显示的最大释放Vusers是7个，那么就表示有些Vuser超时了，引起超时的原因可能是Vuser得到的响应超时了，可以结合平均事务响应时间再详细分析原因。
图5-9集合点状态图
我们本次测试RunningVusers与集合点是一致，说明整个场景执行过程中，并发数用户的执行正确，OA系统测试服务器能够应付7个并发用户的业务操作。
响应时间
在性能测试要求中我们知道，有一项指标是要求登录、考勤业务操作的页面响应时间不超过3秒，那么本次测试是否达到了这个要求呢？
我们先来看“AverageTransactionResponseTime（平均事务响应时间图）”（图5-10），这张图是平均事务响应时间与结果摘要中的“TransactionSummary”合成的。
图5-10平均事务响应时间图
从图形下部我们可以看到，登录部分对应的Action是“submit_login”，考勤业务提交对应的Action是“submit_sign”，他们的“AverageTime（平均响应时间为）”分别是4.425秒与0.848秒，从这两个数值来看，考勤业务的事务响应时间0.848秒小于预期的3秒，达到了要求，而登录是4.425秒，大于预期的3秒，不符合要求。
这样的结果是不正确的，因为在统计的登录业务的时候，我们没有去除思考时间，所以，登录功能的实际事务时间应该是4.425秒-3秒=1.425秒，小于预期的3秒，故登录业务的事务响应时间也达到了我们的要求。
在平时的性能测试活动中，统计结果的时候需要去掉思考时间，加上思考时间是为了真实的模拟用户环境，统计结果中除去思考时间是为了更真实的反映服务器的处理能力，两者并不矛盾。
看完了“AverageTime”，我们再看“90PercentTime”，这个时间从某种程度来说，更准确衡量了测试过程中各个事务的真实情况，表示90%的事务，服务器的响应都维持在某个值附近，“AverageTime”值对于平均事务响应时间变动趋势很大的情况统计就不准确了，比如有三个时间：
1秒、5秒、12秒，则平均时间为6秒，而另外一种情况：
5秒、6秒、7秒，平均时间也为6秒，显然第二种比第一种要稳定多了。
所以，我们在查看平均事务响应时间的时候，先看整体曲线走势，如果整体趋势比较平滑，没有忽上忽下的波动情况，取“AverageTime”与“90PercentTime”都可以，如果整体趋势毫无规律，波动非常大，我们就不用“AverageTime”而使用“90PercentTime”可能更真实些。
从图5-10可以看出，所有Action平均事务响应时间的趋势都非常平滑，所以使用“AverageTime”与“90PercentTime”差别不是很大，用哪个都可以。
这里是使用最常用的统计方法“90PercentTime”。
登录业务的“90PercentTime”是5.298秒-3秒（思考时间）=2.298秒，考勤业务的“90PercentTime”是1.469秒，没有思考时间，那么就是实打实的啦。
根据上面的计算，本次测试结果记录如表5-1所示。
测试项
目标值
实际值
是否通过
登录业务响应时间
<
=3秒
2.298秒
Y
考勤业务响应时间
1.469秒
登录业务成功率
100%
考勤业务成功率
登录业务总数
30分钟完成2000
考勤业务总数
CPU使用率
75%
内存使用率
70%
表5-1测试结果对照表一
每秒点击数
“HitsperSecond（每秒点击数）”反映了客户端每秒钟向服务器端提交的请求数量，如果客户端发出的请求数量越多，与之相对的“AverageThroughput（bytes/second）”也应该越大，并且发出的请求越多会对平均事务响应时间造成影响，所以在测试过程中往往将这三者结合起来分析。
图5-11显示的是“HitsperSecond”与“AverageThroughput（bytes/second）”的复合图，从图中可以看出，两种图形的曲线都正常并且基本一致，说明服务器能及时的接受客户端的请求，并能够返回结果。
如果“HitsperSecond”正常，而“AverageThroughput（bytes/second）”不正常，则表示服务器虽然能够接受服务器的请求，但返回结果较慢，可能是程序处理缓慢。
如果“HitsperSecond”不正常，则说明客户端存在问题，那种问题一般是网络引起的，或者录制的脚本有问题，未能正确的模拟用户的行为。
具体问题具体分析，这里仅给出一些建议。
图5-11每秒点击数与每秒吞吐量复合图
对于本次测试来说，“HitsperSecond”与“AverageThroughput（bytes/second）”都是正常的，而且整体表现还是不错的。
一般情况下，这两种指标用于性能调优，比如给定了几个条件，去检测另外一个条件，用这两个指标衡量，往往起到很好的效果。
比如要比较某两种硬件平台的优劣，就可以使用相同的配置方法部署软件系统，然后使用相同的脚本、场景设计、统计方法去分析，最终得出一个较优的配置。
业务成功率
“业务成功率”这个指标在很多系统中都提及到，比如电信的、金融的、企业资源管理的等等。
举个例子，我们楼下的建行，假如每天的业务类别是这样的：
20个开户，5个销户，300个存款，500取款，100个汇款等，那么在做他们的营业系统测试时就需要考虑业务成功率了，一般不得低于98%。
具体的业务成功率是什么意思呢？
排除那些复杂的业务，比如异步处理的业务（移动的套卡开通就是异步的），业务成功率就是事务成功率，用户一般把一个Aciton当做一笔业务，在LoadRunner场景执行中一笔交易称为一个事务。
所以，说业务成功率其实就是事务成功率、通过率的意思。
在“TransactionSummary”中我们可以很明确的看到每个事务的执行状态，如图5-12所示。
图5-12事务状态统计图
从图中可以看出，所有的Aciton都是绿色的，即表示为Passed，同时除了vuser_init与vuser_end两个事务，其他的事务通过数为2163，也就表明在30分钟的时间里，共完成了2163次登录考勤业务操作。
那么根据这些可以判断本次测试登录业务与考勤业务的成功率是100%，再次更新测试结果记录表如表5-2所示。
2163
表5-2测试结果对照表二
系统资源
系统资源图显示了在场景执行过程中被监控的机器系统资源使用情况，一般情况下监控机器的CPU、内存、网络、磁盘等各个方面。
本次测试监控的是测试服务器的CPU使用率与内存使用率，以及处理器队列长度，具体的数据如图5-13所示。
图5-13测试服务器系统资源监控结果图
从图中可以看出，CPU使用率、可用物理内存、CPU的队列长度三个指标的曲线逗较为平滑，三者的平均值分别为：
53.582%、83.456M、8.45，而测试服务器总的物理内存为384M，那么内存使用率为（384-83.456）/384=78.26%，根据本次性能测试要求的：
CPU使用率不超过75%，物理内存使用率不超过70%这两点来看，内存的使用率78.26%大于预期的70%，故内存使用率不达标。
根据Windwos资源性能指标的解释，一般情况下，如果“ProcessorQueueLength（处理器队列长度）”一直超过二，则可能表示处理器堵塞，我们这里监控出来的数值是8.45，而且总体上保持平衡，那么由此推断，测试服务器的CPU也可能是个瓶颈。
同时在测试过程中，场景执行到23分半钟的时候，报出了错误！
未找到引用源。
的错误，意思是说被监控的服务器当前无法再进行计数器数据的获取了，所以，本次操作系统资源的监控只得到了场景执行的前23分半钟的数据。
这样对本次测试结果有一定的影响。
获得上述数据后，最新的测试结果记录表如表5-3所示。
53.582%
78.26%
N
表5-3测试结果对照表三
从上表数据来看，本次测试总体上已经达到了预期的性能指标，但从其他的数据，比如CPU的队列长度、内存使用率来看，被测服务器的硬件资源需要提升。
网页细分图
网页细分图可以评估页面内容是否影响事务响应时间。
使用网页细分图，可以分析网站上有问题的元素（例如下载很慢的图像或打不开的链接）。
我们这里查看一下网页细分图中的“PageDownloadTimeBreakdown”，点击错误！
左边的“NewGraph”，出现图5-14，展开“WebPageDiagnostics”前的加号，双击“PageDownloadTimeBreakdown”，待出现“PageDownloadTimeBreakdown”监控图后，点击【Close】按钮关闭添加监控图界面。
图5-14添加网页细分图
在监控图列表中，我们看到图5-15，从图中我们看到，在所有的页面中，登录后的用个人面页面“http:
//192.168.0.52:
8080/oa/oa.jsp”的下载时间最长。
图5-15网页下载时间细分图
图5-16详细列出了每个页面所消耗的时间分布，图中每一个指标含义见表5-4所示。
该表由LoadRunner使用手册提供。
通过这些指标的数据，我们可以轻易的判断是哪个页面、哪个请求导致了响应时间变长，甚至响应失败。
图5-16oa.jsp页面下载时间分布图
名称
描述
ClientTime
显示因浏览器思考时间或其他与客户端有关的延迟而使客户机上的请求发生延迟时，所经过的平均时间。
ConnectionTime
显示与包含指定URL的Web服务器建立初始连接所需的时间。
连接度量是一个很好的网络问题指示器。
此外，它还可表明服务器是否对请求做出响应。
DNSResolutionTime
显示使用最近的DNS服务器将DNS名称解析为IP地址所需的时间。
DNS查找度量是指示DNS解析问题或DNS服务器问题的一个很好的指示器。
ErrorTime
显示从发出HTTP请求到返回错误消息（仅限于HTTP错误）这期间经过的平均时间。
FirstBufferTime
显示从初始HTTP请求（通常为GET）到成功收回来自Web服务器的第一次缓冲时为止所经过的时间。
第一次缓冲度量是很好的Web服务器延迟和网络滞后指示器。
（注意：
由于缓冲区大小最大为8K，因此第一次缓冲时间可能也就是完成元素下载所需的时间。
）
FTPAuthernticationTime
显示验证客户端所用的时间。
如果使用FTP，则服务器在开始处理客户端命令之前，必须验证该客户端。
FTP验证度量仅适用于FTP协议通信
ReceiveTime
显示从服务器收到最后一个字节并完成下载之前经过的时间。
接收度量是很好的网络质量指示器（查看用来计算接收速率的时间/大小比率）。
SSLHandshakingTime
显示建立SSL连接（包括客户端hello、服务器hello、客户端公用密钥传输、服务器证书传输和其他部分可选阶段）所用的时间。
此时刻后，客户端和服务器之间的所有通信都被加密。
SSL握手度量仅适用于HTTPS通信。
表5-4网页下载时间细分指标说明
对于本次测试，从网页细分图来看，基本上每个页面的加载时间都是预期范围内，oa.jsp页面因为集成了用户的个人工作平台，需要检索很多的数据，并合成了很多图片，所以相应的加载时间较长，这是正确的。
Web服务器资源
上述所有的监控图形LoadRunner都可以提供，但对于某些测试监控图来说，LoadRunner就没有提供了，期望其新版支持这些功能，当然想监控Tomcat、Jboss或者其他的Web服务器可以SiteScope工具，这个工具配置较为复杂，根据个人需要吧。
我这里监控Tomcat使用的是ManageEngineApplicationsManager8的试用版，测试结束后得出Tomcat的JVM使用率如图5-17所示。
图5-17TomcatJVM使用率监视图
从图中我们可以明显看出，Tomcat的JVM使用率不断上升，配置Tomcat时共分配了100M左右的物理内存给其，测试初期使用的JVM相对来说较少，我们的测试场景是从15:
从图中看到，从16:
00到16:
30这个时间内，也就是测试场景执行期间，JVM的使用率不断上升，并没有在请求达到均衡状态后也呈现一种平衡
升级会员 