CPU 限制	vmstat当%user+%sys 超过80%
磁盘I/O限制	vmstat当%iowait超过40%
应用磁盘限制	iostat当tm_act超过70%
虚存空间少	lsps-a当分页空间的活动率超过70%
换页限制	Iostat vmstat
虚存逻辑卷	%tm_act超过I/O(iostat)的30%，激活的虚存率超过CPU数量(vmstat)的10倍
系统失败	Vmstat sar页交换增大、CPU等待并运行队列

【相对的性能指标】

CPU	Good：70%
	Bad：85%
	Very Bad：90%+
Memory	Good：no page change
	Bad：每个CPU每秒10个页交换
	Very Bad：more page change
Disk	Good：<30%
	Bad：40%
	Very Bad：50%+
Network	好：带宽小于30%
运行队列	好：<2*CPU数量

1 、    熟悉需求背景及商业目标：

a)      了解清楚项目发起的原因，是为了解决用户的什么问题。

b)      当前的解决方案是不是最优的，为什么会这样做。

2 、    业务模型法：

a)      考虑本项目与外部系统的交互，划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），。可以参考系统分析说明书。

b)      确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互。

3 、    业务场景法：

a)      考虑用例的调用者；考虑每一个用例提供的服务是供哪些外部用例或者系统调用，找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。（一般和外部有交互的用例出错的概率比较大，需要重点关注。具体被哪些外部调用，每个产品线都需要自己整理添加。）

b)      考虑系统内部各个用例之间的交互（有可能 PD 划分用例的粒度不同，我们暂时考虑用户一次提交并且系统的状态及数据发生变化的功能是一个用例），形成内部业务流程图。需要分析每个用例之间的约束关系、执行条件，组织出各种业务流程图。

4 、    功能分解法（对每一个 UC ）：

a)      用户与系统的每一次交互，都可以认为是一个小功能。

比较内容

LoadRunner

Robot+TestManager

脚本录制

Robot 是按照不同协议来录制VU脚本的，不同的协议录制出的脚本不同

可以录制不通过本机之间机器之间的通讯内容

录制时的人机交互界面支持不够好

Robot 的VU脚本与GUI脚本不同

函数支持丰富处理较灵活

易读性差调试难度大

为用户内置了一些场景可以较为方便的使用

用户可以灵活的定制测试场景，但是有些需要通过修改测试脚本来进行

图形化处理界面操作简便

用户、场景、Suit定义层次清楚

定制灵活性差一些

一般测试人员较难上手，需要熟悉时间长

监控设置

可以监控多种资源情况

无

运行时获得资源数据与脚本运行情况相匹配

无

采集数据含义不够明确和通用

无

运行控制

可以监控和设定不同虚拟用户的运行状态

针对脚本内容有全面的运行监控，图形化的表示不同的运行状态

监控资源和虚拟用户同时进行

细节的看到脚本运行情况，运行效率较高

运行脚本效率较差

无法与资源情况统一

结果获得

汇总信息采用单独工具，可以较为详细对数据结果进行统计分析，可以自动生成报告

对脚本的各种情况监控支持较为全面

数据结果详细图表丰富，可以灵活生成报表和报告

结果对每一步骤执行时间做记录方便分析，自动记录每一次测试结果

结果不易保存，处理速度较慢

不能自动生成可读的测试报告，需要再加工

操作性

容易上手，适合于非技术人员操作

上手困难，需要有一定技术基础的人使用

界面友好性

界面友好性较强

界面友好性较强，但是容易down掉，并且很难重启

技术支持性

Mercury 技术人员较少，支持有困难

Rational 技术人员较多，IBM还有其他服务提供商给予技术支持

其他

LR 测试范围更广的专业工具，盗版License也在网上很容易找

Rational 的产品重点不在Robot上，况且以后会修改到Eclipse平台上，License也不容易给

明确测试的目标，一般适合用到的范围是，制定被测试的对象是在满足某个条件的区间内的所有数据。

案例设计方法：从其中区间数据段中选择任意一个或者两个数据，只要这个数据满足了，那么其他的数据就是满足的。

范例 1 ：在登陆某系统需要验证用户名，要求是长度是最小是 6 位，最长是 14 位，名字中可以包含数字，但是不能以数字开头，可以包含各种符号，不能包含中文。

1 、随意字母组合成一个 12 位的姓名，测试是否可以通过验证。

2 、随意生成一个长度 12 位的姓名，测试是否可以通过验证

3 、测试以任意一个数字打头 12 位的姓名，测试是否可以通过验证

4 、测试姓名长度为 12 位且包含中文情况，测试是否可以通过验证

5 、测试长度不满足条件情况下，是否通过验证

6 、如果长度不满足，是以数字开头的，提示信息验证

7 、如果长度不满足，姓名中包含中文的，提示信息验证……

注：这个可能比较简单，但是说明一个问题：为什么随意生成一个 12 位姓名的 , 其实你选择 8 位姓名长度或者 10 位姓名长度是一样的，所以这种情况下考虑采用等效方法比较合适。

范例 2 ：要求选择 1~12 之间进行调整，手机的背光就会随着数值的变化而变化。总体的是数值越大越暗。

测试案例设计：清晰记忆 1 的情况，然后随意调整一个数值，因为要求是变化了，至于变化成什么样子，变暗到什么程度才正确，没有明确的指标数值，所以只需要记住临街点 1 的情况，然后随意调整一个数据，然后和当前调整后的数据进行比较。

注：没有明确的说明，只是含糊的结果，但是总体的结果是在变化，那么这个时候比较适合使用等效法。

因果分析法

需要有一定的程序基础，了解程序的架构，就是当问题发生以后，能够有效的补充相关的案例或者筛选相关的案例。因果分析的核心是从自己的理解去分析问题所在的真正原因。

范例 1 ：删除磁盘上某个文件失败，分析原因：如果是管理员权限，那么可以随意删除，无论这个文件的属性是只读的还是存档的，那么如果不能删除磁盘文件，除非是坏道上的文件。分析完成以后，使得测试案例设计有针对性，而不是盲目的将所有的文件格式都去尝试一次。

范例 2 ：假设我们用 Excel 作一个计算，结果和我们用计算器计算的结果不同。分析原因： Excel 的计算函数单独运算没有错误，然后插入一行，结果错误了，说明插入行时导致计算错误，那么插入一行怎么会引起函数计算错误呢？原因是由于插入行后，导致传给计算函数的区域没有更新，所以造成计算结果错误，那么这个 Bug 就很明确了。

范例 3 ：假设我们平常在做讲座的时候发现在某台机器上就会死机。这是一种现象。分析原因：为什么在这台机器上死，在其他机器上不死。原因有两个，第一个先找系统原因，是否是我们的产品在当前这个系统下有 Bug, 经过验证没有，那问题出在那里？其实演示产品需要的是硬件的支持，那就是显卡，如果显卡内存不够大，可能导致某些演示文件死。

注：因果分析需要有广泛的知识面，使得我们在分析的时候能够拓宽面积，模糊的定位问题。

范例 4 ：用户给我发送一个文件，打印的时候发现是乱码。后来逼迫无奈，就让用户将这个文件传真给我。这是现象。分析原因：为什么打印出现乱码？问题基本定位，系统字库不够，系统下打印驱动问题，打印虚拟内存问题，操作系统问题，软件本身问题？最后问题经过验证，最终归结为在此操作系统下，打印驱动程序有问题，使得文件不能正常打印。

注：问题需要先框定范围，不要乱了套路。

逻辑分析法

在逻辑分析方面，也需要有一定的程序理解能力。从程序逻辑和日常常识去判断问题。逻辑分析法其实就一堆假设的罗列，推论出系列结果的假设，然后将假设反推翻，问题就可以暴露出来。无论那种方法都是通过表现去分析问题的实质的。

范例 1: 我们在做 MP3 播放器快进和快退测试中，要考虑的同步问题，就是我们液晶显示屏上出现的歌词进度，时间进度和我们耳朵听到的进度不同。我们分析一下，为什么出现不同步现象，为什么其他的能同步，就某一个或者某几个不能同步。首先我们了解同步的算法：快进和快退是按照当前歌曲的数据流来计算应该到那里，它是以当前歌曲的数据流为系数，然后进行的一些调整，那么出现不同步的原因是由于系数不同造成的，所以考虑到同步问题，我们需要找不同格式不同数据流的歌曲，这样问题容易暴露，容易清楚的定位问题的真正原因

边界数值分析法

一、JTEST

1、简介：

jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具,它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。Jtest先分析每个java类，然后自动生成junit测试用例并执行用例，从而实现代码的最大覆盖，并将代码运行时未处理的异常暴露出来；另外，它还可以检查以DbC（Design by Contract）规范开发的代码的正确性。用户还可以通过扩展测试用例的自动生成器来添加更多的junit用例。Jtest还能按照现有的超过350个编码标准来检查并自动纠正大多数常见的编码规则上的偏差，用户可自定义这些标准，通过简单的几个点击，就能预防类似于未处理异常、函数错误、内存泄漏、性能问题、安全隐患这样的代码问题。

2、优势：

1）使预防代码错误成为可能，从而大大节约成本，提高软件质量和开发效率

2）使单元测试——包括白盒、黑盒以及回归测试成为可能

3）使代码规范检查和自动纠正成为可能

4）鼓励开发团队横向协作来预防代码错误

3、特征：

1）通过简单的点击，自动实现代码基本错误的预防，这包括单元测试和代码规范的检查

2）生成并执行junit单元测试用例，对代码进行即时检查

3）提供了进行黑盒测试、模型测试和系统测试的快速途径

4）确认并阻止代码中不可捕获的异常、函数错误、内存泄漏、性能问题、安全弱点的问题

5）监视测试的覆盖范围

6）自动执行回归测试

7）支持DbC编码规范

8）检验超过350个来自java专家的开发规范

9）自动纠正违反超过160个编码规范的错误

10）允许用户通过图形方式或自动创建方式来自定义编码规范

11）支持大型团队开发中测试设置和测试文件的共享

12）实现和IBM Websphere Studio /Eclipse IDE 的安全集成

4、价格：昂贵

二、JMETER

1、简介：

JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。使用JMeter进行性能测试

2、特征：

JMeter可以用于测试静态或者动态资源的性能（文件、Servlets、Perl脚本、java对象、数据库和查询、ftp服务器或者其他的资源）。JMeter用于模拟在服务器、网络或者其他对象上附加高负载以测试他们提供服务的受压能力，或者分析他们提供的服务在不同负载条件下的总性能情况。你可以用JMeter提供的图形化界面分析性能指标或者在高负载情况下测试服务器/脚本/对象的行为。

3、价格：未知

三、JUNIT

1、简介：

JUnit是一个开源的java测试框架，它是Xuint测试体系架构的一种实现。在JUnit单元测试框架的设计时，设定了三个总体目标，第一个是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写；第二个是使测试单元保持持久性；第三个则是可以利用既有的测试来编写相关的测试。

2、优势：

2.1)junit是完全Free的。

2.2)使用方便。在你提升程序代码的品质时JUnit测试仍允许你更快速的撰写程序 那听起来似乎不是很直觉，但那是事实。当你使用JUnit撰写测试，你将花更少的时间除虫，同时对你程序代码的改变更 俱有信心。这个信心让你更积极重整程序代码并增加新的功能。没有测试，对于重整及增加新功能你会变得没有信心；因为你不知道有甚么东西会破坏产出的结果。采用一个综合的测试系列，你可以在改变程序代码之后快速的执行多个测试并对于你的变动并未破坏任何东西感到有信心。在执行测试时如果发现臭虫，原始码仍然清楚的在你脑中，因此很容易找到臭虫。在JUnit中撰写的测试帮助你以一种极 大(extreme)的步伐撰写程序及快速的找出缺点。

2.3)JUnit非常简单撰写测试应该很简单--这是重点！如果撰写测试太复杂或太耗时间，便无法要求程序设计师撰写测试。使用JUnit你可以快速的撰写测试并检测你的程序代码并逐 步随着程序代码的成长增加测试。只要你写了一些测试，你想要快速并频繁的执行测试而不至于中断建立设计及开发程序。使用JUnit执行测试就像编译你的程序代码那么容易。事实上，你应该执行编译时也执行测试。编译是检测程序代码的语法而测试是检查程序代码的完整性(integrity)。

2.4)JUnit测试检验其结果并提供立即的回馈。 如果你是以人工比对测试的期望与实际结果那么测试是很不好玩的，而且让你的速度慢下来。JUnit测试可以自动执行并且检查他们自己的结果。当你执行测试，你获得简单且立即的回馈； 比如测试是通过或失败。而不再需要人工检查测试结果的报告。

2.5)JUnit测试可以合成一个测试系列的层级架构。 JUnit可以把测试组织成测试系列；这个测试系列可以包含其它的测试或测试系列。JUnit测试的合成行为允许你组合多个测试并自动的回归(regression)从头到尾测试整个测试系列。你也可以执行测试系列层级架构中任何一层的测试。

2.6)撰写JUnit测试所费不多。 使用Junit测试框架，你可以很便宜的撰写测试并享受由测试框架所提供的信心。撰写一个测试就像写一个方法一样简单；测试是检验要测试的程序代码并定义期望的结果。这个测试框架提供自动执行测试的背景；这个背景并成为其它测试集合的一部份。在测试少量的投资将持续让你从时间及品质中获得回收。

2.7)JUnit测试提升软件的稳定性。 你写的测试愈少；你的程序代码变的愈不稳定。测试使得软件稳定并逐步累积信心；因为任何变动不会造成涟漪效应而漫及整个软件。测试可以形成软件的完整结构的胶结。

2.8)JUnit测试是开发者测试。 JUnit测试是高度区域性(localized)测试；用以改善开发者的生产力及程序代码品质。不像功能测试(function test)视系统为一个黑箱以确认软件整体的工作性为主，单元测试是由内而外测试系统基础的建构区块。开发者撰写并拥有JUnit测试。每当一个开发反复(iteration)完成，这个测试便包裹成为交付软件的一部份提供一种沟通的方式，「这是我交付的软件并且是通过测试

2.9)JUnit测试是以Java写成的。 使用Java测试Java软件形成一个介于测试及程序代码间的无缝(seamless)边界。在测试的控制下测试变成整个软件的扩充同时程序代码可以被重整。Java编译器的单元测试静态语法检查可已帮助测试程序并且确认遵守软件接口的约定。

一段测试的程序代码无法单独的执行，它需要是执行环境的一部份。同时，它需要自动执行的单元测试--譬如在系统中周期性的执行所有的测试以证明没有任何东西被破坏。由于单元测试需要符合特定的准则：一个成功的测试不应该是人工检查的（那可要到天荒地老了啊），一个未通过测试的失败应可以产出文件以供诊断修改。而Junit可以提供给我们这些便利.。这样所有测试开发者所需撰写的只是测试码本身了。跟optimizeit、Jtest那些昂贵而又超级麻烦的tool比较起来，其利昭然可见！

3、价格：免费

四、WEBLODE

1、简介：

webload是RadView公司推出的一个性能测试和分析工具,它让web应用程序开发者自动执行压力测试;webload通过模拟真实用户的操作,生成压力负载来测试web的性能。

2、特征：

1)用户创建的是基于javascript的测试脚本,称为议程agenda,用它来模拟客户的行为,通过执行该脚本来衡量web应用程序在真实环境下的性能

2)如有需要可以在做负载测试的同时，使用服务器监控工具对服务器端的内容进行记录那样使负载测试更加全面。

3、价格：

五、WINRUNNER

1、简介

WinRunner:强大的企业级自动化测试工具

Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

企业级应用可能包括Web应用系统，ERP系统，CRM系统等等。这些系统在发布之前，升级之后都要经过测试，确保所有功能都能正常运行，没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统，是每个公司都会面临的问题。

如果时间或资源有限，这个问题会更加棘手。人工测试的工作量太大，还要额外的时间来培训新的测试人员等等。为了确保那些复杂的企业级应用在不同环境下都能正常可靠地运行，你需要一个能简单操作的测试工具来自动完成应用程序的功能性测试。

2、特征：

1)轻松创建测试

用WinRuuner创建一个测试，只需点击鼠标和键盘，完成一个标准的业务操作流程，WinRunner自动记录你的操作并生成所需的脚本代码。这样，即使计算机技术知识有限的业务用户轻松创建完整的测试。你还可以直接修改测试脚本以满足各种复杂测试的需求。WinRunner提供这两种测试创建方式，满足测试团队中业务用户和专业技术人员的不同需求。

2)插入检查点

在记录一个测试的过程中，可以插入检查点，检查在某个时刻/状态下，应用程序是否运行正常。在插入检查点后，WinRunner会收集一套数据指标，在测试运行时对其一一验证。WinRunner提供几种不同类型的检查点，包括文本的、GUI、位图和数据库。例如，用一个位图检查点，你可以检查公司的图标是否出现于指定位置。

3)检验数据

除了创建并运行测试，WinRunner还能验证数据库的数值，从而确保业务交易的准确性。例如，在创建测试时，可以设定哪些数据库表和记录需要检测；在测试运行时，测试程序就会自动核对数据库内的实际数值和预期的数值。WinRunner自动显示检测结果，在有更新/删除/插入的记录上突出显示以引起注意。

4)增强测试

为了彻底全面地测试一个应用程序，需要使用不同类型的数据来测试。WinRunner的数据驱动向导( Data Driver Wizard)可以让你简单地点击几下鼠标，就可以把一个业务流程测试转化为数据驱动测试，从而反映多个用户各自独特且真实的行为。

以一个订单输入的流程为例，你可能希望把订单号或客户名称作为可变栏，用多套数据进行测试。使用Data Driver Wizard，你可以选择订单号或客户名称用数据表格文件中的哪个栏目的数据替换。你可以把订单号或客户名称输入数据表格文件，或从其它表格和数据库中导入。数据驱动测试不仅节省了时间和资源，又提高了应用的测试覆盖率。

WinRunner还可以通过Function Generator增加测试的功能。使用Function Generator可以从目录列表中选择一个功能增加到你的测试中以提高测试能力。例如，你可以选择”calendar”，然后从日历功能的下属目录中选择，如Calendar_select_date(),然后你可以直观地输入参数，把这个功能插入到你的测试中。

针对相当数量的企业应用里非标准对象，WinRunner提供了Virtual Object Wizard来识别以前未知的对象。使用Virtual Object Wizard，你可以选择未知对象的类型，设定标识和命名。在录制使用该对象的测试时，WinRunner会自动对应它的名字，从而提高测试脚本的可读性和测试质量。

5)运行测试

创建好测试脚本，并插入检查点和必要的添加功能后，你就可以开始运行测试。运行测试时，WinRunner会自动操作应用程序，就象一个真实的用户根据业务流程执行着每一步的操作。测试运行过程中，如有网络消息窗口出现或其它意外事件出现，WinRunner也会根据预先的设定排除这些干扰。

6)分析结果

测试运行结束后，你需要分析测试结果。WinRunner通过交互式的报告工具来提供详尽的、易读的报告。报告中会列出测试中发现的错误内容、位置、检查点和其它重要事件，帮助你对测试结果进行分析。这些测试结果还可以通过Mercury Interactive的测试管理工具TestDirector来查阅。

7)维护测试

随着时间的推移，开发人员会对应用程序做进一步的修改，并需要增加另外的测试。使用WinRunner，你不必对程序的每一次改动都重新创建你的测试。WinRunner可以创建在整个应用程序生命周期内都可以重复使用的测试，从而大大地节省时间和资源，充分利用你的测试投资。

每次记录测试时，WinRunner会自动创建一个GUI Map文件以保存应用对象。这些对象分层次组织，既可以总览所有的对象，也可以查询某个对象的详细信息。一般而言，对应用程序的任何改动都会影响到成百上千个测试。通过修改一个GUI Map文件而非无数个测试，WinRunner可以方便地实现测试重用。

8)帮助你的应用程序为无线应用作准备

随着无线设备种类和数量的增加，你的应用程序测试计划需要同时满足传统的基于浏览器的用户和无线浏览设备，如移动电话、传呼机和个人数字助理(PDA)。

无线应用协议是一种公开的、全球性的网络协议，用来支持标准数据格式化和无线设备信号的传输。
使用WinRunner，测试人员可以利用微型浏览模拟器来记录业务流程操作，然后回放和检查这些业务流程功能的正确性。

六、LOADRUNNER

1、简介：

LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

目前企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢，系统崩溃等问题。这些都不可避免地导致公司收益的损失。Mercury Interactive 的 LoadRunner 能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT 资源，并确保终端用户在应用系统的各个环节中对其测试应用的质量，可靠性和可扩展性都有良好的评价。

LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，LoadRunner 能支持广范的协议和技术，为您的特殊环境提供特殊的解决方案。

2、特征：

1)轻松创建虚拟用户

使用LoadRunner 的Virtual User Generator，您能很简便地创立起系统负载。该引擎能够生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程(如下订单或机票预定)，然后将其转化为测试脚本。利用虚拟用户，您可以在Windows ，UNIX 或Linux 机器上同时产生成千上万个用户访问。所以LoadRunner能极大的减少负载测试所需的硬件和人力资源。另外，LoadRunner 的TurboLoad 专利技术能。

提供很高的适应性。TurboLoad 使您可以产生每天几十万名在线用户和数以百万计的点击数的负载。

用Virtual User Generator 建立测试脚本后，您可以对其进行参数化操作，这一操作能让您利用几套不同的实际发生数据来测试您的应用程序，从而反映出本系统的负载能力。以一个订单输入过程为例，参数化操作可将记录中的固定数据，如订单号和客户名称，由可变值来代替。在这些变量内随意输入可能的订单号和客户名，来匹配多个实际用户的操作行为。

LoadRunner 通过它的Data Wizard 来自动实现其测试数据的参数化。Data Wizard 直接连于数据库服务器，从中您可以获取所需的数据（如定单号和用户名）并直接将其输入到测试脚本。这样避免了人工处理数据的需要，Data Wizard 为您节省了大量的时间。

为了进一步确定您的Virtual user 能够模拟真实用户，您可利用LoadRunner 控制某些行为特性。例如，只需要点击一下鼠标，您就能轻易控制交易的数量，交易频率，用户的思考时间和连接速度等。

2)创建真实的负载

Virtual users 建立起后，您需要设定您的负载方案，业务流程组合和虚拟用户数量。用LoadRunner 的Controller，您能很快组织起多用户的测试方案。Controller 的Rendezvous 功能提供一个互动的环境，在其中您既能建立起持续且循环的负载，又能管理和驱动负载测试方案。

而且，您可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负载。这样，您就能将测试过程自动化。同样您还可以用Controller 来限定您的负载方案，在这个方案中所有的用户同时执行一个动作---如登陆到一个库存应用程序----来模拟峰值负载的情况。另外，您还能监测系统架构中各个组件的性能---- 包括服务器，数据库，网络设备等----来帮助客户决定系统的配置。

LoadRunner 通过它的AutoLoad 技术，为您提供更多的测试灵活性。使用AutoLoad ，您可以根据目前的用户人数事先设定测试目标，优化测试流程。例如，您的目标可以是确定您的应用系统承受的每秒点击数或每秒的交易量。

3)定位性能问题

LoadRunner 内含集成的实时监测器，在负载测试过程的任何时候，您都可以观察到应用系统的运行性能。这些性能监测器为您实时显示交易性能数据（如响应时间）和其它系统组件包括application server, web server，网路设备和数据库等的实时性能。这样，您就可以在测试过程中从客户和服务器的双方面评估这些系统组件的运行性能，从而更快地发现问题。

再者，利用LoadRunner 的ContentCheck TM ，您可以判断负载下的应用程序功能正常与否。ContentCheck 在Virtual users 运行时，检测应用程序的网络数据包内容，从中确定是否有错误内容传送出去。它的实时浏览器帮助您从终端用户角度观察程序性能状况。

4)分析结果以精确定位问题所在

一旦测试完毕后，LoadRunner 收集汇总所有的测试数据，并为您提供高级的分析和报告工具，以便迅速查找到性能问题并追溯原由。使用LoadRunner 的Web 交易细节监测器，您可以了解到将所有的图象、框架和文本下载到每一网页上所需的时间。例如，这个交易细节分析机制能够分析是否因为一个大尺寸的图形文件或是第三方的数据组件造成应用系统运行速度减慢。另外，Web 交易细节监测器分解用于客户端、网络和服务器上端到端的反应时间，便于确认问题，定位查找真正出错的组件。例如，您可以将网络延时进行分解，以判断DNS 解析时间，连接服务器或SSL 认证所花费的时间。通过使用LoadRunner 的分析工具，您能很快地查找到出错的位置和原因并作出相应的调整。

5)重复测试保证系统发布的高性能

负载测试是一个重复过程。每次处理完一个出错情况，您都需要对您的应用程序在相同的方案下，再进行一次负载测试。以此检验您所做的修正是否改善了运行性能。

6) Enterprise Java Beans的测试

LoadRunner 完全支持EJB 的负载测试。这些基于Java 的组件运行在应用服务器上，提供广泛的应用服务。通过测试这些组件，您可以在应用程序开发的早期就确认并解决可能产生的问题。

利用LoadRunner, 您可以很方便地了解系统的性能。 它的Controller 允许您重复执行与出错修改前相同的测试方案。它的基于HTML 的报告为您提供一个比较性能结果所需的基准，以此衡量在一段时间内，有多大程度的改进并确保应用成功。由于这些报告是基于HTML 的文本，您可以将其公布于您公司的内部网上，便于随时查阅。

7)最大化投资回报

所有Mercury Interactive 的产品和服务都是集成设计的, 能完全相容地一起运作。由于它们具有相同的核心技术，来自于LoadRunner和ActiveTest TM 的测试脚本，在Mercury Interactive 的负载测试服务项目中，可以被重复用于性能监测。借助Mercury Interactive的监测功能－－Topaz TM 和ActiveWatch TM ，测试脚本可重复使用从而平衡投资收益。更重要的是，您能为测试的前期布署和生产系统的监测提供一个完整的应用性能管理解决方案。

8)支持无线应用协议

随着无线设备数量和种类的增多，您的测试计划需要同时满足传统的基于浏览器的用户和无线互联网设备，如手机和PDA。LoadRunner 支持2 项最广泛使用的协议：WAP和I-mode。此外，通过负载测试系统整体架构，LoadRunner 能让您只需要通过记录一次脚本，就可完全检测上述这些无线互联网系统。

9)支持Media Stream应用

LoadRunner 还能支持Media Stream应用。为了保证终端用户得到良好的操作体验和高质量Media Stream，您需要检测您的Media Stream应用程序。使用LoadRunner ，您可以记录和重放任何流行的多媒体数据流格式来诊断系统的性能问题，查找原由，分析数据的质量。

10)完整的企业应用环境的支持

LoadRunner 支持广泛的协议，可以测试各种IT 基础架构。

七、WAS

1、简介：

Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。

2、特征：

1）可以数种不同的方式建立测试指令：包含以手动、录制浏览器操作步骤、或直接录入IIS的记录文件、录入网站的内容及录入其它测试程序的指令等方式。

2）支持多种客户端接口：标准的网站应用程序C++的客户端，使用Active Server Page 客户端，或是使用Web Application Stress对象模型建立您自定的接口。

3）支持多用户：利用多种不同的认证方式仿真实际的情况，包含了DPA, NTLM 及 SSL等。

响应时间 （ response time ） —— 是应用程序处理一个请求所需的时间 （ 比如：从用户的浏览器得到的一个 HTTP 请求 ） 。一般我们对平均响应时间感兴趣，在负载增大时响应时间的一贯性也很重要。提高负载后若响应时间曲线出现锯齿，往往说明性能乏善可陈，还有潜在的不稳定。
 

延迟时间 （ latency ） ——是从应用程序得到反馈所需的最少时间（不管程序是否需要做多工作才能得到这个反馈，远程方法调用具有很长的延迟；不管被调用的方法是否成功，都有一个固定的最小开销）。
 

吞吐量（ throughput ）——是程序或者组件在一段给定时间内所能进行工作的总和（对 web 应用来说，常常用每秒点击率来衡量；对事务处理应用来说，则是每秒能完成的事务数）。
 

可伸缩性（ scalability ）——指应用程序如何应对增长的流量。说到可伸缩性的时候，我们通常指向上可伸缩（ scaling up ），以便应对更大的负载。可伸缩性经常等价于水平可伸缩性（ horizontal scalability ）：向上伸缩到服务器集群来提高吞吐量。 我们也可以通过把应用转移到更强的服务器上来提高吞吐量。后者要简单得多，但显然并不能让应用更牢固，也只能得到有限的提高。
另一种选择是垂直伸缩（ vertical scaling ）：在每台服务器上运行多份服务。“垂直伸缩”这个术语被 Fowler 用来指“为单台服务器增加更多的计算能力”，比如添加额外的 CPU 或者内存。
性能和可伸缩性有时候在现实中是对立的。能在单台服务器上高性能运行的应用，却可能无法被部署到集群中， 比如：为了获得高性能，针对每个用户在 session 中维护大量的数据；而在集群环境下，这些数据无法被高效地复制。然而，必须意识到，性能地下的应用同样不会具有很好的可伸缩性。如果应用程序在单台服务器上浪费资源，就以为着即便在集群中运行，也只不过是浪费更多的资源。
 

性能测试简单说，就是在预期的压力下，我的应用能跑多快。注意，这里的压力是你预期的，更多的时候就是你的性能指标。

负载测试（ load test ）——目标是给系统以期望的负载量[ 在没有速度要求的情况下，我的应用能支撑多少的并发用户，这里更多的是考虑容量。 ]

压力测试（ stress test ）——目标是在超过期望能力时确定系统行为[ 超过容量压力下的表现，也关注应用的恢复能力，这里更多的是关注系统的变化,属于健壮性测试(robustness )一类 ]

稳定性测试 （ stability test ）—— 测试系统长时间运行的表现，更多的是发现一些资源泄漏等问题，一般压力随便设置。

基准测试对比性测试 （ benchmark ） ——一般用来厂商之间同类产品之间,相同产品版本之间的对比。

　　如果不进行合理的规划，对 J2EE 应用程序进行性能测试将会是一项令人望而生畏且有些混乱的任务。因为对于任何的软件开发流程，都必须收集需求、理解业务需要，并在进行实际测试之前设计出正式的进度表。性能测试的需求由业务需要驱动，并由一组用例阐明。这些用例可以基于历史数据（例如，服务器一周的负载模式）或预测的近似值。弄清楚需要测试的内容之后，就需要知道如何进行测试了。

　　在开发阶段前期，应该使用基准测试来确定应用程序中是否出现性能倒退。基准测试可以在一个相对短的时间内收集可重复的结果。进行基准测试的最好方法是，每次测试改变一个且只改变一个参数。例如，如果想知道增加 JVM 内存是否会影响应用程序的性能，就逐次递增 JVM 内存（例如，从 1024 MB 增至 1224 MB ，然后是 1524 MB ，最后是 2024 MB ），在每个阶段收集结果和环境数据，记录信息，然后转到下一阶段。这样在分析测试结果时就有迹可循。下一小节我将介绍什么是基准测试，以及运行基准测试的最佳参数。

　　开发阶段后期，在应用程序中的 bug 已经被解决，应用程序达到一种稳定状态之后，可以运行更为复杂的测试，确定系统在不同的负载模式下的表现。这些测试被称为容量规划测试、渗入测试 (soak test) 、峰谷测试 (peak-rest test) ，它们旨在通过测试应用程序的可靠性、健壮性和可伸缩性来测试接近于现实世界的场景。对于下面的描述应该从抽象的意义上理解，因为每个应用程序的使用模式都是不同的。例如，容量规划测试通常都使用较缓慢的 ramp-up （下文有定义），但是如果应用程序在一天之中的某个时段中有快速突发的流量，那么自然应该修改测试以反映这种情况。但是，要记住，因为更改了测试参数（比如 ramp-up 周期或用户的考虑时间 (think-time) ），测试的结果肯定也会改变。一个不错的方法是，运行一系列的基准测试，确立一个已知的可控环境，然后再对变化进行比较。

基准测试

　　基准测试的关键是要获得一致的、可再现的结果。可再现的结果有两个好处：减少重新运行测试的次数；对测试的产品和产生的数字更为确信。使用的性能测试工具可能会对测试结果产生很大影响。假定测试的两个指标是服务器的响应时间和吞吐量，它们会受到服务器上的负载的影响。服务器上的负载受两个因素影响：同时与服务器通信的连接（或虚拟用户）的数目，以及每个虚拟用户请求之间的考虑时间的长短。很明显，与服务器通信的用户越多，负载就越大。同样，请求之间的考虑时间越短，负载也越大。这两个因素的不同组合会产生不同的服务器负载等级。记住，随着服务器上负载的增加，吞吐量会不断攀升，直到到达一个点。

　　注意，吞吐量以稳定的速度增长，然后在某一个点上稳定下来。

　　在某一点上，执行队列开始增长，因为服务器上所有的线程都已投入使用，传入的请求不再被立即处理，而是放入队列中，当线程空闲时再处理。

 
图 2. 随着负载的增加，系统执行队列长度的曲线

　　注意，最初的一段时间，执行队列的长度为零，然后就开始以稳定的速度增长。这是因为系统中的负载在稳定增长，虽然最初系统有足够的空闲线程去处理增加的负载，最终它还是不能承受，而必须将其排入队列。

　　当系统达到饱和点，服务器吞吐量保持稳定后，就达到了给定条件下的系统上限。但是，随着服务器负载的继续增长，系统的响应时间也随之延长，虽然吞吐量保持稳定。

 
图 3. 随着负载的增加，系统中两个事务的响应时间曲线

　　注意，在执行队列（图 2 ）开始增长的同时，响应时间也开始以递增的速度增长。这是因为请求不能被及时处理。

　　为了获得真正可再现的结果，应该将系统置于相同的高负载下。为此，与服务器通信的虚拟用户应该将请求之间的考虑时间设为零。这样服务器会立即超载，并开始构建执行队列。如果请求（虚拟用户）数保持一致，基准测试的结果应该会非常精确，完全可以再现。

　　您可能要问的一个问题是： “ 如何度量结果？ ” 对于一次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。这称为 “flat” 测试。

图 4. flat 测试的情况（所有的用户都是同时加载的）

　　与此相对应的是 “ramp-up” 测试。

 
图 5. ramp-up 测试的情况（在测试期间，用户以稳定速度（每秒 x 个）增加）

　　 ramp-up 测试中的用户是交错上升的（每几秒增加一些新用户）。 ramp-up 测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。因此， flat 运行是获得基准测试数据的理想模式。

　　这不是在贬低 ramp-up 测试的价值。实际上， ramp-up 测试对找出以后要运行的 flat 测试的范围非常有用。 ramp-up 测试的优点是，可以看出随着系统负载的改变，测量值是如何改变的。然后可以据此选择以后要运行的 flat 测试的范围。

　　 Flat 测试的问题是系统会遇到 “ 波动 ” 效果。

  
图 6. 一次 flat 测试中所测得的系统吞吐量的曲线（单位：页面 / 秒）

　　注意波动的出现，吞吐量不再是平滑的。

　　这在系统的各个方面都有所体现，包括 CPU 的使用量。

 
图 7. 一次 flat 测试中所测得的系统 CPU 使用量随时间变化的曲线

　　注意，每隔一段时间就会出现一个波形。 CPU 使用量不再是平滑的，而是有了像吞吐量图那样的尖峰。

　　此外，执行队列也承受着不稳定的负载，因此可以看到，随着系统负载的增加和减少，执行队列也在增长和缩减。

 
图 8. 一次 flat 测试中所测得的系统执行队列的曲线

　　注意，每隔一段时间就会出现一个波形。执行队列曲线与上面的 CPU 使用量图非常相似。

　　最后，系统中事务的响应时间也遵循着这个波动模式。

 
图 9. 一次 flat 测试中所测得的系统事务的响应时间

　　注意，每隔一段时间就会出现一个波形。事务的响应时间也与上面的图类似，只不过其效果随着时间的推移逐渐减弱。

　　当测试中所有的用户都同时执行几乎相同的操作时，就会发生这种现象。这将会产生非常不可靠和不精确的结果，所以必须采取一些措施防止这种情况的出现。有两种方法可以从这种类型的结果中获得精确的测量值。如果测试可以运行相当长的时间（有时是几个小时，取决于用户的操作持续的时间），最后由于随机事件的本性使然，服务器的吞吐量会被 “ 拉平 ” 。或者，可以只选取波形中两个平息点之间的测量值。该方法的缺点是可以捕获数据的时间非常短。

性能规划测试

　　对于性能规划类型的测试来说，其目标是找出，在特定的环境下，给定应用程序的性能可以达到何种程度。此时可重现性就不如在基准测试中那么重要了，因为测试中通常都会有随机因子。引入随机因子的目的是为了尽量模拟具有真实用户负载的现实世界应用程序。通常，具体的目标是找出系统在特定的服务器响应时间下支持的当前用户的最大数。例如，您可能想知道：如果要以 5 秒或更少的响应时间支持 8,000 个当前用户，需要多少个服务器？要回答这个问题，需要知道系统的更多信息。

　　要确定系统的容量，需要考虑几个因素。通常，服务器的用户总数非常大（以十万计），但是实际上，这个数字并不能说明什么。真正需要知道的是， 这些用户中有多少是并发与服务器通信的 。其次要知道的是， 每个用户的 “ 考虑时间 ” 即请求时间是多少 。这非常重要， 因为考虑时间越短，系统所能支持的并发用户越少 。例如，如果用户的考虑时间是 1 秒，那么系统可能只能支持数百个这样的并发用户。但是，如果用户的考虑时间是 30 秒，那么系统则可能支持数万个这样的并发用户（假定硬件和应用程序都是相同的）。在现实世界中，通常难以确定用户的确切考虑时间。还要注意，在现实世界中，用户不会精确地按照间隔时间发出请求。

　　于是就引入了随机性。如果知道普通用户的考虑时间是 5 秒，误差为 20% ，那么在设计负载测试时，就要确保请求间的时间为 5× （ 1 +/- 20% ）秒。此外，可以利用 “ 调步 ” 的理念向负载场景中引入更多的随机性。它是这样的：在一个虚拟用户完成一整套的请求后，该用户暂停一个设定的时间段，或者一个小的随机时间段（例如， 2× （ 1 +/- 25% ）秒），然后再继续执行下一套请求。将这两种随机化方法运用到测试中，可以提供更接近于现实世界的场景。

　　现在该进行实际的容量规划测试了。接下来的问题是： 如何加载用户以模拟负载状态？ 最好的方法是模拟在高峰时间用户与服务器通信的状况 。这种用户负载状态是在一段时间内逐步达到的吗？如果是，应该使用 ramp-up 类型的测试，每隔几秒增加 x 个用户。或者，所有用户是在一个非常短的时间内同时与系统通信？如果是这样，就应该使用 flat 类型的测试，将所有的用户同时加载到服务器。两种不同类型的测试会产生没有可比性的不同测试。例如，如果进行 ramp-up 类型的测试，系统可以以 4 秒或更短的响应时间支持 5,000 个用户。而执行 flat 测试，您会发现，对于 5,000 个用户，系统的平均响应时间要大于 4 秒。这是由于 ramp-up 测试固有的不准确性使其不能显示系统可以支持的并发用户的精确数字。以门户应用程序为例，随着门户规模的扩大和集群规模的扩大，这种不确定性就会随之显现。

　　这不是说不应该使用 ramp-up 测试。对于系统负载在一段比较长的时间内缓慢增加的情况， ramp-up 测试效果还是不错的。这是因为系统能够随着时间不断调整。如果使用快速 ramp-up 测试，系统就会滞后，从而报告一个较相同用户负载的 flat 测试低的响应时间。那么，什么是确定容量的最好方法？结合两种负载类型的优点，并运行一系列的测试，就会产生最好的结果。例如， 首先使用 ramp-up 测试确定系统可以支持的用户范围。确定了范围之后，以该范围内不同的并发用户负载进行一系列的 flat 测试，更精确地确定系统的容量。

渗入测试

　　渗入测试是一种比较简单的性能测试。渗入测试所需时间较长，它使用固定数目的并发用户测试系统的总体健壮性。这些测试将会通过内存泄漏、增加的垃圾收集 (GC) 或系统的其他问题，显示因长时间运行而出现的任何性能降低。测试运行的时间越久，您对系统就越了解。运行两次测试是一个好主意 —— 一次使用较低的用户负载（要在系统容量之下，以便不会出现执行队列），一次使用较高的负载（以便出现积极的执行队列）。

　　测试应该运行几天的时间，以便真正了解应用程序的长期健康状况。要确保测试的应用程序尽可能接近现实世界的情况，用户场景也要逼真（虚拟用户通过应用程序导航的方式要与现实世界一致），从而测试应用程序的全部特性。确保运行了所有必需的监控工具，以便精确地监测并跟踪问题。

峰谷测试

　　峰谷测试兼有容量规划 ramp-up 类型测试和渗入测试的特征。其目标是 确定从高负载（例如系统高峰时间的负载）恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力 。

生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷（ Software Bug ）的具体含义包括下面几个因素：

•    软件未达到客户需求的功能和性能；

•    软件超出客户需求的范围；

•    软件出现客户需求不能容忍的错误；

•    软件的使用未能符合客户的习惯和工作环境。

考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合规范，未能在特定的条件（资金、范围等）达到最佳等。可惜的是，我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。

在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。

下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。

•    测试是不完全的（测试不完全）

很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测试复杂性的一条必经之道。

•    测试具有免疫性（软件缺陷免疫性）

软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。

•    测试是 “ 泛型概念 ” （全程测试）

我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。

另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。

•   80-20 原则

80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。

80-20 原则还能反映到软件测试的自动化方面上来，实践证明 80% 的软件缺陷可以借助人工测试而发现， 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。

•    为效益而测试

为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是： Keep it simple but not too simple 。

•    缺陷的必然性

软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

•    软件测试必须有预期结果

没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般，不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的东西作为正确的结果来判断，因此常常出现误测的现象。

•    软件测试的意义 - 事后分析

软件测试的目的单单是发现缺陷这么简单吗？如果是 “ 是 ” 的话，我敢保证，类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好， “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析，我们就无法了解缺陷发生的原因和应对措施，结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜，目前大多测试团队都没有意识到这一点，测试报告中缺乏测试结果分析这一环节。

结论：

软件测试是一个需要 “ 自觉 ” 的过程，作为一个测试人员，遇事沉着，把持尺度，从根本上应对软件测试有着正确的认识，希望本文对读者对软件测试的认识有所帮助。

    交易的平均响应时间（期望值： <15s ）

    交易的最大响应时间（期望值： <30s ）

    平均每秒处理交易数量（分别记录单位时间内成功、失败和停止的交易数量）

    交易成功率 （期望值： >95% ）

    不同并发用户数的状况下的上述记录值
 

测试结果分析情况   

    单笔记录的处理时间（期望值： <15s ）

    单位时间内的处理交易笔数（期望值： >10 个）

    某个时间段内的交易处理数量

    单笔能处理的最大数据量

    在每个交易处理中最大（最耗时）的模块

    在不同数量的测试数据基础上的上述记录值
 

网络级别的测试指标   

    吞吐量：单位时间内网络传输数据量

    冲突率：在以太网上监测到的每秒冲突数
 

操作系统级别的测试指标

    进程 / 线程交换率：进程和线程之间每秒交换次数

    CPU 利用率：即 CPU 占用率（％）

    系统 CPU 利用率：系统的 CPU 占用率（％）

    用户 CPU 利用率：用户模式下的 CPU 占用率（％）

    磁盘交换率：磁盘交换速率

    中断速率： CPU 每秒处理的中断数

    读入内存页速率：物理内存中每秒读入内存页的数目

    写出内存页速率：每秒从物理内存写到页文件中的内存页数目或者从物理内存中删掉的内存页数目

    内存页交换速率：每秒写入内存页和从物理内存中读出页的个数

    进程入交换率：交换区输入的进程数目

    进程出交换率：交换区输出的进程数目
 

数据库级别的测试指标

    数据库的并发连接数：客户端的最大连接数

    数据库所资源的使用数量

from mercury