软件测试Part9.docx
- 文档编号:24150650
- 上传时间:2023-05-24
- 格式:DOCX
- 页数:28
- 大小:448.40KB
软件测试Part9.docx
《软件测试Part9.docx》由会员分享,可在线阅读,更多相关《软件测试Part9.docx(28页珍藏版)》请在冰豆网上搜索。
软件测试Part9
第9章网络层--应用网络分析
在不同的操作系统(MicrosoftWindowsNT,Windows2000,andWindowsXP)开发技术(staticHTML,ASP,WindowsDNA,andnow.NET)和数据访问技术中(RDO,ADOandADO.NET),进行基于web应用的应用网络分析的方法是相同的。
这一过程之所以保持不变是因为(对于它们来说)因特网上传播信息的基本协议是一样的。
随之.NET技术和软件技术作为一种服务的出现,这种方法能用来鉴别相关网络瓶颈现象,改善旧的网络应用以及.NET框架的网络应用的网络行为。
9.1进行一个应用网络分析
许多因特网用户仍使用modems接入网络——这是一种令人痛苦的低速方式,而且在可预见的将来他们仍将使用这种方式。
一个应用网络分析的目标是识别出低速执行的页面或代码,通过改善它们来提供一个更好的终端用户体验。
我们假设你熟悉基本的网络原理,例如开放系统互连模型,但并没有期望你熟悉(如何)进行一个网络分析。
因此在我们对如何进行一个网络分析进行深入探讨前,需要你先熟悉应用网络分析过程所涉及到的相关概念和术语。
假如这一章涉及到的术语有你不熟悉的,请查阅MitchTullock所著的《MicrosoftEncyclopediaofNetworking》(第二版,微软2002年出版)。
你也需要熟悉从用户的角度所会碰到的问题。
例如,你从应用所有者所听到的问题可能包括:
网络延迟如何影响我的全局用户?
什么是一个网络往返以及它如何影响我的终端用户?
当客户访问我的web应用(网站)时,我如何测定每一页面阅览和其它加载内容的数据传送量?
当用户抱怨响应时间过长时,我该如何做呢?
我如何才能识别和避免IISserver或者SQLserver上所产生的延迟?
随着本章的推进,我们将会回答上述的这些问题。
首先将给出上述相关术语的定义,并提供一些例子以帮助阐述这些概念以及它们在实际应用中的作用。
本章也对用于应用网络分析的工具做一个介绍,这些工具包括:
MicrosoftNetworkMonitor和Compuware公司的ApplicationExpert。
1.网络延迟
网络延迟最简单的定义是一个数据包通过一个网络连接所花费的时间。
Web应用层间的延迟越低,响应时间越快。
延迟和带宽是决定一个网络连接的速度的两个因素。
测定客户端和web应用间的网络延迟的一个较容易的方法是使用pathpingutility(这一工具),或者其他工具例如应用专家(ApplicationExpert)所提供的可视化路线追踪功能。
本书配套的CD中有介绍Compuware公司的ApplicationExpert这一工具的幻灯片文件。
注意:
pathpingutility是结合了ping和tracert命令(这两个工具)的功能的一个命令行工具.要使用它时,打开命令提示符(框),键入pathping服务器名,来自pathping命令的输出将显示你正在使用的客户端和你正在ping服务器端间的跳或者网络路线,连同特殊的跳的延迟或往返时间。
每一个局域网和广域网连接都受到网络延迟的限制。
导致延迟增加的因素有:
低质量的网络设备,导致穿越更多跳或网络设备的长距离连接,以及网络拥塞。
例如,一个典型的56kbps的modem连接可能有两百毫秒的延迟,而一个更远距离的相同的连接可能经过更多的网络设备,使其延迟增加到500毫秒。
在表9-1中,当用IE浏览器请求一个46kbps的IBuySpy主页时,我们用网络监视器捕获到一个踪迹来衡量网络延迟的影响。
捕获到的数据被导入应用专家(这一工具)的响应时间预报器中,使得我们能推测出延迟分别为200毫秒和500毫秒,速度为56kbps的两个连接的响应时间。
在这一章后面的“使用Compuware应用专家”这一节中我们将会讨论应用专家(这一工具)的功能与其它方面内容。
表9-1接受和响应时间
连接速度
延迟
响应时间
10mbps
10毫秒
0.5秒
56kbps
200毫秒
6秒
56kbps
500毫秒
8.5秒
对这一具体页面阅览与相关元素来说,增加的300毫秒的延迟的影响是2.5秒而不是300毫秒,原因是延迟影响每一次应用往返。
注意:
解决延迟影响的一种方法是在地理上使你的web应用离用户更近。
这并不能保证客户端与web应用间有一个更好的连接但会显著的降低延迟。
2.网络往返
一个网络往返是一个应用所产生的客户服务器间的请求-响应对。
从一个web浏览器发送到一个web服务器并返回的一个请求-响应对就叫单个往返。
例如,当你在web浏览器中键入一个URL,例如,每一张图片﹑样式表或其它页面元素——它们在对你发出的请求的响应(来自web服务器)中定义——是被当作一个单独的网络往返。
在这个例子中,其它的网络往返跟到服务器的连接有关。
这一章的后面我们将讨论如何使用应用专家快速的获得你的ASP页面所耗费的网络往返的数量。
当与延迟结合在一起,网络往返对应用的响应时间有深刻影响。
设想你的IIS服务器是被放置在美国东海岸与西海岸。
你在加利福尼亚的山脉景点访问你在西海岸的IBuySpy登陆页面将花4秒钟,而访问你在东海岸的IBuySpy登陆页面将花6.5秒钟。
进一步的研究显示到东海岸的连接的网络延迟是500毫秒,而到西海岸的是200毫秒。
因为每一个往返皆受网络延迟的影响,东海岸的响应时间比西海岸大约长2秒。
对于大部分的应用开发者来说,因特网上的网络延迟并不受他们的控制。
这就是为什么发展这样的应用——此种应用使用尽可能少的网络往返,使得即使在高网络延迟的条件也能保持较快的响应时间——是如此的重要。
3.减少网络往返
减少往返(次数)的最有效的方法是减少每一页面对象的数量。
表9-2是两个搜索站点的主页执行性能数据列表,用户应该比较熟悉。
第一个主页拥有的对象少于六个,加载非常快。
第二个主页有大约15个对象,加载慢了许多。
注意这些主页的每一个被加载时产生的网络往返数的不同。
表9-2页内对象响应效率
站点
对象数目
每次请求/响应的对象数
搜索站点1(优化)
6
8
搜索站点2(未优化)
15
19
表9-2中使用的搜索站点1能将对象限制到六个,在大部分56kbps连接中的响应时间少于10秒。
它们通过在主页顶端创造一个包含8张图片的大图片,从而将对象数限制到六个。
考虑到每个被请求的对象将创造一个网络往返,通过将8个小图片合并成一个大的图片已经省掉了7个网络往返。
4.被传送的数据
被传送的数据是指一个客户端的web浏览器与web服务器之间数据移动的数量,它通常用千字节来衡量。
测量被传送的数据的最好的方法是按照页面阅览(包括与之相关的元素)去分解你应用里的情节。
例如,当首次访问IBuySpy主页时它传送46千字节的无缓冲数据,以后则传送24千字节(由于许多对象从你位于Internet临时文件夹的缓冲区中加载)。
根据我们的经验,对于50千字节(或者更少)的页面阅览及其相关元素来说,被传送的数据量将会给出一个可接受的响应时间。
这将使得低速的因特网连接(如56-kbpsmodems)具有较快的响应时间。
这一章使用了几个术语来描述数据大小,例如千位每秒和千字节被传送的数据。
为了更好的描述这些公制的关系。
表9-3给出了位到字节,千位到千字节,千字节到兆字节的转换。
表9-3公制转换
测量值
转换值
8b
1B
1Kb
1024B
1024Kb
1MB
5.减少被传送的数据量
有几种技术可以减少IE与IIS层间传送的数据的量。
这些方法包括:
IIS压缩、去掉不必要的字符和空格、减少页面对象的数量、以及优化图片。
HTTP压缩是IIS和IE的一个固有功能。
对于静态内容,例如HTM文件,HTML文件,CSS文件,JS文件以及未压缩的图片,这一方法是很有用的。
然而,对于动态内容你可能会碰到一些问题,例如页面翻译不正确或者失效。
假如你选择使用IIS压缩,你的IIS服务器将需要一些附加费用及相关资源。
缺省时,HTTP压缩这一功能并未启用,若要启用,打开WWWServiceMasterProperties,选择Services项,如图9-1所示。
一旦HTTP压缩启用,你必须通过编辑元数据库指定要被压缩的文件类型。
以下步骤将教你如何编辑元数据库的设置去压缩静态TXT,JS,CSS,DOC,andXLS文件。
1.启用图9-1所示的HTTP压缩。
2.打开命令提示符并转到脚本管理文件夹
3.执行以下命令:
cscript.exeadsutil.vbssetW3Svc/Filters/Compression/GZIP/HcFileExtensions“txt”“js”“css”“doc”“xls”
图9-1授权IIS压缩
4.执行以下命令:
cscript.exeadsutil.vbssetW3Svc/Filters/Compression/DEFLATE/HcFileExtensions“txt”“js”“css”“doc”“xls”
5.执行以下命令:
iisreset.exe/restart
另一个减少浏览器和IIS层间被传送的数据的量的方法是通过去掉你代码中不必要的字符与空格来将数据包裹的更紧凑。
对有大量数据返回的循环体中,这个方法很有效。
许多的开发者在代码中加入注释,这将为页面增加多余的字符与行,导致被传送数据增加。
注意:
确定你设置了每一张图片的高与宽。
由于IE客户端不必决定(图片的)尺寸,图片将加载更快。
6.延迟处理
当客户端的请求花费了不必要的时间在中间层或者后端层,此种情况就被称做延迟处理。
这可能归咎于要花几秒种处理的低质量的代码,或者导致存储过程和其它SQL命令耗费了宝贵的时间的低质量的SQL调试。
延迟处理直接影响响应时间。
为了使我们所做调整获得最大的效果,我们特地将目光集中在超过1秒的延迟。
然而,可能你的应用要求更为严格或者有较多的类型规模等的调整。
例如,假定你的应用计划提交大量报告给决策支持分析小组,预期的响应时间可能会很长。
这是因为大量的报告可能花费更长时间在你的数据库服务器上进行处理,并且假设你的用户基地是较小的,预算上的限制可能会限制你在优化这个应用上所花费的时间。
然而,假如你的用户基地是非常大的并且有许多订购产品的客户,你将花费更多的时间去优化应用的响应时间以确保不会失去任何一宗买卖,因为客户对慢的响应会很失望的。
7.减少处理上的延迟
加快响应时间的最常用的方法是减少应用处理的延迟。
这是通过加快ASPX,管理程序,以及质量较差的SQL代码的执行来实现的。
本书第十一章有更多的关于数据库层的测试的内容。
正像前面的“延迟处理”中所讨论的,通过使用网络监视器显示数据视图或者应用专家(这一工具)的跳动图表,能够确定你的页面阅览和相关元素是否有延迟处理,以及哪一层导致了延迟处理。
下一步,确定延迟处理发生在应用代码的哪个地方。
有几种方法能够剖析和识别导致处理延迟的代码:
(1)使用.NET应用你能够在你的ASPX页面上进行追踪。
在你用浏览器请求一个ASPX页面后,统计和时间控制将位于页面阅览的底部。
要使得追踪在页面级别进行,需增加ASPX页面指令Trace=“True”,如图9-2所示。
图9-2授权ASPX页面追踪
(2)使用标准的ASP应用,你能够在你的代码里使用计时器去鉴别问题。
在你的脚本中简单的增加时间控制变量,并将值写到文本文件。
这种ASP剖析的方法允许将处理延迟缩减至一个特殊的函数或代码行。
许多时候这些延迟与到一个效率低下的自定义组件的具体呼叫有关,或者跟一个SQL命令有关,此SQL命令的执行会花费几百毫秒甚至几秒。
注意:
一个简单的剖析方法是在你的某一ASP页面中插入response.end,此页面是你怀疑产生处理延迟的页面。
此ASP页面被加载时,执行到加入的命令时脚本将退出,这表明发生了处理延迟。
假如没有延迟发生,在你的ASP页面里将response.end命令进一步向下移并再次加载。
最后你将缩减产生处理延迟的那部分脚本。
(3)识别SQL瓶颈和处理延迟的最简单的方法是使用SQLProfiler。
当你请求一个页面阅览时,简单地创建一个SQLProfiler追踪文件。
SQL命令或者存储过程导致的任何延迟将在数毫秒内在追踪文件的Duration字段显现出来。
一旦你已经识别出执行效率很差的SQL命令或者存储过程,你就能够对它们进行优化。
有关优化SQL命令或者存储过程的更多信息请见第11章。
8.响应时间
进行一个应用网络分析时,响应时间指从客户端初始化请求到请求完成时数据传播的时间。
改善应用的运行和减少每个页面阅览(包括相关元素)的全部响应时间具有相同的含义。
制约响应时间的因素有:
数量很大的网络往返,小的带宽,使用高延迟连接的终端用户,大量被传输的数据,以及在IIS代码、管理程序或者SQL代码上的处理延迟。
这一章的后面我们会介绍如何使用应用专家快速地计算出响应时间。
响应时间的可接受性依赖许多的因素,包括应用的类型,应用里每一个被请求页面的功能,因特网连接的带宽和延迟。
例如,一个与后端数据库没有交互的被请求的页面(即是一个静态页面阅览),或者一个有少量的内容比被请求的页面(这些页面具有大量内容或者需频繁地从数据库获取数据或更新数据库—即是动态页面阅览)需要更快加载的页面将会更慢。
表9-4显示进行一个网络分析时我们认为可接受的响应时间。
低响应时间表示应用有很少的静态页面阅览或者与数据库间的交互很少。
高响应时间表示应用有大量的页面阅览或者与数据库间的交互很多。
表9-4接受及响应时间
连接速度
最低响应时间
最高响应时间
低速连接(modems)
10秒
15秒
高速连接(DSL,cable,orhigher)
5秒
10秒
9.用户情节
用户情节是页面阅览(包括其相关元素)的一个集合,能够实现商业或功能性的处理。
例如,搜索IBuySpy站点(第7章讨论到的)就是现实中一个用户情节的好例子。
搜索情节包括几个步骤,例如加载主页,输入搜索行,点击GO按钮,从多个搜索结果中选择一个并浏览这一结果的具体页面。
这一情节包括两个页面阅览。
推荐进行分析时将情节分解成不同的用户动作,例如点击按钮或链接去提交一个送一个请求到web服务器的表单,而不是捕捉整个用户情节。
将用户情节分解为多个独立的页面阅览或者用户动作的原因是它有助于你识别产生低响应时间的准确原因。
10.识别用户情节
IBuySpy.NET的样本应用使用了典型的电子商务功能。
下面的例子我们已经将用户情节分解成三个独立的页面阅览(包括它们的相关元素):
♦步骤1用户浏览主页,加载Home.aspx或Default.aspx页面。
♦步骤2用户在搜索区键入搜索行,点击GO,加载SearchResults.aspx页面。
♦步骤3用户选择或者点击搜索所返回的一个结果,加载ProductDetails.aspx页面。
假如应用已经部署好,你能通过两个方法识别情节:
或者将注意力集中在用户所抱怨的那些页面,或者对应用进行研究并识别出加载或执行较慢的页面。
第二种方法要求每一个应用页面都被命中。
对某些应用来说这是不切实际的。
然而,如果你从未在某一应用中进行应用网络分析,这是一个建立响应时间基线的好方法。
假如你正工作在一个新的应用上,这一方法将更有用,因为在执行前你能识别并修正执行效率较差的页面。
本节已经对术语进行了定义,下一节将对用来进行应用网络分析的工具进行介绍。
9.2微软网络监视器
网络监视器是一个基于网络嗅探器的软件,网络嗅探器能够用来分析与检修一个网络上结点与设备间传送的数据。
这个工具是为几类信息技术(IT)学科设计的。
网络管理员经常使用网络监视器去捕捉和监控整个网络应用。
网络工程师可以使用网络监视器去发现并修正网络设计和结构上潜在的瓶颈。
开发者可以使用网络监视器去检修代码。
在一个应用网络中,网络监视器主要是被用来识别被传送的数据的数量,以及计算网络往返的数量,这些网络往返是被用在每一页面阅览(包括相关元数据以及用户操作产生的对Web服务器的性能影响)的响应时间的计算中。
可用于Windows2000的网络监视器有两个版本:
♦NetworkMonitor2Lite可用于Windows2000AdvancedServerandDataCenter。
这一版本只能够探测从本地网络接口卡(NIC)到其它正与它对话的节点间的网络流量。
♦NetworkMonitor2Full可用于MicrosoftSystemManagementServer(SMS)2。
这一版本允许捕捉网络上所有来自具有已初始化的网络监视器驱动的唯一地点的流量。
网络监视器捕捉网络数据的帧,这有助于你发现并分析网络问题。
网络监视器有助于通过捕捉应用层、网络往返、网络时间以及处理延迟间被传送的数据来追捕网络应用中的问题。
1.MAC地址与IP地址设置
在对要进行的网络捕捉做准备时,你需要验证所有结点的MAC地址和IP地址。
验证时,打开Windows的命令窗口,从每一个后端服务器与客户端键入ipconfig/all。
此命令的输出将显示IP地址信息,DNS服务器,DNS后缀,物理或者MAC地址,以及其它重要信息。
这将使你更容易去设置“捕获过滤器”(capturefilter)并隔离应用所创造的网络传输。
你能够使用一条主文件词条去促使节点与你正在追捕的正确的NIC和IP地址相连。
此主文件经常位于C:
\windows\system32\drivers\etc文件夹且没有文件扩展名。
若要改变或增加文件词条,你可以使用微软记事本打开此主文件,依照文件提供的例子去做就行。
注意:
假如你使用的客户端或者服务器有不止一个网络借口卡(NIC),确定你并未启用其它网络接口卡或者所有的传输与同一个网络接口卡相连。
2.设置网络监视器
从你的用户情节捕捉数据之前,需要正确设置网络监视器。
这里面有三个关键的设置:
捕获过滤器,捕获缓冲器,以及网络,你可通过调节这些来确保你创建了一个正确的、完全的捕捉。
捕获过滤器允许你将网络捕获缩减到应用所使用的层或节点。
这时代独立的数据传输更为简单,并且减少对不必要的网络阻塞进行跟踪。
图9-3显示一个典型的捕获过滤器。
图9-3网络监视器捕获过虑信息
捕获缓冲器是一个重要的调节装置。
缺省时缓冲器容量被设为1MB。
假如一个页面传输的数据数量很大,有可能超过一亿兆的界限。
通常我们将捕获缓冲器容量调节到10MB以适应捕获到任何数量的数据。
图9-4显示网络监视器的捕获缓冲器对话框。
图9-4网络监视器缓存设置
确定在正确的网络上进行捕获是非常重要的。
当客户端与服务器有不止一个网络接口卡时,你需要确认哪一个网络是你想要去捕获的。
若想要查证你是否在正确的网络上进行捕获,启动网络监视器追踪,ping正在测试的web应用的IP地址或URL。
接着,停止网络监视器追踪并核对是否收集到ping传输。
假如没有,调整网络监视器去捕捉另一个不同的网络,如此重复直到你在正确的网络上进行捕获为止。
图9-5显示在哪里设置网络监视器使其在正确的网络上进行捕获。
图9-5网络监视器中选择一个网络
3.环境设置
应用网络分析中使用的硬件包括测试客户端,所有对应用进行补充的后端服务器(IISServer,SQLServer,ApplicationServer)和任何其它被使用的网络设备(switch,hub,router,bridge,loadbalancer等等)。
要求高实用性与可测量性的应用常使用多个相同的web服务器去加载平衡流量。
假如你的应用采用平衡加载,你必须确保在一个应用网络分析期间只有唯一的一个节点(前端web服务器)被启用。
这样做的目的是确保你在正确的web服务器上捕获流量。
可以有很多种方法来使用网络监视器去捕获你的应用所创造的流量。
下面是一些:
(1)大部分的应用由多个服务器组成,这些服务器通过一个网络交换机相连,因为每一个端口有专属带宽并且性能更好。
网络交换机隔离来自每一个端口的流量(traffic),这使得网络监视器不可能看到来自每一应用层的流量。
然而,通过端口扩充或者端口映象,你能够设定大部分的网络供应商交换器去拷贝或者映射你分配的每一个端口的流量。
就设定网络扩充的说明书向网络软件供应商请教。
通过使用网络监视器的SMS版本,并将网络监视器捕获客户端(networkmonitorcaptureclient)插入这一端口,你能够看到每一应用层的所有流量。
图9-6描述了这一模型。
(2)假如你没权更改交换器的配置,或者端口扩充并非你的网络交换器中可用的选项,另一种简单的方法是将组成应用的所有后端服务器插到一个网络集线器。
网络集线器在所有的端口间共享带宽;用做网络监视器客户端的机器能够捕捉来自所有层的流量。
图9-7显示了这一模型。
图9-6使用交换机端口跨网段
图9-7使用独立的集线器
(3)完整版本的网络监视器允许你初始化应用的每一层上的远程网络监视器驱动,此应用是用来捕捉远程流量的。
假如你选择这种方法,初始化每一应用层上的远程网络驱动。
从开始菜单选择控制面板,接着选择添加或删除程序。
在添加或删除程序对话框中,点击添加新程序,转到Windows组件,选择管理和监视工具,选择网络监视工具并点击OK。
这一方法允许集中从所有远程代理到一个客户端的捕捉。
这一方法的好处是比进行分离的捕捉更快,这些捕捉获取所有来自Web应用层的数据。
然而它的缺点是需要花更长的时间去设置,因为你必须初始化每一服务器上附加的组件。
图9-8显示了这一模型。
图9-8使用网络监视器远程驱动
(4)捕捉流量最容易的方法是在作为捕获客户端的IIS层上使用NetworkMonitor2Lite这一版本。
IIS层通常位于IE客户端和SQL层之间。
因此,当网络监视器客户端位于你的IIS服务器时,你能够看到所有到达它和来自它的流量。
图9-9显示了这一模型。
4.捕捉网络流量
现在网络监视器已被初始化并被正确设置,环境也已建立好,你准备开始捕获网络流量。
我们有几个有助于聚集捕获的小窍门:
(1)因为我们常将用户情节分解成单独用户行为。
我们建议为每一页面阅览建立一个单独的捕获。
使用此方法很容易确定每一页面阅览(包括相关元素)所传输的数据的量。
(2)进行几次网络监视器捕获去检验它们的完整性。
在大约90%已进行的网络分析里中,网络捕获是正确的,然而,除非你进行了几次捕捉来检验,你并不能确定(是否正确)。
我们运行每一个捕捉至少三次或者四次直到得到一致的可接受的结果。
对于(网络)往返和被传输的数据,不要求每一次取样都相同但应相似。
图9-9网络监视器客户端位于IIS服务器
(3)网络监视器允许你保存捕获文件(CAP,CaptureFile),这些文件能够被用于进一步的分析或者引入第三方工具,例如应用专家。
(4)保存你的网络监视过滤器和地址数据库以免你需要重新捕获。
保存过滤器将节省你重新配置网络监视器的时间。
图9-10和9-11显示【SaveCaptureFilter】对话框和【SaveAddress】对话框。
(5)进行捕获的目的是去记录节点间唯一相关的传输数据。
为了达到这一目的,启动网络监视器捕捉,通过在浏览器的地址栏里键入URL来请求一个页面
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 Part9
![提示](https://static.bdocx.com/images/bang_tan.gif)