软件测试实验报告.docx

《软件质量保证与测试》
实验报告

实验一 用例设计
1. 实验目的
(1) 能够熟练应用黑盒测试技术进行测试用例设计
(2) 对测试用例进行优化测试
2. 实验设备
主流PC机一套，安装有jdk、jre、tomcat、mysql，至少两种主流浏览器，截屏或录屏软件
3. 实验内容
（1）为QQ的注册账号功能设计测试用例。
详细的界面可打开QQ网站的注册账号链接查看，每个字段的要求点击相应的输入域即可看到。
（2）教材二上的《大学学籍管理系统》中的登录和添加学生信息功能。
4. 实验要求
从实验内容（1）和（2）选择一项内容，使用黑盒测试的方法设计测试用例，撰写实验报告
选做实验内容1
5、 QQ注册页面测试
功能（注册账户）
有效等价类
无效等价类
昵称
1.必填
2.不能超过24个字母或12个汉字
（可以包含特殊字符）

1.不填
2. >24个字母
<12个汉字
密码
1.必填
2.长度为6-16个字符
3.不能包含空格
4.不能是9位以下纯数字

不填
小于6个字符
大于16个字符
包含空格
纯数字
确认密码
必填
密码一致
不填
不同的密码
性别
二选一

生日
在所供给的范围内
（公历：1898—2017年 1-12月 1-31日）
1898.1.1—2017.3.2
（农历：1898—2017年 1-12月 1-30
超过范围
除数字外的字符
所在地
在所供给的范围内
超过范围
数字或字母或其他特殊字符
手机号码
有效手机号
无效手机号
短信验证码
有效
无效
Tab键是否有效

注册失败返回页面是否显示出正确信息

测试用例：
序号
输入
期望结果
1
在“昵称”文本框什么也不输
提示昵称不可以为空
2
AWE@#%$^#%&**(&^#$!@#~
（蠕虫这是第一次数字世界战争）
提示不能超过24个字母或12个汉字
3
在“昵称”文本框输入“！@#”
提示该昵称可以使用
4
在“密码”文本框什么也不输
提示密码不可以为空
5
在“密码”文本框输入“123ab”
提示长度为6~16个字符
6
在“密码”文本框输入“Shool #$+”
提示不能包含空格
7
在“密码”文本框输入“123”
提示不能是9位以下纯数字
8
在“密码”文本框输入“123456789”
提示该密码可以使用
9
在“密码”文本框输入“Shool#$+”
提示该密码可以使用
10
在“确认密码”文本框输入与“密码”文本框不一样的内容
提示密码不一致
11
在“确认密码”文本框输入与“密码”文本框相同的内容
提示密码设置成功
12
阴历阳历、年、月、日四个下拉列表框检测
能正常拉动
13
下拉列表中内容的显示
能显示完整的内容
14
选择下拉列表中的内容后在相应显示栏显示内容
正确显示所选内容
15
点击输入显示框是有光标闪烁
光标闪烁，等待输入
16
在下拉列表中选择农历、1990、10、07
正确显示选择的内容
17
在显示输入框输入农历、1990、10、07
正确显示输入的内容
18
在年框中，月框，日框中分别输入超过列表的时间
自动跳转到今年的1月1日
19
国家、省、市三个下拉框检测
能正常拉动
20
下拉列表中内容的显示
能显示完整的内容
21
选择下拉列表中的内容后在相应显示栏显示内容
正确显示所选内容
22
点击输入显示框是有光标闪烁
光标闪烁，等待输入
23
在下拉列表中选中中国、河南、郑州
正确显示选择的内容
24
在显示输入框输入中国、河南、郑州
正确显示输入的内容
25
在手机号框中输入不正确的号码
提示输入正确号码
26
在手机号框中输入正确的号码
正确显示输入的内容
27
输入与系统给的验证码不一致
请输入正确的验证码
28
输入与系统给的验证码一致
验证码输入正确
29
同时开通qq空间和我已阅读并同意相关服务条款两个多选项检测
可以同时被选中
30
我已阅读并同意相关服务条款下拉列表框检测
能正常拉动
31
选择qq号码规则
能正常显示内容
32
选择qq空间协议
能正常显示内容
33
点击立即注册按钮
恭喜注册成功
34
Tab键是否正确响应
Tab键能正确响应顺序
35
输入框是否支持 复制和黏贴  和移动 

输入
输出
昵称
密码
确认密码
性别
年
月
日
所在地
手机号

验证码
期望结果
为空

提示昵称不可以为空
AWE@#%$^#%&**(&^#$!@#~
（蠕虫这是第一次数字世界战争）

可以通过

！@#
为空

提示密码不能为空
123ab

提示长度为6-16个字符
Shool#$+

可以通过
Shool #$+

提示不能为空格
123

提示不能是9位以下纯数字
123456789

可以通过
Shool#$+
为空

提示请再输入密码
Shool#$+
shool

提示密码不一致
昵称
密码
确认密码
性别
年
月
日
所在地
手机号
安全验证
验证码
期望结果

！@#

Shool#$+

Shool#$+

可以通过
男
1898
1
1

可以通过
男
1897

自动跳转至2017年
女
2017
3
2

可以通过

女
2017
3
3

自动跳转至1日

2005
2
28

下拉选择否则自动跳转

中国 安徽 马鞍山

下拉选择
为空

跳转另一页面提示请完成安全验证
为空或非数字
错误选择

提示验证错误

正确手机号
正确
正确
申请成功

6、实验总结
通过本次实验，我掌握了利用黑盒测试技术进行简单的测试用例设计，能够对登录等简单功能实现的进行测试，同时加深了我对黑盒测试的理解和掌握。

实验二 Web系统测试
1.实验目的
掌握用例执行及缺陷报告的书写方法。
2.实验设备
主流PC机一套，安装有jdk、jre、tomcat、mysql，至少两种主流浏览器，截屏或录屏软件
3.实验内容
执行实验1中的测试用例，准确描述发现的缺陷。
4.实验要求
将所发现的缺陷进行详细描述，撰写实验报告，附件若必要，也可使用视频，截取图片或抓取视频时，需要有浏览器的标题栏和地址栏。
5、
举例缺陷案例1：返回页面需重新填写信息　　　　　　　　　　　　　　　　　　　　　　　　　　　　
缺陷标题：QQ注册官方首页:注册失败返回页面所填信息为空
测试平台与浏览器：Windows 7 + IE10或360安全浏览器
测试步骤：
1. 打开QQ注册官网:
2. 分别在IE与360安全浏览器上观察主页信息
3. 正确填写前面信息，至手机验证填写错误，出现“你未通过安全验证，注册失败”
4. 点击返回，观察页面
期望结果：返回页面显示前面所填正确信息
实际结果：返回页面中前面所填正确信息全为空

举例缺陷案例2：发送短信验证存在问题　　　　　　　　　　　　　　　　　　　　　　　　　　　　
缺陷标题：QQ注册官方首页:用错误收件人号码发送短信验证显示注册成功
测试平台与浏览器：Windows 7 + IE10或360安全浏览器
测试步骤：
1. 打开QQ注册官网:
2. 正确填写前面信息，填写正确手机号，用错误收件人号码（106906021077）发送短信1完成验证
期望结果：注册失败
实际结果：申请成功

举例缺陷案例3：同一人同一手机号可重复注册相同QQ　　　　　　　　　　　　　　　　　　　　　　　　　　　　
缺陷标题：QQ注册官方首页:同一人相同的手机号可重复注册相同QQ
测试平台与浏览器：Windows 7 + IE10或360安全浏览器
测试步骤：
1. 打开QQ注册官网:
2. 正确填写自己已注册QQ相同信息，并填写同一手机号，完成验证
期望结果：提示此QQ已被你注册过
实际结果：申请成功
6、实验总结
通过本次实验，我掌握了如何查找缺陷，以及编写正确的缺陷描述标准格式。同时找到了一些常见的bug，也掌握了bug查找的一些规律，相信这对我学习本课程有了极大帮助。

实验三 代码分析与单元测试
1.实验目的
掌握白盒测试方法，并用白盒测试方法设计测试用例；
掌握使用Junit进行单元测试的方法。
2.实验设备
主流PC机一套，安装有Java的集成开发环境MyEclipse
3.实验内容
请按要求对下面的Java代码进行测试。代码的功能是：用折半查找法在元素呈升序排列的数组中查找值为key的元素。
public int binSearch(int array[],int key){
1 int mid,low,high;
2 low=0;
3 high=array.length-1;
4 while(low<=high){
5 mid=(low+high)/2;
6 if(key==array[mid])
7 return mid;
8 else if(key<array[mid])
9 high=mid-1;
10 else
11 low=mid+1;
12 }
13 return -1;
14 }
(1) 用基本路径测试给出测试路径；
(2) 为各测试路径设计测试用例。
（3）利用Junit实施自动测试

4.实验要求
撰写实验报告，给出测试用例，测试的源代码，及测试执行成功与否的截图。
5. 实验步骤及结果截图
（1） 绘制程序流程图：

程序的控制流图

2） 测试路径设计测试用例。

（3）利用Junit实施自动测试

源程序：

测试结果与预期结果一致。

总结：
白盒测试与程序内部结构相关，因此也称为结构测试或逻辑驱动测试，而在进行百合测试时，测试者必须检查程序的内部结构，从程序的逻辑结构着手，得出测试数据。

实验四 性能测试与结果分析
1. 实验目的
（1）掌握性能测试的原理，及使用LoadRunner进行性能测试的方法；
（2）掌握分析测试结果的基本方法。
2. 实验设备
主流PC机一套， LoadRunner 8.0
3. 实验内容
（1）选择《大学学籍管理系统》或loadrunner自带系统的登录功能；
（2）录制脚本（即创建虚拟用户脚本）；
（3）创建场景（设置用户数<=30），并执行场景；
（4）分析测试结果。
4. 实验要求
撰写实验报告，填写测试步骤和结果，包括：录制的测试脚本，场景的设置和测试结果图，可以截图。
LoadRunner性能测试结果分析是个复杂的过程，通常可以从结果摘要、并发数、平均事务响应时间、每秒点击数、业务成功率、系统资源、网页细分图、Web服务器资源、数据库服务器资源等几个方面分析，如图1-1所示。

图1-1 性能测试结果分析流程图
§ 结果摘要
　　　LoadRunner进行场景测试结果收集后，首先显示的该结果的一个摘要信息，如图1- 2所示。概要中列出了场景执行情况、“Statistics Summary（统计信息摘要）”、“Transaction Summary（事务摘要）”以及“HTTP Responses Summary（HTTP响应摘要）”等。以简要的信息列出本次测试结果。

图1- 2性能测试结果摘要图
场景执行情况
该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如图5- 3所示。从该图我们知道，本次测试从15:58:40开始，到16:29:42结束，共历时31分2秒。与我们场景执行计划中设计的时间基本吻合。

 图1- 3场景执行情况描述图
Statistics Summary（统计信息摘要）
该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图5- 4所示。从该图我们得知，本次测试运行的最大并发数为7，总吞吐量为842,037,409字节，平均每秒的吞吐量为451,979字节，总的请求数为211,974，平均每秒的请求为113.781，对于吞吐量，单位时间内吞吐量越大，说明服务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量一般是成正比关系。

图1- 4统计信息摘要图
Transaction Summary（事务摘要）
该部分给出了场景执行结束后相关Action的平均响应时间、通过率等情况，如图1- 5所示。从该图我们得到每个Action的平均响应时间与业务成功率。
注意：
　　因为在场景的“Run-time Settings”的“Miscellaneous”选项中将每一个Action当成了一个事务执行，故这里的事务其实就是脚本中的Action。

 图1- 5事务摘要图
HTTP Responses Summary（HTTP响应摘要）
该部分显示在场景执行过程中，每次HTTP请求发出去的状态，是成功还是失败，都在这里体现，如图5- 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运行错误。在脚本中我们加入了这样一段代码：
if (atoi(lr_eval_string("{num}")) > 0){
              lr_output_message("登录成功，继续执行.");
              }
        else{
              lr_error_message("登录失败，退出测试");
              return -1;
        }
上述代码的意思是说，如果登录失败了，就退出脚本的迭代，那么什么原因可能会导致登录失败呢？就是我们前面参数化的设置，一旦Vuser分配不到正确的登录账号，就可能导致登录失败，从而引起Vuser停止运行。所以，从图5- 7的表现，可以认为参数化是没有问题的。

 图1- 7运行的并发数图
测试脚本中我们还使用了集合点，那么这里还可以看看集合点在场景执行过程中的表现，点击左边的“New Graph”，出现图5- 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”可能更真实些。
从图5- 10可以看出，所有Action平均事务响应时间的趋势都非常平滑，所以使用“Average Time”与“90 Percent Time”差别不是很大，用哪个都可以。这里是使用最常用的统计方法“90 Percent Time”。登录业务的“90 Percent Time”是5.298秒-3秒（思考时间）=2.298秒，考勤业务的“90 Percent Time”是1.469秒，没有思考时间，那么就是实打实的啦。根据上面的计算，本次测试结果记录如表1所示。
测试项
目标值
实际值
是否通过
登录业务响应时间
<=3秒
2.298秒
Y
考勤业务响应时间
<=3秒
1.469秒
Y
登录业务成功率
100%

考勤业务成功率
100%

登录业务总数
30分钟完成2000

考勤业务总数
30分钟完成2000

CPU使用率
<75%

内存使用率
<70%

表1测试结果对照表一
§ 每秒点击数
　　“Hits per Second（每秒点击数）”反映了客户端每秒钟向服务器端提交的请求数量，如果客户端发出的请求数量越多，与之相对的“Average Throughput (bytes/second)”也应该越大，并且发出的请求越多会对平均事务响应时间造成影响，所以在测试过程中往往将这三者结合起来分析。图1- 11显示的是“Hits per Second”与“Average Throughput(bytes/second)”的复合图，从图中可以看出，两种图形的曲线都正常并且基本一致，说明服务器能及时的接受客户端的请求，并能够返回结果。如果“Hits per Second”正常，而“Average Throughput (bytes/second)”不正常，则表示服务器虽然能够接受服务器的请求，但返回结果较慢，可能是程序处理缓慢。如果“Hits per Second”不正常，则说明客户端存在问题，那种问题一般是网络引起的，或者录制的脚本有问题，未能正确的模拟用户的行为。具体问题具体分析，这里仅给出一些建议。

 图1- 11每秒点击数与每秒吞吐量复合图
对于本次测试来说，“Hits per Second”与“Average Throughput (bytes/second)”都是正常的，而且整体表现还是不错的。
一般情况下，这两种指标用于性能调优，比如给定了几个条件，去检测另外一个条件，用这两个指标衡量，往往起到很好的效果。比如要比较某两种硬件平台的优劣，就可以使用相同的配置方法部署软件系统，然后使用相同的脚本、场景设计、统计方法去分析，最终得出一个较优的配置。
§ 业务成功率
　　“业务成功率”这个指标在很多系统中都提及到，比如电信的、金融的、企业资源管理的等等。举个例子，我们楼下的建行，假如每天的业务类别是这样的：20个开户，5个销户，300个存款，500取款，100个汇款等，那么在做他们的营业系统测试时就需要考虑业务成功率了，一般不得低于98%。具体的业务成功率是什么意思呢？排除那些复杂的业务，比如异步处理的业务（移动的套卡开通就是异步的），业务成功率就是事务成功率，用户一般把一个Aciton当做一笔业务，在LoadRunner场景执行中一笔交易称为一个事务。所以，说业务成功率其实就是事务成功率、通过率的意思。在“Transaction Summary”中我们可以很明确的看到每个事务的执行状态，如图1- 12所示。

 图1- 12事务状态统计图
从图中可以看出，所有的Aciton都是绿色的，即表示为Passed，同时除了vuser_init与vuser_end两个事务，其他的事务通过数为2163，也就表明在30分钟的时间里，共完成了2163次登录考勤业务操作。那么根据这些可以判断本次测试登录业务与考勤业务的成功率是100%，再次更新测试结果记录表如表2所示。
测试项
目标值
实际值
是否通过
登录业务响应时间
<=3秒
2.298秒
Y
考勤业务响应时间
<=3秒
1.469秒
Y
登录业务成功率
100%
100%
Y
考勤业务成功率
100%
100%
Y
登录业务总数
30分钟完成2000
2163
Y
考勤业务总数
30分钟完成2000
2163
Y
CPU使用率
<75%

内存使用率
<70%

表2测试结果对照表二
§ 系统资源
　　　系统资源图显示了在场景执行过程中被监控的机器系统资源使用情况，一般情况下监控机器的CPU、内存、网络、磁盘等各个方面。本次测试监控的是测试服务器的CPU使用率与内存使用率，以及处理器队列长度，具体的数据如图1- 13所示。

 图1- 13测试服务器系统资源监控结果图
从图中可以看出，CPU使用率、可用物理内存、CPU的队列长度三个指标的曲线逗较为平滑，三者的平均值分别为：53.582%、83.456M、8.45，而测试服务器总的物理内存为384M，那么内存使用率为（384-83.456）/384=78.26%，根据本次性能测试要求的：CPU使用率不超过75%，物理内存使用率不超过70%这两点来看，内存的使用率78.26%大于预期的70%，故内存使用率不达标。根据Windwos资源性能指标的解释，一般情况下，如果“Processor Queue Length（处理器队列长度）”一直超过二，则可能表示处理器堵塞，我们这里监控出来的数值是8.45，而且总体上保持平衡，那么由此推断，测试服务器的CPU也可能是个瓶颈。同时在测试过程中，场景执行到23分半钟的时候，报出了错误！未找到引用源。的错误，意思是说被监控的服务器当前无法再进行计数器数据的获取了，所以，本次操作系统资源的监控只得到了场景执行的前23分半钟的数据。这样对本次测试结果有一定的影响。
获得上述数据后，最新的测试结果记录表如表3所示。
测试项
目标值
实际值
是否通过
登录业务响应时间
<=3秒
2.298秒
Y
考勤业务响应时间
<=3秒
1.469秒
Y
登录业务成功率
100%
100%
Y
考勤业务成功率
100%
100%
Y
登录业务总数
30分钟完成2000
2163
Y
考勤业务总数
30分钟完成2000
2163
Y
CPU使用率
<75%
53.582%
Y
内存使用率
<70%
78.26%
N
表3测试结果对照表三
从上表数据来看，本次测试总体上已经达到了预期的性能指标，但从其他的数据，比如CPU的队列长度、内存使用率来看，被测服务器的硬件资源需要提升。
§ 网页细分图
　　　网页细分图可以评估页面内容是否影响事务响应时间。使用网页细分图，可以分析网站上有问题的元素（例如下载很慢的图像或打不开的链接）。
我们这里查看一下网页细分图中的“Page Download Time Breakdown”，点击错误！未找到引用源。左边的“New Graph”，出现图1- 14，展开“Web Page Diagnostics”前的加号，双击“Page Download Time Breakdown”，待出现“Page Download Time Breakdown”监控图后，点击【Close】按钮关闭添加监控图界面。

 图1- 14添加网页细分图
在监控图列表中，我们看到图1- 15，从图中我们看到，在所有的页面中，登录后的用个人面页面“http://192.168.0.52:8080/oa/oa.jsp”的下载时间最长。

图1- 15网页下载时间细分图
图1- 16详细列出了每个页面所消耗的时间分布，图中每一个指标含义见表4所示。该表由LoadRunner使用手册提供。通过这些指标的数据，我们可以轻易的判断是哪个页面、哪个请求导致了响应时间变长，甚至响应失败。

图1- 16 oa.jsp页面下载时间分布图
名称
描述
Client Time
显示因浏览器思考时间或其他与客户端有关的延迟而使客户机上的请求发生延迟时，所经过的平均时间。
Connection Time
显示与包含指定URL的Web服务器建立初始连接所需的时间。连接度量是一个很好的网络问题指示器。此外，它还可表明服务器是否对请求做出响应。
DNS Resolution Time
显示使用最近的DNS服务器将DNS名称解析为IP地址所需的时间。DNS查找度量是指示 DNS解析问题或DNS服务器问题的一个很好的指示器。
Error Time
显示从发出HTTP请求到返回错误消息（仅限于HTTP错误）这期间经过的平均时间。
First Buffer Time
显示从初始HTTP请求（通常为GET）到成功收回来自Web服务器的第一次缓冲时为止所经过的时间。第一次缓冲度量是很好的Web 服务器延迟和网络滞后指示器。
（注意：由于缓冲区大小最大为8K，因此第一次缓冲时间可能也就是完成元素下载所需的时间。）
FTP Autherntication Time
显示验证客户端所用的时间。如果使用 FTP，则服务器在开始处理客户端命令之前，必须验证该客户端。FTP验证度量仅适用于 FTP协议通信
Receive Time
显示从服务器收到最后一个字节并完成下载之前经过的时间。接收度量是很好的网络质量指示器（查看用来计算接收速率的时间 / 大小比率）。
SSL Handshaking Time
显示建立SSL连接（包括客户端hello、服务器hello、客户端公用密钥传输、服务器证书传输和其他部分可选阶段）所用的时间。此时刻后，客户端和服务器之间的所有通信都被加密。SSL握手度量仅适用于HTTPS通信。
表4网页下载时间细分指标说明
对于本次测试，从网页细分图来看，基本上每个页面的加载时间都是预期范围内，oa.jsp页面因为集成了用户的个人工作平台，需要检索很多的数据，并合成了很多图片，所以相应的加载时间较长，这是正确的。
§ Web服务器资源
　　　上述所有的监控图形LoadRunner都可以提供，但对于某些测试监控图来说，LoadRunner就没有提供了，期望其新版支持这些功能，当然想监控Tomcat、Jboss或者其他的Web服务器可以SiteScope工具，这个工具配置较为复杂，根据个人需要吧。我这里监控Tomcat使用的是ManageEngine Applications Manager 8的试用版，测试结束后得出Tomcat的JVM使用率如图1- 17所示。

图1- 17 Tomcat JVM使用率监视图
从图中我们可以明显看出，Tomcat的JVM使用率不断上升，配置Tomcat时共分配了100M左右的物理内存给其，测试初期使用的JVM相对来说较少，我们的测试场景是从15:58:40开始，到16:29:42结束，共历时31分2秒。从图中看到，从16:00到16:30这个时间内，也就是测试场景执行期间，JVM的使用率不断上升，并没有在请求达到均衡状态后也呈现一种平衡状态，所以，从这点可以推断，如果测试场景继续执行，或者加大并发数，最终必将导致Tomcat内存不够用而报出“Out Of Memory”内存溢出的错误。在正常情况下，内存的使用应该与“Hit per Second”、“Average Throughput (bytes/second)”等监控图的图形走势是一致的。
从上述过程可以得出一个结论，出现图1- 17中的问题，可能有两个原因：
1、  Tomcat的内存分配不足；
2、  程序代码有错误，可能导致内存泄露。
解决方法：
1、  为Tomcat分配更多的内存，如果是使用的catalina.sh或Catalina.bat启动的Tomcat，则可在这两个文件中添加“SET CATALINA_OPTS= -Xms300m–Xmx300m”，如果使用的winnt服务方式启动的Tomcat，则可在“运行”中输入“regedit”进入注册表，然后在“HKEY_LOCAL_MACHINE-->SOFTWARE-->Apache Software Foundation-->Process Runner 1.0-->Tomcat5-->Parameters”修改两个属性，一个是JvmMs，另外一个是JvmMx，如图1- 18所示。
2、  检查程序代码，使用一些内存泄露检查工具进行清查。

 图1- 18修改Tocat的JVM数据
§ 数据库服务器资源
数据库服务器资源监控相对来说就复杂的多了，现在常用的数据有Mysql、SQL Server、Oracle、DB2等，LoadRunner提供对后面几种数据库的监控方法，但对Mysql没有提供对应的监控方法。他不提供，咱们就自己找监控工具，我这里使用的是Spotlight，该工具监控数据库的好处是配置连接简单，不仅能监控数据库，还能监控操作系统的资源，监控结果直观明了。错误！未找到引用源。显示了Mysql数据库在场景执行过程中SQL语句的执行情况，从图中可以看到，“Selects（查询）”与“Inserts（插入）”两种语句执行的趋势在场景执行过程中是比较平滑，并且测试中没有错误发现，也就说明在处理相关业务时Mysql的处理是正常的。假如这两种SQL语句任何一个出现波动很大的情况，就可以推出在场景执行过程中存在页面错误，因为这些语句不执行，就表明某些页面未被加载或者某些功能未被使用。在本次测试中，OA系统的“oa.jsp”页面有大量的“Selects（查询）”语句，而考勤操作则是“Inserts（插入）”，所以，只要有一方出问题，必然表示测试过程中存在页面打不开或者考勤不成功的错误。
通过前面的分析，在查看错误！未找到引用源。中的SQL语句执行状态，本次测试在页面访问、功能执行方面是没有问题的。