【文档说明】软件测试理论和方法(全面推荐)课件.ppt，共(580)页，6.192 MB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-45281.html

以下为本文档部分文字说明：

软件测试软件测试的目的和原则软件测试的重要性错误的分类软件测试用例设计软件测试的过程与策略软件测试种类程序的静态测试程序调试GUI测试文档测试面向对象系统的测试客户/服务器系统的测试WEB系统的测试RUP中的

测试工作流软件测试的目的和原则软件测试的目的软件测试的原则软件测试的对象测试信息流测试与软件开发各阶段的关系软件测试的目的基于不同的立场，存在着两种完全不同的测试目的。从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。从软件开发者的

角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。Myers软件测试目的(1)测试是程序的执行过程，目的在于发现错误；(2)一个好的测试用例在于能发

现至今未发现的错误；(3)一个成功的测试是发现了至今未发现的错误的测试。换言之，测试的目的是想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，我们就能够发现软件中的错误。测试的附带收获是，它能够证明软件的

功能和性能与需求说明相符合。实施测试收集到的测试结果数据为可靠性分析提供了依据。测试不能表明软件中不存在错误，它只能说明软件中存在错误。软件测试的原则1.测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立

刻开始。因此所有测试可以在任何代码被产生前进行计划和设计。应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。2.所有的测试都应追溯到用户需求。软件测试的目标在于揭示错误，而最严重的错误（从用户角度看）是那些导

致程序无法满足需求的错误。3.测试用例应由测试输入数据和对应的预期输出结果这两部分组成。4.程序员应避免检查自己的程序。5.在设计测试用例时，应包括合理的输入条件和不合理的输入条件。6.测试应从“小规模”开始，逐步转向“大规模”。从单元测

试到组装测试再到系统测试7。穷举测试是不可能的，然而充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。软件测试的原则8.Pareto原则应用于软件测试。Pareto原则暗示着测试发现的错误中80%很可能起源于程序模块中20%。因此应集

中精力孤立有疑点的模块，对其进行彻底测试，这对测试的安排很重要。9.充分注意测试中的群集现象。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。10.严格执行测试计划，排除测试的随意性。应当对每一个测试结果做全面检查。妥善保存测试计划

，测试用例，出错统计和最终分析报告，为维护提供方便。软件测试的原则软件测试的对象软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。需求分析、概要设计、详细设计以及程序编码等各阶段

所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。为把握软件开发各个环节的正确性，需要进行各种确认和验证工作。确认(Validation)，是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的

逻辑正确性。需求规格说明确认程序确认(静态确认、动态确认)验证(Verification)，试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。测试信息流测试信息流软件配置：

软件需求规格说明、软件设计规格说明、源代码等；测试配置：测试计划、测试用例、测试程序等；测试工具：测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等。测试结果分

析：比较实测结果与预期结果，评价错误是否发生。排错(调试)：对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档再测试：直到通过测试为止。通过收集和分析测试结果数

据，对软件建立可靠性模型利用可靠性分析，评价软件质量：软件的质量和可靠性达到可以接受的程度；所做的测试不足以发现严重的错误；如果测试发现不了错误，可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。这些错误最终不得不由用户在使用中

发现，并在维护时由开发者去改正。但那时改正错误的费用将比在开发阶段改正错误的费用要高出40倍到60倍。测试与软件开发各阶段的关系软件开发过程是一个自顶向下，逐步细化的过程软件计划阶段定义软件作用域软件需求分析建立软件信息域、功能和性能需求、约束等软件设计

把设计用某种程序设计语言转换成程序代码测试过程是依相反顺序安排的自底向上，逐步集成的过程。传统测试过程建立设计测试测试生命周期建立1建立2建立3建立4用户改进迭代测试测试测试测试测试需要尽早的开始设计无须“冻结”规格测试生命周期规格测

试规格1建立2建立3建立4测试规格2测试规格3测试规格4建立1测试生命周期开发生命周期...维护需求定义应用定义应用开发修订建立建立测试生命周期开发生命周期...维护需求定义应用定义应用开发修订建立建立测试生命周期..

.执行.执行执行.测试计划缺陷跟踪测试开发测试设计评估测试生命周期...执行.执行测试计划缺陷跟踪测试开发测试设计评估建立建立...执行建立测试生命周期测试计划定义测试项目的过程，以便测试项目能被正确的度量和控制。包括测试需求，测试策略，测试资源和

测试计划...执行.执行..测试计划缺陷跟踪测试开发测试设计评估建立建立...执行..建立测试生命周期测试设计为了最有效的验证测试需求被覆盖，定义自动的测试...执行..执行.测试计划缺陷跟踪测试开发测试设计评估建立建立...

执行..建立测试生命周期测试开发在测试设计期间已被定义，创建或获得自动的测试过程....执行..执行..测试计划缺陷跟踪测试开发测试设计评估建立建立...执行..建立测试生命周期测试执行运行与被测试应用的软件构造相对应的测试过程集，并记录结果日志，包括缺陷报告和测试日志。...执

行.执行.测试计划缺陷跟踪测试开发测试设计评估建立建立...执行.建立测试生命周期测试评估分析测试结果，确定是否测试标准被覆盖的过程....执行.执行.测试计划缺陷跟踪测试开发测试设计评估建立建立...执行.

建立测试生命周期缺陷跟踪初始记录测试故障或用户问题，检查测试故障以及提供解决它们的结构的过程。测试人员项目持续时间测试人员100%50%0%完成比率代码实现消除缺陷质量问题延迟上市维护的费用1x10x10

0x软件测试重要性项目持续时间100%50%0%完成比率消除缺陷消除缺陷保证软件质量缩短上市时间软件测试重要性系统性能应用性能功能可靠性100%软件测试重要性风险代码完成可靠性功能应用性能系统性能风险•越早测试越好•自动的测试•测

试每一个版本•传统的测试是在代码实现之后进行软件测试重要性程序错误分类(1)按错误的影响和后果分类较小错误：只对系统输出有一些非实质性影响。如，输出的数据格式不合要求等。中等错误：对系统的运行有局部影响。如输出的某些数据有错误或出现冗余。较严重错误：系

统的行为因错误的干扰而出现明显不合情理的现象。比如开出了0.00元的支票，系统的输出完全不可信赖。严重错误：系统运行不可跟踪，一时不能掌握其规律，时好时坏。非常严重的错误：系统运行中突然停机，其原因不明，无法软启动。最严重的错误：系统运行导致环境破坏，或是造成

事故，引起生命、财产的损失。(2)按错误的性质和范围分类。B.Beizer从软件测试观点出发，把软件错误分为5类。①功能错误规格说明错误：规格说明可能不完全，有二义性或自身矛盾。功能错误：程序实现

的功能与用户要求的不一致。这常常是由于规格说明中包含错误的功能、多余的功能或遗漏的功能所致。测试错误：软件测试的设计与实施发生错误。软件测试自身也可能发生错误。测试标准引起的错误：对软件测试的标准要选

择适当，若测试标准太复杂，则导致测试过程出错的可能就大。②系统错误外部接口错误：外部接口指如终端、打印机、通信线路等系统与外部环境通信的手段。所有外部接口之间，人与机器之间的通信都使用形式的或非形式的专门协议。如果协议有错

，或太复杂，难以理解，致使在使用中出错。此外还包括对输入／输出格式错误理解，对输入数据不合理的容错等等。内部接口错误：内部接口指程序之间的联系。它所发生的错误与程序内实现的细节有关。例如，设计协议错、输入／输出格式错、数据保护不可靠、子程序访

问错等。硬件结构错误：这类错误在于不能正确地理解硬件如何工作。例如，忽视或错误地理解分页机构、地址生成、通道容量、I／O指令、中断处理、设备初始化和启动等而导致的出错。操作系统错误：这类错误主要是由于不了解操

作系统的工作机制而导致出错。当然，操作系统本身也有错误，但是一般用户很难发现这种错误。软件结构错误：由于软件结构不合理或不清晰而引起的错误。这种错误通常与系统的负载有关，而且往往在系统满载时才出现。这是最难发现的一类错误。例如，错误

地设置局部参数或全局参数；错误地假定寄存器与存储器单元初始化了；错误地假定不会发生中断而导致不能封锁或开中断；错误地假定程序可以绕过数据的内部锁而导致不能关闭或打开内部锁；错误地假定被调用子程序常驻内存或非常驻内存等等，都将导致软件出错。控制与顺

序错误：这类错误包括：忽视了时间因素而破坏了事件的顺序；猜测事件出现在指定的序列中；等待一个不可能发生的条件；漏掉先决条件；规定错误的优先级或程序状态；漏掉处理步骤；存在不正确的处理步骤或多余的处理步骤等。

资源管理错误：这类错误是由于不正确地使用资源而产生的。例如，使用未经获准的资源；使用后未释放资源；资源死锁；把资源链接在错误的队列中等等。③加工错误算术与操作错误：指在算术运算、函数求值和一般操作过程中发生的错误。包括：数据类型转换

错；除法溢出；错误地使用关系比较符；用整数与浮点数做比较等。初始化错误：典型的错误有：忘记初始化工作区，忘记初始化寄存器和数据区；错误地对循环控制变量赋初值；用不正确的格式，数据或类型进行初始化等等。控制和次序错误：这类错误与系统级同名错误类似，但它是局部错误。包括：遗漏

路径；不可达到的代码；不符合语法的循环嵌套；循环返回和终止的条件不正确；漏掉处理步骤或处理步骤有错等。静态逻辑错误：这类错误主要包括：不正确地使用CASE语句；在表达式中使用不正确的否定（例如用“＞”代替“＜”的否定）；对情况不适当地分解与组合；混淆“或”与“异或”等。④数据错误动态

数据错误：动态数据是在程序执行过程中暂时存在的数据。各种不同类型的动态数据在程序执行期间将共享一个共同的存储区域，若程序启动时对这个区域未初始化，就会导致数据出错。由于动态数据被破坏的位置可能与出错的位置在距离上相差很远，因

此要发现这类错误比较困难。静态数据错误：静态数据在内容和格式上都是固定的。它们直接或间接地出现在程序或数据库中。由编译程序或其它专门程序对它们做预处理。这是在程序执行前防止静态错误的好办法，但预处理也会出错。数据内容错误：数据内容是指存储于存储单

元或数据结构中的位串、字符串或数字。数据内容本身没有特定的含义，除非通过硬件或软件给予解释。数据内容错误就是由于内容被破坏或被错误地解释而造成的错误。数据结构错误：数据结构是指数据元素的大小和组织形式。在同一存储区域中可以定义不同的数据结构。数据结构错误主要包括结构说明错误及把一个数据结构误当

做另一类数据结构使用的错误。这是更危险的错误。数据属性错误：数据属性是指数据内容的含义或语义。例如，整数、字符串、子程序等等。数据属性错误主要包括：对数据属性不正确地解释，比如错把整数当实数，允许不同类型数据混合运算而导致的错误等。

⑤代码错误，主要包括语法错误打字错误对语句或指令不正确理解所产生的错误。(3)按软件生存期阶段分类，Gerhart分类方法把软件的逻辑错误按生存期不同阶段分为4类。①问题定义（需求分析）错误：它们是在软件定义阶段，分析员研究用户的要求后所编写的文档中出现的错误。换句话说，这类错误是由于

问题定义不满足用户的要求而导致的错误。②规格说明错误：这类错误是指规格说明与问题定义不一致所产生的错误。它们又可以细分成：不一致性错误：规格说明中功能说明与问题定义发生矛盾。冗余性错误：规格说明中某些功能说明与问题定义相比是多余的。不完整性错误：规格说明中缺少某

些必要的功能说明。不可行错误：规格说明中有些功能要求是不可行的。不可测试错误：有些功能的测试要求是不现实的。③设计错误：这是在设计阶段产生的错误，它使系统的设计与需求规格说明中的功能说明不相符。它们

又可以细分为：设计不完全错误：某些功能没有被设计，或设计得不完全。算法错误：算法选择不合适。主要表现为算法的基本功能不满足功能要求、算法不可行或者算法的效率不符合要求。模块接口错误：模块结构不合理；模块与外部数据库的界面不一致，

模块之间的界面不一致。控制逻辑错误：控制流程与规格说明不一致；控制结构不合理。数据结构错误：数据设计不合理；与算法不匹配；数据结构不满足规格说明要求。④编码错误：编码过程中的错误是多种多样的，大体可

归为以下几种：数据说明错、数据使用错、计算错、比较错、控制流错、界面错、输入／输出错，及其它的错误。在不同的开发阶段，错误的类型和表现形式是不同的，故应当采用不同的方法和策略来进行检测。测试用例设计两种常用的测试方法黑盒测试白盒测试黑盒测试这种方法是把测试对象看做一个黑盒

子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能测试或数据驱动测试。黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误:是否有不正确或遗漏了的功能?在接口上，输入能否正确地接受?能否输出正

确的结果?是否有数据结构错误或外部信息(例如数据文件)访问错误?性能上是否能够满足要求?是否有初始化或终止性错误?用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。但这是不可能的。假

设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：可能采用的测试数据组：232×232＝264如果测试一组数据需要1毫秒，一年工作365×24小时，完成所有测试需5亿年。白盒

测试此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结

构测试或逻辑驱动测试。软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：对程序模块的所有独立的执行路径至少测试一次；对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；在循环的边界

和运行界限内执行循环体；测试内部数据结构的有效性，等。对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字。给出一个小程序的流程图，它包括了一个执行20次的循环。包含的不同执行路径数达520条，

对每一条路径进行测试需要1毫秒，假定一年工作365×24小时，要想把所有路径测试完，需3170年。为什么进行白盒测试？一个合理的问题：“我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？”，换一种说法，我们为什么

不将所有的精力用于黑盒测试呢？答案在于软件的自身缺陷：逻辑错误和不正确的假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们的工作中。我们经

常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试能发现这种错误。；印刷上的错误是随机的。程序员可能会

产生某些拼写错误，绝大多数可以在编译时被发现，但是，有些在测试时才会被发现。黑盒测试，不管它多全面，都可能忽略前面提到的某些类型的错误“错误潜伏在角落里，聚集在边界上”。白盒测试更可能发现它们！逻辑覆盖语句覆盖判定覆盖条件覆盖判定－条件覆盖条件组合覆盖路径覆盖。逻辑覆盖是以程序内部

的逻辑结构为基础的设计测试用例的技术。它属白盒测试。(A>1)and(B=0)(A=2)or(X>1)X=X/AX=X+1TTFFabdceL1(ace)={(A>1)and(B=0)}and{(A=2)or(X/A>1)}=(A>1)and(B=0)and(A=2)o

r(A>1)and(B=0)and(X/A>1)=(A=2)and(B=0)or(A>1)and(B=0)and(X/A>1)L2(abd)=not{(A>1)and(B=0)}andnot{(A=2)or

(X>1)}={not(A>1)ornot(B=0)}and{not(A=2)andnot(X>1)}=not(A>1)andnot(A=2)andnot(X>1)ornot(B=0)andnot(A=2)andnot(X>1)L3(abe)=not{(A>1)and(B=0)}and{

(A=2)or(X>1)}={not(A>1)ornot(B=0)}and{(A=2)or(X>1)}=not(A>1)and(A=2)ornot(A>1)and(X>1)ornot(B=0)and(A=2)ornot(B=0)and(X>1)L4(acd)={(A>1)and(B=

0)}andnot{(A=2)or(X/A>1)}=(A>1)and(B=0)andnot(A=2)andnot(X/A>1)语句覆盖语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一

次。这种覆盖又称为点覆盖，它使得程序中每个可执行语句都得到执行，但它是最弱的逻辑覆盖准，效果有限，必须与其它方法交互使用。在图例中，正好所有的可执行语句都在路径L1上，所以选择路径L1设计测试用例，就可以覆

盖所有的可执行语句。测试用例的设计格式如下【输入的(A,B,X)，输出的(A,B,X)】为图例设计满足语句覆盖的测试用例是:【(2,0,4)，(2,0,3)】覆盖ace【L1】(A=2)and(B=0)or(A>1)and(B=0)and(X/A>1)判定覆盖判定覆盖就是设计若干个测试

用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖。判定覆盖只比语句覆盖稍强一些，但实际效果表明，只是判定覆盖，还不能保证一定能查出在判断的条件中存在的错误。因此，

还需要更强的逻辑覆盖准则去检验判断内部条件。对于图例，如果选择路径L1和L2，就可得满足要求的测试用例:【(2,0,4)，(2,0,3)】覆盖ace【L1】【(1,1,1)，(1,1,1)】覆盖abd【L2】(A=2)and(B=0)or

(A>1)and(B=0)and(X/A>1)not(A>1)andnot(A=2)andnot(X>1)ornot(B=0)andnot(A=2)andnot(X>1)如果选择路径L3和L4，还可得另一组可用的测试用例:【(2,1,1)，(2,1,2)】覆盖abe【L3】【(

3,0,3)，(3,1,1)】覆盖acd【L4】not(A>1)and(X>1)ornot(B=0)and(A=2)ornot(B=0)and(X>1)(A>1)and(B=0)andnot(A=2)a

ndnot(X/A>1)条件覆盖条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。条件覆盖深入到判定中的每个条件，但可能不能满足判定覆盖的要求。在图例中，我们事先可对所有条件的取值加以标记。例如，对于第一个判断：

条件A＞1取真为，取假为条件B＝0取真为，取假为T1T1T2T2对于第二个判断：条件A＝2取真为，取假为条件X＞1取真为，取假为测试用例覆盖分支条件取值【(2,0,4)，(2,0,3)】L1(c,e)【(1,0,

1)，(1,0,1)】L2(b,d)【(2,1,1)，(2,1,2)】L3(b,e)或T3T3T4T4TTTT12344321TTTTTTTT1234测试用例覆盖分支条件取值【(1,0,3)，(1,0,4)】L3(b,e)【(2,1,1)，(2,1,2)】L3(b,e)TTTT1234TTTT

1234判定－条件覆盖判定－条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，每个判断中的每个条件的可能取值至少执行一次。换言之，即是要求各个判断的所有可能的条件取值组合至少执行一次。判定－条件覆盖有缺陷。从表面上来看，它

测试了所有条件的取值。但是事实并非如此。往往某些条件掩盖了另一些条件。会遗漏某些条件取值错误的情况。为彻底地检查所有条件的取值，需要将判定语句中给出的复合条件表达式进行分解，形成由多个基本判定嵌套的流程图。这样就可以有效地检查所有的条件是否正确了。测试用例覆盖分支条件取值【(2,0,

4)，(2,0,3)】L1(c,e)【(1,1,1)，(1,1,1)】L2(b,d)TTTT1234TTTT1234(A=2)and(B=0)or(A>1)and(B=0)and(X/A>1)not(A>1)andnot(A=2)andnot(X>1)

ornot(B=0)andnot(A=2)andnot(X>1)andorA>1TB=0TX=X/ATFFA=2TFX>1FX=X+1改为单个条件判定的嵌套结构条件组合覆盖条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件

取值组合至少执行一次。这是一种相当强的覆盖准则，可以有效地检查各种可能的条件取值的组合是否正确。它不但可覆盖所有条件的可能取值的组合，还可覆盖所有判断的可取分支，但可能有的路径会遗漏掉。测试还不完全。记①A＞1,B＝0作②A＞1,B≠0作

③A≯1,B＝0作④A≯1,B≠0作TT12TT12TT12TT12⑤A＝2,X＞1作⑥A＝2,X≯1作⑦A≠2,X＞1作⑧A≠2,X≯1作测试用例覆盖条件覆盖组合【(2,0,4),(2,0,3)】(L1)①,⑤【(2,1,1),(2,1,2)】(L3)②,

⑥【(1,0,3),(1,0,4)】(L3)③,⑦【(1,1,1),(1,1,1)】(L2)④,⑧TT34TT34TT34TT34TTTT1234TTTT1234TTTT1234TTTT1234L4被漏掉了！路径测试路径测试就是设计足

够的测试用例，覆盖程序中所有可能的路径。这是最强的覆盖准则。但在路径数目很大时，真正做到完全覆盖是很困难的，必须把覆盖路径数目压缩到一定限度。测试用例通过路径覆盖条件【(2,0,4),(2,0,3)】ace(L1)【(1,1,1),(1,1,1)】abd(L2)【(1

,1,2),(1,1,3)】abe(L3)【(3,0,3),(3,0,1)】acd(L4)TTTT1234TTTT1234TTTT1234TTTT3412条件测试路径选择当程序中判定多于一个时，形成的分支结构可以分为两类：嵌套型分支结构和连锁型分支结构。对于

嵌套型分支结构，若有n个判定语句，需要n+1个测试用例；对于连锁型分支结构，若有n个判定语句，需要有2n个测试用例，覆盖它的2n条路径。条件测试路径选择为减少测试用例的数目，可采用试验设计法，抽取部分路径进行测试。由于抽样服从均匀分布，因

此，在假定各条路径的重要性相同，或暂不明确各条路径的重要性的情况下可以做到均匀抽样。如果明确了各条路径的重要性，还可以采取加权的办法，筛选掉部分路径，再用如下的措施进行抽样。具体步骤如下：ⅰ）设连锁型分支结构中有n个判定，计算满足关系式n+1≤2m的最小自然数m；ⅱ）设

t=2m，取正交表Lt，并利用它设计测试数据。条件测试路径选择例如，一个连锁型分支结构中有三个判定语句P1，P2，P3。它全部路径是23＝8条。先计算3+1≤2m=t的t，得t=4。取正交表L4，如图所示把每一列当做一个判定，每一行当做可取的测试用例，则正交表L4最多可取三个判

定，分别代之以P1，P2，P3。判定P1，P2，P3的取假分支和取真分支分别记作S1、S2；S3、S4；S5、S6，用各个判定的取假分支取代正交表L4中的“0”，用取真分支取代正交表中的“1”，就建立起一个测试路径矩阵，如图所示。测试路径数目从23＝8条减少到3

＋1＝4条。条件测试路径选择正交表L4路径抽样矩阵条件测试的策略程序中的条件分为简单条件和复合条件。简单条件是一个布尔变量或一个关系表达式（可加前缀NOT）复合条件由简单条件通过逻辑运算符（AND、OR、NOT）和括号连接而成。如果条件出错，至

少是条件中某一成分有错。条件中可能的出错类型有：布尔运算符错、布尔变量错、布尔括号错、关系运算符错、算术表达式错。如果在一个判定的复合条件表达式中每个布尔变量和关系运算符最多只出现一次，而且没有公共变量，应用一种称之为BRO（分支与关系运算符）的测试法可以发现多个布尔运算符或关系

运算符错，以及其它错误。条件测试的策略BRO策略引入条件约束的概念。设有n个简单条件的复合条件C，其条件约束为D=（D1,D2,…,Dn），其中Di（1≤i≤n）是条件C中第i个简单条件的输出约束。如果在C的执行过程中，其每个简单条件的输出都满足D中对应的约束，则称条件C的条件约束D由C的执

行所覆盖。特别地，布尔变量或布尔表达式的输出约束必须是真（t）或假（f）；关系表达式的输出约束为符号>、=、<。设条件为C1:B1&B2，其中B1、B2是布尔变量，C1的输出约束为（D1,D2），在此，D1和D2或为t或为f。则（

t,f）是C1可能的一个约束。覆盖此约束的测试（一次运行）将令B1为t，B2为f。条件测试的策略BRO策略要求对C1的可能约束集合{(t,t),(f,t),(t,f)}中的每一个，分别设计一组测试用例。如果布尔运算符有错，这三组测试用例

的运行结果必有一组导致C1失败。设条件为C2:B1&(E3=E4)，其中B1是布尔表达式，E3和E4是算术表达式，C2的输出约束为（D1,D2），在此，D1或为t或为f；D2则是<、=或>。因此，只有D2与C1中D2的不同，可以修改C1的约束集合{(t,t),(

f,t),(t,f)}，导出C2的约束集合。因为在(E3=E4)中，"t"相当于"="，"f"相当于"<"或">"，则C2的约束集合为{(t,=),(f,=),(t,<),(t,>)}。据此设计4组测试用例，检查C

2中可能的布尔或关系运算符中的错误。条件测试的策略设条件为C3:(E1>E2)&(E3=E4)，其中E1、E2、E3、E4都是算术表达式，C3的输出约束为（D1,D2），在此，D1和D2的约束均为<、=、>。C3中只有D1

与C2中的D1不同，可以修改C2的约束集合{(t,=),(f,=),(t,<),(t,>)}，导出C3的约束集合。因为在(E1>E2)中，"t"相当于">"，"f"相当于"<"或"="，则C3的约束集合为{(

>,=),(<,=),(=,=),(>,<),(>,>)}。根据这个约束集合设计测试用例，就能够检测C3中的关系运算符中的错误。循环测试路径选择循环分为4种不同类型：简单循环连锁循环嵌套循环非结构循环。(1)简单循环

对于简单循环，测试应包括以下几种。其中的n表示循环允许的最大次数。①零次循环：从循环入口到出口②一次循环：查找循环初始值方面的错误③二次循环：检查在多次循环时才能暴露的错误。④m次循环：此时

的m＜n，也是检查在多次循环时才能暴露的错误。⑤最大次数循环、比最大次数多一次、少一次的循环。例：求最小值k=i;for(j=i+1;j<=n;j++)if(A[j]<A[k])k=j;k=i;j=i+1;j

<=n?A[j]<A[k]?k=jj++fdcabe循环inA[i]A[i+1]A[i+2]k路径01211iac1212iabefc21i+1abdfc13123iabefefc231i+2abefdfc

321i+2abdfdfc312i+1abdfefcd改改kk的的值值，，ee不不改改kk的的值值测试用例选择对于嵌套循环，不能将简单循环的测试方法简单地扩大到嵌套循环，因为可能的测试数目将随嵌套层次的增加呈几何倍数增长。这可能导致一个天文数字的测试数目。下

面给出一种有助于减少测试数目的测试方法。①对最内层循环做简单循环的全部测试。所有其它层的循环变量置为最小值；②逐步外推，对其外面一层循环进行测试。测试时保持所有外层循环的循环变量取最小值，所有其它嵌套内层循环的循环变量取“典型”值。③反复

进行，直到所有各层循环测试完毕。④对全部各层循环同时取最小循环次数，或者同时取最大循环次数(2)嵌套循环•要区别两种情况：•如果各个循环互相独立，则连锁循环可以用与简单循环相同的方法进行测试。例如，有两个循环处于连锁状态，则前一个循环的循环变量的值就可以做为后一个循环的初值。•但如果几个循环

不是互相独立的，则需要使用测试嵌套循环的办法来处理。•对于非结构循环，应该使用结构化程序设计方法重新设计测试用例。(3)连锁循环基本路径测试基本路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。它是在程序控制流图的基础上

，分析控制构造的环路复杂性，导出基本可执行路径集合，设计测试用例的方法。设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。1.程序的控制流图符号○为控制流图的一个结点，表示一个或多个无分支的

PDL语句或源程序语句。箭头为边，表示控制流的方向。在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。如果判断中的条件表达式是由一个或多个逻辑

运算符(OR,AND,...)连接的复合条件表达式，则需改为一系列只有单个条件的嵌套的判断。2.程序环路复杂性程序的环路复杂性给出了程序基本路径集中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。从控制流图来看，一条独立路径是至少包含有一条在其它独立

路径中从未有过的边的路径。例如，在图示的控制流图中，一组独立的路径是path1：1-11path2：1-2-3-4-5-10-1-11path3：1-2-3-6-8-9-10-1-11path4：1-2-3-6-7-

9-10-1-11路径path1，path2，path3，path4组成了控制流图的一个基本路径集。只要设计出的测试用例能够确保这些基本路径的执行，就可以使得程序中的每个可执行语句至少执行一次，每个条件的取真和取假分支也能得到测试。基本路径集不是唯一的，对

于给定的控制流图，可以得到不同的基本路径集。通常环路复杂性可用以下三种方法求得：将环路复杂性定义为控制流图中的区域数。设E为控制流图的边数，N为图的结点数，则定义环路复杂性为V(G)＝E－N＋2。若设P为控制流图中的判定结点数，则有V(G)

＝P＋1。因为图所示控制流图有4个区域。其环路复杂性为4。它是构成基本路径集的独立路径数的上界。可以据此得到应该设计的测试用例的数目。3.导出测试用例导出测试用例，确保基本路径集中的每一条路径的执行。根

据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到—用逻辑覆盖方法。每个测试用例执行之后，与预期结果进行比较。如果所有测试用例都执行完毕，则可以确信程序中所有的可执行语句至少被执行了一次。必须注意，一些独立的路径(如例中的路径1)，往往不是完全孤立的，有时它是程序

正常的控制流的一部分，这时，这些路径的测试可以是另一条路径测试的一部分。黑盒测试的测试用例设计等价类划分边界值分析错误推测法因果图等价类划分等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考

虑程序的内部结构，只依据程序的规格说明来设计测试用例。由于不可能用所有可以输入的数据来测试程序，而只能从全部可供输入的数据中选择一个子集进行测试。如何选择适当的子集，使其尽可能多地发现错误。解决的办法之一就是等价类划分。首先把数目极多的输入数据（有效的

和无效的）划分为若干等价类。所谓等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等价于对这一类其它值的测试。因此，我们可以把全部输入数据合理划分为若干等价类，在每一个等价类中取

一个数据做为测试的输入条件，就可用少量代表性测试数据，取得较好的测试效果。使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。划分等价类等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都

是等效的。测试某等价类的代表值就等价于对这一类其它值的测试。等价类的划分有两种不同的情况：①有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。②无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。在设计测试用例时，要同时考虑有效等价类和

无效等价类的设计。软件不能都只接收合理的数据，还要经受意外的考验，接受无效的或不合理的数据，这样获得的软件才能具有较高的可靠性。划分等价类等价类的原则。（1）按区间划分：如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等

价类和两个无效等价类。例如，在程序的规格说明中，对输入条件有一句话：“……项数可以从1到999……”则有效等价类是“1≤项数≤999”两个无效等价类是“项数＜1”或“项数＞999”。在数轴上表示成:(2)按数值

集合划分：如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。例如，在Pascal语言中对变量标识符规定为“以字母打头的……串”。那么所有以字母打头的构成有效等价类，而不在

此集合内（不以字母打头）的归于无效等价类。(3)按数值划分：如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。这时可为每一个输入值确立一个有效等价类，此外针对这组值确立一个无效等价类，它是所有不允许的输入值的集合。例如，在教师上岗方案中规定对教授、副教授、讲师和助教分别

计算分数，做相应的处理。因此可以确定4个有效等价类为教授、副教授、讲师和助教，一个无效等价类，它是所有不符合以上身分的人员的输入值的集合。(4)按限制条件或规则划分：如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从

不同角度违反规则）。例如，Pascal语言规定“一个语句必须以分号‘;’结束”。这时，可以确定一个有效等价类“以‘;’结束”，若干个无效等价类“以‘:’结束”、“以‘,’结束”、“以‘’结束”、“以LF结束”等。确立测试用例在确立了等价类之后，建立等价类表，列出所有划分出的等价

类。再从划分出的等价类中按以下原则选择测试用例：(1)为每一个等价类规定一个唯一编号；(2)设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；(3)设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无

效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。用等价类划分法设计测试用例的实例在某一PASCAL语言版本中规定：“标识符是由字母开头，后跟字母或数字的任意组合构成。有效字符数为8个，最大字符数为80个。”并且规定：“标识符

必须先说明，再使用。”“在同一说明语句中，标识符至少必须有一个。”用等价类划分方法，建立输入等价类表:下面选取了9个测试用例，它们覆盖了所有的等价类。①VARx，T1234567：REAL；BEGINx:=3.414；T

1234567:=2.732；...…(1),(2),(4),(8),(9),(12),(14)②VAR：REAL；(3)③VARx，：REAL;(5)④VART12345678：REAL；(6)⑤VART12345......：REAL；(7)多于8

0个字符⑥VART$：CHAR；(10)⑦VARGOTO：INTEGER；(11)⑧VAR2T：REAL；(13)⑨VARPAR：REAL；(15)BEGIN......PAP:=SIN(3.14*0.8)/6；边界值分析边界值分析也是一种黑盒测试方法，是对等价类

划分方法的补充。人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。比如，在做三角形计算时，要输入三角形的三个边长：A、B和C。我们应注意到这三个数值

应当满足A＞0、B＞0、C＞0、A＋B＞C、A＋C＞B、B＋C＞A，才能构成三角形。但如果把六个不等式中的任何一个大于号“＞”错写成大于等于号“≥”，那就不能构成三角形。问题恰出现在容易被疏忽的边界附近。这里所说的边界是指，相当于输入等价类和

输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。使用边界值分析方法设计测试用例，首先应确定边界情况。应当选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做

为测试数据。边界值分析方法是最有效的黑盒测试方法，但当边界情况很复杂的时候，要找出适当的测试用例还需针对问题的输入域、输出域边界，耐心细致地逐个考虑。错误推测法人们也可以靠经验和直觉推测程序中可能存在的各

种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。例如，输入数据为0，或输出数据为0是容易发生错误的情形，因此可选择输入数据为0，或使输出数据为0的例子作为测试用例。又例如，

输入表格为空或输入表格只有一行，也是容易发生错误的情况。可选择表示这种情况的例子作为测试用例。再例如，可以针对一个排序程序，输入空的值（没有数据）、输入一个数据、让所有的输入数据都相等、让所有输入数据有序排列、让所有输入数据逆序排列

等，进行错误推测。因果图前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系。如果在测试时必须考虑输入条件的各种组合，可能的组合数将是天文数字。因此必须考虑使用一种适合于描述对于多种条件的组合，相应产生多个动作

的形式来考虑设计测试用例，这就需要利用因果图。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。用因果图生成测试用例的基本步骤(1)分析软件规格说明描述中，哪些是原因(即输入条件或输入条件的等价类)，哪些是结果(即

输出条件)，并给每个原因和结果赋予一个标识符。(2)分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系?根据这些关系，画出因果图。(3)由于语法或环境限制，有些原因与原因之间，原因与结果之

间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。(4)把因果图转换成判定表。(5)把判定表的每一列拿出来作为依据，设计测试用例。在因果图中出现的基本符号通常在因果图中用Ci表示原因，用Ei表示结果，各结点表示状态，可取值“0”或“1”。“0”表示某

状态不出现，“1”表示某状态出现。主要的原因和结果之间的关系有:表示约束条件的符号为了表示原因与原因之间，结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束条件的符号。例如，有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角钱或1

元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。”(

1)分析这一段说明，列出原因和结果原因:1.售货机有零钱找2.投入1元硬币3.投入5角硬币4.押下橙汁按钮5.押下啤酒按钮建立中间结点，表示处理中间状态11.投入1元硬币且押下饮料按钮12.押下〖橙汁〗或〖啤酒〗的按钮13.应当找5角零钱并且售货机有零钱找14.钱已

付清结果：21.售货机〖零钱找完〗灯亮22.退还1元硬币23.退还5角硬币24.送出橙汁饮料25.送出啤酒饮料(2)画出因果图。所有原因结点列在左边，所有结果结点列在右边。(3)由于2与3，4与5不能同时发生

，分别加上约束条件E。(4)因果图(5)转换成判定表由因果图得到的判定表在判定表中，阴影部分表示因违反约束条件的不可能出现的情况，删去。第16列与第32列因什么动作也没做，也删去。最后可根据剩下的16列作为确定测试用例的依

据。因果图方法是一个非常有效的黑盒测试方法，它能够生成没有重复性的且发现错误能力强的测试用例，而且对输入、输出同时进行了分析。黑盒测试方法选择的综合策略Myers提出了使用各种测试方法的综合策略:在任何情况下都必须使用边界值分

析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。必要时用等价类划分方法补充一些测试用例用错误推测法再追加一些测试用例。对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。如果程序的功能说明中含有输入条件的

组合情况，则一开始就可选用因果图法。软件测试的过程与策略测试过程按4个步骤进行：开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。组装测试把

已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。系统测试把已经经过确认的软件纳

入实际运行环境中，与其它系统成份组合在一起进行测试。严格地说，系统测试已超出了软件工程的范围单元测试(UnitTesting)单元测试又称模块测试，是针对软件设计的最小单位─程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设

计测试用例。多个模块可以平行地独立进行单元测试。1.单元测试的内容在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。(1)模块接口测试在

单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：调用本模块的输入参数是否正确；本模块调用子模块时输入给子模块的参数是否正确；全局量的定义在各模块中是否一致；在做内外存交换时要考虑：

文件属性是否正确；OPEN与CLOSE语句是否正确；缓冲区容量与记录长度是否匹配；在进行读写操作之前是否打开了文件；在结束文件处理时是否关闭了文件；正文书写／输入错误，I／O错误是否检查并做了处理。(2)局部数据结构测试不正确或不一致的

数据类型说明使用尚未赋值或尚未初始化的变量错误的初始值或错误的缺省值变量名拼写错或书写错不一致的数据类型全局数据对模块的影响(3)路径测试选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致

的错误。对基本执行路径和循环进行测试可以发现大量的路径错误。(4)错误处理测试出错的描述是否难以理解出错的描述是否能够对错误定位显示的错误与实际的错误是否相符对错误条件的处理正确与否在对错误进行处理之前，错误条件是否已经引起系统的干预等(5)边界测试注意数据流、控制流中

刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因

素。2.单元测试的步骤通常单元测试在编码阶段进行。在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。模块并不是一

个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。驱动模块(driver)：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。桩模块(stub)──存根

模块：用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。单元测试的测试环境如果一个模块要完成多种功能，且以程序包或对象类的形式出现，例如Ada中的包，MODULA中的模

块，C++中的类。可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准例程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测

试。组装测试（IntegratedTesting）组装测试(集成测试、联合测试）通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：在把各个模块连接起来的时侯，

穿越模块接口的数据是否会丢失；一个模块的功能是否会对另一个模块的功能产生不利的影响；各个子功能组合起来，能否达到预期要求的父功能；全局数据结构是否有问题；单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。在单元测试的

同时可进行组装测试，发现并排除在模块连接中可能出现的问题，最终构成要求的系统。子系统的组装测试特别称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。通常，把模块组装成为系统的方式有两种一次性组装方式

增殖式组装方式1一次性组装方式(bigbang)它是一种非增殖式组装方式。也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。由于程序中不可避免地存在涉及模块间接口、

全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。2.增殖式组装方式这种组装方式又称渐增式组装首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统在组装的过程中边连接边测试，以发现连接过程中产生的问题通过增殖逐步组装成为要求的软件系统。(1)自顶向下

的增殖方式这种组装方式将模块按系统程序结构，沿控制层次自顶向下进行组装。自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序结构中，判断常出现在较高的层次，较早就能遇到。如果主要控制有问

题，尽早发现它能够减少以后的返工。选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。(2)自底向上的增殖方式这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块

的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能将是十分困难的。同时涉及

复杂算法和真正输入／输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，导致过多的回归测试。自顶向下增殖方式的优点是能够较早地发现在主要控制方面的问题。自底向上增殖方式的缺点是“程序一直未能做为一个实体存在，直到最后一个模块加上去

后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。自底向上增殖方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入／输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施

多个模块的并行测试。(3)混合增殖式测试衍变的自顶向下的增殖测试首先对输入／输出模块和引入新算法模块进行测试;再自底向上组装成为功能相当完整且相对独立的子系统;然后由主模块开始自顶向下进行增殖测试。自底向上自顶向下的增殖测试首先对含读操作的子系统自底向上直至根结点模

块进行组装和测试;然后对含写操作的子系统做自顶向下的组装与测试。回归测试这种方式采取自顶向下的方式测试被修改的模块及其子模块;然后将这一部分视为子系统，再自底向上测试。以检查该子系统与其上级模块的接口是否适配。关键模块问题在

组装测试时，应当确定关键模块，对这些关键模块及早进行测试。关键模块的特征：①满足某些软件需求；②在程序的模块结构中位于较高的层次（高层控制模块）；③较复杂、较易发生错误；④有明确定义的性能要求。确认测试（Validat

ionTesting）确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。1.进行有效性测

试（黑盒测试）有效性测试是在模拟的环境(可能就是开发的环境)下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。通过实施预定的测试计划和测试步骤，确定软件的特性是否与需求相符，确保所有的软件功能

需求都能得到满足，所有的软件性能需求都能达到，所有的文档都是正确且便于使用。同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试，确认是否满足。在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：测试结果

与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。2.软件配置复查

软件配置复查的目的是保证软件配置的所有成分都齐全；各方面的质量都符合要求；具有维护阶段所必需的细节；而且已经编排好分类的目录。除了按合同规定的内容和要求，由人工审查软件配置之外，在确认测试的过程中，应当严格遵守用户手册和操作手册中规定的使用步骤，以便检

查这些文档资料的完整性和正确性。必须仔细记录发现的遗漏和错误，并且适当地补充和改正。验收测试（AcceptanceTesting）在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。验收测试是以用户为主的

测试。软件开发人员和QA（质量保证）人员也应参加。由用户参加设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果。一般使用生产中的实际数据进行测试。在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误

的恢复功能等进行确认。确认测试应交付的文档有：确认测试分析报告最终的用户手册和操作手册项目开发总结报告。系统测试（SystemTesting）系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件

、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较,发现软件与系统的定义不符合或与之矛盾的地方。系统测试的测试用例应根据需求分析规格说明来设计，并在实际使用环境下来运行。α测试和β测试在软件交付

使用之后，用户将如何实际使用程序，对于开发者来说是无法预测的。因为用户在使用过程中常常会发生对使用方法的误解、异常的数据组合、以及产生对某些用户来说似乎是清晰的但对另一些用户来说却难以理解的输出等等。如果软件是为多个用户开

发的产品的时侯，让每个用户逐个执行正式的验收测试是不切实际的。很多软件产品生产者采用一种称之为α测试和β测试的测试方法，以发现可能只有最终用户才能发现的错误。α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实

际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。尤其注重产品的界面和特色。α测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，

也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应事先准备好。α测试β测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境

下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。开发者在综合用户的报告之后，做出修改，最后将软件产品交付给全体用户使用。β测试β测试主要衡量产品的FLURPS。

着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当α测试达到一定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。由于β测试的主要目标是测试可支持性，所以β测试应尽可能由主

持产品发行的人员来管理。测试种类软件测试是由一系列不同的测试组成。主要目的是对以计算机为基础的系统进行充分的测试。功能测试功能测试是在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严

重错误。可靠性测试如果系统需求说明书中有对可靠性的要求，则需进行可靠性测试。①平均失效间隔时间MTBF(MeanTimeBetweenFailures)是否超过规定时限?②因故障而停机的时间MTTR(MeanTimeToRepairs)在一年中应

不超过多少时间。强度测试强度测试是要检查在系统运行环境不正常乃至发生故障的情况下，系统可以运行到何种程度的测试。例如：把输入数据速率提高一个数量级，确定输入功能将如何响应。设计需要占用最大存储量或其它资源的测试用例进行测试。设计出在虚拟存储管理机制中引起“颠簸”的测试用例进行测试。设计出

会对磁盘常驻内存的数据过度访问的测试用例进行测试。强度测试的一个变种就是敏感性测试。在程序有效数据界限内一个小范围内的一组数据可能引起极端的或不平稳的错误处理出现，或者导致极度的性能下降的情况发生。此测试用以发现可能引起这种不稳定性或不正常处理的某些数据

组合。性能测试性能测试是要检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统。性能测试常常需要与强度测试结合起来进行，并常常要求同时进行硬件和软件检测。通常，对软件性能的检测表现在以下几个方面：响应时间、吞吐量、辅助存储区，例如缓冲区，工作区的大小等、处理

精度，等等。恢复测试恢复测试是要证实在克服硬件故障(包括掉电、硬件或网络出错等)后，系统能否正常地继续进行工作，并不对系统造成任何损害。为此，可采用各种人工干预的手段，模拟硬件故障，故意造成软件出错。并由此检查：错误探测功能──系统能否发现硬

件失效与故障；能否切换或启动备用的硬件；在故障发生时能否保护正在运行的作业和系统状态；在系统恢复后能否从最后记录下来的无错误状态开始继续执行作业，等等。掉电测试：其目的是测试软件系统在发生电源中断时能否

保护当时的状态且不毁坏数据，然后在电源恢复时从保留的断点处重新进行操作。启动／停止测试这类测试的目的是验证在机器启动及关机阶段，软件系统正确处理的能力。这类测试包括反复启动软件系统(例如，操作系统自举、网络的启动、应用程序的调用等)在尽可能多的情况下关机。配置测试这类测试是要检

查计算机系统内各个设备或各种资源之间的相互联结和功能分配中的错误。它主要包括以下几种：配置命令测试：验证全部配置命令的可操作性（有效性）；特别对最大配置和最小配置要进行测试。软件配置和硬件配置都要测试。循环配置测

试：证明对每个设备物理与逻辑的，逻辑与功能的每次循环置换配置都能正常工作。修复测试：检查每种配置状态及哪个设备是坏的。并用自动的或手工的方式进行配置状态间的转换。安全性测试安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。力图破坏系统的保护机构以进入系统的

主要方法有以下几种：正面攻击或从侧面、背面攻击系统中易受损坏的那些部分；以系统输入为突破口，利用输入的容错性进行正面攻击；申请和占用过多的资源压垮系统，以破坏安全措施，从而进入系统；故意使系统出错，利用系统恢复的过程，窃取用户口令及其它有用的信息；通

过浏览残留在计算机各种资源中的垃圾（无用信息），以获取如口令，安全码，译码关键字等信息；浏览全局数据，期望从中找到进入系统的关键字；浏览那些逻辑上不存在，但物理上还存在的各种记录和资料等。可使用性测试可使用性测试主要从使用的合理性和方便性等角度对软件系统

进行检查，发现人为因素或使用上的问题。要保证在足够详细的程度下，用户界面便于使用；对输入量可容错、响应时间和响应方式合理可行、输出信息有意义、正确并前后一致；出错信息能够引导用户去解决问题；软件文档全面、正规、确切。可支持性测试这类测试是要验证系统的支持策略对于公司与用户方面是否切实

可行。它所采用的方法是试运行支持过程(如对有错部分打补丁的过程，热线界面等)；对其结果进行质量分析；评审诊断工具；维护过程、内部维护文档；修复一个错误所需平均最少时间。安装测试安装测试的目的不是找软件错误，而是找安装错误。在安装软件系统时，会有多种选择。要分配和装入

文件与程序库布置适用的硬件配置进行程序的联结。而安装测试就是要找出在这些安装过程中出现的错误。安装测试是在系统安装之后进行测试。它要检验：用户选择的一套任选方案是否相容；系统的每一部分是否都齐全；所有文件是否都已产生并确有所需要的内

容；硬件的配置是否合理，等等。过程测试在一些大型的系统中，部分工作由软件自动完成，其它工作则需由各种人员，包括操作员，数据库管理员，终端用户等，按一定规程同计算机配合，靠人工来完成。指定由人工完成的过程也需经过仔细的检查，这就是所谓的过程测试。互连测试互连测试是要验证两个或多个不同的系统

之间的互连性。兼容性测试这类测试主要想验证软件产品在不同版本之间的兼容性。有两类基本的兼容性测试：向下兼容交错兼容容量测试容量测试是要检验系统的能力最高能达到什么程度。例如，对于编译程序，让它处理特别长的源程序

；对于操作系统，让它的作业队列“满员”；对于信息检索系统，让它使用频率达到最大。在使系统的全部资源达到“满负荷”的情形下，测试系统的承受能力。文档测试这种测试是检查用户文档(如用户手册)的清晰性和精确性。用

户文档中所使用的例子必须在测试中一一试过，确保叙述正确无误。测试和质量测试是质量可以被评估——更实际点说，错误可以被发现——的最后堡垒，但是测试步应当被视为一个安全网。程序测试的内在动机是使用对大规模系统和小规模系统都

能节约地并且有效地应用的方法来认可软件的质量需要重点加以注意的是：验证和确认（V&V）包含了范围很广的SQA活动，其中包括正式的技术复审、质量和配置审查、性能监控、仿真、可行性研究、文档复审、数据库复审、算法

分析、开发测试、质量测试和安装测试。虽然测试在（V&V）中发挥着非常重要的作用，但是其它的活动也是必不可少的。测试的组织对一个软件项目来说，在测试开始的时候总会产生一些固有的利益冲突。开发人员现在开始被要求对软件进行测试。这本身

来说似乎是无害的：毕竟，谁能比开发人员更了解这个软件呢？不幸的是，这些开发人员有很高的兴趣要急于证明他们的程序是毫无错误的，是按照用户的需求开发的，而且完全能够按照预定的进度和预算完成。这些兴趣和认真的测试是相互冲突的。测试的组织从心理学角度上讲

，软件分析和设计（包括编码）是建设性的工作。软件工程师和建筑师一样，对自己的“大厦”感到非常的骄傲，而对任何试图摧毁其“大厦”的人嗤之以鼻。当测试开始时，就会存在一种微妙的、但确实存在的、试图要“摧毁”软件工程师建立

起来的东西的企图。从开发者的观点来看，测试可以被看作是（从心理上来说）破坏性的。所以开发者只是简单地设计和进行能证明程序正确的测试，而不是尽量去发现错误。不幸的是，错误确确实实地存在着，而且软件工程师不能找到错误，那么客户就会找到

他们。测试的组织人们常产生这样的误解：软件的开发人员根本不应当参与测试软件应当给那些会无情地挑毛病的陌生人来测试测试者只有在测试的步骤即将开始的时候才参与项目这些想法都是错误的，正确的是：软件开发人员总是负责程序的单个单元（

模块）的测试，保证每个单元能够完成设计的功能。在很多情况下，开发者也应进行集成测试——进行完整的程序结构构造（和测试）的步骤仅仅在软件体系结构完成后，独立测试组织（ITG）才介入。软件开发人员不

能把程序交给ITG就一走了之，开发人员应该和ITG成员密切合作，以保证测试顺利进行。程序的静态测试源程序静态分析人工测试：经验表明，使用这种方法能够有效地发现30％到70％的逻辑设计和编码错误。静态分析中进行人工测试的主要方法：桌前检查代码审查走查。源程

序静态分析①生成各种引用表直接从表中查出说明／使用错误等。如，循环层次表、变量交叉引用表、标号交叉引用表等。为用户提供辅助信息。如，子程序（宏、函数）引用表、等价（变量、标号）表、常数表等。用来做错误预测和程

序复杂度计算。如，操作符和操作数的统计表等。②静态错误分析，静态错误分析主要用于确定在源程序中是否有某类错误或“危险”结构。类型和单位分析：为了强化对源程序中数据类型的检查，发现在数据类型上的错误和单位上的不一致性，在程序设计

语言中扩充了一些结构。如单位分析要求使用一种预处理器，它能够通过使用一般的组合／消去规则，确定表达式的单位。引用分析：最广泛使用的静态错误分析方法就是发现引用异常。如果沿着程序的控制路径，变量在赋值以前被引用，或变量在赋值以后未被引用，这时就发生了引用异常。为了检测引用异常

，需要检查通过程序的每一条路径。也可以建立引用异常的探测工具。表达式分析：对表达式进行分析，以发现和纠正在表达式中出现的错误。包括：在表达式中不正确地使用了括号造成错误。数组下标越界造成错误。除式为零造成错误。对负数开平方，或对π求正切值造成错误。以及对浮点数计算的误差进行检查。接口分析：

关于接口的静态错误分析主要检查过程、函数过程之间接口的一致性。因此要检查形参与实参在类型、数量、维数、顺序、使用上的一致性；检查全局变量和公共数据区在使用上的一致性。桌前检查（DeskChecking）由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前

，对源程序代码进行分析，检验，并补充相关的文档，目的是发现程序中的错误。检查项目有：检查变量的交叉引用表：重点是检查未说明的变量和违反了类型规定的变量；还要对照源程序，逐个检查变量的引用、变量的使用序列；临时变量在某条路径上的重写情况；局部变量、全局变量与特权变量的使用；检查标号的交叉引

用表：验证所有标号的正确性：检查所有标号的命名是否正确；转向指定位置的标号是否正确。检查子程序、宏、函数：验证每次调用与被调用位置是否正确；确认每次被调用的子程序、宏、函数是否存在；检验调用序列中调用方式与参数顺序、个数、类型上

的一致性。等值性检查：检查全部等价变量的类型的一致性，解释所包含的类型差异。常量检查：确认每个常量的取值和数制、数据类型；检查常量每次引用同它的取值、数制和类型的一致性；标准检查：用标准检查程序或手工检查程序中违反标准的问题。风格检查：

检查在程序设计风格方面发现的问题。比较控制流：比较由程序员设计的控制流图和由实际程序生成的控制流图，寻找和解释每个差异，修改文档和校正错误。选择、激活路径：在程序员设计的控制流图上选择路径，再到实际的控制流图上激

活这条路径。如果选择的路径在实际控制流图上不能激活，则源程序可能有错。用这种方法激活的路径集合应保证源程序模块的每行代码都被检查，即桌前检查应至少是语句覆盖。对照程序的规格说明，详细阅读源代码：程序员对

照程序的规格说明书、规定的算法和程序设计语言的语法规则，仔细地阅读源代码，逐字逐句进行分析和思考，比较实际的代码和期望的代码，从它们的差异中发现程序的问题和错误。补充文档：桌前检查的文档是一种过渡性的文档，不是公开的正式文档。通过编写文档，

也是对程序的一种下意识的检查和测试，可以帮助程序员发现和抓住更多的错误。这种桌前检查，由于程序员熟悉自己的程序和自身的程序设计风格，可以节省很多的检查时间，但应避免主观片面性。代码会审（CodeReadingReview）代码会审

是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码会审分两步：第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，

作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步：召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过

程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。在会前，应当给会审小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的实效。这个常见错误清单也叫做检查表，它把程序中可能发生的各种错误进行分类，

对每一类列举出尽可能多的典型错误，然后把它们制成表格，供在会审时使用。走查（Walkthroughs）走查与代码会审基本相同，其过程分为两步。第一步也把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。开会的程序与代码会审不同，不是简单地读程序和对照错

误检查表进行检查，而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。人们借助于测试用例的

媒介作用，对程序的逻辑和功能提出各种疑问，结合问题开展热烈的讨论和争议，能够发现更多的问题。调试（Debug）软件调试是在进行了成功的测试之后才开始的工作。它与软件测试不同，调试的任务是进一步诊断和改正程序中潜在的错误。调试活动由两部分组成：确定程序中可疑错误的

确切性质和位置。对程序(设计,编码)进行修改，排除这个错误。调试工作是一个具有很强技巧性的工作。软件运行失效或出现问题，往往只是潜在错误的外部表现，而外部表现与内在原因之间常常没有明显的联系。如果要

找出真正的原因，排除潜在的错误，不是一件易事。可以说，调试是通过现象，找出原因的一个思维分析的过程。调试的步骤(1)从错误的外部表现形式入手，确定程序中出错位置；(2)研究有关部分的程序，找出错误的内在原因；

(3)修改设计和代码，以排除这个错误；(4)重复进行暴露了这个错误的原始测试或某些有关测试。(5)如果所做的修正无效，则撤消这次改动，重复上述过程，直到找到一个有效的解决办法为止。从技术角度来看，查找错误的难度在于：现象与原因所处的位置可能相距甚远。

当其它错误得到纠正时，这一错误所表现出的现象可能会暂时消失，但并未实际排除。现象实际上是由一些非错误原因(例如，舍入不精确)引起的。现象可能是由于一些不容易发现的人为错误引起的。错误是由于时序问题引起的，与处理过程无关。

现象是由于难于精确再现的输入状态（例如，实时应用中输入顺序不确定）引起。现象可能是周期出现的。在软、硬件结合的嵌入式系统中常常遇到。几种主要的调试方法调试的关键在于推断程序内部的错误位置及原因。可以采用以下方法：强

行排错:这种调试方法目前使用较多，效率较低。它不需要过多的思考，比较省脑筋。例如：通过内存全部打印来调试，在这大量的数据中寻找出错的位置。（MemoryDump）在程序特定部位设置打印语句，把打印语句插在出错的源程序的各个关键变

量改变部位、重要分支部位、子程序调用部位，跟踪程序的执行，监视重要变量的变化。自动调试工具。利用某些程序语言的调试功能或专门的交互式调试工具，分析程序的动态过程，而不必修改程序。应用以上任一种方法之前，都应当对错误的征兆进行全面

彻底的分析，得出对出错位置及错误性质的推测，再使用一种适当的调试方法来检验推测的正确性。回溯法调试:这是在小程序中常用的一种有效的调试方法。一旦发现了错误，人们先分析错误征兆，确定最先发现“症状”的位置。然后，人工沿程序

的控制流程，向回追踪源程序代码，直到找到错误根源或确定错误产生的范围。例如，程序中发现错误处是某个打印语句。通过输出值可推断程序在这一点上变量的值。再从这一点出发，回溯程序的执行过程，反复考虑：“如

果程序在这一点上的状态（变量的值）是这样，那么程序在上一点的状态一定是这样...”，直到找到错误的位置。归纳法调试:归纳法是一种从特殊推断一般的系统化思考方法。归纳法调试的基本思想是：从一些线索(错误征兆)着手，通过

分析它们之间的关系来找出错误。收集有关的数据:列出所有已知的测试用例和程序执行结果。看哪些输入数据的运行结果是正确的，哪些输入数据的运行结果有错误。组织数据:由于归纳法是从特殊到一般的推断过程，所以需要组织整理数据，以

发现规律。常以3W1H形式组织可用的数据：“What”列出一般现象；“Where”说明发现现象的地点；“When”列出现象发生时所有已知情况；“How”说明现象的范围和量级；“Yes”描述出现错误的3W1H；“No”作为比较，描述了没有错误的3W1H。通过分析找出矛盾来。

提出假设:分析线索之间的关系，利用在线索结构中观察到的矛盾现象，设计一个或多个关于出错原因的假设。如果一个假设也提不出来，归纳过程就需要收集更多的数据。此时，应当再设计与执行一些测试用例，以获得更多的数据。证明假设:把假设与原始线索或数据进行比较，若它能完全解释一切现象，则假设得到证明

；否则，就认为假设不合理，或不完全，或是存在多个错误，以致只能消除部分错误。演绎法调试演绎法是一种从一般原理或前提出发，经过排除和精化的过程来推导出结论的思考方法。演绎法排错是测试人员首先根据已有的测试用例，设想及枚举出所有可能出错的原因做为假设；然后再用原始测试数据或新的测试，从中

逐个排除不可能正确的假设；最后，再用测试数据验证余下的假设确是出错的原因。列举所有可能出错原因的假设:把所有可能的错误原因列成表。通过它们，可以组织、分析现有数据。利用已有的测试数据，排除不正确的假设:仔细分

析已有的数据，寻找矛盾，力求排除前一步列出所有原因。如果所有原因都被排除了，则需要补充一些数据(测试用例)，以建立新的假设。改进余下的假设:利用已知的线索，进一步改进余下的假设，使之更具体化，以便可以精确地确定

出错位置。证明余下的假设调试原则在调试方面，许多原则本质上是心理学方面的问题。调试由两部分组成，调试原则也分成两组。确定错误的性质和位置的原则用头脑去分析思考与错误征兆有关的信息。最有效的调试方法是用头脑分析与错误征兆有关的信息。一个能干的程

序调试员应能做到不使用计算机就能够确定大部分错误。避开死胡同。如果程序调试员走进了死胡同，或者陷入了绝境，最好暂时把问题抛开，留到第二天再去考虑，或者向其他人讲解这个问题。事实上常有这种情形：向一个好的听众简单地描述这个问题时，不需要任何听讲者的提示，你自己会突然发现问题

的所在。只把调试工具当做辅助手段来使用。利用调试工具，可以帮助思考，但不能代替思考。因为调试工具给你的是一种无规律的调试方法。实验证明，即使是对一个不熟悉的程序进行调试时，不用工具的人往往比使用工具的

人更容易成功。避免用试探法，最多只能把它当做最后手段。初学调试的人最常犯的一个错误是想试试修改程序来解决问题。这还是一种碰运气的盲目的动作，它的成功机会很小，而且还常把新的错误带到问题中来。修改错误的原则在出现错误的地方，很可能还有别的错误

。经验证明，错误有群集现象，当在某一程序段发现有错误时，在该程序段中还存在别的错误的概率也很高。因此，在修改一个错误时，还要查一下它的近邻，看是否还有别的错误。修改错误的一个常见失误是只修改了这个错误的征兆或这个错误的表现，而没有修改错误的本身。如果提出的修改不能解释与这个错误有关的

全部线索，那就表明了只修改了错误的一部分。当心修正一个错误的同时有可能会引入新的错误。人们不仅需要注意不正确的修改，而且还要注意看起来是正确的修改可能会带来的副作用，即引进新的错误。因此在修改了错误之后，必须进行回归测试，以确认是否引进了新的错误。修改错误的过程将迫使人们暂时回到程序设计阶

段。修改错误也是程序设计的一种形式。一般说来，在程序设计阶段所使用的任何方法都可以应用到错误修正的过程中来。修改源代码程序，不要改变目标代码。GUI测试窗口下拉菜单鼠标操作数据项因为GUI操作相关的排列数非常大，所

以应用自动化工具进行测试文档测试文档错误会同数据和代码错误一样给程序带来灾难性的后果。没有什么精确地按照用户手册操作，但得到地结果却不符合文档的描述更令人气恼的事了。文档测试可以分为两个步骤：第一步为正式的技术复审，检查文档的编辑错误；第

二步是活动测试（LiveTesting)，结合实际程序的使用而使用文档。活动测试可使用黑盒测试方法，基于因果图的测试可以用于描述程序的使用。等价划分和边界值分析可以定义输入类型及相关的交互，然后按照文档跟踪程序的使用。面向对象测试为了充分地测

试OO系统，必须做好三件事：测试的定义必须扩大包括用于OOA和OOD模型的错误发现技术单元和集成测试策略必须有很大的改变测试用例的设计必须考虑OO软件的独特特征扩大测试的视角OO软件工程范型具有演化的性质，模型从对系统需求的非正式的表示开始，逐步演化为详细的类模型

、类关联和关系、系统设计和分配，以及对象设计。在每个阶段，测试模型以试图在错误传播到下一次递进前发现错误。OOA和OOD模型提供了关于系统的结构和行为的实质性信息，为此，它们应该在生成代码前经受严格的复审所有面

向对象模型应该被测试（这里测试代表正规的技术复审，因为这些模型不能被执行，不能进行传统意义上的测试），以保证在模型的语法、语义和语用的语境内的正确性。面向对象的测试策略当考虑面向对象的软件时，单元的概念发生了变化。封装驱动了类和对象的定义，这意味着每个类和类的实例（对象）

包装了属性（数据）和操纵这些数据的操作（也称为方法或服务）。而不是个体的模块。最小的可测试单位是封装的类或对象，类包含一组不同的操作，并且某些特殊的操作可能作为一组不同的类的一部分存在，因此，单元测试的意义发生了很大的变化。不再

孤立地测试单个操作（传统的单元测试观点），而是将操作作为类的一部分。传统的单元测试往往关注模块的算法细节和模块接口间的数据流动，OO软件的类测试是由封装在类中的操作和类的状态行为所驱动的。面向对象的测试策略因为面向对象软件没有层次的控制结构，传统的自顶向下和自底向上集成策略就没有意义，此外，

一次集成一个操作到类中（传统的增量集成方法）经常是不可能的，这时由于“构成类的成分的直接和间接的交互”对OO软件的集成策略有两种不同的策略第一种称为基于线程的测试：集成对回应系统的一个输入或事件所需的一组类，每个线程被集成并分别测试，应用回归测试以保证没有产生副作用。第二种称为基于

使用的测试，通过测试那些几乎不使用服务器类的类（称为独立类）而开始构造系统，在独立类测试完成后，下一层的使用独立类的类，称为依赖类，被测试。这个依赖层次的测试序列一直持续到构造完整个系统为止。序列和传统集成不同，驱动模块和桩模块作为替代操作是要尽量避免的。集群测试（C

lustertesting）是OO软件集成测试的一步，这里一群协作类通过设计试图发现协作中的错误的测试用例而被测试。面向对象测试和传统测试白盒测试方法可以用于对类定义的操作的测试黑盒测试方法对OO系

统同样适用，USECASE可以作为黑盒及基于状态的测试的设计提供有用的输入。使用USECASE作为有效性测试的主要驱动基于场景的测试主宰了OO系统的有效性。客户/服务器系统的测试客户/服务器系统的分布式性质为软件测试者带来了一些独特的问题：客户端GUI的

考虑目标环境及平台多样性的考虑分布数据库的考虑（包括复制的数据）分布处理的考虑非鲁棒的目标环境非线性的性能关系整体C/S测试策略通常，客户/服务器软件的测试发生在三个不同的层次：个体的客户端应用以“分离的”模式被测试——步考虑服务器和底层网络的运行客户端软件和关联的

服务器端应用被一起测试，但网络运行不被明显的考虑完整的C/S结构，包括网络运行和性能，被测试C/S应用中经常使用的测试方法应用功能测试：用前面讲到的方法测试客户端的应用。在本质上，应用被独立的测试，以揭示在运行中的错误服务器测试：测试服务器的协调和数据管理功能，也考虑服务器

性能（整体反应时间和数据吞吐量）数据库测试：测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证数据被适当地存储、更新和检索。事务测试：创建一系列地测试以保证每类事务被按照需求处理。测试着重于事务处理的正确性，也关注性能问题（如事务处理时间和事务量测试）网络通

信测试：这些测试验证网络节点间的通信正确的发生，并且消息传递、事务和相关的网络交通无错的发生。网络安全性测试也可能作为测试的一部分。WEB系统的测试静态测试：识别网页中的静态错误浏览测试：测试导航和链接的正

确性功能测试：包括传统测试中的单元测试、集成测试和系统测试非功能测试大规模集成测试静态测试HTML测试浏览器兼容性测试VisualBrowsevalidation内容检查浏览测试链接测试加载及加载时间测试交易验证功

能测试脚本的功能测试组件测试：CGI、ActiveX交易测试应用程序测试可以直接使用浏览器浏览、导航无状态性Cookie测试失去网络连接的测试国际性测试非功能性测试配置测试性能

吸收测试/可靠性可用性测试可用性测试安全性测试大规模集成测试外部链接测试传统系统集成测试端到端功能测试非功能测试大规模集成测试RUP中的测试工作流测试的目的在于：核实对象之间的交互。核实软件的所有

构件是否正确集成。核实所有需求是否已经正确实施。确定缺陷并确保在部署软件之前将缺陷解决。在很多组织中，软件测试占软件开发费用的30%到50%。但大多数人仍然认为软件在交付之前没有进行充分的测试。这一矛盾根植于两个明显的事实。第一个，测试软件十分困难。给定程

序具有无数的不同行为方式。第二个，测试通常是在没有明确的方法，不采用必须的自动化手段和工具支持的情况下进行的。RUP中的测试工作流由于软件的复杂性，无法实现完全测试，但采用周密的方法和最新技术水平的工具可以明显提高软件测试

的生产率和有效性。对于失败将导致人员伤亡这类“安全至上”的系统（如空中交通管制系统、导弹制导系统、或医用输送系统）来说，高质量的软件是系统成功的要素。对于典型的MIS系统，上述情况不是非常明显，但是消除缺陷造成的影响将需要相当昂

贵的开支。在软件生命周期的早期启动的执行良好的测试，将明显降低完成和维护软件的开支。它还可以大大降低与部署质量低劣的软件相关的责任或风险，如用户的生产率低下、数据输入和计算错误，以及令人无法接受的功能行为。现在，许多MIS系

统是“任务至上”的，也就是说当出现失败时，公司将无法正常运转并导致大量损失。例如：银行或运输公司。测试任务至上的系统时，必须使用安全至上的系统所采用的类似严格方法。与其他核心工作流程的关系需求工作流程采集用例模型中的需求，这些需求是用于确定执行什么

测试的一个主要输入。分析设计工作流程描述进行设计的方法，这是在确定执行什么测试时的另一个主要输入。实施工作流程生成由测试工作流程进行测试的实施模型的工作版本。在一次迭代中将测试多个工作版本，第一个是系统集成后的工作版本，最后一个是用于测试整个系统的工作版本。环境工作流程开发并维护测

试过程中使用的支持工件，如“测试指南”。管理工作流程对项目和各迭代（说明参见“迭代计划”）作出计划。工作流程制定测试计划目的此工作流程明细的目的是确定和描述要实施和执行的测试。这是通过生成包含测试需求和测试策略的测试计划来完成的。可以制定一个单独的测试计划，用于描述所有要实施和执行的

不同测试类型，也可以为每种测试类型制定一个测试计划。两者都是可以采用的方法。完成制定测试计划后可以评测和管理测试工作。如何配备人员带有最终用户代表输入的测试设计员是此工作流程明细涉及的主要角色。工作指南以下是可以用于确保得到正确信息的示例方法：访谈调查问卷功能

监测活动：制定测试计划目的收集和组织测试计划信息。创建测试计划。步骤确定测试需求评估风险制定测试策略确定资源创建时间表生成测试计划输入工件：补充规约用例模型设计指南设计模型类用例实现软件构架文档构件和实施子系统迭代计划测试指南生成工件：

已完成的测试计划确定测试需求目的：确定测试对象并指明测试范围。确定测试需求是测试计划活动的开始。测试需求确定测试对象以及测试工作的范围和作用。测试需求还用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。被确定的

测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。执行如下步骤确定测试需求：复审所有材料。指明测试需求。本步骤产生的结果是一份确定将成为测试目标的需求的报告（层次结构）。确定测试需求复审所有材料。由于测试需

求可从多种来源确定，因此作为第一步，对将要开发的应用程序/系统的所有可用材料进行复审是十分重要的。最常用的测试需求来源包括现有的需求列表、用例、用例模型、用例实现、补充规约、设计需求、商业理由、最终用户访谈以及对现有系统的复审。指明测

试需求。除确定测试需求的来源之外，还必须有某种形式的确定方法来确定将成为测试目标的需求。这将导致测试需求层次的产生。该层次可能基于现有的层次结构，也可能是新近生成的。层次结构是测试需求的逻辑分组。常用分组方法包括按照用例、商业理由、测试类型（功能、性能等）或者以上各项的组合对项目进

行分组。评估风险目的最大限度地提高测试效率并确定测试工作的优先级。制定一个可接受的测试顺序。要获得对风险的认识，请执行如下操作：确定并验证风险因子确定并验证实施概要因子确定并验证测试优先级因子确定并验证测试风险因子测试工作需要平衡资源约束和风险。最重要的测试需求能够

反映最高的风险。可从以下几个方面观察风险：效果-用例（需求等）失效造成的影响或后果原因-确定不合需要的结果，并确定哪些用例或需求一旦失效将产生该结果。可能性-用例或需求失效的概率复审每一项测试需求并确定风险因子（比如高、中或低）。有时从两个或

更多方面对风险进行评估可能会得到不同的风险因子。在这种情况下，请使用最高的风险因子值。同时还应给出关于对某一给定测试需求为何选择特定风险因子的说明。确定并验证测试的实施概要因子大多数应用程序都有某些功能是经常使用的，而另外一些则是较少使用的。因此要对应用程序进行合理的测试，必须

确保不仅测试具有最高风险的测试需求，而且还应测试经常使用的功能（因为这些功能通常是最终用户最频繁使用的）。确定每一个测试需求的实施概要因子，并说明为什么确定特定因子值的原因。这可通过复审商业理由或者同最终用户及其经理访谈来完成。另一种方法是观

察最终用户与系统的交互行为或者使用监视/记录软件来记录最终用户与系统的交互行为（供分析用）。确定并验证测试优先级因子在确定和验证每一个测试需求的测试风险和实施概要之后，就应该确定和验证测试优先级因子。测试优先级因子确定测试需求的相对

重要性以及测试其的顺序或时序。测试优先级因子通过利用风险因子、实施概要、合同义务、其他约束或者它们的组合来确定。在确定测试优先级时，考虑所有的因素十分重要，这样可以确保测试适当而有重点。制定测试策略目的确定并传达测试手段和工具

确定并传达用于确定产品质量和测试是否完成的评估方法测试策略的目的是向每一个人传达如何进行测试以及采用何种评测标准来确定测试的完成和成功程度。策略不必十分详尽，但它应该向读者指明如何进行测试。制定测试策略包括：确定和描述测试方法确定测试标

准确定测试的特殊事项确定和描述测试方法测试方法是对如何实施测试的说明（陈述）。它应该说明或指出测试对象、测试时采取的主要操作以及如何核实结果等。说明应该为读者提供足够的信息以便他们能够理解测试的对象（尽管

尚不了解测试深度），如以下说明陈述：对于每一个用例，确定并执行测试用例，包括有效和无效的输入数据。对于每一个用例都将设计和开发测试流程。利用三个月的时间来实施测试过程以模拟客户账号管理。测试过程包括添加、修改和删除账号以及客户。实施测试过程并通过1500个虚拟用户来执行测试脚本，每个用户都

执行功能A、B和C，并且使用不同的输入数据。确定测试标准测试标准是关于测试的客观说明，它指明那些用于确定/识别测试完成时间的值和被测试应用程序质量。测试标准可能包括一系列说明或对其他文档（比如方法指南或测试标准等）的引用。测试标准应确定：测试对象（具体测试目标）评测方法评估评测方法

所采用的标准测试标准示例：对于每一高优先级用例：所有计划好的测试用例和测试过程已被执行。所有确定的缺陷已被解决。所有计划好的测试用例和测试过程已被重新执行并且没有发现新的缺陷。在上例中，“对于每一高优先级用例”说明测试对象。“所有计划好的

测试用例和测试过程已被执行”说明评测的方法。评估标准包含在最后两个陈述“所有确定的缺陷已被解决”和“所有计划好的测试用例和测试过程已被重新执行并且没确定测试的特殊事项应列出所有关于测试或者依赖关系的特殊事项，如下所示：测试数据库将由

操作资源恢复。测试（性能）必须在办公结束后开始（不受日常的正常操作影响）并且在凌晨5:00以前结束。必须与遗留系统同步（或模拟同步）。设计测试目的此工作流程明细的目的是确定、描述和生成测试模型及其已报告的工件（测试过程和测试用例）。设计测试已经完成，测

试的实施和执行工作效率较高，并且达到了预期的效果如何配备人员带有用例阐释者输入的测试设计员是此工作流程明细所涉及的主要角色。工作指南以下是可以用于确保得到正确信息的示例方法：访谈调查问卷功能监测实施测试目的此工作流程明细的目的是实施（

记录、生成或编写）设计测试中定义的测试过程。输出工件是测试过程的计算机可读版本，称为测试脚本。测试脚本的生成可以在测试自动化工具环境中或编程环境中完成。如何配备人员测试设计员使用测试模型，同时可能使用其他的已实施构件，来实施测试以确保一些测试专用的功能

（桩模块、驱动程序等）以及非测试重点但要与测试对象交互的元素得到实施和测试。工作指南可以使用多种方法生成测试脚本，包括：录制-使用录制/回放工具来获取（记录）与测试对象的交互和执行测试对象的结果。编程-使用开发

环境编写执行和获取执行测试对象结果的必要步骤的程序。自动生成-在没有用户介入的情况下，使用测试生成工具生成测试脚本（生成的设置和启动除外）。在集成测试阶段执行测试目的集成测试阶段的目的是确保各构件组合在一起后能够按既定意

图协作运行，并确保增量的行为正确。系统集成员在各增量中编译并链接系统。每一增量都需要测试增加的功能，并进行以前版本测试过的所有测试（回归测试）。在一次迭代中，将多次执行集成测试，直到整个系统（由迭代目

标定义）集成成功。该活动的输出工件即测试结果。在迭代的最后，应该测试整个系统。系统测试的重点通常在系统与其主角之间的交互上。如何配备人员测试员是此工作流程明细所涉及的主要角色，但也存在与实施员和系统集成员的交互。此外，如果需要测试类和包，则还存在与这些角色的额外交互。工作

指南测试的执行必须在受控环境中进行。这包括：不受非测试因素影响的测试系统为测试系统设置已知初始状态并在测试结束时返回该状态（以重复执行测试）的能力。在系统测试阶段执行测试目的系统测试阶段的目的是确保整个系统按既定意图运行。系统集成员

在各增量中编译并链接系统。每一增量都需要测试增加的功能，并进行以前版本测试过的所有测试（回归测试）。在一次迭代中，将多次执行系统测试，直到整个系统（由迭代目标定义）按既定意图运行并达到测试成功或完成的标准为止。该活动的输出工件即测试结果。如何配备人员测试员是此

工作流程明细所涉及的主要角色，但也存在与实施员和系统集成员的交互。此外，如果需要测试类和包，则还存在与这些角色的额外交互。工作指南测试的执行必须在受控环境中进行。这包括：不受非测试因素影响的测试系统为测试系统设置已知初

始状态并在测试结束时返回该状态（以重复执行测试）的能力。评估测试目的评估测试的目的是生成并交付测试评估摘要。这是通过复审并评估测试结果、确定并记录变更请求，以及计算主要测试评测方法来完成的。测试评估摘要以组织有序的格式提供测试结果和主要测试评测方法，用于评估测试对象和测试流程的质量。

如何配备人员测试设计员负责复审和评估测试对象和测试流程的质量。他们必须熟悉测试指标和统计学。工作指南在此工作流程明细中，要使用两种主要的评测方法：覆盖指标-判定是否已经实施和执行了充分的测试质量指标-确定测试对象和测试流程的质量。测试：活动概述测试：工件概述

角色：测试设计员测试设计员是测试中的主要角色。该角色负责对测试进行计划、设计、实施和评估，包括：生成测试计划和测试模型执行测试过程评估测试范围和测试结果，以及测试的有效性生成测试评估摘要人员配备测试设计员应具备的相应技能和知识包括：了解系统或所测试的应

用程序了解测试及测试自动化工具具备诊断和解决问题的技能编程技能（最好具备）角色：测试设计员角色：测试员测试员负责执行测试，其职责包括：设置和执行测试评估测试执行过程并修改错误人员配备测试

员应具备的知识和技能可能会因为他们所执行的测试类型和/或测试阶段的不同而有所差异。例如，在执行性能测试或集成阶段的测试时，需要更高级的技能。在执行功能测试或系统测试阶段的测试时，则不需要太高级的技能。以下是测试员所需知识和技能的一些标准：高级测试员：了解系统或所测试的应用程序了解联网

和系统构架了解测试及测试自动化工具具备诊断和解决问题的技能编程技能（必备）初级测试员：角色：测试员指南概述：测试测试用例测试数据单元测试测试模型测试计划测试过程测试脚本负载分析文档指南：测试用例测试用

例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。测试与质量——产品质量产品质量是正在由流程生产的产品的质量。在软件开发中，产品是许多工件的

聚合，其中包括：已部署的可执行代码（应用程序、系统等），这可能是最显而易见的工件，因为项目通常是由于该工件才存在的。也就是说，它是为客户（最终用户、股东、涉众等）提供价值的首要产品。已部署的不可执行工件，包括用户手册和教程资料等工件。未部署的

可执行工件，如工件的实施集，包括已创建用于支持实施的测试脚本和开发工具。未部署的不可执行工件，如实施计划、测试计划和各种模型。由于很多工件都建立在其他工件的基础上，所以在某种程度上，所有工件的质量都是相关的。因此，对每个工件的质量都应

该评测和评估。可执行工件的产品质量（部署的和未部署的）可执行工件是通过其需求来描述的，并表述为用例或补充需求（如销售、性能等）。要评测并达到质量要求，必须了解这些需求并以清楚、简明和可核实（可测试）的方式陈述这些需求。对于软件来说，测试角色不会将所有需求当作测试对象（如市场渗透或

销售收益）。对于那些将成为测试对象的需求来说，测试设计员必须能够指定一种方法来核实是否满足需求（正如已指定的）、没有偏离既定意图并且没有缺陷。产品质量是通过评测以下质量维度和评测产品是否满足这些维度的要求来决定的：可靠性：已部署的代码在执行过程中的防故障（崩溃、挂

起、内存丢失等）能力。功能：已部署的代码按既定意图执行所需的用例。性能：在实际的操作特征（如负载、强度和长时间运行）条件下，已部署的代码以及时和可接受的方式执行和响应，并以可接受的方式继续运行。对于每一维度，在测试的一个或多个不同阶段，应该实施和执行

一种或多种测试类型。此外，还可通过评测每一工件新版本的可执行工件中所作的变更数量和类型来评估产品质量。不可执行工件的产品质量（已部署的或未部署的）不可执行工件的产品质量通过工件的目的、目标和结构来描述，并通过确保工件符合以下各项要求来评估：工件内部和工件之间的一致性（语言

的使用、术语或语义等）。指南、标准和合同需求（语言的使用、术语、语义、格式或内容等）的兼容性此外，还可以通过工件版本之间所作变更的数量和类型来评估不可执行工件的产品质量。为了帮助评估RUP中工件的产品质量,我们在RUP中包括了以下针

对大多数工件的信息类型：工件指南和检查点：有关如何开发、评估和使用工件的信息。模板：工件的“模型”或原型，为内容提供结构和指导。质量维度质量不是一个可以简单描述的概念。同样，当我们转而关注于鉴别质量的测试时，也无法从单一的角度来描述质量的概念或评测质量的方法。在Ration

alUnifiedProcess中，这一问题是通过指定“质量”具备以下维度来解决的：可靠性：软件坚固性和可靠性（防故障能力，如防止崩溃、内存丢失等能力）、资源利用率和代码完整性以及结构（语言和语法的技术兼容性）。功能：按照既定意图和要求，执行指定用例的能力。性能：测试对象的计时配置

文件和操作特征。计时配置文件包括代码的执行流、数据访问、函数调用和系统调用。性能的操作特征包括与作业负载相关的特征，如响应时间、操作可靠性(MTTF)；以及与操作限制相关的特征，如负载容量或强度。对于各维度的元素，在测试的不同阶段，应该实施和执行一种或多种测试类型测试的生命周期

在软件开发生命周期中，软件是通过迭代来不断加以完善的。在这种环境中，对于每个作为测试目标的工作版本，测试的生命周期还都必须具有一种迭代方法。对于针对每个工作版本执行的测试，都作出了增补和改进，并累积为一个测试体，用于后续阶段的回归测试。

该方法表明它将导致在整个流程中重复进行测试，就象修订软件本身一样。这里没有一成不变的软件规约，也没有一成不变的测试。测试的生命周期在同一张图中，观察不具有项目其余部分的测试的生命周期。图中展示了不同测试活动在非迭代视图中相互联系的方式：测试的生

命周期该生命周期必须与迭代方法结合起来，这意味着每个迭代都将具有遵循该模式的测试周期。测试的主要评测方法测试的主要评测方法包括覆盖和质量。测试覆盖是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用

例的覆盖或已执行代码的覆盖表示的。质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。测试的主要评测方法——覆盖评测覆盖指标提供了“测试的完全程度如何？”

这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）

或所有代码行的执行（基于代码的）。系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完

全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了75%的性能测试需求。如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到。测试的主要评测方法——基于需求的测试覆盖基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。测试覆盖通过以下公式计算：测

试覆盖=T(p,i,x,s)/RfT其中：T是用测试过程或测试用例表示的测试(Test)数（已计划的、已实施的或成功的）。RfT是测试需求(RequirementforTest)的总数。在制定测试计划活动中，将计算测试覆盖以决定已计划的测试覆盖，其计算方法如下：

测试覆盖（已计划的）=Tp/RfT其中：Tp是用测试过程或测试用例表示的已计划测试(Test)数。RfT是测试需求(RequirementforTest)的总数。测试的主要评测方法——基于需求的测试覆盖在实施测试活动中，由于测试过程正

在实施中（按照测试脚本），在计算测试覆盖时使用以下公式：测试覆盖（已执行的）=Ti/RfT其中：Tx是用测试过程或测试用例表示的已执行的测试(Test)数。RfT是测试需求(RequirementforTest

)的总数。在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。这些覆盖评测通过以下公式计算：测试覆盖（已执行的）=Tx/RfT其中：Tx是用测试过程或测试用例表示

的已执行的测试(Test)数。RfT是测试需求(RequirementforTest)的总数。成功的测试覆盖（已执行的）=Ts/RfT其中：Ts是用完全成功、没有缺陷的测试过程或测试用例表示的已执

行测试(Test)数。RfT是测试需求(RequirementforTest)的总数。如将以上比率转换为百分数，则以下基于需求的测试覆盖的陈述成立：x%的测试用例（上述公式中的T(p,i,x,s)）已经覆盖，成功率为y%这一关于测试覆盖的陈述是有意义的，

可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。测试的主要评测方法——基于代码的测试覆盖基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控

制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。基于代码的测试覆盖通过以下公式计算：测试覆盖=Ie/TI

ic其中：Ie是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。TIic(TotalnumberofItemsinthecode)是代码中的项目总数。如将该比率转换为百分数，则以下基于代码的测试覆盖的陈述成立：x%的测试用例（上述公式中的I）已经覆盖，成

功率为y%这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。质量评测测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的

评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。缺陷评估可能建立在各种方法上，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。严格的评估

假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具

支持，所以应该慎重平衡成本与其增加价值。缺陷分析就是分析缺陷在与缺陷关联的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。对于缺陷分析，常用的主要缺陷参数有四个：状态：缺陷的当前状态（打开的、正在修复或关闭的等）。优先级：必须处理

和解决缺陷的相对重要性。严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺

陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。例如，预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值，在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数，以允许检测“较差的模块

”、“热点”或需要再三修复的软件部分，从而指示一些更基本的设计缺陷。这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷，这是因为某些缺陷可能是扩展请求，超出了项目的规模，或描述的是已报

告的缺陷。然而，需要查看并分析一下，为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷，这样做是有价值的。缺陷报告RationalUnifiedProcess以三类形式的报告提供缺陷评估：缺陷分布（密度）报告允许将缺陷计数作为一个或多

个缺陷参数的函数来显示。缺陷龄期报告是一种特殊类型的缺陷分布报告。缺陷龄期报告显示缺陷处于特定状态下的时间长短，如“提出的”。在龄期类别中，缺陷还可以按其他属性分类，如“拥有者”。缺陷趋势报告按状态（新的、已打开的或关闭的）将缺陷计数作为时间的函

数显示。趋势报告可以是累计的，也可以是非累计的。测试结果和进度报告显示对测试的应用程序进行若干次迭代和测试生命周期后的测试过程执行结果。许多此类报告对于评估软件质量具有很高的价值。一般测试标准中包括

有关特定类别（如严重性级别）中打开的缺陷数的陈述。通过缺陷分布评估可以轻松地核对该标准。对测试需求进行过滤或分类，该评估可以侧重于不同的需求集。要有效生成此类报告，一般需要工具支持。测试策略测试类型测试阶段在

软件交付周期的不同阶段，通常需要对不同类型的目标应用测试。这些阶段是从测试小的构件（单元测试）到测试整个系统（系统测试）不断向前发展的。单元测试单元测试在迭代的早期实施，侧重于核实软件的最小可测试元素。单元测试通常应用于实施模型中的构件，核

实是否已覆盖控制流和数据流，以及构件是否可以按照预期工作。这些期望值建立在构件参与执行用例的方式的基础上，参与方式可参见该用例的序列图。_实施员在单元的开发期间执行单元测试。实施工作流程对单元测试作出了详细描述。集成测试执行集成测试是为了确保当

把实施模型中的构件集成起来执行用例时，这些构件能够正常运行。测试对象是实施模型中的一个包或一组包。要集成的包通常来自于不同的开发组织。集成测试将揭示包接口规约中不够完全或错误的地方。系统测试当将软件作为整体运行或实施明确定义的软件行为子集时，

即可进行系统测试。这种情况下的目标是系统的整个实施模型。验收测试验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以供最终用户用于执行软件的既定功能和任务。请参见概念：验收测试以获取附加信息性能测试性能测试是为描述测试对象与性能相

关的特征并对其进行评价，而实施和执行的一类测试，如描述和评价计时配置文件、执行流、响应时间以及操作的可靠性和限制等特征。不同类型的性能测试侧重于不同的测试目标，这些性能测试的实施贯穿于整个软件开发生命周期(Software

DevelopmentLifeCycle,SDLC)。在早期的构架迭代中，性能测试侧重于确定和消除与构架有关的性能瓶颈。在构建迭代中还将实施和执行其他类型的性能测试，以调整软件和环境（优化响应时间和资源），并核

实应用程序和系统是否能够处理高负载和高强度的情况，如有大量事务、客户机和/或数据的情况。性能测试中包含以下测试类型：基准测试-比较新的或未知测试对象与已知参照标准（如现有软件或评测标准）的性能。争用测试：-核实测试对象对于多

个主角对相同资源（数据记录、内存等）的请求的处理是否可以接受。性能配置-核实在操作条件保持不变的情况下，测试对象在使用不同配置时其性能行为的可接受性。负载测试-核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。强度测试-

核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。性能评价通常是和用户代表一起协作并且以多级方法执行的。性能分析的第一级涉及单一主角/用例实例的结果评价和多个测试执行的结果比较。例如，在测试对象上没有其他活动的情况下，记录单一

主角执行单一用例的性能行为，并将结果与相同主角/用例的其他几个测试执行进行比较。第一级分析有助于确定可以表明系统资源中存在争用的趋势，该趋势将影响从其他性能测试结果所得出的结论的有效性。分析的第二级检查特定主角/

用例执行的摘要统计信息和实际数据值，以及测试对象的性能行为。摘要统计信息包括响应时间的标准偏差和百分位分布，这些信息显示了系统响应的变动情况，正如每个主角所见到的一样。分析的第三级有助于理解性能问题的起因和加权值。

该详细分析采用低级数据并且使用统计方法，帮助测试员从数据中得出正确的结论。详细分析为决策提供客观和定量的标准，但是它耗时较长，并且要求对统计学有基本的理解。当性能行为差异确实存在，或是由于某些与测试数据收集相关的随机事件引起时，详细分析使用统计加权值的概念来帮助理解。即认

为在基本级上，任何事件都具有随机性。统计测试确定是否存在无法用随机事件解释的系统差异。结构测试基于Web的应用程序（使用Internet应用技术的程序）的吸引力和流行程度都在不断提高，尤其是因为组织可以通过此类应用程序利用多项与技术相关的优

点，例如：发展客户、潜在客户和业务伙伴群体，而无需分发任何软件或技术说明书。只要有浏览器并可访问“网络”(Internet/Intranet)，任何人都可以轻松地使用浏览器浏览已发布的URL并立即运

行该应用程序。集中式的控制和维护。借助基于Web的应用程序的“瘦客户机/胖服务器”模型，应用程序构件和逻辑放置在Web服务器上，集中并简化了控制和维护。这还使开发人员能够自动分发软件，只要将应用程序存放在服务器上，所有用户就可以立即执行它。

在为采用该技术的人员带来好处的同时，基于Web的应用程序也提高了对测试的要求。这些基于Web的应用程序的测试与其对应的非Web应用程序（客户机/服务器、遗留的应用程序等）相似，需要进行测试来处理应用程序的功能和性能特征。但基于Web

的应用程序另外还需要进行侧重于应用程序结构的测试，以确保其结构良好和所有链接有效。基于Web的应用程序通常使用一系列文档（既有HTML文本文档，又有GIF/JPEG图形）来构建，这些文档通过很多静态链接，以及少量活动的或

由程序控制的链接连接起来。这些应用程序还可包括“活动内容”，如表单、Java脚本、通过插件显示的内容或Java应用程序。这种活动内容通常只用于输出，如用于音频输出或视频显示。它还可以用作导航助手，帮助用户遨游于应用（Web站点）之中。基于Web的应用程序的这种

自由形态的本质（通过其链接）是一种强大的功能，但同时也是一个巨大的弱点，因为其结构完整性很容易损坏。实施和执行结构测试的目的是核实所有链接（静态的或活动的）都连接正确。这些测试包括：核实是否显示每一链接的

正确内容（文本、图形等）。在基于Web的应用程序中，目标内容是使用不同类型的链接引用的，如指向其他目标内容（在相同或不同Web站点中）的书签、超链接或热点链接。每个链接都要核实，以确保呈现在用户面前的是正确的目标内容。确保没有断开的链接。断开的链接是

指那些无法找到目标内容的链接。链接断开的原因有多种，包括移动、删除或重命名目标内容文件。链接还可能由于使用不正确的语法而断开，包括丢失斜杠、冒号或字母。核实是否有孤立的内容。孤立的内容是指当前Web站点中没有“入站”链接的文件，即无法访问

或显示的内容。必须对孤立的内容进行仔细地调查，确定其原因-孤立的内容是由于本身不再需要而导致的？还是由于断开的链接而导致的？或者其内容是通过当前Web站点以外的链接访问的。确定了原因之后，需要采取适当的操作（删除该内容文件、修复断开的链接或忽略孤立的

内容）。验收测试验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。实施验收测试的常用策略有三种，它们分别是：正式验收非正式验收或Alpha测试Beta测试您选择的策略通常建

立在合同需求、组织和公司标准以及应用领域的基础上。正式验收测试正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中

所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。对于系统测试，活动和工件是一样的。在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执

行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。这种测试形式的优点是：要测试的功能和特性都是已知的。测试的细节是已知的并且可以对其进行评测。这种测试可以自动执行，支持回归测试。可以对测试过程

进行评测和监测。可接受性标准是已知的。缺点包括：要求大量的资源和计划。这些测试可能是系统测试的再次实施。可能无法发现软件中由于主观原因造成的缺陷，这是因为您只查找预期要发现的缺陷。非正式验收测试在非正式验收测试中，执行测试过程的限定不象正式验收测试中那样严格。

在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不象正式验收测试那样组织有序，而且更为主观。大多数情况下，非正式验收测试是由最终用户组织执行的。这种测试形式的优点是：要测试的功能和特性都是已知的。可以对测试过程进行评

测和监测。可接受性标准是已知的。与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。缺点包括：要求资源、计划和管理资源。无法控制所使用的测试用例。最终用户可能沿用系统工作的方式，并可能无法发现缺陷。最终用户可能专注于比较新系统与遗留系统，而不是专注于查

找缺陷。用于验收测试的资源不受项目的控制，并且可能受到压缩。Beta测试在以上三种验收测试策略中，Beta测试需要的控制是最少的。在Beta测试中，采用的细节多少、数据和方法完全由各测试员决定。各测试

员负责创建自己的环境、选择数据，并决定要研究的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。Beta测试由最终用户实施，通常开发（或其他非最终用户）组织对其的管理很少或不进行管理。Beta测试是所有验收测试策略中最主观的。这种

测试形式的优点是：测试由最终用户实施。大量的潜在测试资源。提高客户对参与人员的满意程度。与正式或非正式验收测试相比，可以发现更多由于主观原因造成的缺陷。缺点包括：测试自动化和工具测试自动化工具越来越多的出现在市场上，这些工具可以自动执行测试活动。迄今为止

，现有工具中还没有哪一种工具能够自动执行所有测试活动。事实上，多数工具是一个或几个活动专用的；有些工具的功能针对性很强，只能处理一个活动的某一部分。评估不同的测试自动化工具时，有必要了解工具类型、工具的限制以及工具能够处理和自动执行的活动情

况。关于测试自动化工具分类的说明如下所示。功能测试工具可以按其执行的功能分类。典型的工具功能名称包括：数据获取工具，用于获取要在测试活动中使用的数据。数据可以通过转化、析取、变换或捕捉现有数据获取，或者通过从

用例或补充规约生成获取静态评测工具，用于分析设计模型、源代码或其他固定源中包含的信息。该分析将生成有关逻辑流、数据流或质量指标的信息，如复杂性、可维护性或代码行。动态评测工具，用于在代码的执行过程中进行分析。这些评测包括代码的运行时操作，如内存错误检测和性能。模拟

器或驱动程序，它们执行由于时间、费用或安全原因而无法用于测试的活动。测试管理工具，用于辅助测试活动或工件的计划、设计、实施、执行、评估和管理。白盒与黑盒通常根据工具的使用方式或使用工具所需要的技术或知识，用白盒或黑盒作为测试工具的特征。白盒工具，依赖代码、设计模型

或其他来源的资料的知识来实施和执行测试。黑盒工具，依赖用例或测试对象的功能描述。其中白盒工具知道测试对象如何处理请求，而黑盒工具依赖输入和输出条件来评估测试。测试工具的专用性除了以上对工具作出的不太严格的分类外，还可

以按专用性对工具进行分类。录制/回放工具，用于将数据获取与动态评测结合起来。测试数据是在记录事件期间（测试实施的过程中）获取的。在测试执行过程中，这些数据随后将用于“回放”测试脚本，而后者用于评估测试对象的执行。质量指标工具，该工具是静态评测工具，用于执行设计模型或源代码的静态分析，以

建立描述测试对象质量的参数集。这些参数可以表明可靠性、复杂性、可维护性或其他质量评测标准。覆盖监测器工具，可通过鉴别测试过程中对于测试对象在某些维度的覆盖程度，来表示测试的完全程度。典型的覆盖类包括基于需求的（用

例）、逻辑分支或节点（基于代码）、数据状态和功能点。测试用例生成器，可自动生成测试数据。测试用例生成器使用测试对象数据输入的正式规约或设计模型/源代码，生成测试指定输入、错误输入以及限制和边界用例的测试数据。比较器工具，可比较

测试结果与参照结果，并找出区别。比较器根据其专用的特定数据格式不同而有所区别。例如，比较器可能是基于像素的（比较位图图像）或基于对象的（比较对象特征或数据）。数据析取器，用于从现有来源为测试用例提供输入。来源包括数据库、通信系统中的

数据流、报告或设计模型/源代码。软件测试程序的静态测试程序调试GUI测试文档测试面向对象系统的测试客户/服务器系统的测试WEB系统的测试RUP中的测试工作流程序的静态测试源程序静态分析人工测试：经验表明，使用这种方法能够有效地发现30％到70％的逻辑设计和编码错误。

静态分析中进行人工测试的主要方法：桌前检查代码审查走查。源程序静态分析①生成各种引用表直接从表中查出说明／使用错误等。如，循环层次表、变量交叉引用表、标号交叉引用表等。为用户提供辅助信息。如，子程序（宏、函数）引用表、等价（变量、标号）表、常

数表等。用来做错误预测和程序复杂度计算。如，操作符和操作数的统计表等。②静态错误分析，静态错误分析主要用于确定在源程序中是否有某类错误或“危险”结构。类型和单位分析：为了强化对源程序中数据类型的检查，发现在数据类型上的错误和

单位上的不一致性，在程序设计语言中扩充了一些结构。如单位分析要求使用一种预处理器，它能够通过使用一般的组合／消去规则，确定表达式的单位。引用分析：最广泛使用的静态错误分析方法就是发现引用异常。如果沿着程序的控制路径，变

量在赋值以前被引用，或变量在赋值以后未被引用，这时就发生了引用异常。为了检测引用异常，需要检查通过程序的每一条路径。也可以建立引用异常的探测工具。表达式分析：对表达式进行分析，以发现和纠正在表达式中出现的错误。包括：在表达式中不正确地使用了括号造成错误。数组下标越界造成错误。除式为零造成错误

。对负数开平方，或对π求正切值造成错误。以及对浮点数计算的误差进行检查。接口分析：关于接口的静态错误分析主要检查过程、函数过程之间接口的一致性。因此要检查形参与实参在类型、数量、维数、顺序、使用上的一致性；检查全局变量和公共数据区在使用上的一致性。桌前检查（DeskChecking）由

程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析，检验，并补充相关的文档，目的是发现程序中的错误。检查项目有：检查变量的交叉引用表：重点是检查未说明的变量和违反了类型规定的变量；还要对照源程序，逐

个检查变量的引用、变量的使用序列；临时变量在某条路径上的重写情况；局部变量、全局变量与特权变量的使用；检查标号的交叉引用表：验证所有标号的正确性：检查所有标号的命名是否正确；转向指定位置的标号是否正确。检查子程序、宏、函数：验证每次调用与被调用位置是否正确；

确认每次被调用的子程序、宏、函数是否存在；检验调用序列中调用方式与参数顺序、个数、类型上的一致性。等值性检查：检查全部等价变量的类型的一致性，解释所包含的类型差异。常量检查：确认每个常量的取值和数制、数据类型；检查常量每次引用同它的取值

、数制和类型的一致性；标准检查：用标准检查程序或手工检查程序中违反标准的问题。风格检查：检查在程序设计风格方面发现的问题。比较控制流：比较由程序员设计的控制流图和由实际程序生成的控制流图，寻找和解释每个差异，修改文档和校正错误。选择、激活路径：在程序员设

计的控制流图上选择路径，再到实际的控制流图上激活这条路径。如果选择的路径在实际控制流图上不能激活，则源程序可能有错。用这种方法激活的路径集合应保证源程序模块的每行代码都被检查，即桌前检查应至少是语句覆盖。对照程序的规格说明，详细阅读源代码：程序员对照程序的规格说明书、规定的算法

和程序设计语言的语法规则，仔细地阅读源代码，逐字逐句进行分析和思考，比较实际的代码和期望的代码，从它们的差异中发现程序的问题和错误。补充文档：桌前检查的文档是一种过渡性的文档，不是公开的正式文档。通过编写文档，也是对程序的一种下意识的检查和测试，可以帮助程序员发现和抓

住更多的错误。这种桌前检查，由于程序员熟悉自己的程序和自身的程序设计风格，可以节省很多的检查时间，但应避免主观片面性。代码会审（CodeReadingReview）代码会审是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的

过程。代码会审分两步：第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步：召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出

问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。在会前，应当给会审小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的实效。这个常见

错误清单也叫做检查表，它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供在会审时使用。走查（Walkthroughs）走查与代码会审基本相同，其过程分为两步。第一步也把材料先发给走查小组每个成员，让他们认真研究程

序，然后再开会。开会的程序与代码会审不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。

人们借助于测试用例的媒介作用，对程序的逻辑和功能提出各种疑问，结合问题开展热烈的讨论和争议，能够发现更多的问题。调试（Debug）软件调试是在进行了成功的测试之后才开始的工作。它与软件测试不同，调试的任务是进一步诊断和改正程

序中潜在的错误。调试活动由两部分组成：确定程序中可疑错误的确切性质和位置。对程序(设计,编码)进行修改，排除这个错误。调试工作是一个具有很强技巧性的工作。软件运行失效或出现问题，往往只是潜在错误的外部表现，而外部表现与内在原因之间常常没有明显的联系。如果要找出

真正的原因，排除潜在的错误，不是一件易事。可以说，调试是通过现象，找出原因的一个思维分析的过程。调试的步骤(1)从错误的外部表现形式入手，确定程序中出错位置；(2)研究有关部分的程序，找出错误的内在原因；(3)修改设计和代码，以排除这个错误；(4)

重复进行暴露了这个错误的原始测试或某些有关测试。(5)如果所做的修正无效，则撤消这次改动，重复上述过程，直到找到一个有效的解决办法为止。从技术角度来看，查找错误的难度在于：现象与原因所处的位置可能相距甚远。

当其它错误得到纠正时，这一错误所表现出的现象可能会暂时消失，但并未实际排除。现象实际上是由一些非错误原因(例如，舍入不精确)引起的。现象可能是由于一些不容易发现的人为错误引起的。错误是由于时序问题引起的，与处理

过程无关。现象是由于难于精确再现的输入状态（例如，实时应用中输入顺序不确定）引起。现象可能是周期出现的。在软、硬件结合的嵌入式系统中常常遇到。几种主要的调试方法调试的关键在于推断程序内部的错误位置及原因。可以采用以下方法：强行排错:

这种调试方法目前使用较多，效率较低。它不需要过多的思考，比较省脑筋。例如：通过内存全部打印来调试，在这大量的数据中寻找出错的位置。（MemoryDump）在程序特定部位设置打印语句，把打印语句插在出错的源程序的

各个关键变量改变部位、重要分支部位、子程序调用部位，跟踪程序的执行，监视重要变量的变化。自动调试工具。利用某些程序语言的调试功能或专门的交互式调试工具，分析程序的动态过程，而不必修改程序。应用以上任一种方法之前，都应当对错误的征兆进行全面彻底的分析，得出对出错位置及错误性质的推

测，再使用一种适当的调试方法来检验推测的正确性。回溯法调试:这是在小程序中常用的一种有效的调试方法。一旦发现了错误，人们先分析错误征兆，确定最先发现“症状”的位置。然后，人工沿程序的控制流程，向回追踪源程序代码，直到找到错误根源或

确定错误产生的范围。例如，程序中发现错误处是某个打印语句。通过输出值可推断程序在这一点上变量的值。再从这一点出发，回溯程序的执行过程，反复考虑：“如果程序在这一点上的状态（变量的值）是这样，那么程序在上一点的状态一定是这样...”，直到找到错

误的位置。归纳法调试:归纳法是一种从特殊推断一般的系统化思考方法。归纳法调试的基本思想是：从一些线索(错误征兆)着手，通过分析它们之间的关系来找出错误。收集有关的数据:列出所有已知的测试用例和程序执行结果。看哪些输入数据的运行结果是正确的，哪些输入数据的运行结果有

错误。组织数据:由于归纳法是从特殊到一般的推断过程，所以需要组织整理数据，以发现规律。常以3W1H形式组织可用的数据：“What”列出一般现象；“Where”说明发现现象的地点；“When”列出现象发生时所有已知情况；“How”说明现象的范围和

量级；“Yes”描述出现错误的3W1H；“No”作为比较，描述了没有错误的3W1H。通过分析找出矛盾来。提出假设:分析线索之间的关系，利用在线索结构中观察到的矛盾现象，设计一个或多个关于出错原因的假设。如果一个假设也提不出来，归纳过程就需要收集更多的数据。此时，应当再设计与执行一些测试

用例，以获得更多的数据。证明假设:把假设与原始线索或数据进行比较，若它能完全解释一切现象，则假设得到证明；否则，就认为假设不合理，或不完全，或是存在多个错误，以致只能消除部分错误。演绎法调试演绎法是一种从一般原理

或前提出发，经过排除和精化的过程来推导出结论的思考方法。演绎法排错是测试人员首先根据已有的测试用例，设想及枚举出所有可能出错的原因做为假设；然后再用原始测试数据或新的测试，从中逐个排除不可能正确的假设；最后，再用测试数据验证余下的假设确是出错的原因。列举所有可能出错原因的假设:把所有可

能的错误原因列成表。通过它们，可以组织、分析现有数据。利用已有的测试数据，排除不正确的假设:仔细分析已有的数据，寻找矛盾，力求排除前一步列出所有原因。如果所有原因都被排除了，则需要补充一些数据(测试用例)，以建立新的假设。改进余下的假设:利用已知的线索，进一步改

进余下的假设，使之更具体化，以便可以精确地确定出错位置。证明余下的假设调试原则在调试方面，许多原则本质上是心理学方面的问题。调试由两部分组成，调试原则也分成两组。确定错误的性质和位置的原则用头脑去分析思考与错误征兆有关的信息。最有效的调试方法是用头脑分析与错误征兆有关的信息

。一个能干的程序调试员应能做到不使用计算机就能够确定大部分错误。避开死胡同。如果程序调试员走进了死胡同，或者陷入了绝境，最好暂时把问题抛开，留到第二天再去考虑，或者向其他人讲解这个问题。事实上常有这种情形：向一个好的听众简单地描述这个问题时

，不需要任何听讲者的提示，你自己会突然发现问题的所在。只把调试工具当做辅助手段来使用。利用调试工具，可以帮助思考，但不能代替思考。因为调试工具给你的是一种无规律的调试方法。实验证明，即使是对一个不熟悉的程序进行调试时，不用工具的人往往比使用工具的人更容易成功。避免用试探

法，最多只能把它当做最后手段。初学调试的人最常犯的一个错误是想试试修改程序来解决问题。这还是一种碰运气的盲目的动作，它的成功机会很小，而且还常把新的错误带到问题中来。修改错误的原则在出现错误的地方，很可能还有别的错误。经验证明，错误有群集现象，当在某一程序段发

现有错误时，在该程序段中还存在别的错误的概率也很高。因此，在修改一个错误时，还要查一下它的近邻，看是否还有别的错误。修改错误的一个常见失误是只修改了这个错误的征兆或这个错误的表现，而没有修改错误的本身。如果提出的修改不能解释与这个错误有关的全部线

索，那就表明了只修改了错误的一部分。当心修正一个错误的同时有可能会引入新的错误。人们不仅需要注意不正确的修改，而且还要注意看起来是正确的修改可能会带来的副作用，即引进新的错误。因此在修改了错误之后，必须进行回归测试，以确认是否引进了新的错误。修改错误的过程将迫使人们暂时回到程序设计阶段。

修改错误也是程序设计的一种形式。一般说来，在程序设计阶段所使用的任何方法都可以应用到错误修正的过程中来。修改源代码程序，不要改变目标代码。GUI测试窗口下拉菜单鼠标操作数据项因为GUI操作相关的排列数非常

大，所以应用自动化工具进行测试文档测试文档错误会同数据和代码错误一样给程序带来灾难性的后果。没有什么精确地按照用户手册操作，但得到地结果却不符合文档的描述更令人气恼的事了。文档测试可以分为两个步骤：第一步为正式的技术复审，检查文档的编辑错误；第二步是活

动测试（LiveTesting)，结合实际程序的使用而使用文档。活动测试可使用黑盒测试方法，基于因果图的测试可以用于描述程序的使用。等价划分和边界值分析可以定义输入类型及相关的交互，然后按照文档跟踪程序的使用。面向对象测试

为了充分地测试OO系统，必须做好三件事：测试的定义必须扩大包括用于OOA和OOD模型的错误发现技术单元和集成测试策略必须有很大的改变测试用例的设计必须考虑OO软件的独特特征扩大测试的视角OO软件工程范型具有演化的性质，模型从对系统需求的非正式的表示开始，逐步演化为详细的类模型、类

关联和关系、系统设计和分配，以及对象设计。在每个阶段，测试模型以试图在错误传播到下一次递进前发现错误。OOA和OOD模型提供了关于系统的结构和行为的实质性信息，为此，它们应该在生成代码前经受严格的复审所有面向对象模型应该被测试（这里测试代表正规的技术复审，因

为这些模型不能被执行，不能进行传统意义上的测试），以保证在模型的语法、语义和语用的语境内的正确性。面向对象的测试策略当考虑面向对象的软件时，单元的概念发生了变化。封装驱动了类和对象的定义，这意味着每个类和类的实例（对象）包装了属性（数据）

和操纵这些数据的操作（也称为方法或服务）。而不是个体的模块。最小的可测试单位是封装的类或对象，类包含一组不同的操作，并且某些特殊的操作可能作为一组不同的类的一部分存在，因此，单元测试的意义发生了很大的变化。

不再孤立地测试单个操作（传统的单元测试观点），而是将操作作为类的一部分。传统的单元测试往往关注模块的算法细节和模块接口间的数据流动，OO软件的类测试是由封装在类中的操作和类的状态行为所驱动的。面向对象的测

试策略因为面向对象软件没有层次的控制结构，传统的自顶向下和自底向上集成策略就没有意义，此外，一次集成一个操作到类中（传统的增量集成方法）经常是不可能的，这时由于“构成类的成分的直接和间接的交互”对OO软件的集成策略有两种不同的策略第一种称为基于线程的测试：集成对回应系统的一个输入或

事件所需的一组类，每个线程被集成并分别测试，应用回归测试以保证没有产生副作用。第二种称为基于使用的测试，通过测试那些几乎不使用服务器类的类（称为独立类）而开始构造系统，在独立类测试完成后，下一层的使用独立类的类，称为依赖类，被测试。这个依赖层次的测试序列一直持续到构造完整个系统为止。序列和传统集

成不同，驱动模块和桩模块作为替代操作是要尽量避免的。集群测试（Clustertesting）是OO软件集成测试的一步，这里一群协作类通过设计试图发现协作中的错误的测试用例而被测试。面向对象测试和传统测试白盒测试方法可以用于对类定义的操作的测试黑盒测试方法对OO系统同样适用，US

ECASE可以作为黑盒及基于状态的测试的设计提供有用的输入。使用USECASE作为有效性测试的主要驱动基于场景的测试主宰了OO系统的有效性。客户/服务器系统的测试客户/服务器系统的分布式性质为软件测试者带来了一

些独特的问题：客户端GUI的考虑目标环境及平台多样性的考虑分布数据库的考虑（包括复制的数据）分布处理的考虑非鲁棒的目标环境非线性的性能关系整体C/S测试策略通常，客户/服务器软件的测试发生在三个不同的层次：个体的客

户端应用以“分离的”模式被测试——步考虑服务器和底层网络的运行客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑完整的C/S结构，包括网络运行和性能，被测试C/S应用中经常使用的测试方法应用功能测

试：用前面讲到的方法测试客户端的应用。在本质上，应用被独立的测试，以揭示在运行中的错误服务器测试：测试服务器的协调和数据管理功能，也考虑服务器性能（整体反应时间和数据吞吐量）数据库测试：测试服务器存储的数据的精确性和完整

性，检查客户端应用提交的事务，以保证数据被适当地存储、更新和检索。事务测试：创建一系列地测试以保证每类事务被按照需求处理。测试着重于事务处理的正确性，也关注性能问题（如事务处理时间和事务量测试）网络通信测试：这些测试验证网络节点间的通信正确

的发生，并且消息传递、事务和相关的网络交通无错的发生。网络安全性测试也可能作为测试的一部分。WEB系统的测试静态测试：识别网页中的静态错误浏览测试：测试导航和链接的正确性功能测试：包括传统测试中的单元测试、集成测试和系统测试非功能测试大规模集成测试静态测试HTM

L测试浏览器兼容性测试VisualBrowsevalidation内容检查浏览测试链接测试加载及加载时间测试交易验证功能测试脚本的功能测试组件测试：CGI、ActiveX交易测试应用程序测试可以直

接使用浏览器浏览、导航无状态性Cookie测试失去网络连接的测试国际性测试非功能性测试配置测试性能吸收测试/可靠性可用性测试可用性测试安全性测试大规模集成测试外部链接测试传统系统集成测试端到端

功能测试非功能测试大规模集成测试RUP中的测试工作流测试的目的在于：核实对象之间的交互。核实软件的所有构件是否正确集成。核实所有需求是否已经正确实施。确定缺陷并确保在部署软件之前将缺陷解决。在很多组织中，软件测试占软件开发费用的30%到50%。但大多数人仍然认

为软件在交付之前没有进行充分的测试。这一矛盾根植于两个明显的事实。第一个，测试软件十分困难。给定程序具有无数的不同行为方式。第二个，测试通常是在没有明确的方法，不采用必须的自动化手段和工具支持的情况下进行的。

RUP中的测试工作流由于软件的复杂性，无法实现完全测试，但采用周密的方法和最新技术水平的工具可以明显提高软件测试的生产率和有效性。对于失败将导致人员伤亡这类“安全至上”的系统（如空中交通管制系统、导弹制导系统、或医用输送系统）来

说，高质量的软件是系统成功的要素。对于典型的MIS系统，上述情况不是非常明显，但是消除缺陷造成的影响将需要相当昂贵的开支。在软件生命周期的早期启动的执行良好的测试，将明显降低完成和维护软件的开支。它还可以大大降低与部署

质量低劣的软件相关的责任或风险，如用户的生产率低下、数据输入和计算错误，以及令人无法接受的功能行为。现在，许多MIS系统是“任务至上”的，也就是说当出现失败时，公司将无法正常运转并导致大量损失。例如：银行或运输公司。测

试任务至上的系统时，必须使用安全至上的系统所采用的类似严格方法。与其他核心工作流程的关系需求工作流程采集用例模型中的需求，这些需求是用于确定执行什么测试的一个主要输入。分析设计工作流程描述进行设计的方法，这是在确定执行什么测试时的另一个主要输入。实施工作流程生成由测试工作

流程进行测试的实施模型的工作版本。在一次迭代中将测试多个工作版本，第一个是系统集成后的工作版本，最后一个是用于测试整个系统的工作版本。环境工作流程开发并维护测试过程中使用的支持工件，如“测试指南”。管理工作流程对项目和各迭代（说明参见“迭代计

划”）作出计划。工作流程制定测试计划目的此工作流程明细的目的是确定和描述要实施和执行的测试。这是通过生成包含测试需求和测试策略的测试计划来完成的。可以制定一个单独的测试计划，用于描述所有要实施和执行的不同测试类型，也可以为每种测试类型制定

一个测试计划。两者都是可以采用的方法。完成制定测试计划后可以评测和管理测试工作。如何配备人员带有最终用户代表输入的测试设计员是此工作流程明细涉及的主要角色。工作指南以下是可以用于确保得到正确信息的示例方法：访谈调查问卷功能监测活动：制定测试计

划目的收集和组织测试计划信息。创建测试计划。步骤确定测试需求评估风险制定测试策略确定资源创建时间表生成测试计划输入工件：补充规约用例模型设计指南设计模型类用例实现软件构架文档构件和实施子系统迭代计划测试指南生成

工件：已完成的测试计划测试计划概述测试计划的目的是明确测试活动的意图。尽早地创建测试计划文档是非常关键的一项任务。在精化阶段首批迭代的早期生成该工件并不算太早。最好以迭代的方式编制测试计划，并且在获得相应信息时添加各部分内容。应谨慎而明确地表述测试范围、测试要求、测试策

略以及所需资源。这些信息可确定测试工作的目的和范围、测试的内容、测试的方式以及测试所需的资源。明确地表述这些信息将加快对测试工作的复审、反馈和批准。在项目开始时，应创建一个确定整个项目的预期测试活动的测试计划，该测试计划称为

“主测试计划”。当对每次迭代进行计划时，将创建更精确的“迭代测试计划”（或按测试类型来组织的几个测试计划），其中只包括与本次迭代相关的数据（测试需求、测试策略、资源等等）。或者，在不会使迭代计划难于管理或使用的前提下，还可以在迭代计划中包括这些迭代测试信息。为了更好地确定和

传达测试需求、测试风险和优先级以及测试策略，可以采用以下提供的一些指南。确定测试需求目的：确定测试对象并指明测试范围。确定测试需求是测试计划活动的开始。测试需求确定测试对象以及测试工作的范围和作用。测试需求还用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基

础。被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。执行如下步骤确定测试需求：复审所有材料。指明测试需求。本步骤产生的结果是一份确定将成为测试目标的需求的报告（层次

结构）。确定测试需求复审所有材料。由于测试需求可从多种来源确定，因此作为第一步，对将要开发的应用程序/系统的所有可用材料进行复审是十分重要的。最常用的测试需求来源包括现有的需求列表、用例、用例模型、用例实现、补充规约、设计需求、商业理由、最终用户访谈以及对现有

系统的复审。指明测试需求。除确定测试需求的来源之外，还必须有某种形式的确定方法来确定将成为测试目标的需求。这将导致测试需求层次的产生。该层次可能基于现有的层次结构，也可能是新近生成的。层次结构是测试需求的逻辑分组。常用分组方法包括按照用

例、商业理由、测试类型（功能、性能等）或者以上各项的组合对项目进行分组。功能性测试需求正如其名称所示，功能性测试需求来自于测试对象的功能性行为说明。每个用例至少会派生一个测试需求。对于每个用例事件流，测试需求的详细列表至少会包括一个测试需求。性能测试需求性能测试需

求来自于测试对象的指定性能行为。性能通常被描述为对响应时间和/或资源使用率的某种评测。性能在各种条件下进行评测，这些条件包括不同的工作量和/或系统条件不同的用例不同的配置性能需求在补充规约中说明。检查这些材料，对包括以下内容的语句要

特别注意：时间语句，如响应时间或定时情况指出在规定时间内必须出现的事件数或用例数的语句将某一项性能的行为与另一项性能的行为进行比较的语句将某一配置下的应用程序行为与另一配置下的应用程序行为进行比较的语句一段时间内的操作可靠性（平均故障时间或MTTF）配置或约束应该为规约中反

映以上信息的每个语句生成至少一个测试需求。可靠性测试需求测试可靠性需求有若干个来源，它们通常在补充规约、用户界面指南、设计指南和编程指南中进行说明。检查这些工件，对包括以下内容的语句要特别注意：有关可靠性或对故障、运行时错误（如内存减少

）的抵抗力的语句说明代码完整性和结构（与语言和语法相一致）的语句有关资源使用的语句应该为工件中反映以上信息的每个语句生成至少一个测试需求。评估风险和确定测试优先级目的最大限度地提高测试效率并确定测试工作的优先级。制定一个可接受的测试顺序。要获得对风险的认识，请执行如下操

作：确定并验证风险因子确定并验证实施概要因子确定并验证测试优先级因子确定并验证测试风险因子测试工作需要平衡资源约束和风险。最重要的测试需求能够反映最高的风险。可从以下几个方面观察风险：效果-用例（需求等）失效造成的影响或后果原因-确定不

合需要的结果，并确定哪些用例或需求一旦失效将产生该结果。可能性-用例或需求失效的概率复审每一项测试需求并确定风险因子（比如高、中或低）。有时从两个或更多方面对风险进行评估可能会得到不同的风险因子。在这种情况下，请使用最高的风险因子值。同时还应给出关于对某一

给定测试需求为何选择特定风险因子的说明。评估风险为了确定测试优先级，首先要评估风险。有些用例或构件会因为故障而导致最大的风险，或者很可能会发生故障。对于这些用例或构件应该首先进行测试。在开始时可确

定并说明将要使用的风险程度指标，例如：H-高风险，无法忍受。极易遭受外部的风险。公司将遭受巨大的经济损失、债务或不可恢复的名誉损失。M-中等风险，可以忍受，但是不希望其出现。遭受外部风险的可能性最小，公司可能会遭受经

济损失，但只存在有限的债务或名誉损失。L-低风险，可以忍受。根本不会或不太可能遭受外部的风险，公司只有少许经济损失或债务或根本没有损失。公司的名誉也不会受到影响。评估风险在确定风险程度指标之后，列出测试对象中的每个用例或构件。为列表中的每一个用例或构件确定一个风险

程度指标，并简要说明您选择相应值的原因。可以从三个方面来评估风险：结果-指定用例（需求等）失效后将造成的影响或后果原因-用例失效所导致的非预期结果可能性-用例失效的可能性。选择一个方面，确定风险程度指标并说明您所作选择的原因。不必为风险的每个方面

都确定一个指标。然而，如果确定了一个低风险指标，最好再从另一个方面来评估该风险，以确保它的确是低风险。影响要根据结果评估风险，应确定条件、事件或操作，从而确定它的影响。询问以下问题："如果___________，将出现什么情况？"例如："如果在安装新软件时，系统磁盘空间不足，将出现

什么情况？""如果Internet连接在查询事务过程中丢失，将出现什么情况？""如果Internet连接在购买事务过程中丢失，将出现什么情况？"“如果用户输入一个非预期值，将出现什么情况？”以下是这些问题的理由矩阵示例说明风险降低因子理由安装过程中磁盘空间不足H用户会从软件安

装中获得对该产品的第一印象。任何非预期的结果（如下列结果）都会降低用户系统（即已安装的软件）的性能，并给用户造成一种负面的印象：软件仅部分安装（部分文件、部分注册项），使已安装的软件处于不稳定的环境下；或者安装过程异常终止，使系统处

于不稳定的状态Internet连接在查询过程中丢失L这种连接丢失不会给数据或数据库造成损坏。但应该注意到：连接丢失会给用户造成一种负面的印象。Internet连接在购买过程中丢失H导致以下结果的连接丢失或事务丢失会

增加日常开支并降低利润，因此都是不可接受的：数据库崩溃订单不完整数据或订单丢失（重复的）多重订单输入了非预期值H任意导致下列结果的事务都是无法接受的：数据库崩溃数据不准确原因与根据结果评估风险相对的是根据原因评估风险。在开始时可以声明某个非预期的事件或条件，并确定一组能够

允许该条件存在的事件。询问如下问题："___________为什么会发生？"例如："为什么只有部分文件存在于系统中而且没有构造出所有的注册项？""事务为什么没有在中央数据库中得到适当的反映？""付帐循环语句为什么只反映了数据库中满足

预期标准的部分记录?"以下是这些问题的理由矩阵示例：说明风险降低因子理由缺少/应用程序文件和注册项H致使应用程序（并可能使系统）不可用。安装使用户得到对应用程序的第一印象。如果安装失败，用户就会对该软件形成负面的印象。导致这

种情况的原因可能包括：安装过程没有安装所有文件，并且没有正确地更新注册表因用户干涉（取消或退出）而使安装过程异常终止因软件/硬件干涉（磁盘空间不足、配置不被支持等）而使安装过程异常终止因未知情况而使安装过程异常终止用户删除了文件/注册项在这些原因中，只有最后一个是安装过程所无法检测和

处理的。订单不完整H由于无法执行不完整的订单，因而会导致收入和客户两方面的损失。可能的原因包括：因用户操作（断开调制解调器、关闭PC等）而导致Internet连接丢失因IP而导致Internet连接丢失

因雇员操作（断开调制解调器，关闭服务器电源等）而导致Internet连接丢失说明风险降低因子理由数据/数据库崩溃H无论是因为何种原因，数据的崩溃都是不可容忍的。可能的原因包括：因用户的干涉而没有完成/提交将写入数据库的事务因Internet连接丢失而没有完成/提交将写入

数据库的事务用户在事务中输入无效的数据数据库访问方法/实用程序数据库没有正确地装入（当进行初始实例化时）订单出现重复H重复的订单会导致货运、处理以及重新进货等方面的成本，从而将增加公司的日常开支并降低利润。可能的原因包括：因用户干涉、用户两次输入订单而没有确认输入而重复将订单写入

数据库这一事务因非用户干涉（从丢失的Internet连接中进行恢复、恢复数据库等）而重复将订单写入数据库这一事务说明风险降低因子理由某个订单的数据不准确H任何无法完成的订单或导致额外日常开支的订单都是不可接受的。可能的原因

包括：因用户干涉而没有完成/提交订单事务因Internet连接丢失而没有完成/提交订单事务用户输入无效的数据在语句中反应出错误的记录数H业务决策和应收帐款都依赖于这些报告的准确性。可能的原因包括：搜索/选择标准不正确SQL语句不正确数据

库中的数据被破坏数据库中的数据不正确可能性根据可能性来评估风险也就是确定用例（或实施用例的构件）失效的概率。这种概率通常基于某个外部因素，例如：故障率和/或密度变更率复杂性来源/始创人应该注意的是：当根据这一方面来评估风

险时，风险程度指标与发生故障的概率相关，而不是与故障对组织的影响（它用于根据结果和原因来评估风险）相关。这些因素与发生故障的概率之间存在以下相关性外部因素概率故障发现率和/或密度发生故障的概率随着故障发现率或密度的增加而增加。缺陷有聚集的趋势，因此，随着用例或构件内缺陷发现率或缺陷数

量（密度）的增加，发现另一个缺陷的概率也会增加。由于先前的高发现率或密度表明了其他故障的高概率，所以当利用此因素来评估风险时，还应该考虑先前版本中的发现率和密度。变更率随着用例或构件变更率的增加，发生故障的概率也会增加。因而，当变更次数增加时，导致某个缺陷的

概率也会随之增加。每改动一次代码，都存在向代码“注入”另一个缺陷的风险。复杂性随着用例或构件复杂程度的增加，发生故障的概率也会增加。来源/始创人有关代码来源和代码编写者的知识和经验会增加或降低发生故障的概率。如果使用第三

方构件，通常会降低发生故障的概率。然而，其前提是第三方构件已经通过认证（通过正式测试或经验判断，证明它满足您的需求）。发生故障的概率通常随着实施员知识和技能的增加而降低。然而，即使由最优秀的人员来实施，使用新工具、新技术以及担任多个角色等情况也会增加发生故障的概率。说明风险降低因

子理由安装新软件H我们正在编写自己的安装实用程序。致使应用程序不可用。安装使用户得到对应用程序的第一印象。如果安装失败，用户将对该软件形成负面的印象。安装新软件L我们使用的是已经取得商业成功的安装实用程序。虽然失败的安装会导致应用程序不可用，但我们选择的是由一

个成功厂商提供的安装实用程序，该厂商的产品已经占有了最大的市场份额，其从业时间也超过四年。我们对他们的评估表明，该产品符合我们的需要而且客户也对他们的产品、厂商以及他们的服务和水平感到满意。用例1、10、12中的高故障发现率/缺陷密度。H由于先

前的高故障发现率和缺陷密度，用例1、10和12被认为是高风险的。用例14和19中的变更请求H对这些用例进行的大量更改将增加在代码中“注入”缺陷的可能性。确定实施概要评估风险和确定测试优先级的下一个步骤是确定测试对象的实施概要。在开始时可确定和说明将要使用的实施概要程度指

标，例如：H-使用得相当频繁，在每个时期会使用很多次，或者由多个主角或用例使用。M-使用得比较频繁，在每个时期会使用若干次，或者由若干个主角或用例使用。L-很少使用，或者由很少的几个主角或用例使用。所选择的实施概要指标应该基于用例或构件的

执行频率，其中包括：一个主角（或用例）在给定时间内执行用例（或构件）的次数，或者执行用例（或构件）的主角（或用例）的数量通常，用例或构件的使用次数越多，实施概要指标也就越高。确定实施概要在确定实施概要程度指标之后，列出测试对象中的每个

用例或构件。为列出的每一项确定一个实施概要指标并且说明每个指标值的理由。工作量分析文档中的信息（请参阅工件：工作量分析文档）可用于此评估。示例：安装新软件对联机目录项进行排序在发出订单后，客户联机查询他们的订单商品选择对话框确定实施概要说明实施概要因子理由安装

新软件H（通常）只执行一次，但是由许多用户执行。然而，不进行安装，应用程序就无法使用。对目录项进行排序H这是用户执行得最多的用例。客户查询订单L很少有客户在发出订单后查询他们的订单商品选择对话框H客户使用此对话框

来发出订单，而负责库存的职员则利用此对话框来补充库存。确定测试优先级评估风险和确定测试优先级的最后一步是确定测试优先级。在开始时可确定和说明将要使用的测试优先程度指标，例如：H-必须测试M-应该测试，只有在测试完所有H项后才进行测试L-可能会测试，但只有在测试完所有H和M项

后才进行测试在确定要使用的测试优先程度指标之后，列出测试对象中的每个用例或构件。然后，为列出的每一项确定一个测试优先级指标并且说明您的理由。以下为确定测试优先级指标提供了一些指南。当确定每一项的测试优先级指

标时，应考虑下列各项：先前确定的风险程度指标值先前确定的实施概要程度指标值主角说明（主角是否有经验？他们是否能够接受变通方法？等等）合同责任（如果不交付用例或构件，测试对象能否被接受？）确定测试优先级确定测试优先级的策略包括：对于每一项，将最高的评估因素（风险、实施概要等）值用作总

体优先级。确定一个最有意义的评估因素（风险、实施概要及其他），然后将该因素的值用作优先级。使用评估因素的组合来确定优先级。采用权重方案。在该方案中，将确定每个因素的权重，然后根据权重来计算各因素的值和优先级。示例：安装新软件对

联机目录项进行排序在发出订单后，客户联机查询他们的订单商品选择对话框当使用最高的评估值来确定优先级时，得到的优先级为：测试项风险实施概要主角合同优先级安装新软件HHLHH对目录项进行排序HHHHH客户查询LLLLL商品选择对话框LHLLH

当使用一个因素（风险）的最高评估值来确定优先级时，得到的优先级为：测试项风险实施概要主角合同优先级安装新软件HHLHH对目录项进行排序HHHHH客户查询LLLLL商品选择对话框LHLLL当使用权重值来计算优先级时，得到的优先级为：（注：在以下的矩阵中：H=5，M=3

，L=1。总权重值大于30则为高优先级的测试项；如果权重值在20和30之间，则为中优先级；当小于20为低优先级。）测试项风险(x3)实施概要(x2)主角(x1)合同(x3)权值优先级安装新软件5（15）5(10)1(1)5(15)41H(2对目录项进行排序5(15)5(10)5(5)5(15)45

H(1)客户查询1(3)1(2)1(1)1(3)9L(4)商品选择对话框1(3)5(10)1(1)1(3)17L(3)制定测试策略目的确定并传达测试手段和工具确定并传达用于确定产品质量和测试是否完成的评估方法测试策略的目的是向每一个人传达如何进行测试以及采用何种评测标

准来确定测试的完成和成功程度。策略不必十分详尽，但它应该向读者指明如何进行测试。一个好的测试策略应该包括下列内容：要实施的测试类型和测试的目标将实施测试的阶段技术用于评估测试结果和测试是否完成的评测和标准对测试策略所述的测试工作存在影响的特殊事项测试类型和目标应清楚地说

明所实施测试的类型和测试的目标。清楚地说明这些信息有助于尽量避免混淆和误解（尤其是由于有些测试看起来非常类似）。测试目标应该表明执行测试的原因。示例：“功能性测试。功能性测试侧重于从用户界面上执行在测试对象内实施的以下用例。”“性能测试。系统的性能测

试将侧重于测评用例2、4和8-10的响应时间。对于这些测试，将使用一个主角的工作量来执行这些用例，而且不在测试系统上施加任何其他的工作量。”“配置测试。通过执行配置测试来确定和评估测试对象在三种不同配置下的行为，并根据我们的基准配置来比较性能特征。”测试阶段测试

阶段测试类型单元集成系统验收功能性测试（配置、功能、安装、安全性、容量）XXXX性能测试（各个构件的性能曲线）XX(X)可选，或者当系统性能测试发现缺陷时性能测试（工作量、强度和竞争）XX可靠性（完整性，结构）XX(X)可选，或

者当其他测试发现缺陷时技术技术应该说明将如何实施和执行测试。其中包括测试内容、在测试执行过程中执行的主要操作以及用于评价结果的方法。示例：功能性测试：对于每个用例事件流，将确定一组有代表性的事务，每个事

务都代表了执行用例时主角所执行的操作。将为每个事务开发最少两个测试用例：一个测试用例用于反映肯定条件而另一个则反映否定（无法接受的）条件。在第一次迭代中，将按照以下方式来测试用例1-4和12：•用例1：•在用例1开始时，主角登录到应用程序中并位于主窗口。当用户指定“保存”时，用例1终止。

•每个测试用例将使用RationalRobot来实施和执行。•将使用以下方法来核实和评估每个测试用例的执行情况：–测试脚本的执行（每个测试脚本是否成功地按计划执行？）–窗口存在或对象数据核实方法（在测试脚本中实施）将用于核实测试对象在测试执行过程中是否获取或显示了关键窗口的显示和指定

数据。–在测试前和测试后将对测试对象的数据库（使用MicrosoftAccess）进行检查，以核实在测试过程中执行的更改是否在数据中得到了准确的反映。性能测试：对于每个用例，使用RationalPerformanceStudio（VU脚本）和Rationa

lRobot（GUI脚本）来实施和执行一组有代表性的事务（即在工作量文档中确定的事务）。测试脚本和测试执行时间表中将至少反映三种工作量，其中包括：强度工作量：750个用户（15%的管理人员、50%的销

售人员、35%的营销人员）最大工作量：350个用户（10%的管理人员、60%的销售人员、30%的营销人员）额定工作量：150个用户（2%的管理人员、75%的销售人员、23%的营销人员）用来执行每个事务的测试脚本将包括适当的计时器来获取响应

时间，例如总的事务时间（在工作量分析文档中定义）和关键事务活动或进程的时间。测试脚本执行这些工作量的持续时间将是一个小时（除非工作量分析文档中另有说明）。对（某个工作量的）每个测试执行执行的核实和评估将包括：将使用状态柱状图来监测（以核实测试和工作量是否正在按预定计划执行）测试执行情况

测试脚本的执行（每个测试脚本是否成功地按计划执行？）使用以下报告来获取和评估已确定的响应时间：•性能百分位数•响应时间完成标准规定完成标准的目的在于以下两方面：确定可接受的产品质量确定测试工作成功实施的时间表述明确的完成标准应该包括以下内容：所测评的功能、行为或条件测评方

法标准或与测评的相符程度示例1所计划的测试用例已全部执行经确定的所有缺陷都已得到了商定的解决结果所计划的测试用例已全部重新执行，已知的所有缺陷都已按照商定的方式进行了处理，而且没有发现新的缺陷。完成标准示例2高优先级的测试用例已

全部执行。经确定的所有缺陷都已得到了商定的解决结果。严重性为1和2的缺陷已经全部解决（状态=固定或延期）。高优先级的测试用例已全部重新执行，已知的所有缺陷已按照商定的方式进行了处理，而且没有发现

新的缺陷。示例3所计划的测试用例已全部执行。经确定的所有缺陷都已得到了商定的解决结果。严重性为1和2的缺陷已经全部解决（状态=核实或延期）。高优先级的测试用例已全部重新执行，已知的所有缺陷已按

照商定的方式进行了处理，而且没有发现新的缺陷。特殊的考虑事项本节应该确定所有会影响测试策略中所述测试工作的影响因素或依赖关系。这些影响因素可能包括：人力资源（如用来支持/参与测试的非测试资源的可用性或对

这些资源的需要）约束（例如设备限制或可用性，或对特殊设备的需要/特殊设备的缺乏）特殊需求（例如测试时间安排或对系统的访问）示例：测试数据库将需要数据库设计员/管理员的支持来创建、更新和刷新测试数据。系统性能测试将使用现有网络（支持非测试通信）上的服

务器。需要在几个小时之后安排测试，以确保网络上不存在非测试通信。为了实施和执行全功能性测试，测试对象必须使遗留系统同步（或模拟同步）。确定资源目的确定测试所需的资源，包括人力资源（技能、知识、可用性）、硬件、软件、工具等。一旦确定测试对象和测试方法，就需要确定执行

测试人员及测试活动所需支持。确定资源需求包括确定所需的资源，资源包括如下：人力资源（人员数量和技能）测试环境（包括硬件和软件）工具数据确定人力资源需求对于大多数测试工作而言，您需要符合下列条件的人力资源：管理和制定测试计划设计测

试及数据实施测试和数据执行测试并评估结果管理和维护测试系统确定非人力资源需求测试环境（包括硬件和软件）推荐使用两个不同的物理环境（尽管这不是必需的）：执行测试管理、设计和实施活动的实施环境，以及执行所有测试的执行环境，它是一个独立的执行系统（通

常是生产系统的克隆）。软件也有必要进行测试。需要测试的软件最少应包括所测试的应用程序、客户机操作系统、网络以及服务器端操作系统。此外，可能还需要精确地模拟/复制生产环境的软件，这类软件包括：与其他系统

（如遗留系统）的接口。其他桌面应用程序，如MicrosoftOffice、LotusNotes等。其他驻留于文件服务器和网络或在其中执行的应用程序。当所测试的应用程序不需要这些应用程序时，它们就驻留在其执行环境中。确定非人力资源需求工具应该声明何种

软件工具（供测试用）将被使用、被谁使用，以及使用各种工具所能够获得哪些信息或好处。数据软件测试在很大程度上取决于输入数据（创建或支持某一测试条件）和输出数据（同预期结果作比较）的使用。应确定解决以下与测试数据有关的问题的策略：收集或生成用于测

试的数据（输入和输出）。数据库构架（隔离外界影响的手段以及在测试完成后将数据返回初始状态的方法）。创建时间表目的确定并传达测试工作、时间表和里程碑。创建时间表包括：估计测试工作制定测试时间表估计测试工作估计测试工作时，应考虑如下假设：投入到项目中的人力资源的生产率和技能/知

识水平（比如他们使用测试工具或程序的能力）。要构建的应用程序的有关参数（比如窗口数目、构件、数据实体和相互关系以及重复使用的百分比等）。测试覆盖（实施并执行测试的可接受深度）。如果只实施和执行一个测试用例（对每一个用例/需求），则表述每一个用例/需求是不同的。经常需要多个测试用例来对某一

个用例/需求进行可以接受的测试。测试估计还应考虑到在测试生命周期的各个阶段使用不同方式对工作进行划分，这是因为某些类型的（工作）量在生命周期内是变化的。例如，性能测试工作，由于其包含在复杂环境中建立测试系统并执行测试的工作，因此该测

试执行活动就占了工作估计的很大比重。估计测试工作此划分对于安排时间是很重要的。测试设计和测试实施工作需要一个单独的调度时期，并增加一些小的改进。相比之下，每一个应用程序工作版本都需要重复执行测试，因此必须

对测试执行工作做相应的调整。测试工作需要包含回归测试的时间。下表显示了经过不同测试阶段的几次迭代之后回归测试用例是如何进行积累的。估计测试工作迭代与阶段系统集成单元第一次迭代本次迭代中以系统为目标的测试用例的测试本次迭代中以工作版本为目标的测试用例的测试本次迭代中以单元为目标的测试用例的测试

下一次迭代本次迭代测试用例以及用于回归测试的先前迭代的测试用例的测试。对本次迭代测试用例以及用于回归测试的先前迭代的测试用例的测试。本次迭代测试用例以及用于回归测试的先前迭代的测试用例的测试。制定测试时间表测试项目时间表可以通过工作估计和资源分配来建立。在迭代开

发环境中，每一迭代都需要一个独立的测试项目时间表。在每一迭代中都将重复所有的测试活动。在某一特定迭代中，测试计划和测试设计活动处理软件中的新功能。测试实施活动包括为新功能创建新的测试用例，并为已变更的功能修改测试用例。测试执行和评估步骤验证新功能并为

现有功能执行回归测试。早期迭代引入许多新功能和新测试。随着集成流程继续进行，新测试的数目将减少，而需要执行以检验累计功能的回归测试的数目将增加。因此，早期迭代更多地要求在测试计划和设计上进行工作，而后期迭代则偏重于测试执

行和评估。制定测试时间表制定测试时间表为每一迭代提供详尽的时间表是不可能的。通常并不知道将会有多少迭代，或者在哪一次迭代中将达到某一测试标准。使用估计好的工作和已分配的资源创建测试工作的时间表。以下示例表概述了所有测试活动。显示的工作估计是各项任

务的相对工作数量。在制定时间表时，必须确保它符合实际。有些时间表很有野心，但人们没有足够的时间或精力来按时间安排行动，从而导致无法成功执行测试。这样的时间表是再令人沮丧不过的了。制定测试时间表任务有关

工作工作总计38d测试计划7d确定测试项目1d确定测试策略1d估计工作1d确定资源1d安排测试活动的日程1d记录测试计划2d指定测试用例5d确定测试用例5d设计测试7d分析测试需求2d指定测试过程3d指定测试用例1d复审测试需求覆盖1d实施测试

12d建立测试实施环境1d记录并回放原型脚本1d制定测试过程5d测试与调试测试过程1d修改测试过程2d建立外部数据集1d重新测试与调试测试过程1d执行系统测试6d设置测试系统1d执行测试2d核实预期结果1d调查意外结果1d记录缺陷1d评估测试1d

复审测试记录0.25d评估测试用例覆盖0.25d评估缺陷0.25d确定是否满足测试完成标准0.25d制定测试计划目的组织并向其他人员传达测试计划信息。要生成测试计划，请执行如下步骤：复审/改进现有材料确定测试可交

付工件生成测试计划复审/改进现有材料在生成测试计划之前，应该复审所有现有项目信息以确保测试计划包含最新和最准确的信息。如果需要，应修改测试相关信息（测试需求、测试策略、资源等）以反映所有变更。确定测试可交付工件测试可交付工件部分的目的在于落实和规定创建、维护以及如何向其

他人提供测试工件的方法。这些工件包括：测试模型测试用例测试过程测试脚本变更请求生成测试计划制定测试计划活动的最后步骤是生成测试计划。它通过集中收集到的所有测试信息来完成，并生成一份报告。测试计划应至少分发到以下对象：所有测试角色开发人员代表股东代表涉众代表

客户代表最终用户代表设计测试目的此工作流程明细的目的是确定、描述和生成测试模型及其已报告的工件（测试过程和测试用例）。设计测试已经完成，测试的实施和执行工作效率较高，并且达到了预期的效果如何配备人员带有用例阐释者输入的测试设计员是此工作流程明细所涉及的主要角色。工作指南以下是可以

用于确保得到正确信息的示例方法：访谈调查问卷功能监测活动：设计测试目的为每个工作版本确定可验证的测试用例集。确定如何实现测试用例的测试过程。步骤工作量分析（仅用于性能测试）确定并说明测试用例确立并结构化测试过程

复审并评估测试覆盖活动：设计测试输入工件：测试指南测试计划迭代计划产品验收计划质量保证计划补充规约用例模型设计模型类与设计包构件用例实现软件构架文档生成工件：测试模型，设计视图测试用

例测试过程工作量分析文档，（仅用于性能测试）工作量分析文档软件质量要从不同的维度来进行评估，其中包括可靠性、功能和性能。创建工作量分析文档是为了识别并定义不同的变量，这些变量会影响应用程序或系统的性能，

并会影响到评估性能所需的评测。工作量分析文档由以下角色使用：测试设计员使用工作量分析文档来为不同的性能测试生成测试用例测试员使用工作量分析文档来更好地了解测试的目标并正确地实现该目标用户代表使用工作量分析文档来评估在进行性能评估时所执行的工作量

、测试用例和测试的适当性。工作量分析文档中包括的信息侧重于以下主要变量的特征和属性：要在性能测试过程中执行和评估的用例要在性能测试过程中模拟/仿真的主角负载-同时参与的主角的数量和类型、被执行的用例的数量和类型以及时间或吞吐量百分比。将用来执行并评估性能测试的部署系统（实际的、模拟

的或仿真的）用例和用例属性可以为性能测试确定并使用两种类型的用例：关键用例-在性能测试中所评测和评估的用例重要用例-可能对关键用例的性能行为产生影响的非关键用例关键用例并非在测试对象中实施的所有用例都是性能测试的对象。关键用例

是那些将成为性能测试重点的用例，这意味着它们的性能行为将得到评测和评估。要确定关键用例，可确定用例是否符合一条或多条以下标准：用例需要评测和评估性能用例被一个或多个主角频繁执行用例表现出较高的系统使用率百分比用

例需要使用重要的系统资源列出关键用例，以将其包括在性能测试中。在确定并列出关键用例的同时，应检查事件的用例流。特别是，应开始确定当执行用例时在主角（类型）和系统之间的特定事件序列。另外，还需确定（或核实）以下信息：用例的前提

条件，如数据的状态（什么样的数据应/不应存在）和测试对象的状态可能是常量（相同量）的数据，或从一个用例实例到下一个用例实例必须不同的数据该用例与其他用例之间的关系，例如在执行该用例时必须遵循的顺序

用例的执行频率，例如同时执行的用例实例的数量，或用例占系统总负载的百分比重要用例与关键用例不同，关键用例是性能测试的重点，而重要用例是那些可能影响关键用例性能行为的用例。重要用例包括符合一条或多条以下标准的用例：用例必须在执行关键用例之前或之后执行用

例被一个或多个主角频繁执行用例表现出较高的系统使用率百分比用例需要使用重要的系统资源用例在执行关键用例的同时在部署系统上定期执行，如电子邮件或后台打印。在确定并列出重要用例的同时，应检查事件的用例流和附加信息（类似于上面对关键用例进行的检查）。主角和主角属性成功的性能

测试不仅需要确定执行关键用例和重要用例的主角，还必须模拟/仿真主角行为。也就是说，一个主角实例在执行与另一个主角实例相同的用例和事件用例流的同时，可以与测试对象进行不同的交互（响应提示、输入不同数据值等活动需要更长的时

间）。可考虑以下的简单用例：主角和主角属性主角“顾客”在用例执行的第一个实例中是一位有经验的ATM用户，但在另一个主角实例中却是一位没有经验的ATM用户。有经验的ATM主角迅速浏览ATM用户界面，他几乎不会花时间来阅读每条提示，而是按照记忆按动按钮。但没有经验的ATM

主角则要阅读每条提示，并且在作出响应之前要用较多的时间来理解信息。符合实际的性能测试反映了这种差异，从而可确保准确地评估在部署测试对象时的性能行为。首先确定以上列出的各个用例的主角。然后确定可能执行各个用例的不同主角原型。在上面的ATM示例中，可能有以下主角原型：有经验的ATM用户

没有经验的ATM用户ATM用户的帐户位于该ATM的银行网络“之内”（用户的开户银行为拥有该ATM的银行）ATM用户的帐户位于该ATM的银行网络之外（其他竞争银行）主角和主角属性对于每个主角原型，需确定主角属性的

不同值，例如：思考时间-主角响应测试对象的各项提示所用的时间按键速度-主角与接口交互的速度请求速度-主角向测试对象提出请求的速度重复次数-按顺序重复用例或请求的次数交互方法-主角所使用的交互方法，例如使用键盘输入值、切换到某个子段、使用快捷键等，

或使用鼠标“指向并单击”、“剪切并粘贴”等。此外，对于每个主角原型，应确定它们的工作简档，并指定它们要执行的所有用例和流程，以及执行用例的主角所用时间的百分比或工作量的比例。这些信息可用于确定和创建符合

实际的负载（见下面的“负载和负载属性”）。系统属性和变量另外，还必须确定唯一标识环境的部署系统特定属性和变量，因为这些属性也会影响性能的评测和评估。这些属性包括：物理硬件（CPU速度、内存、磁盘缓存等）部署构架（服务器的数量、处理活动的分布等

）网络属性可以与测试对象同时安装和执行的其他软件（和用例）确定并列出性能测试中可以包括的系统属性和变量。该信息可以从多处获得，其中包括：软件构架文档前景文档涉众请求负载和负载属性前面已经提到过，负载是影响测试对象的性能行为的因素之一。负载的定义为：“

模拟的最终用户与测试对象进行交互的实例，以及影响系统使用和性能的变量”准确地确定将被用来执行和评估性能行为的负载是很关键的。一般情况下，性能测试要在不同的负载下执行多次，每种负载都是下列属性的一种变形：与测试对象同时进行交互的主角数量与测试对象进行交互的主角类型（以及

每个主角所执行的用例类型）各个关键用例的执行频率，及其按顺序执行的频率（重复频率）负载和负载属性对于用于评估测试对象性能的每种负载，应确定以上各变量的值。各个变量在不同的负载中所使用的值可以从业务用例模型

（请参见工件：业务用例模型）中获得，或通过观察和访问主角获得。至少应获得三种负载：最佳-反映最佳可能部署条件的负载，例如，只有一个或少数几个主角与系统进行交互、只执行关键用例，这种负载在测试过程中很少执行或根本不执行额外的软件

或用例。额定-反映当前部署条件的负载。峰值-反映最差部署条件的负载，例如，最大数量的主角、执行最大数量的关键用例，这种负载要同时执行许多或所有额外的软件和用例。如果性能测试包括强度测试（请参见概念：性能测试和概念：测试类型）时，应确定几种额外的负载，每种负载都针对

于一个系统或负载变量，并将其设置到部署系统的正常预期容量之上。性能评测和标准只有在对测试进行评测并对性能行为进行评估后，性能测试才能获得成功。在确定性能评测和标准时，应考虑以下因素：要进行哪些评测？在执行测试对象或用例的过程中，关键的评测点在哪里/是什么？判

断性能行为是否可以接受的标准是什么？性能评测在执行测试的过程中可以进行多种不同的评测。要确定将进行的最重要的评测，并证明它们为什么最重要。下面列出了所监测或捕获到的最常见的性能行为：测试脚本状态或状况-以图形化方式描述测试执行过程的当前状态、状况或进

度响应时间/吞吐量-评测（或计算）响应时间或吞吐量（通常表述为每秒钟处理的事务数）。统计性能-使用统计方法（如平均数、标准偏差和百分位数）对响应时间/吞吐量进行评测性（或计算性）的描述。追踪-捕获执行期间主角（测试脚本）与测试对

象之间的来往消息或会话，或者数据流和/或流程。关键性能评测点在上面的“用例和用例属性”部分中已经提到，不必为性能测试执行所有用例。同样，不必为每个被执行的用例进行所有性能评测。通常会有一个（或几个）特定的用例流程专门用于评测。或者，在特定的事件用例流中可能存在特定序列的事件

，这些事件将为评估性能行为而进行评测。应谨慎地为性能行为的评测选择最重要的起“点”和终“点”。它们通常是最显而易见的事件序列，或者是我们可以通过更改软件或硬件来直接影响的点。例如，在上面提到的ATM-提款用例中，从主角进行提款操作的起点到该用例结束的终点（即主角收到他的银行卡而ATM

准备接受另一张卡），我们可以评测整个用例的性能特征，如下图中黑色的“总计花费时间”所示：关键性能评测点关键性能评测点但请注意，有很多事件序列会影响总计花费时间。我们可以控制某些事件序列（例如阅读卡中信息、核实

卡类型、开始与银行系统的通信等，如上图中的B、D和E项），但却无法控制其他序列（例如主角在输入他们的提款金额之前输入他们的PIN或阅读提示，如上图中的A、C和F项）。在上例中，除了评测总计花费时间外，还要评测序列B、D和E的响应时间，因为这些事件的响应时间对主角来说最为显而

易见（并且我们可以通过用于部署的软件/硬件来影响这些响应时间）。性能评测标准一旦确定了关键性能评测和评测点，就要检查性能标准。性能标准在补充规约（请参见工件：补充规约）中列出。如有必要，应修订该标准

。性能评测通常要使用两项标准：响应时间或吞吐率百分位数按秒评测的响应时间或按所处理的事务（或消息）量评测的吞吐率是主要的标准。例如，在“提款”用例中，所规定的标准为“每个B、D和E事件（参见上图）都必须

在3秒钟之内发生（合并后总计为9秒）”。如果在测试过程中，我们注意到每个被确定为B、D或E的事件所花费的时间超过了规定的3秒标准，就要记录一项失败。百分位数评测可以同响应时间和/或吞吐率结合使用，它们用于“在统计上忽略”在规定标准以外的评测

。例如，现在规定的用例性能标准为“B、D或E事件的90%都必须在3秒钟之内发生...”。在测试执行过程中，如果我们评测到所有性能评测中的90%都发生在规定标准之内，就不记录失败。测试用例要使最终用户对

软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技

术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的

需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。确定测试用例之所以很重要，原因有以下几方面。测试用例构成了设计和制定测试过程的基础。测试的“深度

”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。测试用例判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说

明：“95%的关键测试用例已得以执行和验证”，远比“我们已完成95%的测试”更有意义。测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。测试设计和开发的类型以及所需的资源主要都受控于测试用例

。测试用例通常根据它们所关联的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例：一个测试用例用于证明该需求已经满足，通常称作正面测试用例；另一个测试用例反映某个无法接受

、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。从用例中生成测试用例用于功能性测试的测试用例来源于测试目标的用例（请参见工件：用例）。应该为每个用例场景编制测

试用例。用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。例如，下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定

条件下执行。备选流可能会重新加入基本流中（备选流1和3），还可能起源于另一个备选流（备选流2），或者终止用例而不再重新加入某个流（备选流2和4）。用例的事件流示例遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从

基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：场景1基本流场景2基本流备选流1场景3基本流备选流1备选流2场景4基本流备选流3场景5基本流备选流3备选流1场景6基本流备选流3备选流1备选流2场景7基本流备选流4场景8基本流备选流3备选流4

注：为方便起见，场景5、6和8只描述了备选流3指示的循环执行一次的情况。从用例中生成测试用例生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。例如，假定上图描述的用例对备选流3规定如下：“如果在上述步骤

2„输入提款金额’中输入的美元量超出当前帐户余额，则出现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤2„输入提款金额’，此时银行客户可以输入新的提款金额。”据此，可以开始确定需要用来执行备选流3的测试用例：从用例中生成测试用例测试用例ID场景条件预期结果TCx场景

4步骤2-提款金额>帐户余额在步骤2处重新加入基本流TCy场景4步骤2-提款金额<帐户余额不执行备选流3，执行基本流TCz场景4步骤2-提款金额=帐户余额不执行备选流3，执行基本流注：由于没有提供其他信息，以上显示的测试用例都非常简单

。测试用例很少如此简单。一个由用例生成测试用例的更符合实际情况的示例上图中提款用例的基本流和某些备用流：基本流本用例的开端是ATM处于准备就绪状态。1.准备提款-客户将银行卡插入ATM机的读卡机。2.验证银行卡-ATM机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡

。3.输入PIN-ATM要求客户输入PIN码（4位）4.验证帐户代码和PIN-验证帐户代码和PIN以确定该帐户是否有效以及所输入的PIN对该帐户来说是否正确。对于此事件流，帐户是有效的而且PIN对此帐户来说正确无误。5.ATM选项-A

TM显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款”。6.输入金额-要从ATM中提取的金额。对于此事件流，客户需选择预设的金额（10美元、20美元、50美元或100美元）。7.授权-ATM通过将卡ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程

。对于此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户余额。8.出钞-提供现金。9.返回银行卡-银行卡被返还。10.收据-打印收据并提供给客户。ATM还相应地更新内部记录。用例结束时ATM又回到准备就绪状态。上图中提款用例的

基本流和某些备用流：备选流1-银行卡无效在基本流步骤2中-验证银行卡，如果卡是无效的，则卡被退回，同时会通知相关消息。备选流2-ATM内没有现金在基本流步骤5中-ATM选项，如果ATM内没有现金，则“提款”选项将无法使用。备选流3-ATM内现金不足在基本流步骤6中-输入金额，如

果ATM机内金额少于请求提取的金额，则将显示一则适当的消息，并且在步骤6-输入金额处重新加入基本流。备选流4-PIN有误在基本流步骤4中-验证帐户和PIN，客户有三次机会输入PIN。如果PIN输入有误，ATM将显示适当的消息；如果还

存在输入机会，则此事件流在步骤3-输入PIN处重新加入基本流。如果最后一次尝试输入的PIN码仍然错误，则该卡将被ATM机保留，同时ATM返回到准备就绪状态，本用例终止。备选流5-帐户不存在在基本流步骤4中-验证帐户和PIN，如果银行系统返回的代码表明找不到该帐户或禁止从该帐户中

提款，则ATM显示适当的消息并且在步骤9-返回银行卡处重新加入基本流。备选流6-帐面金额不足在基本流步骤7-授权中，银行系统返回代码表明帐户余额少于在基本流步骤6-输入金额内输入的金额，则ATM显示适当的消息并且在步

骤6-输入金额处重新加入基本流。上图中提款用例的基本流和某些备用流：备选流7-达到每日最大的提款金额在基本流步骤7-授权中，银行系统返回的代码表明包括本提款请求在内，客户已经或将超过在24小时内允许提取的最多金额，则ATM显示适当的消息并在

步骤6-输入金额上重新加入基本流。备选流x-记录错误如果在基本流步骤10-收据中，记录无法更新，则ATM进入“安全模式”，在此模式下所有功能都将暂停使用。同时向银行系统发送一条适当的警报信息表明ATM已经暂停工作.备选流y-退出客户可随时决定终止交易（退出）。交易终止，银行卡随之退出

。备选流z-“翘起”ATM包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压器以及动作检测器等。在任一时刻，如果某个传感器被激活，则警报信号将发送给警方而且ATM进入“安全模式”，在此模式下所有功能都暂停使用，直到采取适当的重

启/重新初始化的措施在第一次迭代中，根据迭代计划，我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流：基本流-提取预设金额（10美元、20美元、50美元、100美元）备选流2-ATM内没有现金备选流3-ATM内现金不足备选流

4-PIN有误备选流5-帐户不存在/帐户类型有误备选流6-帐面金额不足可以从这个用例生成下列场景场景1-成功的提款基本流场景2-ATM内没有现金基本流备选流2场景3-ATM内现金不足基本流备选流3场景4-PIN有误（还有输入机会）基本流备选流4场景5-PIN有误（不再有输入机会）基本流备选流4

场景6-帐户不存在/帐户类型有误基本流备选流5场景7-帐户余额不足基本流备选流6注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。导出测试用例对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩

阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结

果。通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是VALID（有效的）才可执行基本流，而I（无效）用于表明这种条件下将激活

所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。测试用例TCID场景/条件PIN帐号输入/选择的金额帐面金额ATM内的金额预期结果CW1.场景1-成功的提款VVVVV成功的提款。CW2.场景2-ATM内没有现金VVVVI提款选项不可用，用例结束CW

3.场景3-ATM内现金不足VVVVI警告消息，返回基本流步骤6-输入金额CW4.场景4-PIN有误（还有不止一次输入机会）IVn/aVV警告消息，返回基本流步骤4，输入PINCW5.场景4-PIN有误（还有一次输入机会）IVn/aVV

警告消息，返回基本流步骤4，输入PINCW6.场景4-PIN有误（不再有输入机会）IVn/aVV警告消息，卡予保留，用例结束测试用例在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用

例CW1称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由CW2至6表示（阴影单元格表明这种条件下需要执行备选流

）。虽然CW2至6对于基本流而言都是负面测试用例，但它们相对于备选流2至4而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1-基本流）。每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景4正是这样的一个示例。要全面地测试场景4-PIN

有误，至少需要三个正面测试用例（以激活场景4）：输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤3-输入PIN。输入了错误的PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。最后一次输入时输入了“正确”的PIN。备选流在步骤5-输入金额处重新加入基本流。测试

用例注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看V和I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了

充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完全，如场景6-不存在的帐户/帐户类型有误和场景7-帐户余额不足就缺少测试用例。一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其

准确且适度，并取消多余或等效的测试用例。测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。测试数据TCID场景/条件PIN帐号输入/选择的金额帐面金额ATM内的金额预期结果CW1.场景1-成功的提款4987123505002000成功的提款。

CW2.场景2-ATM内没有现金49871231005000提款选项不可用，用例结束CW3.场景3-ATM内现金不足498712310050070警告消息，返回基本流步骤6-输入金额CW4.场景4-PIN有误（还有不止一次输入机会）4978123n/a5002000警告消息，返

回基本流步骤4，输入PINCW5.场景4-PIN有误（还有一次输入机会）4978123n/a5002000警告消息，返回基本流步骤4，输入PINCW6.场景4-PIN有误（不再有输入机会）4978123n/a5002000警告消息，卡予保留，用例结束测试用例以

上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：场景6-帐户不存在/帐户类型有误：未找到帐户或帐户不可用场景6-帐户不存在/帐户类型有误：禁止从该帐户中提款场景7-帐户余额不足

：请求的金额超出帐面金额在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）无法读卡（读卡机堵塞、脱机或出现故障）帐户已消户、冻结或由于其他方面原因而无法使用ATM内的现金不足或不能提供所请求的金额（与CW

3不同，在CW3中只是一种币值不足，而不是所有币值都不足）无法联系银行系统以获得认可银行网络离线或交易过程中断电在确定功能性测试用例时，确保满足下列条件：已经为每个用例场景确定了充足的正面和负

面测试用例。测试用例可以处理用例所实施的所有业务规则，确保对于业务规则，无论是在内部、外部还是在边界条件/值上都存在测试用例。测试用例可以处理所有事件或动作排序（如在设计模型的序列图中确定的内容），还应能处理用户界面对象状态或条

件。测试用例可以处理为用例所指定的任何特殊需求，如最佳/最差性能，有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。从补充规约中生成测试用例并不是所有的测试目标需求都将在用例中有所反映。非功能性需求（如性能、安全性和访问控制）以及配置要求等将会说明

测试目标的其他行为或特征。补充规约是为其他行为生成测试用例的主要来源。关于如何生成这些其他测试用例的指南说明如下：为性能测试生成测试用例为安全性测试/访问控制测试生成测试用例为配置测试生成测试用例为安装测试生成测试用例为其他非

功能性测试生成测试用例为性能测试生成测试用例性能测试用例的主要输入是补充规约，补充规约中包含了非功能性需求（请参见工件：补充规约）。为性能测试生成测试用例时，请使用下列指南：对于补充规约内阐明性能标准的各条说明都应

确保至少要确定一个测试用例。性能标准通常表示为时间/事务、事务量/用户或百分数的形式。对每个关键用例，都应确保至少要确定一个测试用例。关键用例是在上述说明中和/或在工作量分析文档中确定的、必须采用性能评测方法来评估的用例（请参见工作量分析文档）。与功能性测试的测试用

例类似，通常对于每个用例/需求都会存在不止一个测试用例。常见的情况是：存在一个低于性能阈值的测试用例、一个处于阈值上的测试用例，还有一个测试用例高于阈值。除了以上性能标准以外，确保已确定影响响应时间的特定条件，包括：数据库的大小-存在多少个记录？工作

量-同时执行操作的最终用户的数量和类型，以及要同时执行的事务的数量和类型环境特征（硬件、网件以及软件配置）将用于性能测试的测试用例记录在类似于功能测试所使用的矩阵中。以下是各种性能测试的一些示例：负载测试TCID

号工作量条件预期结果PCW1.1（单个ATM）完成提款交易全部交易（不依赖于主角的时间）在20秒之内完成PCW2.2（1,000个同时运行的ATM)完成提款交易全部交易（不依赖于主角的时间）在30秒之内完成PCW3.3（10

,000个同时运行的ATM）完成提款交易全部交易（不依赖于主角的时间）在50秒之内完成强度测试TCID号工作量条件预期结果SCW1.2（1,000个同时运行的ATM）数据库锁定-2个ATM请求同一帐户ATM请求排成队列SCW2.2（1,000个同时运行的ATM)无法实现银行系统的通信交易排成队列或

超时SCW3.2（1,000个同时运行的ATM）在交易过程中，银行系统通信被终止显示警告消息为安全性/访问控制测试生成测试用例主角和用例一同说明系统外部用户与系统所执行的动作之间的交互，以便为特定主角生成测试结果。复杂系统包含许多主角，所以我们编制测试用例时必须确保只有指定执行用例的主角可以进行

此操作，这一点非常关键。在基于主角类型的用例事件流存在差别时，尤其如此。例如，在ATM用例中，如果主角“银行客户”的卡和帐户有的属于拥有这个ATM机的银行，有的是竞争银行的银行卡（和帐户），或是企图使用该ATM不支持的银行卡，则将对该主角“银行客

户”执行不同的用例事件流。对于功能性测试用例，请同样遵循上面列举的指南。安全性和访问控制测试用例的示例TCID条件卡（V表明卡有效）读卡机（V表明读卡机工作正常）银行的网络预期结果ACW1.在银行网络之内VVV所有用例都可用ACW2.银行网络之外VVI只有提款用例可用ACW3.无法读

卡IVV警告消息，卡被退出ACW4.因被盗，卡已挂失IVV警告消息，卡予保留ACW5.卡已过期IVV警告消息，卡予保留为配置测试生成测试用例在典型的分布式系统中，允许存在许多种受支持的硬件和软件组合。为了核实测试目标在不同的配置情况下（如不同的操

作系统、浏览器或CPU的速度）能否正常工作或执行，应该对此进行测试。此外，测试还应涵盖构件的组合，以便检测在不同构件的交互中产生的缺陷。例如，确保由应用程序安装的DDL版本不会与另一个应用程序需要的相同DDL的版本发生冲突。采用下列指南来生成用于配置测试的测试用例：确保对每个关键配置，应至少存

在一个测试用例可用于对其进行确定。这是通过确定测试目标的环境所要求的硬件和软件配置以及确定这些配置的优先级来完成的。应确保最先测试最常见的配置，包括：打印机支持网络连接-局域网和广域网服务器配置-服务器驱动程序、服务器硬件台

式机和/或服务器上安装的其他软件所有已安装软件的软件版本确保对于每个可能有问题的配置至少存在一个测试用例。这些配置可能包括：具有最低性能的硬件。历史上存在兼容性问题的共驻内存的软件。通过最慢的LAN/WAN连接访问服务器的客户机。资源不足（缓慢的CPU速度、最小的内存或

分辨率，磁盘空间不足等等）为安装测试生成测试用例安装测试需要核实测试目标可以在所有可能的安装情况下安装。安装情况可以指首次安装测试目标，或是在装有较早版本的机器上安装测试目标的某个较新的版本或工作版本。安装测试还应确保在遇到异常情况时（如磁盘空间不足），测试目标的执行情况仍可接受。测试

用例应包含以下各种软件的安装情况：分发介质，例如磁盘、CD-ROM或文件服务器。首次安装。完全安装。自定义安装。升级安装。客户机服务器软件的安装程序具备一组特定的测试用例。不同于基于主机的系统，服务器和客户机上的安装程序是有所不同的。因而，安装测试应执行

构成测试目标的所有构件的安装，包括客户机、中间层以及服务器，这一点至关重要。为其他非功能性测试生成测试用例理论上,应找到所有必需的输入来生成测试用例模型、设计模型以及补充规约工件的测试用例。不过，如果此时您需要补充已有的输入，那也不足为奇。示例如下：操作测试（用以检验在

某次故障发生后以及在下一次故障发生前“较长时间”内软件的运行情况）的测试用例。对性能瓶颈、系统容量或测试目标的强度承受能力进行调查的测试用例。大多数情况下，您可以通过先前所确定的测试用例生成的某些测试用例来构建其变体或聚合体

，借此来查找测试用例。为单元白盒测试生成测试用例理论上，应通过代码测试每一条可能的路径。在所有这些非常简单的单元内实现这样的目标是不切实际或几乎是不可能的。作为最基本的测试，应将每个决定到决定路径（DD路径）测试至少一次，这

样可确保将所有语句至少执行一次。决定通常是指if语句，而DD路径是两个决定之间的路径。要达到这种程度的测试覆盖，建议您在选择测试数据时应使每个决定都可以用每种可能的方法来评估。为达到上述目标，测试用例应确保：每个布尔表达式的求值结果为true和false。例

如，表达式(a<3)OR(b>4)的求值结果为true/false的四种组合每一个无限循环至少要执行零次、一次和一次以上。可使用代码覆盖工具来确定白盒测试未测试到的代码。在进行白盒测试的同时应进行可靠性测试。为单元黑盒测试生成测试

用例黑盒测试的目的是为了在不了解单元将如何实施指定行为的情况下，对指定行为进行验证。黑盒测试侧重并依赖于单元的输入和输出。等价类划分是一种用来减少所需测试数量的技术。对于每一个操作都应确定参数和对象状态的等价类。等价类是一组值的集合，对这组值来说，对象的行为应

类似。例如，一个集合可有三个等价类：空、若干元素以及满。可使用代码覆盖工具来确定白盒测试未测试到的代码。在进行黑盒测试的同时应进行可靠性测试。如何通过选择特定参数的测试数据来确定测试用例。基于输入参数的测试用例输入参数是由某个操作使用的参数。对于以下每个输入条件，都应通

过使用每个操作的输入参数来编制测试用例：每个等价类的正常值。每个等价类的边界值。等价类之外的值。非法值。请记住要将对象状态视作输入参数。例如：如果在对集合这个对象测试添加操作，您必须使用集合内所有等价类的

值来测试添加操作。所有等价类的值指的是：充满元素的集合、有若干元素的集合、以及空集合。基于输出参数的测试用例输出参数是某个操作所改变的参数。某个参数既可以是输入参数也可以是输出参数。根据以下每个条件选择输入，以便获得输出。每个

等价类的正常值。每个等价类的边界值。等价类之外的值。非法值。请记住将对象状态视为输出参数。例如，假设您对某个列表测试删除操作，您必须选择输入值以便执行操作之后，列表为充满状态、具有若干元素或为空（采用它的所有等价类的值进行测试）。如果对象受状态控制（根据

对象的状态产生不同的反应），您应利用状态矩阵，如下图所示：用于测试的状态矩阵,可以在此矩阵的基础上测试激励和状态的所有组合为产品验收测试生成测试用例产品验收测试是部署软件前的最后测试操作。验收测试的目标在于核实软件是否已经准

备就绪，而且可以由最终用户按软件设计来执行功能和任务。产品验收测试通常不仅涉及执行软件以确认其是否准备就绪，还涉及交付给客户的所有产品工件，如培训、文档和包装。为软件工件生成测试用例是按上文中说明的方式实现的。测试用例可与上面确定的测试用例（正式）或

某个子集（非正式）相同或类似，这取决于产品验收测试的正式程度。不管测试用例的深度如何，应该在实施和执行产品测试之前对测试用例和产品验收计划达成共识。对非软件工件的评估将随着被评估工件的不同而相去甚远。请参见每个特定非软件工件的指南以及核对清单，查看这些工件的评估内容和评估方式

。为回归测试编制测试用例回归测试比较同一测试目标的两个工作版本或版本，并将差异确定为潜在缺陷。据此可假定：新版本应该象早先版本一样操作，并确保并未因为版本的变化而带来缺陷。理想状态下，您可能希望一

次迭代内的所有测试用例都能在后续迭代内使用。应遵照下列指导原则来确定、设计并实施测试用例，这些测试用例可以最大限度地发挥回归测试和复用的价值，同时将维护的成本减至最低：确保测试用例只确定关键的数据元素（创建/支持被测试的条件所需的数据元素）确保每

个测试用例都说明或代表一个唯一的输入集或事件序列，其结果是独特的测试目标行为消除多余或等效的测试用例将具有相同的测试目标初始状态和测试数据状态的测试用例组合到一起测试数据在测试设计活动中，需要确定和描

述两个重要的工件：测试过程和测试用例。如果没有测试数据，这两个工件将无法实施和执行。它们只是对条件、场景和路径的一些说明，而没有具体的值用来简明地确定它们。测试数据虽然本身不是一个工件，但是它对测试的成败产生重要的影响。没有测试数据，将无法实施和执行测试，尤其当要求测试数据作为以下

值时：作为创建条件的输入作为评估需求的输出结果作为支持（作为测试的前置条件）因此，确定这些值是一个重要的工作，并且这项工作在确定测试用例后完成。（请参阅工件：测试用例和指南：测试用例）。确定实际的测试数据时，必须说明处理测试

数据的四个属性：深度-测试数据中数据的容量或数量宽度-测试数据中数据的变化程度范围-测试数据与测试目标的相关性构架-测试数据的物理结构深度深度是在测试中所使用数据的容量或数量。深度是一个需要考虑的重要事项，因为数据太少可能无法反映现实生活的条件，而数据太多将难以管理和维护。理想条件下，

测试应首先使用一个小的支持关键测试用例的数据集（通常为正面测试用例）。随着测试过程中信心不断增强，应该增加测试数据，直到数据深度完全体现出部署环境（或适当可行的范围）为止。测试数据深度与用作输入和用于支持测试（在预先存在的数据中）的测试数据相关。宽度宽度是指测试数据值变化的程度。创

建更多的记录就可以增加测试数据的深度。虽然这通常是一个好的解决方法，但是它无法解决我们期望在实际数据中看到的数据真实变化的问题。如果在测试数据中没有这些变化，我们可能无法确定缺陷（毕竟，不是每次从ATM提取的款项都是50.00美元）。因此，测试数据值应该反映在部署环境内找到的数据值，

例如提取10.00美元或120.00美元。另外，测试数据应该反映现实世界的信息，例如：包括头衔、数值、标点符号和后缀的名字：Dr.JamesBandlin、Ms.SusanSmith和Rev.JosephP.MayersJamesJohnsonIII、StevenWilshire3r

d和CharlesJamesEllsworth,Esq.EllenJones-Smythe、BrianP.Tellstor宽度带有多地址行的地址，例如：6500BroadwayStreetSuite1751550BroadwayFloor17Ma

ilstop75A真实相符的城市代码（和国家代码）和电话号码Lexington,MA,USA+017816762400Kista,Sweden+46856628200Paris,France+33130120950为获得足够的数据宽度，测试数据值既

可以是物理方式表示的真实数据，也可以是统计方式表示的真实数据。这两种方法都具有使用价值，推荐使用它们。为创建利用物理方法表示部署数据的测试数据，需要确定部署数据库中每个数据元素所允许包含的值（或范围），并确保在每个数据元素中，测试数据至少有一个记录包含每一个允许值。物理

表示法帐号（范围）PIN号（整数）帐户余额（十进制）帐户类型（字符串）(S)081200000000到081299999999(C)082900000000到082999999999(X)079900000000到0799999999990000-9999-999

,999.99到999,999.99S、C、X记录10812083702938493-3,123.84S记录208126493835535588,438.53S记录308297483046203526

73.00C记录40799489618934896493,498.49X物理表示法以上矩阵包含了可以用物理方法表示可接受数据值的记录的最小数量。对于帐号，在以上三个范围中每一个范围都有一个记录，所有的PIN号都在指定的范围内，几个帐户余额各不相同，

其中包括一个负余额，并且每一个不同的帐户类型都存在相关记录。以上矩阵对应最小的数据，最佳方案是使用每个范围界限上以及该范围内的数据值物理表示法的一个优点是，测试数据在数量和可管理性上都有限制，重点及导向目标是

可接受值。它的缺点是实际的、现实世界的数据并不是完全随机的。真实数据往往具有可能影响性能的统计曲线，在采用物理表示法时将不会观察到这些特征。统计表示法统计测试数据表示法是指反映了生产数据（在相同百分比下）统计抽样的测试数据。例如，使用和以上相同的数据元素

，如果我们分析该生产数据库，将发现以下事实：总记录数：294,031个帐户类型为S的总数：141,135个（占全部数量的48%）帐户类型为C的总数：144,075个(占全部数量的49%)帐户类型为X的总数：8,821个(占全部数量的3%)帐号和PIN号均匀分布基于统计抽样的测试数据包括

294个记录测试数据（占生产的1%）记录数百分比总记录数294100帐号(S)081200000000到08129999999914148帐号(C)082900000000到08299999999914

449帐号(X)079900000000到07999999999993统计表示法以上矩阵只说明帐户类型。为了开发最佳的基于统计表示法的测试数据，您最好要将重要的数据元素包括在内。以上示例中，包括反映了实际帐户余额的重要数据元素。统

计表示法的一个缺点是可能无法反映可接受值的整个范围。通常情况下，同时使用确定测试数据的两种方法，确保测试数据涵盖所有值并解决性能/填充问题。测试数据宽度与用作输入的测试数据以及用于支持测试（在预先存

在的数据中）的测试数据相关。范围范围是测试数据与测试目标之间的关联关系，它和测试深度和测试宽度相关。具有许多数据并不意味着其数据一定正确。与处理测试数据的宽度一样，我们必须确保测试数据和测试目标相关，也就

是说，需要有支持特定测试目标的测试数据。例如，在以下矩阵中，最初的四个测试数据记录说明了每个数据元素的可接受值。然而，用于评估帐户类型C和X负余额的记录却没有。因此，尽管该测试数据正确地包含了一个负余额（有效的宽度），以下的数据在其范围内不足以支持采用每个帐户类型的负余额进行的任

何测试。扩展此数据以包括更多的记录，并将各个不同帐户类型的负余额包括在内，这些操作对于处理这类疏忽是很有必要的。范围示例帐号（范围）PIN号（整数）帐户余额（十进制）帐户类型（字符串）(S)081200000000到081299999

999(C)082900000000到082999999999(X)079900000000到0799999999990000-9999-999,999.99到999,999.99S、C、X记录10812083702938493-3,123.84S记录2081264938355355

88,438.53S记录30829748304620352673.00C记录40799489618934896493,498.49X新记录10829349149270352-995,498.34C新记录20799657894364896-64

,913.87X构架测试数据的物理结构仅与测试目标用于支持测试的任何预先存在的数据相关，例如某个应用程序的数据库或规则表。测试执行不是一劳永逸的。测试将需要在迭代中以及各个迭代之间重复执行。为统一、有效、有把握地执行测试，测试数据应在测试执行前返回其初始状态。在

自动执行测试时，这一点尤其重要。因此，为了确保测试的完整性、把握性和有效性，测试数据不受外部的任何影响，并且了解测试执行在开始、期间和结束阶段的状态，这两点异常重要。为了达到测试目标，必须处理两个问题：不稳定性/隔离-隔绝测试数据的外部影响初始状态-了解数据的特定初

始状态以及返回此状态的能力这两个问题都将影响您管理测试数据库、设计测试模型以及与其他角色交互的方式。不稳定性/隔离测试数据可能由于以下原因而变得不稳定：外部的、与测试无关的影响修改了该数据其他的测试角色不知道别人正在使用的数据为维护测试的把握性和

完整性，测试数据需要进行高度控制并与这些影响隔绝。确保测试数据被隔绝的策略包括：分离测试环境-每个测试角色有自己的测试环境，在物理上和其他角色分离。测试员没有共享的内容，也就是说，他们有自己的测试目标和数据。例如，每个测试角色

都有自己的个人计算机就可以实现此策略。分离测试数据基础实例-每个测试角色有自己的数据实例，也就是说，它隔离了其他所有的影响。尽管物理环境，也许甚至还有测试目标都是共享的，但是每个测试员有自己的数据实例，这种情况下，测试数据干扰的风险几乎不存在。测试数据/数据库分区-所有的测试角色共享一

个数据库，而且知道其他角色正在使用的数据（避免使用其他角色的数据）。例如，一个测试员使用0到99的记录，而另一个测试员使用100到199的记录，或有人使用姓为Aa到Kz的客户记录，而另一个测试员使用名字从La到Zz的病人记录。初始状态必须解决的另一个测试数据构架问题是，

在开始执行测试时测试数据的初始状态。当使用自动测试时，这个问题尤其重要。正如测试目标必须以一个已知、预期的状态来开始一个测试的执行过程，这个要求对于测试数据也是一样的。由于每一测试执行过程与上一测试执行过程相同，所以这种做法可以提高可重复性和把握性。以下是解决这一问题的四个

常用策略：数据更新数据重新初始化数据重置数据前滚采用何种方法将取决于几个因素，包括数据库的物理特征、测试角色的技术能力、外部（非测试的）角色的可用性以及测试目标。数据更新将数据返回其初始状态的最理想的方法是数据更新。这个方法包括创建初始状态下该数据

库的一个备份，并将其保存。在测试执行完成之后（或执行测试之前），将该测试数据库的存档副本复制到测试环境内使用。这确保了在每次测试执行开始时，测试数据初始状态都是一样的。这种方法有一个优点，即数据能够以几个不

同的初始状态进行存档。例如，测试数据可以按日末状态、周末状态、月末状态等等进行归档。这样，测试者就可以将测试数据快速刷新到给定状态，以便进行测试。例如月末用例的测试。数据重新初始化如果数据无法刷新，那么次佳的方法是通过一些编程手段，将

数据恢复到它的初始状态。数据重新初始化依赖于特殊的用例和工具返回测试数据的初始值。采用这一方法必须小心，保证所有的数据、关系以及关键值都返回到它们适当的初始值状态，以确保没有在数据中引入任何错误。该方法的一个优点是它可以支持数据库内无效值的测试。在正常条件下，无

效数据值将被俘获而不允许进入到数据中（例如利用客户机上的一个确认规则）。然而，另一个主角可能会影响该数据（例如，另一个系统的电子更新）。测试需要在独立于无效数据产生方式的基础上，验证无效数据是否得以确定并进行了适当的处理。数据重置将数据恢复到它的初始状

态的一个简单方法是“撤消更改”，即撤消在测试期间对数据的更改。此方法依赖于使用测试目标来输入撤消条目，即添加被删除的记录/值、恢复被修改的记录/值以及删除已添加的数据。然而，这种方法还存在有一些风险，包括：必须撤消所有的操作，而不只是一部分依赖于测试目标中的用例（这些用例在

用于数据重置之前，必须进行测试以核实其正确的功能性）数据库关键字、索引以及指针不可以或不能重置如果这是在您的测试环境中唯一可用的方法，则避免使用数据库关键字、索引和指针作为核实的主要目标。也就是，例如采

用PatientName字段来确定该病人是否已经添加到数据库中，而不是使用系统生成的PatientID号。数据前滚数据前滚是最不理想的处理测试数据初始状态的方法。事实上，它并没有真正地解决问题。相反，数据状态在完成执行测试时将变成测试数据新的初始状态。一般情况下，这

要求修改用于输入和（或）测试用例的测试数据以及用于评估结果的测试数据。有时候必须采用这种做法。例如，月末。如果在月末之前该数据没有归档，则必须执行每一天和每个星期的测试数据和测试过程以将数据“前滚”到月末处理的测试所需的状态。该方法具有的

风险包括：数据库关键字、索引和指针不能重置（且不能用于核实）数据经常改变需要更多的工作来证明结果的核实情况单元测试单元测试是对最小的可测试软件元素（单元）实施的测试，它所测试的内容包括内部结构（如逻辑和数据流）以及单元的功能和可观测的行为。侧重

于单元内部结构的测试设计和实施依赖于对单元实施情况的了解（白盒方法）。为核实单元的可观测行为和功能而进行的测试设计和实施并不依赖于对实施情况的了解，因而被称为黑盒方法。为了成功和全面地对单元进行测试，需要结合使用这两种方法来设

计和实施不同类型的测试（参见概念：测试类型）。除了各种类型的测试需要单独考虑的事项以及在这里提到的两种方法以外，还有一些仅适用于单元测试的设计和实施考虑事项，它们包括：被继承的操作抽象类多态性白盒测试方法要核实单元的内部结构，应采用白盒测

试方法。理论上，您应当测试代码中每一可能的路径，但这只有在非常简单的单元中才可能做到。作为一种最低限度，您应当对每个决定到决定路径（DD路径）测试至少一次，因为这样您可以将所有语句至少执行一次。决定通常是if语句，而DD路径是两个决定之间的路径。要达到这种程度的测试

覆盖率，在选择测试数据时应该使每个决定都可以用每种可能的方法来评估。可使用代码覆盖率工具来确定白盒测试没有执行到的代码。在进行白盒测试的同时应进行可靠性测试。黑盒测试黑盒测试的目的是在不知道单元将如何实施功能和行为的情况下，核实单元的指定功能和可观测行为。黑盒测试侧重并依赖于单元的

输入和输出。当基于黑盒方法进行单元测试时，将利用单元操作的输入输出参数和/或输出状态来进行评估。例如，单元的操作可能包括某个算法（需要两个值作为输入并返回第三个值作为输出），或者可能会引起对象或构件的状态变

化（例如，添加或删除数据库记录）。对两种情况都必须进行全面的测试。要对一项操作进行测试，应生成足够数量的测试用例来核实以下内容：对于每个用作输入的有效值，该操作是否返回了一个相应值对于每个无效输入值，操

作只返回一个相应值对于每个有效的输入状态，是否出现了一个相应的输出状态对于每个无效的输入状态，是否出现了一个相应的输出状态可使用代码覆盖率工具来确定白盒测试没有执行到的代码。在进行黑盒测试的同时应进行可靠性测试。如何测

试被继承的操作如果被继承的操作在后代中不起作用，这就属于后代和祖先之间的交互问题。您可以在测试用例时核实单元之间的交互。但不要在测试单元时测试被继承的操作。被继承的操作应该在测试用例时进行测试。在以下两种情况下，被继承的操作都可能会失败：后代类修改了被

继承的操作为其指定了特定值的实例（或成员）变量。祖先中的操作调用了在后代中实施的操作。要避免第一种情况，应禁止祖先通过被继承操作以外的操作来修改被继承的实例（或成员）变量。要避免第二种情况，应全面测试被调用的操作。如何测试抽象类如果一个类不会进行

实例化，而只是为了让其他类继承而存在，就必须对其进行测试。这种测试到底具有什么意义，这可能并不明显。因为按照定义，抽象类没有实例，所以测试实例没有任何意义。但是，抽象类可以被继承，而且可以创建其后代的实例。因此，测试抽象类的目的之一是确定继

承是否可能，以及是否有后代类的实例。它的第二个目的是确定对抽象类本身的可能调用（C++中的this、Smalltalk中的self）是否将会实现。要测试这一点，需要让测试程序创建一个继承该抽象类的后代类。测试程序将通过测试该后代类来对单元进行测试。测试和多态性多态性是一

个编程语言方面的概念，它使代码更易于更改，但却使测试更加困难。在以下的示例中，您无法测试包含Shape类的每个子类的代码。当您测试用例时，必须测试这种情况。在面向对象的语言中，多态性产生的一个有趣效果是：在Smalltalk中的每次消息发送以及在C++中的每次功能调用都是一个潜在

的CASE语句。示例：假设您有以下类分层结构，并且类Shape具有操作Draw。测试模型测试模型中表示的是测试对象和测试方式。它是设计和实施模型的视图，是由测试用例、测试过程和测试脚本以及它们之间的关系组成的集合。测试模型是一种表示要在目标测试中测

试的对象的模型（它可以是系统或系统的一部分）。它是设计和实施模型的视图，并且包含专门用于测试的测试用例、测试过程和测试脚本。测试模型的作用在于让我们了解测试对象和测试方法。测试模型的使用对于开发生命周期中的每次迭代，都会开发出测试

模型的一个新版本。新版本应包括旧的测试（作为回归测试），以及用于新功能的新测试。粗略地看起来，您会在测试模型中看到设计和/或实施模型以及反映测试用例的表示法。测试用例定义了输入、执行条件和预期输出的一个集合。多数测试用例来自用例场景或用例实现，而且在遍历测

试目标时，测试用例与用例的执行过程相对应。如果测试目标是整个系统，则测试用例将对应于用例的完全执行过程。如果测试目标是一个子系统，则测试用例对应于遍历该子系统的那部分用例。如果以ATM机为例，测试用例就是要核实顾客是否能够提取100美元，前提条件是：信用卡有效，并且所用帐户内有足够

的金额。另一个用例测试是验证当用户的信用卡有效，但却输入了错误的PIN，此时ATM软件是否还能按预期工作。测试模型的使用初期迭代中，可能还不存在任何完整的用例说明，仅仅是一些场景。因而，测试的第一次迭代中，只有用于验证提现能力的测试用例得以实施，还无法验证对错误PIN代码的

处理能力。最详尽的测试模型将描述为执行测试而生成的测试用例、测试过程和测试脚本之间的关系。并非所有系统需求都能在用例中有所体现。这种需求称为非功能性需求或技术需求。典型的例子是负载需求和应用平台需求。测试用例来自于并可追踪至用例或场景、用例实现或需求测试模型的使

用对有些组织，如果从最初系统需求到实施细节的可追踪性至关重要（或是必需的），则须维护从测试用例到其相应系统需求的可追踪性链接。注：如果不具备有效维护这些可追踪性链接的工具，则管理成本将居高不下。在这种情况下，了解测试用例来源于什么用例、用例场景或用例实现就已足够。在最高一层上，测试用例

应根据测试目标（系统、子系统或构件）进行分组。在下一级别中，可以根据该测试用例来源的用例或需求来选择分组方式。在较简单的实施中，测试用例作为一个测试过程来实施。测试过程实际表示为指导如何执行测试用例的文本说明（针对手工测

试），或作为将要在测试自动化工具的使用环境内执行的测试脚本。在比较复杂的实施中，一个测试用例可能对应于一到多个测试过程，而一个测试过程也可能是一到多个测试用例实施的一部分。同样的，多个测试过程可通过一到多个测试脚本来实施。测试

用例、测试过程和测试脚本之间的关系测试用例、测试过程和测试脚本之间的关系测试用例由一到多个测试过程来实施。测试过程可以实施（全部或部分）一到多个测试用例。执行手工测试时，测试过程与测试用例之间存在一对一

的关系。自动测试（实施测试脚本）时，测试过程可由许多测试脚本来实施，或一个测试脚本可以实施许多测试过程（或测试过程的某些部分）。测试过程测试过程是指设置、执行给定测试用例并对测试结果进行评估的一系列详细指导说明。设计测试过程时需要处理以下各项：测试的前置条件。输入条件。要执行的操

作。预期结果。验证预期结果的方法。例如，在测试过程中如果要测试添加客户帐户这一用例或场景，则需要考虑的事项包括：测试的前置条件-该帐户是否已经存在？该测试过程从软件的什么位置开始执行？是否从“添加客户”菜单选项开始？选择该菜单选项后，“添加客户

”对话框是否随后打开？输入条件-测试过程通常可通过检查菜单或对话框标题来测试其起点是否正确。在随后的过程中将会输入数据，例如客户名和客户地址。要执行的操作-该过程将激活“保存”功能。预期结果-这

个新客户将保存到数据库中。验证预期结果的方法-如何确定在该过程中已添加了这个客户？在这种情况下，有很多验证方法。例如，检查新客户是否出现在客户帐户列表中、检查是否存在已添加客户这一确认消息、直接查询数据库等等。实施测试目的此工作流程明细的目的是实施（记录、生成或编写）设计测试

中定义的测试过程。输出工件是测试过程的计算机可读版本，称为测试脚本。测试脚本的生成可以在测试自动化工具环境中或编程环境中完成。如何配备人员测试设计员使用测试模型，同时可能使用其他的已实施构件，来实施测试以确保一些测试专用的功能（桩模块、驱动程序等）以及非测试重点但要与测试对象交互的元素得

到实施和测试。工作指南可以使用多种方法生成测试脚本，包括：录制-使用录制/回放工具来获取（记录）与测试对象的交互和执行测试对象的结果。编程-使用开发环境编写执行和获取执行测试对象结果的必要步骤的程序

。自动生成-在没有用户介入的情况下，使用测试生成工具生成测试脚本（生成的设置和启动除外）。活动：实施测试目的创建或生成可复用的测试脚本维护从测试实施工件到相关的测试用例及用例或测试需求的可追踪性步骤记录、生成或通过编程创建测试脚本确定设计与实施模型中的测试专

用功能建立外部数据集工件输入工件：补充规约编程指南设计指南设计模型设计类和包软件构架文档构件测试模型测试用例测试构件测试过程测试脚本负载分析文档实施模型软件工作版本生成工件：完整的测试脚本测试构件记录、生成或通过编程创建测试脚本目的:创

建或自动生成适当的测试脚本，以便按照预期的方式实施（并执行）测试用例和测试过程工具向导：RationalRobot使用RationalRobot设置测试环境使用RationalRobot创建测试脚本R

ationalTestManager使用RationalTestManager评估基于需求的代码覆盖RationalTestFactory使用RationalTestFactory设置测试环境使用RationalTestFactory自动生成测试脚本使用Ra

tionalTestFactory评测与评估基于代码的测试对RationalRobot脚本的覆盖记录、生成或通过编程创建测试脚本RationalPurify使用RationalPurify检测运行时错误RationalPureCo

verage使用RationalPureCoverage评估代码覆盖RationalQuantify使用RationalQuantify查找性能瓶颈RationalLoadTest记录性能测试会话制定表示性能测试工作量的性能测试时间表执行下列操作：创建、生成

或获取测试脚本测试/调试测试脚本复审和评估测试覆盖创建、生成或获取测试脚本对于测试模型中的每个结构化测试过程，需创建或生成至少一个测试脚本。在创建、生成或获取测试脚本时，应考虑以下方面：尽量增大测试脚本的复用程度尽量减小测试脚本的维护程度使用现有脚本（如果可行）使

用测试工具（而不通过编程）创建测试脚本（如果可行）以最稳定的方法（如通过对象名或鼠标单击）访问应用程序GUI对象和操作创建、生成或获取测试脚本要创建、生成或获取测试脚本，请执行以下步骤：复审现有的测

试脚本，了解其使用潜力设置测试环境（包括所有硬件、软件、工具、数据与应用程序工作版本）将测试环境初始化（以确保环境处于适当的测试状态或条件）创建或获取测试脚本：记录/获取：对于各个结构化测试过程，在执行测试过程以创建新的测试脚本时，应遵循结构化测试过程中所确定的步骤/操作，并使用适当的记录

技术来尽量增大复用性并减小维护程度。修改现有脚本：手工编辑现有脚本，或按照上述记录说明删除不需要的指令，并重新记录新的指令编程：对于每个结构化测试过程，使用适当的编程技术来生成指令要自动生成测试脚本，请

参考具体的测试脚本生成工具。继续创建、生成或获取代码，直至创建了所期望的/需要的测试脚本根据需要修改这些测试脚本（测试模型中有所说明）测试/调试测试脚本在完成测试脚本的创建、生成或获取时，应该对测试脚本进行测试/调试，以确

保这些测试脚本能正确地实施和执行测试。执行本步骤所用的软件工作版本应与创建/获取测试脚本所用的版本相同。要测试/调试测试脚本，请执行以下步骤：设置测试环境（如果需要）重新将环境初始化执行测试脚本评估结果确定下一

步应执行的操作：得到需要/期望的结果：无需执行操作得到意外结果：确定问题的原因并予以解决复审和评估测试覆盖在完成测试脚本的创建、生成或获取时，应生成测试覆盖报告，以核实测试脚本已实现预期的测试覆盖。确定设计与实施模型中的测试专用功能目的:指定实施或执行测试

所需的软件支持功能方面的需求确定设计模型与实施模型中应包括的测试专用功能。测试专用功能最常用于集成测试中，因为集成测试需要为未包括与未实施的构件或系统提供桩模块或驱动程序。有两种形式的桩模块或驱动程序：只是“哑元”

的桩模块和驱动程序，除了输入特定值或返回预定义值以外，它们不具有任何其他功能。更加智能化的桩模块和驱动程序，它们可以模拟较为复杂的行为。第二种形式应慎重使用，因为它需要较多的资源才能实施。所以，务必要在附加的价值（通过创建复杂的桩模块/驱动程序）和实

施与测试桩模块/驱动程序所需的工作量之间保持平衡。构建测试专用构件的其他原因包括：在没有测试自动化工具的情况下实现回归测试过程的自动化，或构建测试对象与测试自动化工具之间的接口。按照对（移交给设计员与实施员的）设计与实施模型的需求，描述您的结果。建立外

部数据集目的:为了创建和维护数据，应将数据保存在测试脚本的外部，由测试脚本在执行测试时使用。外部数据集以如下方式向测试提供值：数据位于测试脚本之外，从而消除了测试脚本中的硬编码引用外部数据可以很容易地进行修改，修改后测试脚本不

会受到影响（或只受到很小的影响）其他测试用例可以很容易地添加到测试数据中，添加后无需修改测试脚本（或仅作很小的修改）外部数据可以由许多测试用例共享外部数据集可以包括用于控制测试脚本的数据值（有条件的分支逻辑）创建/维护外部数据集要创建外部数据集，请执行以

下步骤：复审测试模型、测试用例和结构化测试过程使用适当的工具和方法创建数据集修改测试脚本以便使用数据集测试/调试测试脚本在完成测试脚本的创建、生成或获取时，应该对测试脚本进行测试/调试，以确保这些测试脚本能正确地实施和执行测试。执行本步骤所用的软件工作版本应与创建/获取测试脚本所用的版本

相同。要测试/调试测试脚本，请执行以下步骤：设置测试环境（如果需要）重新将环境初始化执行测试脚本评估结果确定下一步应执行的操作：得到需要/期望的结果：无需执行操作得到意外结果：确定问题的原因并予以解决测试脚本测试脚本是自动执行测试过程（或部分测试过程）的计

算机可读指令。测试脚本可以被创建（记录）或使用测试自动化工具自动生成，或用编程语言编程来完成，也可综合前三种方法来完成。测试脚本的结构为了提高测试脚本的可维护性和可复用性，必须在执行测试脚本之前对它们进行构建。或许会发现这样的情况，即有的操作将出现在几个测试过程中。因

此，应有目的地确定这些操作的目标，这样就可以复用它们的实施。例如，可以采用这样一些测试过程，这些过程是由对某个记录执行的不同操作组成的。这些测试过程可能是添加、修改和删除某个记录的操作的组合：添加、修改、删除（显而易见的操作）增加、删除、修改增加、删除、增加、删除...

增加、增加、增加...如果把这些操作看作是独立的测试过程，分别在不同的测试脚本中对它们进行实施，而且在其他测试过程中复用它们，那么可以达到更高的复用水平。另外，还可以有目的地以如下方式来构建测试过程：更改目标软件时，需要对测试过程

进行局部的可控制的变更。这将使得测试过程和测试脚本对目标软件的变化有更大的应变能力。例如，假设软件的登录部分已经改变。在遍历该登录部分的所有测试用例中，只有关于登录的测试过程和测试脚本需要进行改变。记录技术为使测试脚本获得更高的可维护性，应该以最不易受测试对象变化影响的方式来记录测试脚本。例

如，在填写对话框字段的测试脚本中，从一个字段跳转到下一个字段有以下几种选择方式：使用TAB键使用鼠标使用键盘快捷键在这些选择中，有一些选择更易于受到设计变化的影响。如果在屏幕上插入了一个新的字段，则使用TAB键将不是很可靠。

如果重新指定快捷键，则它们也无法提供可靠的记录手段。当使用鼠标确定字段的方法受变化制约时，这种方法亦不可靠。然而，一些测试自动化工具带有测试脚本记录器，可以通过比较可靠的方法来命令记录器标识该字段，例如可以通过开发工具（PowerBuilder、SQLWi

ndows或VisualBasic）来指定它的对象名。在这种方式下，记录的测试脚本不会受用户界面的微小变化所影响（例如，布局变更、字段标签变更、格式变更等等）。数据驱动的测试许多测试过程包括在给定的数据输入屏幕内输入几组字段数据，检查字段确认功能、错误处理等等。它们的过程步骤都是一样的；只有数据

不同。不要记录每个输入数据集的测试脚本，而应该建立单独的记录，然后对其进行修改以处理多个数据集。例如，因为无效数据而产生相同错误的所有数据集可以共享同一个已记录的测试脚本。对测试脚本进行修改，将数据作为可变信息进行访问，从文件或其他外部源中读取这些数据集，而且在所有相关

数据集间循环执行。如果在编制测试脚本或测试代码时已经考虑了输入数据集和输出数据集的循环执行因素，则必须先建立相应数据集。这些数据集的常用格式是文本文件中用逗号隔开的字段的记录。这种格式易于从测试脚本和测试代码中读取，同时也易于创建和维护。多数数据库包和电子表格包可以生成逗号分隔的文本输出

。采用这些包来组织或获取数据集有两个重要的优点。首先，它们为输入和编辑数据提供一个构造环境，比单纯使用文本编辑器或文字处理软件要好。其次，它们大多具有查询现有的数据库并捕获返回数据的能力，因此很容易从现有源中提取数据集。错误处理已记录的测试脚本是按顺序执

行的。不存在分支点。测试脚本强壮的错误处理功能要求增加响应错误条件的逻辑。当错误发生时可以应用的决策逻辑包括：分支到另外的测试脚本上。调用试图清除错误条件的脚本。退出该脚本，并启动下一个脚本。退出脚本和软件，重启，并在该脚本失败后重新开始测试下一个测试脚本。

每一种处理错误的技术都需要有添加到测试脚本中的编程逻辑。因此，该逻辑应该尽可能地限制在用来控制低级测试脚本排序的高层测试脚本。这就使得低级测试脚本完全可以从记录中进行创建。测试脚本同步和时间安排当进行重点测试时，通常需要同步测试脚本以便它们在

预先确定的时间启动。通过将期望的开始时间与系统时间比较，可以修改测试脚本以便它们可以在某个特定的时间启动。在联网系统中，每个测试站将通过网络共享同一个时钟。在以下示例中（在用VisualBasic编写的脚本中），有关语句已在脚本启动前插入，以使在达到脚本启动时间

前将其挂起。InputFile$="\TIME.DAT"OpenInputFile$ForInputAs1Input#1,StartTime$Close#1DoWhileTimeValue(StartTime$)>TimeD

oEventsLoop[Startscript]本示例中，要求的开始时间存储在一个文件里。这样，更改开始时间时就无需更改测试脚本。读取该时间并储存到一个名为StartTime$的变量中。DoWhile循环一直进行到到达开始时间为止。DoEvents语句非常重要。它允许在测试脚本被挂

起和等待启动时执行后台任务。如果没有DoEvents语句，那么系统在开始时间到达之前没有任何响应。测试和调试测试脚本在记录测试脚本的同一测试软件上执行这些最近记录的测试脚本时，不应该发生任何错误。此时的环境

及软件与它被记录的时候是相同的。可能存在测试脚本无法成功运行的情况。对该测试脚本进行测试将暴露这些情况，并允许在实际测试之前对其进行修正。以下讨论了三种典型问题：对用于在用户界面选择记录项的方法而言，若存在多义性，将使

得测试脚本在回放时进行不同操作。例如，通过文本（或标题）识别的两个记录项可能拥有完全相同的文本。当执行该脚本时，将会产生多义性。虽然测试运行/会话特定的数据被记录下来（即，指针、日期/时间戳或其他一些系统生成的数据值），但是它们与回放时的数据不同。在记录和回放时的时间差异会导致问题产生。记

录测试脚本比执行测试脚本在过程上一直要慢得多。有时，产生的时间差异会导致测试脚本先于软件运行。这种情况下，可以插入等待状态以调整测试脚本相对于软件的运行速度。活动：设计测试包和测试类目的设计测试专用功能步骤确定测试专用

包和类设计自动测试工具的接口设计测试过程的行为输入工件：设计类与设计包测试过程测试用例测试类测试包生成工件：测试类，已精化测试包，已精化确定测试专用包和类目的:确定并设计类和包，它们将提供所需的测试专用功能

。以测试设计员的输入为基础，在设计模型中确定测试专用类和包。设计类的驱动程序或桩模块具备的方法与初始类相同，但是对这些方法仅定义了提供输入（向测试对象）或返回一个预定义值（向测试对象）的行为，除此未定义其

他行为。设计包的驱动程序或桩模块包括一些模拟类，它们模拟了形成原始包公有接口的那些类。设计自动测试工具的接口目的:确定将自动测试工具与测试专用功能集成所必需的接口。确定您的测试自动工具与测试对象进行有效通信所需的行为。确定并说明适合的设计类和设计包

。设计测试过程的行为目的:让不具备自动测试工具的测试过程实现自动化。让不具备自动工具的测试过程实现自动化，并确定适合的设计类和设计包。将测试用例与其原始用例用作输入。活动：实施测试构件和子系统目的实施测试专用功能步骤实施驱动程序/桩模块并对其进行单元测试实施与自动测试工具

的单元测试接口实施与单元测试的测试过程行为输入工件：测试类和测试包构件和实施子系统测试构件测试过程测试用例生成工件：测试构件测试子系统活动：实施测试构件和子系统实施与单元测试驱动程序/桩模块目的:确定并设计将提供所需的测试专用功能的类和包实施与自动测试工具的

单元测试接口目的:确定在集成自动测试工具与测试专用功能时所必需的接口。实施与单元测试的测试过程行为目的:使没有自动测试工具的测试过程实现自动化。在集成测试阶段执行测试目的集成测试阶段的目的是确保各构件组合在一起后能够按既定意图协作运行，并确保增量的行为正确。系统集成员在各增量中

编译并链接系统。每一增量都需要测试增加的功能，并进行以前版本测试过的所有测试（回归测试）。在一次迭代中，将多次执行集成测试，直到整个系统（由迭代目标定义）集成成功。该活动的输出工件即测试结果。在迭代的最后，应该测

试整个系统。系统测试的重点通常在系统与其主角之间的交互上。如何配备人员测试员是此工作流程明细所涉及的主要角色，但也存在与实施员和系统集成员的交互。此外，如果需要测试类和包，则还存在与这些角色的额外交互。工作指南测试的执行必须在受控环境中进行。这包括：不受非测试因素影响

的测试系统为测试系统设置已知初始状态并在测试结束时返回该状态（以重复执行测试）的能力。在系统测试阶段执行测试目的系统测试阶段的目的是确保整个系统按既定意图运行。系统集成员在各增量中编译并链接系统。每一增量都需要测试增加的功能，并进行

以前版本测试过的所有测试（回归测试）。在一次迭代中，将多次执行系统测试，直到整个系统（由迭代目标定义）按既定意图运行并达到测试成功或完成的标准为止。该活动的输出工件即测试结果。如何配备人员测试员是此工作流程明细所涉及的主要角色，但也存在与实施员和系统集成员的交互。此外，如果需

要测试类和包，则还存在与这些角色的额外交互。工作指南测试的执行必须在受控环境中进行。这包括：不受非测试因素影响的测试系统为测试系统设置已知初始状态并在测试结束时返回该状态（以重复执行测试）的能力。活动：执行测试目的执行测试并获取测试结果。步骤执行测试过程评

估测试的执行情况核实测试结果恢复暂停的测试输入工件：构件开发基础设施实施子系统软件工作版本测试用例测试模型测试过程测试脚本测试构件测试子系统生成工件：测试结果执行测试过程目的:执行测试过程（对于自动测

试，则执行测试脚本）工具向导：RationalRobot使用RationalRobot设置测试环境使用RationalRobot执行测试RationalTestFactory使用RationalTestFactory执行一套测试脚本

RationalLoadTest执行性能测试时间表执行测试时应遵循以下步骤：设置测试环境，确保所需的全部构件（硬件、软件、工具、数据等）都已实施并处于测试环境中。将测试环境初始化，以确保所有构件都处于正确的初始状态，可以开始测试。执行测试过程。注：测试过程的执行

方式将依据测试是自动测试还是手工测试而有所不同。自动测试：执行在实施测试活动中创建的测试脚本。手工测试：按照在设计测试活动中制定的结构化测试过程来手工执行评估测试的执行情况目的确定是将测试执行完毕还是暂停测试确定是否需要纠正措施工具向导：Ration

alLogViewer:使用RationalLogViewer评估测试的执行情况RationalTestFactory:使用RationalTestFactory评估一套测试脚本的执行结果使用RationalTestFactory评测

与评估基于代码的测试对RationalRobot*脚本的覆盖使用RationalTestFactory评估测试覆盖使用RationalTestFactory、RationalRobot和RationalLogViewer分析自动生成的测试脚本RationalLoadT

est:监控性能测试进度评估测试的执行情况测试执行活动结束或终止时，以下两种情况之一会出现：正常终止：所有测试过程（或脚本）按预期方式执行至结束。如果测试正常结束，则继续核实测试结果：异常或提前结束：测试过程（

或脚本）没有按预期方式执行或没有完全执行。当测试异常终止时，测试结果可能不可靠。在执行任何其他测试活动之前，应确定并解决异常/提前终止的原因，然后重新执行测试。如果测试异常终止，则继续恢复暂停的测试核

实测试结果目的确定测试结果是否可靠针对测试结果表明的测试工作或测试工件中存在的缺陷，确定合适的纠正措施工具向导：使用RationalLogViewer评估测试的执行情况中的“核实测试结果”和“调查意外结果”部分测试完成后，应当复审测试结果以确保测试结果可靠，确保所

报告的故障、警告或意外结果不是（对测试对象的）外部影响（例如，不正确的设置或数据等）造成的。核实测试结果在测试过程和测试脚本完全执行时所报告的故障中，最常见的故障及其纠正操作为：测试核实故障-通常发生在实际结果与预期结果不匹配时。验证

所用的核实方法仅侧重于基本项与/或特征，并在必要时进行修改。意外的GUI窗口-发生这种情况有好几种产生原因。最常见的原因是当前的GUI窗口并不是预期的窗口，或所显示的GUI窗口数目大于预期的数目。确保为正确执行测试而设置了测

试环境并对其进行了初始化。GUI窗口遗失-如果某个GUI窗口应该可用（不一定是当前窗口）但实际上却不可用，则应记录该故障。确保为正确执行测试而设置了测试环境并对其进行了初始化。确保实际遗失的窗口已从测试对象中删除。如

果所报告的故障是在测试工件中确定的错误导致的，或者是测试环境的问题造成的，则应当采取适当的纠正措施进行纠正，然后重新执行测试。有关其他信息，请参见下面的“恢复暂停的测试”。如果测试结果表明故障确实是由测试对象造

成的，就可认为执行测试活动已完成。恢复暂停的测试目的确定适当的纠正措施，以便恢复暂停的测试纠正问题，恢复并重新执行测试工具向导：使用RationalLogViewer评估测试的执行情况中的“

恢复暂停的测试”部分暂停的测试主要有两种类型：致命错误-系统故障（网络故障、硬件崩溃等）测试脚本命令故障-针对自动测试，指测试脚本无法执行某条命令（或代码行）。这两种类型的测试异常终止可能会表现出相同的故障现象：当执行测试脚本时，出现许多意外的操作、窗口或事件测试环境没有响

应或处于非理想状态（如悬挂或崩溃）。要恢复暂停的测试，请执行如下步骤：确定问题的实际原因纠正问题重新设置测试环境重新初始化测试环境重新执行测试评估测试目的评估测试的目的是生成并交付测试评估摘要。这是通过复审并评估测试结果、确定并记录变更请求，以及计

算主要测试评测方法来完成的。测试评估摘要以组织有序的格式提供测试结果和主要测试评测方法，用于评估测试对象和测试流程的质量。如何配备人员测试设计员负责复审和评估测试对象和测试流程的质量。他们必须熟悉测试指标和统计学。工作

指南在此工作流程明细中，要使用两种主要的评测方法：覆盖指标-判定是否已经实施和执行了充分的测试质量指标-确定测试对象和测试流程的质量。活动：评估测试目的评估测试结果并记录变更请求。计算并交付测试的主要评测方法。生成

测试评估摘要。步骤分析测试结果并提交变更请求评估基于需求的测试覆盖评估基于代码的测试覆盖分析缺陷确定是否达到了测试的完成标准和成功标准生成测试评估摘要输入工件：测试计划测试用例测试结果生成工件：测试评估摘要变

更请求分析测试结果并提交变更请求目的确定并评估预期结果和实际结果间存在的差异将变更请求信息输入用于评估、管理与解决的跟踪工具工具向导：RationalLogViewer:使用RationalLogViewer评估测试的执行RationalTestFactory：使用R

ationalTestFactory评估一套测试脚本的执行结果RationalPurify：使用RationalPurify检测运行时错误RationalQuantify：使用RationalQuantify查找性能瓶颈RationalPureCover

age：使用RationalPureCoverage评估代码覆盖RationalClearQuest：使用RationalClearQuest提交变更请求（缺陷）RationalLoadTest

TM：监控性能测试进度报告性能测试分析测试结果并提交变更请求在测试执行活动中，测试结果要经过复审以确保测试已执行完全，并确保报告的测试结果没有受到非测试对象因素的影响。在此活动中，经过分析的测试结果可以确定预期测试结果与实际测试结果之间存在的细微差异。这些差异表明了测试对象中存在潜在缺陷，

应将差异作为变更请求输入跟踪系统,下一步则应采取相应的纠正操作。复审各个已报告的测试故障，并确定将变更请求输入相应的跟踪系统所需的信息。输入的信息应准确、适当、并满足既定的变更请求跟踪标准或指南。评估基于需求的测试覆盖目的:确定是否实现了要求的

（或适当的）基于需求的测试覆盖工具向导：RationalTestManager：使用RationalTestManager复审和评估基于需求的测试覆盖RationalTestFactory：使用RationalTestFa

ctory评估测试覆盖要评估基于需求的测试覆盖，您应复审测试结果并决定：此次迭代中执行的基于需求的测试（测试用例）的数量与测试对象的总测试数量的比例。成功执行的测试用例的比例。目的是要确保要在本次迭代中进行的基于需求的测试能够百分之百成功执行。如果这是不可能或不可行的，则应确

定一个不同的测试覆盖标准，该标准的基础可以是：风险或优先级可接受的覆盖百分比在测试评估报告中记录本次迭代的结果。评估基于代码的测试覆盖目的确定是否实现了要求的（或适当的）基于代码的测试覆盖。工具向导：Ration

alTestFactory:使用RationalTestFactory评估测试覆盖使用RationalTestFactory评估一套测试脚本的执行结果RationalPureCoverage：使用RationalPureCoverage评估代码覆盖要评估基于代码的测试覆盖，您应复审

测试结果并决定：在本次迭代的测试期间执行的代码（如代码行或语句）与测试对象中总代码的比例。目的是要确保要在本次迭代中测试的代码百分之百成功执行。如果这是不可能或不可行的，则应确定一个不同的测试覆盖标准，该标准的基础

可以是：风险或优先级可接受的覆盖百分比在测试评估报告中记录本次迭代的结果。分析缺陷目的评估缺陷并推荐适当的后续活动撰写客观报告，传达测试结果工具向导使用RationalClearQuest报告缺陷趋势和

状态要分析缺陷，应将复审和分析所选评测方法作为缺陷分析战略的一部分。最常用的缺陷评测方法包括（通常以图的形式显示）：缺陷密度-缺陷的数量以一个或两个缺陷属性（如状态或严重性）的函数显示。缺陷趋势-缺陷数目以随时间变化的函数表示。缺陷龄期-是特殊的缺陷密度报告，它通

过缺陷在一定时间内保持某特定状态（打开的、新的、待测试的缺陷等）的函数表示。将本次迭代的评测方法与先前各次迭代的分析结果进行比较，判断缺陷的走势。建议用图来显示结果。确定是否达到了测试的完成标准和成功标准目的判定测试的执行是否完全、是否可接受确定适当的后续测试活动

复审测试计划中制定的测试战略。应根据测试覆盖和/或缺陷评估结果说明测试标准。请检验测试结果、缺陷与缺陷分析，并判断是否已达标。如果未达标，请参考以下备选方案：收集进一步的信息：另行撰写报告，如不

同的缺陷密度报告通过研究流程，判断意外条件是否导致背离已确定的测试标准，并在这一新信息的基础上再次评估标准建议安排进一步测试：实施新测试以进一步执行测试用例实施新测试以扩大测试覆盖面修改测试标准：复审并评估测试后变更标准会带来的风险确定满足测试标

准的软件子集，并决定是否可以部署该子集。生成测试评估摘要目的撰写客观报告，传达测试结果、主要评测方法与测试建议评估测试活动中的最后一步是撰写测试评估摘要。此活动通过以下方式进行：将上述信息编入一个报告，然后将其分发

给相应的角色以便复审。概念：测试的主要评测方法测试的主要评测方法包括覆盖和质量。测试覆盖是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测

试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。覆盖评测覆盖指标提供了“测试的完全程度如何？”这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是

就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般

目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果

来得到评测，如已经核实了75%的性能测试需求。如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到。基于需求的测试覆盖基于需求

的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。测试覆盖通过以下公式计算：测试覆盖=T(p,i,x,s)/Rf

T其中：•T是用测试过程或测试用例表示的测试(Test)数（已计划的、已实施的或成功的）。•RfT是测试需求(RequirementforTest)的总数。在制定测试计划活动中，将计算测试覆盖以决定已计划的测试覆盖，其计算方法

如下：测试覆盖（已计划的）=Tp/RfT其中：•Tp是用测试过程或测试用例表示的已计划测试(Test)数。•RfT是测试需求(RequirementforTest)的总数。基于需求的测试覆盖在实施测试活动中，由于测试过程正在实施中（按照测试脚

本），在计算测试覆盖时使用以下公式：测试覆盖（已执行的）=Ti/RfT其中：•Tx是用测试过程或测试用例表示的已执行的测试(Test)数。•RfT是测试需求(RequirementforTest)的总数。在执行测试活动

中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。基于需求的测试覆盖这些覆盖评测通过以下公式计算：测试覆盖（已执行的）=Tx/RfT其中：•Tx是用测试过程或测试用例表示的已执行

的测试(Test)数。•RfT是测试需求(RequirementforTest)的总数。成功的测试覆盖（已执行的）=Ts/RfT其中：•Ts是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试(Test)数。•RfT是测试需求(Requirementfo

rTest)的总数。如将以上比率转换为百分数，则以下基于需求的测试覆盖的陈述成立：x%的测试用例（上述公式中的T(p,i,x,s)）已经覆盖，成功率为y%这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。

如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。基于代码的测试覆盖基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支

或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。基于代码的

测试覆盖通过以下公式计算：测试覆盖=Ie/TIic其中：•Ie是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。•TIic(TotalnumberofItemsinthecode)是代码中的项目总数。如将该比率转换为百分

数，则以下基于代码的测试覆盖的陈述成立：x%的测试用例（上述公式中的I）已经覆盖，成功率为y%这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。质量评测测试覆盖的评估提供对测试完全

程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。缺陷评估可能建立在各种方法上，这些方法

种类繁多，从简单的缺陷计数到严格的统计建模不一而足。严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，

这是一个活跃的研究领域。由于该类型的评估缺乏工具支持，所以应该慎重平衡成本与其增加价值。质量评测缺陷分析就是分析缺陷在与缺陷关联的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。对于缺陷分析，常用的主要缺陷参数有四个：状态：缺陷的当前状态（打开的、正在修复或关闭

的等）。优先级：必须处理和解决缺陷的相对重要性。严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多

个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。质量评测例如，预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值，在缺陷

发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数，以允许检测“较差的模块”、“热点”或需要再三修复的软件部分，从而指示一些更基本的设计缺陷。这种分析中包含的缺陷必须是已确认的缺陷。不是

所有已报告的缺陷都报告实际的缺陷，这是因为某些缺陷可能是扩展请求，超出了项目的规模，或描述的是已报告的缺陷。然而，需要查看并分析一下，为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷，这样做是有价值的。缺陷报告RationalU

nifiedProcess以三类形式的报告提供缺陷评估：缺陷分布（密度）报告允许将缺陷计数作为一个或多个缺陷参数的函数来显示。缺陷龄期报告是一种特殊类型的缺陷分布报告。缺陷龄期报告显示缺陷处于特定状态下

的时间长短，如“提出的”。在龄期类别中，缺陷还可以按其他属性分类，如“拥有者”。缺陷趋势报告按状态（新的、已打开的或关闭的）将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的。测试结果和进度报告显示对测试的应用程序进行若干次迭代和测试生命周期后的测试过程

执行结果。许多此类报告对于评估软件质量具有很高的价值。一般测试标准中包括有关特定类别（如严重性级别）中打开的缺陷数的陈述。通过缺陷分布评估可以轻松地核对该标准。对测试需求进行过滤或分类，该评估可以侧重于不同的需求集。要有效生成此类报告，一般需要工具支持。缺陷密度报告缺陷状态与优

先级应该给定所有缺陷的优先级，通常可行的做法是设定四种优先级中的一种：立即解决高优先级正常排队低优先级一个成功测试的标准可以表示为缺陷在上述优先级上所应体现的分布方式。例如，对于一个成功的测试标准来说，可能不存在优先级为1的打开的缺陷，而且优先级为2的打开的缺陷要少于5

个。例如下面的缺陷分布图。很明显该图显示的情况没有达到标准。请注意，该图需要通过过滤器才能只显示需要的打开的缺陷。缺陷状态与严重性缺陷严重性报告显示每种严重性级别的缺陷个数，例如致命错误、未执行主要功能、次要错误等严重性级别。缺陷状态与在

实施模型中的位置缺陷起源报告显示缺陷在实施模型元素上的分布情况。缺陷分布图缺陷龄期报告缺陷龄期分析提供了有关测试有效性和缺陷排除活动的良好反馈。例如，如果大部分龄期较长的、未解决的缺陷处于有待确认的状态，则可能表明没有充足的资源应用于再次测试

工作。缺陷趋势报告趋势报告确定缺陷率并提供了一个出色的测试状态视图。在测试生命周期中，缺陷趋势遵循着一种比较好预测的模式。在生命周期的初期，缺陷率增长很快。在达到顶峰后，就随时间以较慢的速率下降。缺陷趋势报告要发现问题，可以根据这一趋势复审项

目时间表。例如，在四个星期的生命周期中，如果缺陷率在第三个星期中仍然增长，则项目很明显没有按时间表进行。这一简单的趋势分析假定：缺陷是立即关闭的，且在随后的工作版本中对修复进行测试，这样关闭缺陷的速率应该遵循与打开缺陷的速率相同的增减趋势。如果情况并

非如此，则表明缺陷解决流程发生了问题；缺陷修复所需的资源或再次测试和确认修复所需的资源可能不足。缺陷趋势报告该报告反映的趋势显示，在项目开始时，发现和打开新缺陷的速率很快，但随着时间推移，该速率不断降低。打开的缺陷的趋势与新缺陷的趋势相似，但稍微滞后一些

。关闭的缺陷的趋势随着打开的缺陷的修复和核实而不断增长。这些趋势描述的是成功的工作。如果您的趋势与这些趋势差别显著，则表明存在问题，并可以确定可能需要附加资源以应用于开发或测试特定区域的时间。当与测试覆盖评测结合起来时，缺陷分析可提供出

色的评估，测试完成的标准也可以建立在此评估基础上。性能评测评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在评估测试活动中进行评估，但是也可以在执行测试活动中使

用性能评测评估测试进度和状态。主要的性能评测包括：动态监测-在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。响应时间/吞吐量-测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。百分位报告-数据已收集值的百分位评测

/计算。比较报告-代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。追踪报告-主角（测试脚本）和测试对象之间的消息/会话详细信息。动态监测动态监测通常以柱状图或曲线图的形式提供实时显示/报告。该报告用于在测试执

行过程中，通过显示当前的情况、状态以及测试脚本正在执行的进度来监测或评估性能测试执行情况。例如，在以上柱状图中，有80个测试脚本正在执行相同的用例。图中显示，有14个测试脚本处于空闲状态，12个处于查询状态，34个处于SQL执行状态，4个处于SQL连接状态，1

6个处于其他状态。随着测试的进行，我们将看到各状态脚本的数量会发生变化。显示的输出将是正常执行且正在执行中的典型测试执行。但是，如果在测试执行过程中，测试脚本始终保持一种状态或没有显示任何变化，则表明测试执行发生问题或者需要实

施或执行其他性能评测。动态监测响应时间/吞吐量报告正如其名称的含义一样，响应时间/吞吐量报告评测并计算与时间和/或吞吐量（处理的事务数）相关的性能行为。这些报告通常用曲线图显示，响应时间（或事务数）在

“y”轴上，而事件数在“x”轴上。除了显示实际的性能行为外，它在计算并显示统计信息方面也很实用，如显示数据值的平均偏差和标准偏差。响应时间/吞吐量报告百分位报告百分位报告通过显示已收集数据类型的全体百分位值，提供

了另一种性能统计计算方法。比较报告比较不同性能测试的结果，以评估测试执行过程之间所作的变更对性能行为的影响，这种做法是非常必要的。比较报告应该用于显示两个数据集（分别代表不同的测试执行）之间的差异或多个测试执行之间的趋势。追踪和配置文件报告

当性能行为可以接受时，或性能监测表明存在可能的瓶颈时（如当测试脚本保持给定状态的时间过长），追踪报告可能是最有价值的报告。追踪和配置文件报告显示低级信息。该信息包括主角与测试对象之间的消息、执行流、数

据访问以及函数和系统调用。测试：活动概述测试：工件概述角色：测试设计员测试设计员是测试中的主要角色。该角色负责对测试进行计划、设计、实施和评估，包括：生成测试计划和测试模型执行测试过程评估测试范围和测试结果，以及测试的有效性生成测试评估摘要人员配备测试设计

员应具备的相应技能和知识包括：了解系统或所测试的应用程序了解测试及测试自动化工具具备诊断和解决问题的技能编程技能（最好具备）角色：测试设计员角色：测试员测试员负责执行测试，其职责包括：设置和执行测试评估测试执行过程

并修改错误人员配备测试员应具备的知识和技能可能会因为他们所执行的测试类型和/或测试阶段的不同而有所差异。例如，在执行性能测试或集成阶段的测试时，需要更高级的技能。在执行功能测试或系统测试阶段的测试时，则不需要太高级的技能。以下是测试员所需知识和技能的一些标准：高级测试员：

了解系统或所测试的应用程序了解联网和系统构架了解测试及测试自动化工具具备诊断和解决问题的技能编程技能（必备）初级测试员：了解系统或所测试的应用程序了解测试及测试自动化工具具备诊断和解决问题的技能编程技能（最好具备）角色：测试员测试的生命周期在软件开发生命周期中，软件

是通过迭代来不断加以完善的。在这种环境中，对于每个作为测试目标的工作版本，测试的生命周期还都必须具有一种迭代方法。对于针对每个工作版本执行的测试，都作出了增补和改进，并累积为一个测试体，用于后续阶段的回归测试。该方

法表明它将导致在整个流程中重复进行测试，就象修订软件本身一样。这里没有一成不变的软件规约，也没有一成不变的测试。测试的生命周期在同一张图中，观察不具有项目其余部分的测试的生命周期。图中展示了不同测试活动在非迭代视图中相互联系的方式：测试的生命周期该生命周期必须与迭代方法结合起

来，这意味着每个迭代都将具有遵循该模式的测试周期。