??xml version="1.0" encoding="utf-8" standalone="yes"?>
]]>
]]>
CPU 限制 |
vmstat?user+%sys 过80% |
盘I(y)/O限制 |
vmstat?iowait过40% |
应用盘限制 |
iostat当tm_act过70% |
虚存I间?o:p> |
lsps-a当分늩间的zd率超q?0% |
换页限制 |
Iostat vmstat |
虚存逻辑?o:p> |
%tm_act过I/O(iostat)?0%Q激zȝ虚存率超qCPU数量(vmstat)?0?o:p> |
pȝp| |
Vmstat sar交换增大、CPU{待q运行队?o:p> |
【相对的性能指标?o:p>
CPU |
GoodQ?0% |
|
BadQ?5% |
|
Very BadQ?0%+ |
Memory |
GoodQno page change |
|
BadQ每个CPU每秒10个页交换 |
|
Very BadQmore page change |
Disk |
GoodQ?lt;30% |
|
BadQ?0% |
|
Very BadQ?0%+ |
Network |
好:(x)带宽于30% |
q行队列 |
好:(x)<2*CPU数量 |
1
?/span>
熟?zhn)需求背景及(qing)商业目标Q?/span>
a)
了解清楚目发v的原因,是ؓ(f)了解决用L(fng)什么问题?/span>
b)
当前的解x案是不是最优的Qؓ(f)什么会(x)q样做?/span>
2
?/span>
业务模型法:(x)
a)
考虑本项目与外部pȝ的交互,划分pȝ边界Q除了本目的需求中要求做的事情Q其他的都可以是外部pȝQ本pȝ和外部系l之间的交互是pȝ的边界)Q。可以参考系l分析说明书?/span>
b)
定试范围和关注点。系l的边界是测试的重点Q特别需要关注边界交互时的数据交互?/span>
3
?/span>
业务场景法:(x)
a)
考虑用例的调用者;考虑每一个用例提供的服务是供哪些外部用例或者系l调用,扑և所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流E。(一般和外部有交互的用例出错的概率比较大Q需要重点关注。具体被哪些外部调用Q每个品线都需要自己整理添加。)
b)
考虑pȝ内部各个用例之间的交互(有可?/span>
PD
划分用例的粒度不同,我们暂时考虑用户一ơ提交ƈ且系l的状态及(qing)数据发生变化的功能是一个用例)QŞ成内部业务流E图。需要分析每个用例之间的U束关系、执行条Ӟl织出各U业务流E图?/span>
4
?/span>
功能分解法(Ҏ(gu)一?/span>
UC
Q:(x)
a)
用户与系l的每一ơ交互,都可以认为是一个小功能?/span>
比较内容
LoadRunner
Robot+TestManager
脚本录制
Robot
是按照不同协议来录制VU脚本的,不同的协议录制出的脚本不?span lang="EN-US">
可以录制不通过本机之间机器之间的通讯内容
录制时的人机交互界面支持不够?span lang="EN-US">
Robot
?span lang="EN-US">VU脚本?span lang="EN-US">GUI脚本不同
函数支持丰富处理较灵z?span lang="EN-US">
易读性差调试隑ֺ?span lang="EN-US">
为用户内|了一些场景可以较为方便的使用
用户可以灉|的定制测试场景,但是有些需要通过修改试脚本来进?span lang="EN-US">
囑Ş化处理界面操作简?span lang="EN-US">
用户、场景?span lang="EN-US">Suit定义层次清楚
定制灉|性差一?span lang="EN-US">
一般测试h员较难上手,需要熟(zhn)时间长
监控讄
可以监控多种资源情况
?span lang="EN-US">
q行时获得资源数据与脚本q行情况相匹?span lang="EN-US">
?span lang="EN-US">
采集数据含义不够明确和通用
?span lang="EN-US">
q行控制
可以监控和设定不同虚拟用L(fng)q行状?span lang="EN-US">
针对脚本内容有全面的q行监控Q图形化的表CZ同的q行状?span lang="EN-US">
监控资源和虚拟用户同时进?span lang="EN-US">
l节的看到脚本运行情况,q行效率较高
q行脚本效率较差
无法与资源情늻一
l果获得
汇M息采用单独工P可以较ؓ(f)详细Ҏ(gu)据结果进行统计分析,可以自动生成报告
对脚本的各种情况监控支持较ؓ(f)全面
数据l果详细图表丰富Q可以灵zȝ成报表和报告
l果Ҏ(gu)一步骤执行旉做记录方便分析,自动记录每一ơ测试结?span lang="EN-US">
l果不易保存Q处理速度较慢
不能自动生成可读的测试报告,需要再加工
操作?span lang="EN-US">
Ҏ(gu)上手Q适合于非技术h员操?span lang="EN-US">
上手困难Q需要有一定技术基的h使用
界面友好?span lang="EN-US">
界面友好性较?span lang="EN-US">
界面友好性较强,但是Ҏ(gu)down掉,q且很难重启
技术支持?span lang="EN-US">
Mercury
技术h员较?yu),支持有困?span lang="EN-US">
Rational
技术h员较多,IBMq有其他服务提供商给予技术支?span lang="EN-US">
其他
LR
试范围更广的专业工P盗版License也在|上很容易找
Rational
的品重点不?span lang="EN-US">Robot上,况且以后?x)修改?span lang="EN-US">Eclipseq_上,License也不Ҏ(gu)l?span lang="EN-US">
明确试的目标,一般适合用到的范围是Q制定被试的对象是在满x个条件的区间内的所有数据?/span>
案例设计Ҏ(gu)Q从其中区间数据D中选择L一个或者两个数据,只要q个数据满了,那么其他的数据就是满的?/span>
范例
1
Q在登陆某系l需要验证用户名Q要求是长度是最是
6
位,最长是
14
位,名字中可以包含数字,但是不能以数字开_(d)可以包含各种W号Q不能包含中文?/span>
1
、随意字母组合成一?/span>
12
位的姓名Q测试是否可以通过验证?/span>
2
、随意生成一个长?/span>
12
位的姓名Q测试是否可以通过验证
3
、测试以L一个数字打?/span>
12
位的姓名Q测试是否可以通过验证
4
、测试姓名长度ؓ(f)
12
位且包含中文情况Q测试是否可以通过验证
5
、测试长度不满条g情况下,是否通过验证
6
、如果长度不满Q是以数字开头的Q提CZ息验?/span>
7
、如果长度不满Q姓名中包含中文的,提示信息验证…?/span>
注:(x)q个可能比较单,但是说明一个问题:(x)Z么随意生成一?/span>
12
位姓名的
,
其实你选择
8
位姓名长度或?/span>
10
位姓名长度是一L(fng)Q所以这U情况下考虑采用{效Ҏ(gu)比较合适?/span>
范例
2
Q要求选择
1~12
之间q行调整Q手机的背光׃(x)随着数值的变化而变化。M的是数D大越暗?/span>
试案例设计Q清晰记?/span>
1
的情况,然后随意调整一个数|因ؓ(f)要求是变化了Q至于变化成什么样子,变暗C么程度才正确Q没有明的指标数|所以只需要记住(f)街点
1
的情况,然后随意调整一个数据,然后和当前调整后的数据进行比较?/span>
注:(x)没有明确的说明,只是含糊的结果,但是M的结果是在变化,那么q个时候比较适合使用{效法?/span>
因果分析?/span>
需要有一定的E序基础Q了解程序的架构Q就是当问题发生以后Q能够有效的补充相关的案例或者筛选相关的案例。因果分析的核心是从自己的理解去分析问题所在的真正原因?/span>
范例
1
Q删除磁盘上某个文gp|Q分析原因:(x)如果是管理员权限Q那么可以随意删除,无论q个文g的属性是只读的还是存的Q那么如果不能删除磁盘文Ӟ除非是坏道上的文件。分析完成以后,使得试案例设计有针Ҏ(gu),而不是盲目的所有的文g格式都去试一ơ?/span>
范例
2
Q假设我们用
Excel
作一个计,l果和我们用计算器计的l果不同。分析原因:(x)
Excel
的计函数单独运没有错误,然后插入一行,l果错误了,说明插入行时D计算错误Q那么插入一行怎么?x)引起函数计错误呢Q原因是׃插入行后Q导致传l计函数的区域没有更新Q所以造成计算l果错误Q那么这?/span>
Bug
很明确了?/span>
范例
3
Q假设我们^常在做讲座的时候发现在某台机器上就?x)死机。这是一U现象。分析原因:(x)Z么在q台机器上死Q在其他机器上不歅R原因有两个Q第一个先扄l原因,是否是我们的产品在当前这个系l下?/span>
Bug,
l过验证没有Q那问题出在那里Q其实演CZ品需要的是硬件的支持Q那是昑֍Q如果显卡内存不够大Q可能导致某些演C文件死?/span>
注:(x)因果分析需要有q泛的知识面Q得我们在分析的时候能够拓宽面U,模糊的定位问题?/span>
范例
4
Q用L(fng)我发送一个文Ӟ打印的时候发现是q。后来D无奈Q就让用户将q个文g传真l我。这是现象。分析原因:(x)Z么打印出Cؕ码?问题基本定位Q系l字库不够,pȝ下打印驱动问题,打印虚拟内存问题Q操作系l问题,软g本n问题Q最后问题经q验证,最l归lؓ(f)在此操作pȝ下,打印驱动E序有问题,使得文g不能正常打印?/span>
注:(x)问题需要先框定范围Q不要ؕ了套路?/span>
逻辑分析?/span>
在逻辑分析斚wQ也需要有一定的E序理解能力。从E序逻辑和日常常识去判断问题。逻辑分析法其实就一堆假讄|列Q推论出pdl果的假设,然后假讑֏推翻Q问题就可以暴露出来。无论U方法都是通过表现d析问题的实质的?/span>
范例
1:
我们在做
MP3
播放器快q和快退试中,要考虑的同步问题,是我们液晶昄屏上出现的歌词进度,旉q度和我们x听到的进度不同。我们分析一下,Z么出C同步现象Qؓ(f)什么其他的能同步,某一个或者某几个不能同步。首先我们了解同步的法Q快q和快退是按照当前歌曲的数据来计算应该到那里,它是以当前歌曲的数据ؓ(f)pLQ然后进行的一些调_(d)那么出现不同步的原因是由于系C同造成的,所以考虑到同步问题,我们需要找不同格式不同数据的歌曲Q这样问题容易暴ԌҎ(gu)清楚的定位问题的真正原因
边界数值分析法
一、JTEST
1、简介:(x)
jtest是parasoft公司推出的一N对java语言的自动化白盒试工具,它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。Jtest先分析每个javac,然后自动生成junit试用例q执行用例,从而实C码的最大覆盖,q将代码q行时未处理的异常暴露出来;另外Q它q可以检查以DbCQDesign by ContractQ规范开发的代码的正性。用戯可以通过扩展试用例的自动生成器来添加更多的junit用例。Jtestq能按照现有的超q?50个编码标准来(g)查ƈ自动U正大多数常见的~码规则上的偏差Q用户可自定义这些标准,通过单的几个点击Q就能预防类g未处理异常、函数错误、内存泄漏、性能问题、安全隐(zhn)这L(fng)代码问题?/p>
2、优势:(x)
1Q预防代码错误成ؓ(f)可能Q从而大大节U成本,提高软g质量和开发效?/p>
2Q单元试——包括白盒、黑盒以?qing)回归测试成为可?/p>
3Q代码规范(g)查和自动U正成ؓ(f)可能
4Q鼓励开发团队横向协作来预防代码错误
3、特征:(x)
1Q通过单的点击Q自动实C码基本错误的预防Q这包括单元试和代码规范的(g)?/p>
2Q生成ƈ执行junit单元试用例Q对代码q行x(g)?/p>
3Q提供了q行黑盒试、模型测试和pȝ试的快速途径
4Q确认ƈL代码中不可捕L(fng)异常、函数错误、内存泄漏、性能问题、安全弱点的问题
5Q监视测试的覆盖范围
6Q自动执行回归测?/p>
7Q支持DbC~码规范
8Q检验超q?50个来自java专家的开发规?/p>
9Q自动纠正违反超q?60个编码规范的错误
10Q允许用户通过囑Ş方式或自动创建方式来自定义编码规?/p>
11Q支持大型团队开发中试讄和测试文件的׃n
12Q实现和IBM Websphere Studio /Eclipse IDE 的安全集?/p>
4、h(hun)|(x)昂贵
二、JMETER
1、简介:(x)
JMeter是Apachel织的开放源代码目Q它是功能和性能试的工P100%的用java实现。用JMeterq行性能试
2、特征:(x)
JMeter可以用于试静态或者动态资源的性能Q文件、Servlets、Perl脚本、java对象、数据库和查询、ftp服务器或者其他的资源Q。JMeter用于模拟在服务器、网l或者其他对象上附加高负载以试他们提供服务的受压能力,或者分析他们提供的服务在不同负载条件下的L能情况。你可以用JMeter提供的图形化界面分析性能指标或者在高负载情况下试服务?脚本/对象的行为?/p>
3、h(hun)|(x)未知
三、JUNIT
1、简介:(x)
JUnit是一个开源的java试框架Q它是Xuint试体系架构的一U实现。在JUnit单元试框架的设计时Q设定了三个M目标Q第一个是化测试的~写Q这U简化包括测试框架的学习(fn)和实际测试单元的~写Q第二个是ɋ试单元保持持久性;W三个则是可以利用既有的试来编写相关的试?/p>
2、优势:(x)
2.1)junit是完全Free的?/p>
2.2)使用方便。在你提升程序代码的品质时JUnit试仍允怽更快速的撰写E序 那听hg不是很直觉,但那是事实。当你用JUnit撰写试Q你花更少的时间除虫,同时对你E序代码的改变更 俱有信心。这个信心让你更U极重整E序代码q增加新的功能。没有测试,对于重整?qing)增加新功能你?x)变得没有信心Q因Z不知道有甚么东西?x)破坏出的l果。采用一个综合的试pdQ你可以在改变程序代码之后快速的执行多个试q对于你的变动ƈ未破坏Q何东西感到有信心。在执行试时如果发现臭虫,原始码仍然清楚的在你脑中Q因此很Ҏ(gu)扑ֈ臭虫。在JUnit中撰写的试帮助你以一U极 ?extreme)的步伐撰写程序及(qing)快速的扑և~点?/p>
2.3)JUnit非常单撰写测试应该很?-q是重点Q如果撰写测试太复杂或太耗时_(d)便无法要求程序设计师撰写试。用JUnit你可以快速的撰写试q检你的程序代码ƈ?步随着E序代码的成长增加测试。只要你写了一些测试,你想要快速ƈ频繁的执行测试而不至于中断建立设计?qing)开发程序。用JUnit执行试像~译你的E序代码那么Ҏ(gu)。事实上Q你应该执行~译时也执行试。编译是(g)程序代码的语法而测试是(g)查程序代码的完整?integrity)?/p>
2.4)JUnit试(g)验其l果q提供立即的回馈?如果你是以h工比Ҏ(gu)试的期望与实际结果那么测试是很不好玩的,而且让你的速度慢下来。JUnit试可以自动执行q且(g)查他们自ql果。当你执行测试,你获得简单且立即的回馈; 比如试是通过或失败。而不再需要h工检查测试结果的报告?/p>
2.5)JUnit试可以合成一个测试系列的层架构?JUnit可以把测试组l成试pdQ这个测试系列可以包含其它的试或测试系列。JUnit试的合成行为允怽l合多个试q自动的回归(regression)从头到尾试整个试pd。你也可以执行测试系列层U架构中M一层的试?/p>
2.6)撰写JUnit试所费不多?使用Junit试框架Q你可以很便宜的撰写试qn受由试框架所提供的信心。撰写一个测试就像写一个方法一L(fng)单;试是检验要试的程序代码ƈ定义期望的结果。这个测试框架提供自动执行测试的背景Q这个背景ƈ成ؓ(f)其它试集合的一部䆾。在试量的投资将持箋让你从时间及(qing)品质中获得回收?/p>
2.7)JUnit试提升软g的稳定性?你写的测试愈;你的E序代码变的愈不E_。测试得Y件稳定ƈ逐步累积信心Q因ZQ何变动不?x)造成涟漪效应而O?qing)整个Y件。测试可以Ş成Y件的完整l构的胶l?/p>
2.8)JUnit试是开发者测试?JUnit试是高度区域?localized)试Q用以改善开发者的生力及(qing)E序代码品质。不像功能测?function test)视系lؓ(f)一个黑׃认软g整体的工作性ؓ(f)主,单元试是由内而外试pȝ基础的徏构区块。开发者撰写ƈ拥有JUnit试。每当一个开发反?iteration)完成Q这个测试便包裹成ؓ(f)交付软g的一部䆾提供一U沟通的方式Q「这是我交付的Y件ƈ且是通过试
2.9)JUnit试是以Java写成的?使用Java试Java软g形成一个介于测试及(qing)E序代码间的无缝(seamless)边界。在试的控制下试变成整个软g的扩充同时程序代码可以被重整。Java~译器的单元试静态语法检查可已帮助测试程序ƈ且确认遵守Y件接口的U定?/p>
一D|试的E序代码无法单独的执行,它需要是执行环境的一部䆾。同Ӟ它需要自动执行的单元试--譬如在系l中周期性的执行所有的试以证明没有Q何东西被破坏。由于单元测试需要符合特定的准则Q一个成功的试不应该是人工(g)查的Q那可要到天荒地老了啊)Q一个未通过试的失败应可以产出文g以供诊断修改。而Junit可以提供l我们这些便?。这h有测试开发者所需撰写的只是测试码本n了。跟optimizeit、Jtest那些昂贵而又ȝ的tool比较hQ其利昭然可见!
3、h(hun)|(x)免费
四、WEBLODE
1、简介:(x)
webload是RadView公司推出的一个性能试和分析工?它让web应用E序开发者自动执行压力测?webload通过模拟真实用户的操?生成压力负蝲来测试web的性能?/p>
2、特征:(x)
1)用户创徏的是Zjavascript的测试脚?UCؓ(f)议程agenda,用它来模拟客L(fng)行ؓ(f),通过执行该脚本来衡量web应用E序在真实环境下的性能
2)如有需要可以在做负载测试的同时Q用服务器监控工具Ҏ(gu)务器端的内容q行记录那样使负载测试更加全面?/p>
3、h(hun)|(x)
五、WINRUNNER
1、简?/p>
WinRunner:强大的企业自动化测试工?
Mercury Interactive公司的WinRunner是一U企业的功能测试工P用于(g)应用程序是否能够达到预期的功能?qing)正常运行。通过自动录制、检和回放用户的应用操作,W(xu)inRunner能够有效地帮助测试h员对复杂的企业应用的不同发布版q行试Q提高测试h员的工作效率和质量,保跨^台的、复杂的企业U应用无故障发布?qing)长期稳定运行?
企业U应用可能包括Web应用pȝQERPpȝQCRMpȝ{等。这些系l在发布之前Q升U之后都要经q测试,保所有功能都能正常运行,没有M错误。如何有效地试不断升更新且不同环境的应用pȝQ是每个公司都会(x)面(f)的问题?
如果旉或资源有限,q个问题?x)更加棘手。h工测试的工作量太大,q要额外的时间来培训新的试人员{等。ؓ(f)了确保那些复杂的企业U应用在不同环境下都能正常可靠地q行Q你需要一个能单操作的试工具来自动完成应用程序的功能性测试?/p>
2、特征:(x)
1)L创徏试
用WinRuuner创徏一个测试,只需点击鼠标和键盘,完成一个标准的业务操作程QW(xu)inRunner自动记录你的操作q生成所需的脚本代码。这P即计算机技术知识有限的业务用户L创徏完整的测试。你q可以直接修Ҏ(gu)试脚本以满各种复杂试的需求。WinRunner提供q两U测试创建方式,满试团队中业务用户和专业技术h员的不同需求?
2)插入(g)查点
在记录一个测试的q程中,可以插入(g)查点Q检查在某个时刻/状态下Q应用程序是否运行正常。在插入(g)查点后,W(xu)inRunner?x)收集一套数据指标,在测试运行时对其一一验证。WinRunner提供几种不同cd的检查点Q包括文本的、GUI、位囑֒数据库。例如,用一个位图检查点Q你可以(g)查公司的图标是否出现于指定位|?
3)(g)验数?/p>
除了创徏q运行测试,W(xu)inRunnerq能验证数据库的数|从而确保业务交易的准确性。例如,在创建测试时Q可以设定哪些数据库表和记录需要检;在测试运行时Q测试程序就?x)自动核?gu)据库内的实际数值和预期的数倹{WinRunner自动昄(g)结果,在有更新/删除/插入的记录上H出昄以引h意?
4)增强试
Zd全面地测试一个应用程序,需要用不同类型的数据来测试。WinRunner的数据驱动向? Data Driver Wizard)可以让你单地点击几下鼠标Q就可以把一个业务流E测试{化ؓ(f)数据驱动试Q从而反映多个用户各自独特且真实的行为?/p>
以一个订单输入的程ZQ你可能希望把订单号或客户名UC为可变栏Q用多套数据q行试。用Data Driver WizardQ你可以选择订单h客户名称用数据表格文件中的哪个栏目的数据替换。你可以把订单号或客户名U输入数据表格文Ӟ或从其它表格和数据库中导入。数据驱动测试不仅节省了旉和资源,又提高了应用的测试覆盖率?
WinRunnerq可以通过Function Generator增加试的功能。用Function Generator可以从目录列表中选择一个功能增加到你的试中以提高?gu)试能力。例如,你可以选择”calendar”,然后从日历功能的下属目录中选择Q如Calendar_select_date(),然后你可以直观地输入参数Q把q个功能插入C的测试中?/p>
针对相当数量的企业应用里非标准对象,W(xu)inRunner提供了Virtual Object Wizard来识别以前未知的对象。用Virtual Object WizardQ你可以选择未知对象的类型,讑֮标识和命名。在录制使用该对象的试ӞW(xu)inRunner?x)自动对应它的名字,从而提高测试脚本的可读性和试质量?
5)q行试
创徏好测试脚本,q插入检查点和必要的d功能后,你就可以开始运行测试。运行测试时QW(xu)inRunner?x)自动操作应用程序,p一个真实的用户Ҏ(gu)业务程执行着每一步的操作。测试运行过E中Q如有网l消息窗口出现或其它意外事g出现QW(xu)inRunner也会(x)Ҏ(gu)预先的设定排除这些干扰?/p>
6)分析l果
试q行l束后,你需要分析测试结果。WinRunner通过交互式的报告工具来提供详的、易ȝ报告。报告中?x)列出测试中发现的错误内宏V位|、检查点和其它重要事Ӟ帮助你对试l果q行分析。这些测试结果还可以通过Mercury Interactive的测试管理工具TestDirector来查阅?/p>
7)l护试
随着旉的推U,开发h员会(x)对应用程序做q一步的修改Qƈ需要增加另外的试。用WinRunnerQ你不必对程序的每一ơ改动都重新创徏你的试。WinRunner可以创徏在整个应用程序生命周期内都可以重复用的试Q从而大大地节省旉和资源,充分利用你的试投资?/p>
每次记录试ӞW(xu)inRunner?x)自动创Z个GUI Map文g以保存应用对象。这些对象分层次l织Q既可以总览所有的对象Q也可以查询某个对象的详l信息。一般而言Q对应用E序的Q何改动都?x)?jing)响到成百上千个测试。通过修改一个GUI Map文g而非无数个测试,W(xu)inRunner可以方便地实现测试重用?/p>
8)帮助你的应用E序为无U应用作准备
随着无线讑֤U类和数量的增加Q你的应用程序测试计划需要同时满传l的Z览器的用户和无U浏览设备,如移动电(sh)话、传呼机和个人数字助?PDA)?/p>
无线应用协议是一U公开的、全球性的|络协议Q用来支持标准数据格式化和无U设备信L(fng)传输?br />使用WinRunnerQ测试h员可以利用微型浏览模拟器来记录业务流E操作,然后回放和检查这些业务流E功能的正确性?/p>
六、LOADRUNNER
1、简介:(x)
LoadRunner 是一U预系l行为和性能的负载测试工兗通过以模拟上千万用户实施q发负蝲?qing)实时性能监测的方式来认和查N题,LoadRunner 能够Ҏ(gu)个企业架构进行测试。通过使用LoadRunner Q企业能最大限度地~短试旉Q优化性能和加速应用系l的发布周期?/p>
目前企业的网l应用环境都必须支持大量用户Q网l体pL构中含各cd用环境且׃同供应商提供软g和硬件品。难以预知的用户负蝲和愈来愈复杂的应用环境公司时时担心?x)发生用户响应速度q慢Q系l崩溃等问题。这些都不可避免地导致公司收益的损失。Mercury Interactive ?LoadRunner 能让企业保护自己的收入来源,无需购置额外g而最大限度地利用现有的IT 资源Qƈ保l端用户在应用系l的各个环节中对其测试应用的质量Q可靠性和可扩展性都有良好的评h(hun)?/p>
LoadRunner 是一U适用于各U体pL构的自动负蝲试工具Q它能预系l行为ƈ优化pȝ性能。LoadRunner 的测试对象是整个企业的系l,它通过模拟实际用户的操作行为和实行实时性能监测Q来帮助(zhn)更快的查找和发现问题。此外,LoadRunner 能支持广范的协议和技术,为?zhn)的特D环境提供特D的解决Ҏ(gu)?
2、特征:(x)
1)L创徏虚拟用户
使用LoadRunner 的Virtual User GeneratorQ?zhn)能很便地创立L(fng)l负载。该引擎能够生成虚拟用户Q以虚拟用户的方式模拟真实用L(fng)业务操作行ؓ(f)。它先记录下业务程(如下订单或机预?Q然后将其{化ؓ(f)试脚本。利用虚拟用P(zhn)可以在Windows QUNIX 或Linux 机器上同时生成千上万个用户讉K。所以LoadRunner能极大的减少负蝲试所需的硬件和人力资源。另外,LoadRunner 的TurboLoad 专利技术能?/p>
提供很高的适应性。TurboLoad 使?zhn)可以产生每天几十万名在线用户和数以百万计的点(yn)L的负载?
用Virtual User Generator 建立试脚本后,(zhn)可以对其进行参数化操作Q这一操作能让(zhn)利用几套不同的实际发生数据来测试?zhn)的应用程序,从而反映出本系l的负蝲能力。以一个订单输入过Eؓ(f)例,参数化操作可记录中的固定数据,如订单号和客户名Uͼ由可变值来代替。在q些变量内随意输入可能的订单号和客户名,来匹配多个实际用L(fng)操作行ؓ(f)?
LoadRunner 通过它的Data Wizard 来自动实现其试数据的参数化。Data Wizard 直接q于数据库服务器Q从中?zhn)可以获取所需的数据(如定单号和用户名Qƈ直接其输入到测试脚本。这样避免了人工处理数据的需要,Data Wizard 为?zhn)节省了大量的旉?
Zq一步确定?zhn)的Virtual user 能够模拟真实用户Q?zhn)可利用LoadRunner 控制某些行ؓ(f)Ҏ(gu)。例如,只需要点M下鼠标,(zhn)就能轻易控制交易的数量Q交易频率,用户的思考时间和q接速度{?
2)创徏真实的负?/p>
Virtual users 建立起后Q?zhn)需要设定?zhn)的负载方案,业务程l合和虚拟用h量。用LoadRunner 的ControllerQ?zhn)能很快组lv多用L(fng)试Ҏ(gu)。Controller 的Rendezvous 功能提供一个互动的环境Q在其中(zhn)既能徏立v持箋且@环的负蝲Q又能管理和驱动负蝲试Ҏ(gu)?
而且Q?zhn)可以利用它的日程计划服务来定义用户在什么时候访问系l以产生负蝲。这P(zhn)就能将试q程自动化。同hq可以用Controller 来限定?zhn)的负载方案,在这个方案中所有的用户同时执行一个动?--如登陆到一个库存应用程?---来模拟峰D载的情况。另外,(zhn)还能监系l架构中各个lg的性能---- 包括服务器,数据库,|络讑֤{?---来帮助客户决定系l的配置?
LoadRunner 通过它的AutoLoad 技术,为?zhn)提供更多的测试灵zL。用AutoLoad Q?zhn)可以?gu)目前的用户hC先设定测试目标,优化试程。例如,(zhn)的目标可以是确定?zhn)的应用系l承受的每秒点击数或每秒的交易量?
3)定位性能问题
LoadRunner 内含集成的实时监器Q在负蝲试q程的Q何时候,(zhn)都可以观察到应用系l的q行性能。这些性能监测器ؓ(f)(zhn)实时显CZ易性能数据Q如响应旉Q和其它pȝlg包括application server, web serverQ网路设备和数据库等的实时性能。这P(zhn)就可以在测试过E中从客户和服务器的双方面评估这些系l组件的q行性能Q从而更快地发现问题?/p>
再者,利用LoadRunner 的ContentCheck TM Q?zhn)可以判断负蝲下的应用E序功能正常与否。ContentCheck 在Virtual users q行Ӟ(g)应用程序的|络数据包内容,从中定是否有错误内容传送出厅R它的实时浏览器帮助(zhn)从l端用户角度观察E序性能状况?
4)分析l果以精定位问题所?/p>
一旦测试完毕后QLoadRunner 攉汇L有的试数据Qƈ为?zhn)提供高的分析和报告工具Q以便迅速查扑ֈ性能问题q追溯原由。用LoadRunner 的Web 交易l节监测器,(zhn)可以了解到所有的图象、框架和文本下蝲到每一|页上所需的时间。例如,q个交易l节分析机制能够分析是否因ؓ(f)一个大寸的图形文件或是第三方的数据组仉成应用pȝq行速度减慢。另外,W(xu)eb 交易l节监测器分解用于客L(fng)、网l和服务器上端到端的反应旉Q便于确认问题,定位查找真正出错的组件。例如,(zhn)可以将|络延时q行分解Q以判断DNS 解析旉Q连接服务器或SSL 认证所p的时间。通过使用LoadRunner 的分析工P(zhn)能很快地查扑ֈ出错的位|和原因q作出相应的调整?
5)重复试保证pȝ发布的高性能
负蝲试是一个重复过E。每ơ处理完一个出错情况,(zhn)都需要对(zhn)的应用E序在相同的Ҏ(gu)下,再进行一ơ负载测试。以此检验?zhn)所做的修正是否改善了运行性能?/p>
6) Enterprise Java Beans的测?/p>
LoadRunner 完全支持EJB 的负载测试。这些基于Java 的组件运行在应用服务器上Q提供广泛的应用服务。通过试q些lgQ?zhn)可以在应用程序开发的早期q认ƈ解决可能产生的问题?
利用LoadRunner, (zhn)可以很方便C解系l的性能?它的Controller 允许(zhn)重复执行与出错修改前相同的试Ҏ(gu)。它的基于HTML 的报告ؓ(f)(zhn)提供一个比较性能l果所需的基准,以此衡量在一D|间内Q有多大E度的改qƈ保应用成功。由于这些报告是ZHTML 的文本,(zhn)可以将其公布于(zhn)公司的内部|上Q便于随时查阅?
7)最大化投资回报
所有Mercury Interactive 的品和服务都是集成设计? 能完全相容地一赯作。由于它们具有相同的核心技术,来自于LoadRunner和ActiveTest TM 的测试脚本,在Mercury Interactive 的负载测试服务项目中Q可以被重复用于性能监测。借助Mercury Interactive的监功能-QTopaz TM 和ActiveWatch TM Q测试脚本可重复使用从而^衡投资收益。更重要的是Q?zhn)能?f)试的前期布|和生pȝ的监提供一个完整的应用性能理解决Ҏ(gu)?/p>
8)支持无线应用协议
随着无线讑֤数量和种cȝ增多Q?zhn)的测试计划需要同时满传l的Z览器的用户和无U互联网讑֤Q如手机和PDA。LoadRunner 支持2 Ҏ(gu)q泛使用的协议:(x)WAP和I-mode。此外,通过负蝲试pȝ整体架构QLoadRunner 能让(zhn)只需要通过记录一ơ脚本,可完全(g)上q这些无U互联网pȝ?/p>
9)支持Media Stream应用
LoadRunner q能支持Media Stream应用。ؓ(f)了保证终端用户得到良好的操作体验和高质量Media StreamQ?zhn)需要检?zhn)的Media Stream应用E序。用LoadRunner Q?zhn)可以记录和重放Q何流行的多媒体数据流格式来诊断系l的性能问题Q查扑֎由,分析数据的质量?/p>
10)完整的企业应用环境的支持
LoadRunner 支持q泛的协议,可以试各种IT 基础架构?/p>
七、WAS
1、简介:(x)
Microsoft Web Application Stress Tool 是由微Y的网站测试h员所开发,专门用来q行实际|站压力试的一套工兗透过q套功能强大的压力测试工P(zhn)可以用少量的Client端计机仿真大量用户上线对网站服务所可能造成的媄(jing)响?/p>
2、特征:(x)
1Q可以数U不同的方式建立试指o(h)Q包含以手动、录制浏览器操作步骤、或直接录入IIS的记录文件、录入网站的内容?qing)录入其它测试程序的指o(h){方式?/p>
2Q支持多U客L(fng)接口Q标准的|站应用E序C++的客L(fng)Q用Active Server Page 客户端,或是使用Web Application Stress对象模型建立(zhn)自定的接口?/p>
3Q支持多用户Q利用多U不同的认证方式仿真实际的情况,包含了DPA, NTLM ?SSL{?/p>
响应旉
Q?/span>
response time
Q?/span>
—?/span>
是应用程序处理一个请求所需的时?/span>
Q?/span>
比如Q从用户的浏览器得到的一?/span>
HTTP
h
Q?/span>
?font color="#800080">一般我们对q_响应旉感兴,在负载增大时响应旉的一贯性也很重要。提高负载后若响应时间曲U出现锯齿,往往说明性能乏善可陈Q还有潜在的不稳定?/font>
延迟旉
Q?/span>
latency
Q?/span>
——是从应用程序得到反馈所需的最时_(d)不管E序是否需要做多工作才能得到这个反馈,q程Ҏ(gu)调用h很长的gq;不管被调用的Ҏ(gu)是否成功Q都有一个固定的最开销Q?/span>
吞吐量(
throughput
Q——是E序或者组件在一D늻定时间内所能进行工作的dQ对
web
应用来说Q常常用每秒点击率来衡量Q对事务处理应用来说Q则是每U能完成的事务数Q?/span>
可~性(
scalability
Q——指应用E序如何应对增长的流量?font color="#000000">说到可~性的时候,我们通常指向上可伸羃Q?/font>
scaling up
Q,以便应对更大的负载。可伸羃性经常等价于水^可~性(
horizontal scalability
Q:(x)向上伸羃到服务器集群来提高吞吐量?我们也可以通过把应用{Ud更强的服务器上来提高吞吐量。后者要单得多,但显然ƈ不能让应用更牢固Q也只能得到有限的提高?br />另一U选择是垂直~(
vertical scaling
Q:(x)在每台服务器上运行多份服务。“垂直~”这个术语被
Fowler
用来指“ؓ(f)单台服务器增加更多的计算能力”,比如d额外?/span>
CPU
或者内存?br />
性能和可伸羃性有时候在现实中是对立的。能在单台服务器上高性能q行的应用,却可能无法被部v到集中Q?比如Qؓ(f)了获得高性能Q针Ҏ(gu)个用户在
session
中维护大量的数据Q而在集群环境下,q些数据无法被高效地复制。然而,必须意识刎ͼ性能C的应用同样不?x)具有很好的可~性。如果应用程序在单台服务器上费资源Q就以ؓ(f)着即便在集中q行Q也只不q是费更多的资源?/span>
性能试单说Q就是在预期的压力下Q我的应用能跑多快?font color="#800080">注意Q这里的压力是你预期的,更多的时候就是你的性能指标?/font>
负蝲试Q?/span>
load test
Q——目标是l系l以期望的负载量[
在没有速度要求的情况下Q我的应用能支撑多少的ƈ发用Pq里更多的是考虑定w?/span>
]
压力试Q?/span> stress test Q——目标是?font color="#00cc00">过期望能力时确定系l行为[ 过定w压力下的表现Q也x应用的恢复能力,q里更多的是xpȝ的变?span lang="EN-US">,属于健壮性测?span lang="EN-US">(robustness )一c?/span> ]
E_性测?/span> Q?/span> stability test Q—?/span> 试pȝ长时间运行的表现Q更多的是发C些资源泄漏等问题Q一般压力随便设|?/span>
基准试Ҏ(gu)性测?/span> Q?/span> benchmark Q?/span> —?span lang="EN-US">一般用来厂商之间同cM品之?span lang="EN-US">,相同产品版本之间的对比?/span>
如果不进行合理的规划Q对
J2EE
应用E序q行性能试会(x)是一o(h)人望而生畏且有些混ؕ的Q务。因为对于Q何的软g开发流E,都必L集需求、理解业务需要,q在q行实际试之前设计出正式的q度表。性能试的需求由业务需要驱动,q由一l用例阐明。这些用例可以基于历史数据(例如Q服务器一周的负蝲模式Q或预测的近似倹{弄清楚需要测试的内容之后Q就需要知道如何进行测试了?/span>
在开发阶D前期,应该使用基准试来确定应用程序中是否出现性能倒退。基准测试可以在一个相对短的时间内攉可重复的l果。进行基准测试的最好方法是Q每ơ测试改变一个且只改变一个参数。例如,如果想知道增?/span>
JVM
内存是否?x)?jing)响应用程序的性能Q就逐次递增
JVM
内存Q例如,?/span>
1024 MB
增至
1224 MB
Q然后是
1524 MB
Q最后是
2024 MB
Q,在每个阶D|集结果和环境数据Q记录信息,然后转到下一阶段。这样在分析试l果时就有迹可@。下一节我将介绍什么是基准试Q以?qing)运行基准测试的最?jng)_数?/span>
开发阶D后期,在应用程序中?/span>
bug
已经被解冻I应用E序辑ֈ一U稳定状态之后,可以q行更ؓ(f)复杂的测试,定pȝ在不同的负蝲模式下的表现。这些测试被UCؓ(f)定w规划试、渗入测?/span>
(soak test)
、峰h?/span>
(peak-rest test)
Q它们旨在通过试应用E序的可靠性、健壮性和可~性来试接近于现实世界的场景。对于下面的描述应该从抽象的意义上理解,因ؓ(f)每个应用E序的用模式都是不同的。例如,定w规划试通常都用较~慢?/span>
ramp-up
Q下文有定义Q,但是如果应用E序在一天之中的某个时段中有快速突发的量Q那么自然应该修Ҏ(gu)试以反映q种情况。但是,要记住,因ؓ(f)更改了测试参敎ͼ比如
ramp-up
周期或用L(fng)考虑旉
(think-time)
Q,试的结果肯定也?x)改变。一个不错的Ҏ(gu)是,q行一pd的基准测试,立一个已知的可控环境Q然后再对变化进行比较?/span>
基准试
基准试的关键是要获得一致的、可再现的结果。可再现的结果有两个好处Q减重新运行测试的ơ数Q对试的品和产生的数字更为确信。用的性能试工具可能?x)对试l果产生很大影响。假定测试的两个指标是服务器的响应时间和吞吐量,它们?x)受到服务器上的负蝲的?jing)响。服务器上的负蝲受两个因素媄(jing)响:(x)同时与服务器通信的连接(或虚拟用P的数目,以及(qing)每个虚拟用户h之间的考虑旉的长短。很明显Q与服务器通信的用戯多,负蝲p大。同Ph之间的考虑旉短Q负载也大。这两个因素的不同组合会(x)产生不同的服务器负蝲{。记住,随着服务器上负蝲的增加,吞吐量会(x)不断攀升,直到到达一个点?/span>
注意Q吞吐量以稳定的速度增长Q然后在某一个点上稳定下来?/span>
在某一点上Q执行队列开始增长,因ؓ(f)服务器上所有的U程都已投入使用Q传入的h不再被立卛_理,而是攑օ队列中,当线E空闲时再处理?/span>
?/span>
2.
随着负蝲的增加,pȝ执行队列长度的曲U?/span>
注意Q最初的一D|_(d)执行队列的长度ؓ(f)Ӟ然后开始以E_的速度增长。这是因为系l中的负载在E_增长Q虽然最初系l有_的空闲线E去处理增加的负载,最l它q是不能承受Q而必d其排入队列?/span>
当系l达到饱和点Q服务器吞吐量保持稳定后Q就辑ֈ了给定条件下的系l上限。但是,随着服务器负载的l箋增长Q系l的响应旉也随之g长,虽然吞吐量保持稳定?/span>
?/span>
3.
随着负蝲的增加,pȝ中两个事务的响应旉曲线
注意Q在执行队列Q图
2
Q开始增长的同时Q响应时间也开始以递增的速度增长。这是因求不能被?qing)时处理?/span>
Z获得真正可再现的l果Q应该将pȝ|于相同的高负蝲下。ؓ(f)此,与服务器通信的虚拟用户应该将h之间的考虑旉设ؓ(f)零。这h务器?x)立卌载,q开始构建执行队列。如果请求(虚拟用户Q数保持一_(d)基准试的结果应该会(x)非常_Q完全可以再现?/span>
(zhn)可能要问的一个问题是Q?/span>
?/span>
如何度量l果Q?/span>
?/span>
对于一ơ给定的试Q应该取响应旉和吞吐量的^均倹{精地获得q些值的唯一Ҏ(gu)是一ơ加载所有的用户Q然后在预定的时间段内持l运行。这UCؓ(f)
“flat?/span>
试?/span>
?/span>
4. flat
试的情况(所有的用户都是同时加蝲的)
与此相对应的?/span>
“ramp-up?/span>
试?/span>
?/span>
5. ramp-up
试的情况(在测试期_(d)用户以稳定速度Q每U?/span>
x
个)增加Q?/span>
ramp-up
试中的用户是交错上升的Q每几秒增加一些新用户Q?/span>
ramp-up
试不能产生_和可重现的^均|q是因ؓ(f)׃用户的增加是每次一部分Q系l的负蝲在不断地变化。因此,
flat
q行是获得基准测试数据的理想模式?/span>
q不是在贬低
ramp-up
试的h(hun)倹{实际上Q?/span>
ramp-up
试Ҏ(gu)Z后要q行?/span>
flat
试的范围非常有用?/span>
ramp-up
试的优Ҏ(gu)Q可以看出随着pȝ负蝲的改变,量值是如何改变的。然后可以据此选择以后要运行的
flat
试的范围?/span>
Flat
试的问题是pȝ?x)遇?/span>
?/span>
波动
?/span>
效果?/span>
?/span>
6.
一?/span>
flat
试中所得的系l吞吐量的曲U(单位Q页?/span>
/
U)
注意波动的出玎ͼ吞吐量不再是qx的?/span>
q在pȝ的各个方面都有所体现Q包?/span>
CPU
的用量?/span>
?/span>
7.
一?/span>
flat
试中所得的系l?/span>
CPU
使用量随旉变化的曲U?/span>
注意Q每隔一D|间就?x)出C个L形?/span>
CPU
使用量不再是qx的,而是有了像吞吐量NL(fng)峰?/span>
此外Q执行队列也承受着不稳定的负蝲Q因此可以看刎ͼ随着pȝ负蝲的增加和减少Q执行队列也在增长和~减?/span>
?/span>
8.
一?/span>
flat
试中所得的系l执行队列的曲线
注意Q每隔一D|间就?x)出C个L形。执行队列曲U与上面?/span>
CPU
使用量图非常怼?/span>
最后,pȝ中事务的响应旉也遵循着q个波动模式?/span>
?/span>
9.
一?/span>
flat
试中所得的系l事务的响应旉
注意Q每隔一D|间就?x)出C个L形。事务的响应旉也与上面的图cMQ只不过其效果随着旉的推U逐渐减弱?/span>
当测试中所有的用户都同时执行几乎相同的操作Ӟ׃(x)发生q种现象。这会(x)产生非常不可靠和不精的l果Q所以必采取一些措施防止这U情늚出现。有两种Ҏ(gu)可以从这U类型的l果中获得精的量倹{如果测试可以运行相当长的时_(d)有时是几个小Ӟ取决于用L(fng)操作持箋的时_(d)Q最后由于随Z件的本性?dng)服务器的吞吐量?x)?/span>
?/span>
拉^
?/span>
。或者,可以只选取波Ş中两个^息点之间的测量倹{该Ҏ(gu)的缺Ҏ(gu)可以捕获数据的时间非常短?/span>
性能规划试
对于性能规划cd的测试来_(d)其目标是扑ևQ在特定的环境下Q给定应用程序的性能可以辑ֈ何种E度。此时可重现性就不如在基准测试中那么重要了,因ؓ(f)试中通常都会(x)有随机因子。引入随机因子的目的是ؓ(f)了尽量模拟具有真实用戯载的现实世界应用E序。通常Q具体的目标是找出系l在特定的服务器响应旉下支持的当前用户的最大数。例如,(zhn)可能想知道Q如果要?/span>
5
U或更少的响应时间支?/span>
8,000
个当前用P需要多个服务器?要回{这个问题,需要知道系l的更多信息?/span>
要确定系l的定wQ需要考虑几个因素。通常Q服务器的用hL非常大(以十万计Q,但是实际上,q个数字q不能说明什么。真正需要知道的是,
q些用户中有多少是ƈ发与服务器通信?/span>
。其ơ要知道的是Q?/span>
每个用户?/span>
?/span>
考虑旉
?/span>
卌求时间是多少
。这非常重要Q?/span>
因ؓ(f)考虑旉短Q系l所能支持的q发用户少
。例如,如果用户的考虑旉?/span>
1
U,那么pȝ可能只能支持数百个这L(fng)q发用户。但是,如果用户的考虑旉?/span>
30
U,那么pȝ则可能支持数万个q样的ƈ发用P假定g和应用程序都是相同的Q。在现实世界中,通常难以定用户的确切考虑旉。还要注意,在现实世界中Q用户不?x)精地按照间隔旉发出h?/span>
于是引入了随机性。如果知道普通用L(fng)考虑旉?/span>
5
U,误差?/span>
20%
Q那么在设计负蝲试Ӟp保h间的旉?/span>
5×
Q?/span>
1 +/- 20%
Q秒。此外,可以利用
?/span>
调步
?/span>
的理念向负蝲场景中引入更多的随机性。它是这L(fng)Q在一个虚拟用户完成一整套的请求后Q该用户暂停一个设定的旉D,或者一个小的随机时间段Q例如,
2×
Q?/span>
1 +/- 25%
Q秒Q,然后再l执行下一套请求。将q两U随机化Ҏ(gu)q用到测试中Q可以提供更接近于现实世界的场景?/span>
现在该进行实际的定w规划试了。接下来的问题是Q?/span>
如何加蝲用户以模拟负载状态?
最好的Ҏ(gu)是模拟在高峰旉用户与服务器通信的状?/span>
。这U用戯载状态是在一D|间内逐步辑ֈ的吗Q如果是Q应该?/span>
ramp-up
cd的测试,每隔几秒增加
x
个用戗或者,所有用h在一个非常短的时间内同时与系l通信Q如果是q样Q就应该使用
flat
cd的测试,所有的用户同时加蝲到服务器。两U不同类型的试?x)生没有可比性的不同试。例如,如果q行
ramp-up
cd的测试,pȝ可以?/span>
4
U或更短的响应时间支?/span>
5,000
个用戗而执?/span>
flat
试Q?zhn)会(x)发玎ͼ对?/span>
5,000
个用Ppȝ的^均响应时间要大于
4
U。这是由?/span>
ramp-up
试固有的不准确性其不能显C系l可以支持的q发用户的精数字。以门户应用E序ZQ随着门户规模的扩大和集群规模的扩大,q种不确定性就?x)随之显现?/span>
q不是说不应该?/span>
ramp-up
试。对于系l负载在一D|较长的时间内~慢增加的情况,
ramp-up
试效果q是不错的。这是因为系l能够随着旉不断调整。如果用快?/span>
ramp-up
试Q系l就?x)滞后,从而报告一个较相同用户负蝲?/span>
flat
试低的响应旉。那么,什么是定定w的最好方法?l合两种负蝲cd的优点,q运行一pd的测试,׃(x)产生最好的l果。例如,
首先使用
ramp-up
试定pȝ可以支持的用戯围。确定了范围之后Q以该范围内不同的ƈ发用戯载进行一pd?/span>
flat
试Q更_地确定系l的定w?/span>
渗入试
渗入试是一U比较简单的性能试。渗入测试所需旉较长Q它使用固定数目的ƈ发用h试系l的M健壮性。这些测试将?x)通过内存泄漏、增加的垃圾攉
(GC)
或系l的其他问题Q显C因长时间运行而出现的M性能降低。测试运行的旉久Q?zhn)对系l就了解。运行两ơ测试是一个好L
—?/span>
一ơ用较低的用户负蝲Q要在系l容量之下,以便不会(x)出现执行队列Q,一ơ用较高的负蝲Q以便出现积极的执行队列Q?/span>
试应该q行几天的时_(d)以便真正了解应用E序的长期健L(fng)c(din)要保试的应用程序尽可能接近现实世界的情况,用户场景也要逼真Q虚拟用户通过应用E序D的方式要与现实世界一_(d)Q从而测试应用程序的全部Ҏ(gu)。确保运行了所有必需的监控工P以便_地监ƈ跟踪问题?/span>
峰谷试
峰谷试兼有定w规划
ramp-up
cd试和渗入测试的特征。其目标?/span>
定从高负蝲Q例如系l高峰时间的负蝲Q恢复、{为几乎空闌Ӏ然后再攀升到高负载、再降低的能?/span>
?/span>
生软g的最l目的是Z满客户需求,我们以客户需求作判Y件质量的标准Q认Y件缺P
Software Bug
Q的具体含义包括下面几个因素Q?/span>
?/span>
软g未达到客户需求的功能和性能Q?/span>
?/span>
软g出客户需求的范围Q?/span>
?/span>
软g出现客户需求不能容忍的错误Q?/span>
?/span>
软g的用未能符合客L(fng)?fn)惯和工作环境?/span>
考虑到设计等斚w的因素,我们q可以认Y件缺陯可以包括软g设计不符合规范,未能在特定的条gQ资金、范围等Q达到最佳等。可惜的是,我们中的很多人更們于把软g~陷看成q行时出现问题上来,认ؓ(f)软g试仅限于程序提交之后?/span>
在目前的国内环境下,我们几乎看不到完整准的客户需求说明书Q加以客L(fng)需求时时在变,q求完美的测试变得不太可能。因此作Z个优异的试人员Q追求Y件质量的完美固然是我们的宗旨Q但是明Y件测试现实与理想的差距,在Y件测试中学会(x)取舍和让步,对Y件测试是有百益而无一弊的?/span>
下面是一些Y件测试的常识Q对q些常识的理解和q用有助于我们在进行Y件测试时能够更好的把握Y件测试的度?/span>
?/span>
试是不完全的(试不完全)
很显?dng)׃软g需求的不完整性、Y仉辑路径的组合性、输入数据的大量性及(qing)l果多样性等因素Q哪怕是一个极其简单的E序Q要想穷所有逻辑路径Q所有输入数据和验证所有结果是非常困难的一件事情。我们D一个简单的例子Q比如说求两个整数的最大公U数。其输入信息Z个正整数。但是如果我们将整个正整数域的数字进行一番测试的话,从其数目的无限性我们便可证明是q样的测试在实际生活中是行不通的Q即便某一天我们能够穷该E序Q只怕我们乃x们的子孙都早已作古了。ؓ(f)此作Y件测试,我们一般采用等L(fng)和边界值分析等措施来进行实际的软g试Q寻找最用例集合成为我们精试复杂性的一条必l之道?/span>
?/span>
试h免疫性(软g~陷免疫性)
软g~陷与病毒一样具有可怕的
?/span>
免疫?/span>
?/span>
Q测试h员对光用的试多Q其免疫能力p强,L更多软g~陷更加困难。由数学上的概率论我们可以推一l论。假设一?/span>
50000
行的E序中有
500
个Y件缺陷ƈ且这些Y仉误分布时均匀的,则每
100
行可以找C个Y件缺陗我们假设测试h员用某种Ҏ(gu)花在查找软g~陷的精力ؓ(f)
X
时
/100
行。照此推,软g存在
500
个缺hQ我们查找一个Y件缺陷需?/span>
X
时Q当软g只存?/span>
5
个错误时Q我们每查找一个Y件缺陷需?/span>
100X
时。实践证明,实际的测试过E比上面的假设更刻,为此我们必须更换不同的测试方式和试数据。该例子q说明了在Y件测试中采用单一的方法不能高效和完全的针Ҏ(gu)有Y件缺P因此软g试应该可能的多采用多U途径q行试?/span>
?/span>
试?/span>
?/span>
泛型概念
?/span>
Q全E测试)
我一直反对Y件测试仅存在于程序完成之后。如果单U的只将E序设计阶段后的阶段UCY件测试的话,需求阶D和设计阶段的缺陷生的攑֤效应?x)加大。这非常不利于保证Y件质量。需求缺陗设计缺陷也是Y件缺PC
?/span>
软g~陷h生育能力
?/span>
。Y件测试应该跨整个Y件开发流E。需求验证(自检Q和设计验证Q自(g)Q也可以作软g试Q徏议称为:(x)需求测试和设计试Q的一U。Y件测试应该是一个泛型概念,늛整个软g生命周期Q这h能确保周期的每个阶段得赯(g)验。同时测试本w也需要有W三者进行评伎ͼ信息pȝ审计和Y件工E监理)Q即试本n也应当被试Q从而确保测试自w的可靠性和高效性。否则自w不正,难以服h?/span>
另外q需指出的是软g试是提高Y件品质量的必要条g而非充分条gQY件测试是提高产品质量最直接、最快捷的手D,但决不是一个根本手Dc(din)?/span>
?/span>
80-20
原则
80%
的Y件缺陷常常生存在软g
20%
的空间里。这个原则告诉我们,如果你想使Y件测试有效地话,C常常光(f)光危多?/span>
?/span>
地段
?/span>
。在那里发现软g~陷的可能性会(x)大的多。这一原则对于软g试人员提高?gu)试效率及(qing)缺陷发现率有着重大的意义。聪明的试人员?x)根据这个原则很快找多的~陷而愚蠢的试人员却仍在O无目的地到处搜寻?/span>
80-20
原则的另外一U情冉|Q我们在pȝ分析、系l设计、系l实现阶D늚复审Q测试工作中能够发现和避?/span>
80%
的Y件缺P此后的系l测试能够帮助我们找出剩余缺陷中?/span>
80%
Q最后的
5%
的Y件缺陷可能只有在pȝ交付使用后用L(fng)q大范围、长旉使用后才?x)曝露出来。因Y件测试只能够保证可能多地发现Y件缺P却无法保证能够发现所有的软g~陷?/span>
80-20
原则q能反映到Y件测试的自动化方面上来,实践证明
80%
的Y件缺陷可以借助人工试而发玎ͼ
20%
的Y件缺陷可以借助自动化测试能够得以发现。由于这二者间h交叉的部分,因此有
5%
左右的Y件缺陷需要通过其他方式q行发现和修正?/span>
?/span>
为效益而测?/span>
Z么我们要实施软g试Q是Z提高目的质量效益最l以提高目的M效益。ؓ(f)此我们不隑־出我们在实施软g试应该掌握的度。Y件测试应该在软g试成本和Y件质量效益两者间扑ֈ一个^衡点。这个^衡点是我们在实施Y件测试时应该遵守的度。单斚w的追求都必然损害软g试存在的h(hun)值和意义。一般说来,在Y件测试中我们应该量C持Y件测试简单性,切勿Y件测试过度复杂化Q拿物理学家爱因斯坦的话说就是:(x)
Keep it simple but not too simple
?/span>
?/span>
~陷的必然?/span>
软g试中,׃错误的关联性,q不是所有的软g~陷都能够得以修复。某些Y件缺陯然能够得以修复但在修复的q程中我们会(x)隑օ引入新的软g~陷。很多Y件缺陷之间是怺矛盾的,一个矛盄消失必然?x)引发另外一个矛盄产生。比如我们在解决通用性的~陷后往往?x)带来执行效率上的缺陗更何况在缺L(fng)修复q程中,我们常常q会(x)受时间、成本等斚w的限制因此无法有效、完整地修复所有的软g~陷。因此评估Y件缺L(fng)重要度、媄(jing)响范_(d)选择一个折中的Ҏ(gu)或是从非软g的因素(比如提升g性能Q考虑软g~陷成ؓ(f)我们在面对Y件缺h一个必ȝ面的事实?/span>
?/span>
软g试必须有预期结?/span>
没有预期l果的测试是不可理喻的。Y件缺hl过Ҏ(gu)而得出来的。这正如没有标准无法q行度量一栗如果我们事先不知道或是无法肯定预期的结果,我们必然无法了解试正确性。这很容易然人感觉如盲h摸象一般,不少试人员常常凭借自w的感觉去评判Y件缺L(fng)发生Q其l果往往是把似是而非的东西作为正的l果来判断,因此常常出现误测的现象?/span>
?/span>
软g试的意?/span>
-
事后分析
软g试的目的单单是发现~陷q么单吗Q如果是
?/span>
?/span>
?/span>
的话Q我敢保证,cM的Y件缺陷在下一ơ新目的Y件测试中q会(x)发生。古语说得好Q?/span>
?/span>
不知道历史的人必然会(x)重蹈覆辙
?/span>
。没有对软g试l果q行认真的分析,我们无法了解缺陷发生的原因和应Ҏ(gu)施,l果是我们不得不耗费的大量的人力和物力来再次查找软g~陷。很可惜Q目前大多测试团队都没有意识到这一点,试报告中缺乏测试结果分析这一环节?/span>
l论Q?/span>
软g试是一个需?/span>
?/span>
自觉
?/span>
的过E,作ؓ(f)一个测试h员,遇事沉着Q把持尺度,从根本上应对软g试有着正确的认识,希望本文对读者对软g试的认识有所帮助?/span>
CPU 限制 |
vmstat |
?%user+%sys 过 80% ? |
盘 I/O 限制 |
vmstat |
?%iowait 过Q?AIX4.3.3 或更高版本) 40% ? |
应用盘限制 |
iostat |
?%tm_act 过 70% ? |
虚存I间? |
lsps-a |
当分늩间的zd率超q?70% ? |
换页限制 |
iostat vmstat |
虚存逻辑?%tm_act 过 I/O Q?iostat Q的 30% Q激zȝ虚存率超q?CPU Q?vmstat Q数量的 10 倍时 |
pȝ失效 |
vmstatsar |
交换增大?CPU {待q运行队? |
交易的^均响应时_(d)期望|(x) <15s Q?/p>
交易的最大响应时_(d)期望|(x) <30s Q?
q_每秒处理交易数量Q分别记录单位时间内成功、失败和停止的交易数量)
交易成功?Q期望|(x) >95% Q?/p>
不同q发用户数的状况下的上述记录?/span>
试l果分析情况
单笔记录的处理时_(d)期望|(x) <15s Q?
单位旉内的处理交易W数Q期望|(x) >10 个)
某个旉D内的交易处理数?
单笔能处理的最大数据量
在每个交易处理中最大(最耗时Q的模块
在不同数量的试数据基础上的上述记录?br />
|络U别的测试指?span lang="EN-US">
吞吐量:(x)单位旉内网l传输数据量
冲突率:(x)在以太网上监到的每U冲H数
操作pȝU别的测试指?/span>
q程 / U程交换率:(x)q程和线E之间每U交换次?
CPU 利用率:(x)?span lang="EN-US"> CPU 占用率(Q)
pȝ CPU 利用率:(x)pȝ?span lang="EN-US"> CPU 占用率(Q)
用户 CPU 利用率:(x)用户模式下的 CPU 占用率(Q)
盘交换率:(x)盘交换速率
中断速率Q?span lang="EN-US"> CPU 每秒处理的中断数
d内存速率Q物理内存中每秒d内存늚数目
写出内存速率Q每U从物理内存写到|件中的内存页数目或者从物理内存中删掉的内存|?
内存交换速率Q每U写入内存页和从物理内存中读出页的个?
q程入交换率Q交换区输入的进E数?
q程Z换率Q交换区输出的进E数?br />
数据库别的试指标
数据库的q发q接敎ͼ(x)客户端的最大连接数
数据库所资源的用数?span style="FONT-SIZE: 12pt">
from mercury