第12章软件测试电子教案

第12章软件测试第12章软件测试1）软件测试的概念2）黑盒测试和白盒测试方法3）单元测试过程4）集成测试,系统测试,验收测试的基本过程掌握掌握

理解了解要求12.1软件测试的概念1963年,美国,飞往火星的火箭爆炸,损失$10million。原因:FORTRAN循环：

DO5I=1,3误写为DO5I=1.3

软件测试的工作量约占整个项目工作量的40％左右，对于要求极高的系统测试工作量还要成倍增加。微软Exchange2000和Windows

2000中的人员结构

Exchange2000Windows2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人测试人员/开发人员2:51:9软件测试的目的？为什么需要这么多人、花这么多代价进行测试？目的何在？

“证明程序正确！”对吗？Myers对软件测试目的提出以下观点：（1）软件测试是为了发现错误而执行程序的过程。（2）一个好的测试用例能够发现至今尚未发现的错误。（3）一个成功的测试是发现了至今尚未发现的错误的测试。6

通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”是不正确的。测试的目的决定了测试方案的设计。如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。测试决不能证明软件是正确的，也不能证明错误的不存在，它只能证明错误的存在。测试的定义从广义上讲是指软件产品生存周期内所有的检查、评审和确认活动从狭义上讲，软件测试是为了发现错误而执行程序的过程软件测试是根据软件开发各阶段的规格说明和程序内部结构而精心设计的一批测试用例,用这些测试用例运行程序,以发现程序错误的过程。一个测试用例是一组输入数据及其对应的预期输出结果。测试的工作量一般性软件其测试工作量大约占整个开发工作量的40%系统软件或关系到人的生命财产安全的重要软件，其测试工作量通常可能达到整个开发工作量的3—5倍软件测试的目标优秀的测试用例:以最小的代价、在最短的时间内，尽可能多地发现软件中的错误。10软件测试原则(1)

应该把测试贯穿在整个开发过程之中。事实上从需求分析阶段开始，每个阶段结束之前都要进行阶段审查，目的是尽早发现和纠正错误。概要设计时应完成测试计划，详细的测试用例定义可在设计模型确定后开始，所有测试可在任何代码被产生之前进行计划和设计。

11软件测试原则

软件测试不等于程序测试。据美国一家公司统计，查出的软件错误中，属于需求分析和软件设计的错误约占64%，属于程序编写的错误仅占36%。程序编写的许多错误是“先天的”。12测试与开发前期工作的关系决定软件与系统的配合关系需求分析概要设计详细设计编码单元测试集成测试确认测试系统测试13开发前期出现错误的扩展计划需求分析设计编码测试AB14（2）测试用例应由输入数据和预期的输出结果两部分组成，并兼顾合理的输入和不合理的输入数据。在实际操作中可以列出一张电子表格，包括每个测试用例的编号、类型、输入数据、预期输出结果、实际输出结果、出错原因分析。15（3）穷举测试是不可能的。所谓穷举测试就是把程序所有可能的执行路径都检查一遍的测试。例:输入三条边长可采用的测试用例数(设字长16位)

执行时间:设测试一次需1ms共需一万年.=2X2X2≈3X1016161614穷举测试实例:设程序含5个分支,循环次数≤20,从A到B的可能路径

执行时间:设测试一次需2ms穷举测试需5亿年.=5+5+..+5+5≈1020121914AB18（4）程序员应该尽量避免检查自己编写的代码。为了达到最佳的测试效果，应该由独立的第三方从事测试工作。所谓“最佳效果”是指有最大可能性发现错误的测试。开发软件的软件工程师（心理）并不是完成全部测试工作的最佳人选（通常他们主要承担模块测试工作）。测试原则续（5）在设计测试用例时，应该包括有效的、期望的输入情况，也要包括无效的和不期望的输入情况。即能够验证程序正常运行的合理输入，也能够验证对异常情况处理的不合理输入数据以及临界数据输入。在测试时,人们常常过多地考虑合法和期望的输入条件,以检查程序是否做了它应该做的事情，而忽视了不合法的和预想不到的输入条件。用户在使用系统时,输入一些错误指令和参数是经常发生的,如果软件遇到这种情况不能做出适当的反应,给出相应的提示信息,可能会误导用户,甚至会造成严重损失。测试原则续（6）软件中遗留的错误数量与已经发现的错误数量成正比。根据这个规律对测试中发现错误成堆的模块更要仔细测试。例如，在某个著名的操作系统中，44%的错误仅与4%的模块有关。（7）回归测试的关联性要特别引起注意，修改一个错误而引起更多错误的现象并不少见。测试原则续（8）严格执行测试计划。在测试之前应该有明确的测试计划，内容包括：要测试的软件功能和内容、测试用例和预期结果、测试的进度安排、需要的工具和资源、测试控制方式和过程等。（9）做好测试记录，为统计和维护提供基础数据软件测试的对象软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。为把握软件开发各个环节的正确性，需要进行各种确认和验证工作。验证和有效性确认验证(Verification)：通过检查和提供客观证据，表明规定要求已经满足的认可。在软件生存期各个阶段，验证是指检测各个阶段结束时的工作产品是否满足对上一阶段的结束后的工作产品所定义的规格的验证过程有效性确认(Validation)：通过检查和提供客观证据，表明一些针对某一特定预期用途的要求已经满足的认可。在软件生存周期各个阶段，确认是指检测各个阶段结束时的工作产品是否满足在软件生存周期初期在系统需求文档中描述的各项软件规格的确认过程。都是测试活动。验证和有效性确认验证(Verification)：有效性确认(Validation)：都是测试活动。测试的层次和类型—层次单元测试：针对模块代码的测试,测试的粒度最小集成测试：把经过单元测试的模块组合在一起,重点测试模块之间的接口。系统测试：系统集成后,对整个系统包括硬件等环境的综合测试。验收测试：以用户为主,对软件功能、性能进行全面测试。验证软件是否满足需求规格说明书的要求，检查所有的配置成份是否齐全。测试的层次和类型—类型静态测试：主要通过代码审查和静态分析，检查源代码中存在的问题。过程：代码审查由有经验的程序设计人员根据软件详细设计说明书，阅读程序来发现源程序中类型、引用、参数传递、表达式等不必运行程序就能够发现的错误。特点：这种方法不需要专门的测试工具和设备，一旦发现错误就能定位，但是此方法具有一定的局限性。静态分析主要对程序进行控制流分析、数据流分析、接口分析和表达式分析等测试的层次和类型—类型动态测试：在指定的环境上运行被测程序，输入测试数据，获得测试结果，将获得的测试结果与预期的结果进行比较，发现程序的错误。过程：设计测试用例，运行被测程序。特点：需要有程序的运行环境，必要时要编写测试驱动程序和桩程序。测试的层次和类型—类型功能测试：验证软件是否提供了预期服务。过程：根据软件需求规格说明书设计测试用例，并按照测试用例的要求运行被测程序。特点：将被测程序看成是一个黑盒子，着重验证软件功能和性能的正确性，其典型测试方法包括价类划分、边值分析、因果分析、猜测错误等。测试的层次和类型—类型结构测试：对程序结构的检查，也称为白盒测试。采用这种测试方法，测试者需要了解被测程序的内部结构。白盒测试通常根据覆盖准则设计测试用例，有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖和条件组合覆盖等。测试的层次和类型—类型用户界面测试：对软件提供的用户界面、系统接口的测试。验证其正确性、可操作性、可理解性。性能测试：测试程序的响应时间、并发性、吞吐量、处理精度。负载测试：测试一个软件在重负荷下的运行情况。例如，测试一个Web应用软件在大量的负荷下，何时系统的响应会退化或失败强度测试：在异乎寻常的重载下系统运行情况，如某个动作或输入的不断重复；大量数据的输入；对一个数据库应用系统大量的复杂查询等。

测试的层次和类型—类型安全性测试：检查系统对非法侵入的防范能力。测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，截取或破译口令、破坏系统的保护机制、故意导致系统失败、试图通过浏览非保密数据，推导所需信息等网络通信测试：软件中的网络通信的速度、容量、安全性、延迟处理等方面的测试。测试的层次和类型—类型恢复测试:恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化、数据恢复、重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。测试的难点测试用例是设计者对测试对象的理解，因此，其质量很大程度上取决于设计者的分析、理解和设计能力。这是一种缺乏指导性方法的、不易制订标准规范的、需要“技巧”的设计活动。开发组织与测试组织难一很好的配合。长期以来，大都数软件开发人员认为测试活动是对开发人员劳动成果的不断“挑剔”。但实际上，测试工作的出发点是确保开发人员的劳动成果成为可接收的、高品质的软件产品。有效的测试工作需要投入足够的人力和物力，需要对工作的难度和消耗有充分的估计。测试的产品软件测试工作所产生的文档、程序、服务、以及相关的文件总和称之为软件测试产品。测试配置包括：测试计划；测试方案（包括测试输入数据、测试的功能、测试预期结果）；文档审查项列表；代码审查项列表；软件测试报告；软件问题报告；软件变更报告；软件测试日志。35测试阶段的信息流测试软件配置结果分析测试结果排错改正的软件预期结果可靠性分析预测的可靠性错误出错率数据测试配置测试工具需求规格说明书软件设计说明书被测源程序

测试计划测试用例(测试数据)测试驱动程序测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等。12.2设计测试用例测试用例是用于软件测试的输入数据及预期结果。一个好的测试用例有以下几个特征：是最有可能发现错误的；不是重复的、多余的；通常先按黑盒测试法设计基本测试用例，发现软件功能和性能上的问题，然后再用白盒测试方法补充一些测试用例，发现程序逻辑结构的错误。黑盒测试这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能测试或数据驱动测试。

黑盒测试的作用黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误:是否有不正确或遗漏了的功能?在接口上，输入能否正确地接受?能否输出正确的结果?是否有数据结构错误或外部信息(例如数据文件)访问错误?性能上是否能够满足要求?是否有初始化或终止性错误?黑盒测试的局限用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。但这是不可能的。示例假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：可能采用的测试数据组：232×232＝264

如果测试一组数据需要1毫秒，一年工作365×

24小时，完成所有测试需5亿年。黑盒测试法等价类划分边值分析因果分析猜测错误白盒测试此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试的作用软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：对程序模块的所有独立的执行路径至少测试一次；对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；在循环的边界和运行界限内执行循环体；测试内部数据结构的有效性，等。白盒测试的局限对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字。给出一个小程序的流程图，它包括了一个执行20次的循环。包含的不同执行路径数达520条，对每一条路径进行测试需要1毫秒，假定一年工作365×24小时，要想把所有路径测试完，需3170年。白盒测试与黑盒测试对比黑盒测试白盒测试优点适用于各测试阶段从产品功能角度测试容易入手生成测试数据可以构成测试数据使特定程序部分得到测试有一定的充分性度量手段可获得较多工具支持缺点某些代码段得不到测试如果规格说明有误则无法发现不易进行充分性度量不易生成测试数据无法对未实现规格说明得部分测试工作量大，通常只用于单元测试，有引用局限性质是一种确认技术，回答“我们在构造一个正确得系统吗？”是一种验证技术，回答“我们在正确地构造一个系统吗？”白盒测试法语句覆盖判定覆盖条件覆盖判定/条件覆盖条件组合覆盖路径覆盖48发现错误的能力标准含义1(弱)语句覆盖每条语句至少执行一次2判定覆盖每一判定的每个分支至少执行一次3条件覆盖每一判定中的每个条件，分别按“真”、“假”至少各执行一次4判定/条件覆盖同时满足判定覆盖和条件覆盖的要求5(强)条件组合覆盖求出判定中所有条件的各种可能组合值，每一可能的条件组合至少执行一次

逻辑覆盖测试的5种标准

例子func(intA,B,X){if((A>1)&&(B=0)){X:=X/A};if((A=2)||(X>1)){X:=X+1};}A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced测试覆盖率示例（1）覆盖标准程序结构举例测试用例应满足的条件语句覆盖A^B=.T.判定覆盖A^B=.T.A^B=.F.A^BTFA^BTF测试覆盖率示例（2）覆盖标准程序结构举例测试用例应满足的条件条件覆盖A=.T.A=.F.B=.T.B=.F.判定/条件覆盖A^B=.T.,A^B=.F.A=.T.A=.F.B=.T.B=.F.条件组合覆盖A=.T.^B=.T.A=.T.^B=.F.A=.F.^B=.TA=.F.^B=.F.A^BTFA^BTFA^BTF语句覆盖语句覆盖：选择足够的测试用例，使得程序中每个语句至少都能被执行一次。语句覆盖例测试用例的设计格式如下【输入的(A,B,X)，输出的(A,B,X)】正好所有的可执行语句都在路径L1上测试用例【(2,0,4)，(2,0,3)】A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced54只需设计一个测试用例:

输入数据：A=2，

B=0，

X=4

即达到了语句覆盖。语句覆盖是最弱的逻辑覆盖（如：OR

写成AND，X>1写成X<1,查不出来）分支覆盖分支覆盖又称判定覆盖。分支覆盖：执行足够的测试用例，使得程序中每个判定都获得一次“真”值和“假”值，或者说使得程序中的每一个分支至少都通过一次。分支覆盖例选择路径L1和L2【(2,0,4)，(2,0,3)】覆盖ace【L1】【(1,1,1)，(1,1,1)】覆盖abd【L2】

或选择路径L3和L4【(2,1,1)，(2,1,2)】覆盖abe【L3】【(3,0,3)，(3,0,1)】覆盖acd【L4】A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced条件覆盖条件覆盖：执行足够的测试用例，使得判定中的每个子条件都获得所有可能的结果。条件覆盖例A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced判断条件取真值取假值判断(一)A>1T1T1B=0T2T2判断(二)A=2T3T3X>1T4T4设条件的取值标记

判定/条件覆盖可选取的测试用例

如下表测试用例通过路径条件取值覆盖分支

【(1,0,3)，(1,0,4)】abe(L3)b,e【(2,1,1)，(2,1,2)】abe(L3)b,eT1T2T3T4T1T2T3T4判定/条件覆盖判定/条件覆盖：执行足够的测试用例，

使得判定中每个子条件取到各种可能的值，并使每个判定取到各种可能的结果。分支/条件覆盖例A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced判断条件取真值取假值判断(一)A>1T1T1B=0T2T2判断(二)A=2T3T3X>1T4T4设条件的取值标记

判定/条件覆盖可选取的测试用例

如下表测试用例通过路径条件取值覆盖分支

【(2,0,4)，(2,0,3)】ace(L1)c,e【(1,1,1)，(1,1,1)】abd(L2)b,dT1T2T3T4T1T2T3T4条件组合覆盖条件组合覆盖：执行足够的测试用例，使得每个判定中各条件的所有可能的组合都出现一次。条件组合覆盖例条件标记第一个判断取真假分支

A>1B=0A>1B≠0A≯1B=

0A≯1B≠

0判断条件取真值取假值判断(一)A>1T1T1B=0T2T2判断(二)A=2T3T3X>1T4T4设条件的取值标记T1T2①

取真分支T1T2T1T2②

取假分支③

取假分支④

取假分支T1T2A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced条件组合覆盖例判断条件取真值取假值判断(一)A>1T1T1B=0T2T2判断(二)A=2T3T3X>1T4T4设条件的取值标记A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced条件标记第二个判断取真假分支

A=2X>1A=2X≯1A≠2X>1A≠2X≯1T3T4⑤

取真分支T3T4T3T4⑥

取真分支⑦

取真分支⑧

取假分支T3T4条件组合覆盖例测试用例通过路径条件取值覆盖组合号

【(2,0,4),(2,0,3)】aceL1T1T2T3T4①,⑤【(2,1,1),(2,1,2)】abeL3T1T2T3T4②,⑥【(1,0,3),(1,0,4)】abeL3T1T2T3T4③,⑦【(1,1,1),(1,1,1)】abdL2T1T2T3T4④,⑧A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced路径覆盖路径测试就是设计足够的测试用例，覆盖程序中每一条可能的执行路径。例子func(intA,B,X){if((A>1)&&(B=0)){X:=X/A};if((A=2)||(X>1)){X:=X+1};}A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced路径L1(ace)={(A>1)and(B=0)}and{(A=2)or(X/A>1)}=(A>1)and(B=0)and(A=2)or(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(abd)=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)

or

not(B=0)and

not(A=2)andnot(X>1)L3(abe)=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)

or

not(B=0)and(A=2)

or

not(B=0)and(X>1)L4(acd)={(A>1)and(B=0)}

andnot

{(A=2)or(X/A>1)}=(A>1)and(B=0)andnot(A=2)and

not(X/A>1)路径覆盖例测试用例通过路径条件取值

【(2,0,4),(2,0,3)】aceL1T1T2T3T4【(1,1,1),(1,1,1)】abdL2【(1,1,2),(1,1,3)】abeL3【(3,0,3),(3,0,1)】acdL4T1T2T3T4A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabcedT1T2T3T4T1T2T3T4条件测试路径选择当程序中判定多于一个时，形成的分支结构可以分为两类：嵌套型分支结构和连锁型分支结构。对于嵌套型分支结构，若有n个判定语句，需要n+1个测试用例；对于连锁型分支结构，若有n个判定语句，需要有2n个测试用例，覆盖它的2n条路径。循环测试路径选择循环分为4种不同类型：简单循环连锁循环嵌套循环非结构循环(1)简单循环①零次循环：从循环入口到出口②一次循环：检查循环初始值③二次循环：检查多次循环④m次循环：检查在多次循环⑤最大次数循环、比最大次数多一次、少一次的循环例：求最小值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测试用例选择(2)

嵌套循环①对最内层循环做简单循环的全部测试。所有其它层的循环变量置为最小值；②逐步外推，对其外面一层循环进行测试。测试时保持所有外层循环的循环变量取最小值，所有其它嵌套内层循环的循环变量取“典型”值。③反复进行，直到所有各层循环测试完毕。④对全部各层循环同时取最小循环次数，或者同时取最大循环次数。连锁循环与非结构循环(3)连锁循环如果各个循环互相独立，则可以用与简单循环相同的方法进行测试。但如果几个循环不是互相独立的，则需要使用测试嵌套循环的办法来处理。(4)非结构循环这一类循环应该使用结构化程序设计方法重新设计测试用例。基本路径测试基本路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，设计测试用例的方法。设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。1.程序的控制流图符号○为控制流图的一个结点，表示一个或多个无分支的PDL语句或源程序语句。箭头为边，表示控制流的方向。流图说明在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。如果判断中的条件表达式是由一个或多个逻辑运算符(OR,AND,...)连接的复合条件表达式，则需改为一系列只有单个条件的嵌套的判断。2.程序环路复杂性程序的环路复杂性给出了程序基本路径集中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。从控制流图来看，一条独立路径是至少包含有一条在其它独立路径中从未有过的边的路径。例如在图示的控制流图中，一组独立的路径是

path1：1-11

path2：1-2-3-4-5-10-1-11

path3：1-2-3-6-8-9-10-1-11

path4：1-2-3-6-7-9-10-1-11路径path1，path2，path3，path4组成了控制流图的一个基本路径集。3.导出测试用例导出测试用例，确保基本路径集中的每一条路径的执行。根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到—用逻辑覆盖方法。每个测试用例执行之后，与预期结果进行比较。如果所有测试用例都执行完毕，则可以确信程序中所有的可执行语句至少被执行了一次。测试覆盖要求对单元测试来说，语句覆盖和分支覆盖是最基本的要求。由于程序中错误（异常）处理工作的重要性以及其结构相对简单，要求错误处理要做到路径覆盖。对质量要求高的软件单元，可根据情况提出条件覆盖、分支／条件覆盖、条件组合覆盖以及其它更高的覆盖要求。STARTINPUT(A,B,C)//判定表达式1IFA>5THENX=10ELSEX=1ENDIF//判定表达式2IFB>10THENY=20ELSEY=2ENDIF练习//判定表达式3IFC>15THENZ=30ELSEZ=3ENDIFPRINT(X,Y,Z)STOP设计下列伪码程序的语句覆盖和路径覆盖测试用例：作业（第7章）序号判定输入预期的输出123ABCXYZ1FFF1111232TTT204060102030语句覆盖的测试用例序号判定输入预期的输出123ABCXYZ1FFF1111232FFT116012303FTF140112034FTFF201110236TFT20160102307TTF20401102038TTT204060102030路径覆盖的测试用例90

黑盒测试法把程序看成一个黑盒子，完全不考虑程序的内部结构和处理过程。黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据产生正确的输出信息，并且保持外部信息(如，数据库或文件)的完整性。

黑盒测试又称为功能测试。黑盒测试

91黑盒测试力图发现下述类型的错误：①功能不正确或遗漏了功能；②界面错误；③数据结构错误或外部数据库访问错误；④性能错误；⑤初始化和终止错误。白盒测试在测试过程的早期阶段进行，而黑盒测试主要用于测试过程的后期。黑盒测试故意不考虑程序的控制结构，而把注意力集中于信息域。黑盒测试等价类划分边值分析错误推测因果图一.等价类划分等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。划分等价类所谓等价分类，就是把输入数据的可能值划分为若干等价类(等价类是指某个输入域的子集合。在该集合中，各个输入数据对于揭露程序中的错误都是等价的)。因此，可以把全部输入数据合理地划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，这样就可以少量的代表性测试数据，来取得较好的测试结果。有效等价类和无效等价类①

有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。②

无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。划分等价类等价类的原则：1如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。例如对输入“……项数可以从1到999……”

则有效等价类是“1≤项数≤999”两个无效等价类是“项数＜1”或“项数＞999” 划分等价类等价类的原则：2如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。例如在Pascal语言中对变量标识符规定为“以字母打头的……串”所有以字母打头的构成有效等价类不在此集合内（不以字母打头）的归于无效等价类。划分等价类等价类的原则：4如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。这时可为每一个输入值确立一个有效等价类，此外针对这组值确立一个无效等价类，它是所有不允许的输入值的集合。例如，在教师上岗方案中规定对教授、副教授、讲师和助教分别计算分数，做相应的处理。因此可以确定4个有效等价类为教授、副教授、讲师和助教，一个无效等价类，它是所有不符合以上身分的人员的输入值的集合。划分等价类等价类的原则：3如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。

划分等价类等价类的原则：5如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。例如，Pascal语言规定“一个语句必须以分号‘;’结束”。这时，可以确定一个有效等价类“以‘;’结束”，若干个无效等价类“以‘:’结束”、“以‘,’结束”、“以‘’结束”、“以LF结束”等。注意点1、划分等价类不仅要要考虑代表“有效”输入值的有效等价类，还需考虑代表“无效”输入值的无效等价类。2、每一无效等价类至少要用一个测试用例，不然就可能漏掉某一类错误，但允许若干有效等价类合用同一个测试用例，以便进一步减少测试的次数。确立测试用例在确立了等价类之后，建立等价类表，列出所有划分出的等价类。确立测试用例再从划分出的等价类中按以下原则选择测试用例：

(1)

为每一个等价类规定一个唯一编号；

(2)

设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；

(3)

设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。等价类划分设计测试用例实例某一PASCAL语言版本中规定：“标识符是由字母开头，后跟字母或数字的任意组合构成。有效字符数为8个，最大字符数为80个。”“标识符必须先说明，再使用。”“在同一说明语句中，标识符至少必须有一个。”

建立输入等价类表覆盖所有等价类的测试用例①VARx，T1234567：REAL；BEGINx:=3.414；T1234567:=2.732；...…(1),(2),(4),(8),(9),(12),(14)②VAR：REAL；(3)③VARx，：REAL;(5)

④VART12345678：REAL；(6)⑤VART12345......：REAL；(7)多于80个字符⑥VART$：CHAR；(10)⑦VARGOTO：INTEGER；(11)⑧VAR2T：REAL；(13)⑨VARPAR：REAL；BEGIN......PAP:=SIN(3.14*0.8)/6；(15)107

某工厂公开招工，规定报名者年龄应在16周岁至35周岁之间（到2005年4月30日止）。输入格式为4位年份+2位月份的数字表示，如190012，出生年龄不在上述范围内，将拒绝接受，并显示“年龄不合格”等出错信息。“出生年月”的等价类第一步：划分等价类例108第二步：设计测试用例二.边值分析长期经验表明：大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部边界是指相当于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况使用边界值分析方法设计测试用例，应对确定的边界，选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做为测试数据示例在做三角形计算时，要输入三角形的三个边长A、B和C这三个数值应当满足A＞0、B＞0、C＞0、A＋B＞C、A＋C＞B、B＋C＞A如果把六个不等式中的任何一个大于号“＞”错写成大于等于号“≥”，那就不能构成三角形问题恰出现在容易被疏忽的边界附近边值分析使用原则如果输入条件规定了取值范围或数据个数，则可选择正好等于边界值、刚刚在边界范围内和刚刚超越边界外的值进行测试针对规格说明的每个输入条件，使用上述原则对于有序数列，选择第一个和最后一个边界值分析法与等价类划分法区别边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。被测试子域测试内点测试外点

如果在悬崖峭壁边可以自信地安全行走，平地就不在话下。如果软件在能力达到极限时能够运行，那么在正常情况下就不会出什么问题。软件边界与悬崖很类似113招工年龄的边界值分析（部分）年龄对应输入：月份对应输入：最大合格年龄：年月值为35周岁最小合格年龄：年月值为16周岁恰大于最大合格年龄：年月值比35周岁大1月恰小于最小合格年龄：年月值比16周岁小1月最大月份：12最小月份：01恰大于最大月份：13恰小于最小月份：00输入条件出生日期的类型及长度1个数字字符5个数字字符7个数字字符有1个非数字字符全部是非数字字符6个数字字符显示出错显示出错显示出错显示出错显示出错输入有效日期范围月份范围“招工年龄（6位数字字符）”边界值分析法测试用例测试用例说明测试数据期望结果选取理由51970519700051970.5MAY---197005月份为1月月份为12月月份<1月份>12197001197012197000197013197003198904197002198905输入有效输入有效显示出错显示出错输入有效输入有效显示出错显示出错在有效范围边界上选取数据仅有1个合法字符比有效长度少1比有效长度多1只有1个非法字符6个非法字符类型及长度均有效最小日期最大日期刚好小于最小日期刚好大于最大日期最小月份最大月份刚好小于最小月份刚好大于最大月份115人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试方案。三.错误推测错误猜测法—看一个颇有启发的故事

发生在美国通用汽车的客户与该公司客服部间的真实故事

一天美国通用汽车公司的客服收到一封客户抱怨信,这样写的：我们家有一个传统的习惯,就是每天晚餐后,会吃冰淇淋甜点,我开车去买。奇怪的是每当我买香草口味的冰激凌，车子就发不动。但如果我买的是其他的口味,车子发动就顺得很.难道你们的车对香草冰激凌过敏？

客服经理心存怀疑,但他还是派了一位工程师去查看究竟。工程师与这位仁兄上车，往冰淇淋店开去，买香草口味，当回到车上后，车子起不动了。这位工程师之后又依约来了三个晚上：第1晚巧克力冰淇淋，车子没事；第2晚草莓冰淇淋，车子也没事；第3晚香草冰淇淋，车子又不动了。

工程师开始记下从头到现在所发生的种种详细资料，如时间、车子使用油的种类、车子开出及开回的时间……，根据资料显示他有了一个结论，这位仁兄买香草冰淇淋所花的时间比其它口味的要少。为什么呢？原因是香草冰淇淋是所有冰淇淋口味中最畅销的口味，店家为了让顾客每次都能很快的取拿，将香草口味特别分开陈列在单独的冰柜，时间比买其他口味的要快。

买其他口味冰激凌时由于时间较久，引擎有足够的时间散热，重新发动时就没有太大的问题。买香草口味时，由于花的时间较短，引擎太热以至于还无法让“蒸气琐”有足够的散热时间。

有时问题看起来真的是疯狂，但它是真正存在的；我们应保持冷静的思考去找寻解决的方法。117例：数据排序程序的测试用边界值分析法设计以下测试用例：①输入表为空表；②输入表中仅有一个数据；③输入表为满表。用错误猜测法补充如下用例：④输入表已经排好序；⑤输入表的数据顺序恰好于要求的顺序相反；⑥输入表中的数据完全相同四.因果图法适用范围：如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。因果图的基本步骤(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)转换成判定表

因果图方法实例某电力公司有A、B、C、D四类收费标准,并规定：居民用电<100度/月按A类收费≥100度/月按B类收费动力用电<10000度/月,非高峰,B类收费≥10000度/月,非高峰,C类收费

<10000度/月,高峰,C类收费≥10000度/月,高峰,D类收费用因果图表明输入和输出间的逻辑关系1I12AB∨∧C435∧DI4I3I2∨∧∧∧∧因果<100居民动力<10000非高峰把因果图转换为判定表组合条件条件(原因)动作(结果)ABC123123456101100011000110000100001104101050011D000110010000测试用例为判定表每一列设计一个测试用例:1列居民电,90度/月A2列居民电,110度/月B3列动力电,非高峰,8000度/月B4列动力电,非高峰,1.2万度/月C5列动力电,高峰,0.9万度/月C6列动力电,高峰,1.1万度/月D

条件测试用例预期结果组合(输入数据)(输出动作)测试策略测试步骤测试结果分析测试大纲项目编号：第

次测试1234硬件环境运行是否正常网络环境运行是否正常系统软件运行是否正常防病毒处理结果模块编号测试结果当某一测试结果为’√’时表示通过，为’×’时表示还存在错误。本表内容不足以记录时，可以在附页填写，总页数可用铅笔填写。模块编号按模块依据从属关系或按层次编号。测试问题卡--测试员：项目编号：序号模块编号错误现象等级频率时机改否修改者签字上表解释“等级”是指错误等级，可分为A：严重影响系统运行；B：影响系统运行；C：不影响运行但必须修改；D：所提建议。“频率”指错误出现频率，分为A：操作即出现；B：偶尔出现。“时机”指错误出现时机，分为A：修改后出现；B：已发现但未修改；C：首次出现。“改否”项由开发人员填写，如果已修改该问题，填“√”，否则为空。“建议返回时间”指要求开发人员在某时间之前，将修改后的软件返回给测试人员重新测试。测试用例模版：测试用例编号：

项目名称：模块名称

模块编号项目开发经理

测试负责人功能简述操作步骤测试用例描述：测试输入

预期结果预期时间

测试过程说明

备注：上表解释测试用例描述：用于说明本测试用例的测试要点。操作步骤：用于描述执行该功能的基本操作。操作过程及测试数据：用于描述测试用例的操作步骤及所使用的测试数据。此项内容根据测试用例的复杂性选择使用，对没有必要写明操作步骤的此项可省略预期结果和验证过程：这两项内容用于记录测试用例正确执行应得到的结果，预期结果多用于描述界面上可见结果。验证过程多用于界面上无可见结果但在其它操作中可验证的过程。预期结果和验证过程根据实际需要均可省略，但至少要有一项以明确测试结果。运行预期时间；该项对在运行时间上有要求的，或通过运行时间能反映执行情况的测试用例使用。备注：用于记录该测试用例执行的一些特殊说明，如必须先运行某测试用例。12.5单元测试单元测试是软件测试环节中最基本的测试，测试的对象是独立的模块。单元测试开始之前要先通过编译程序检查并改正语法错误，然后用详细设计说明书作为指南对模块的功能和模块代码中的重要执行路径及主要算法进行测试。单元测试可以对多个模块同时进行。单元测试主要分为人工静态检查和动态执行跟踪两个步骤进行。人工静态检查主要是保证算法代码实现的正确性和高效性，代码编写清晰、规范。经验表明，使用人工静态检查法能够有效的发现30%--70%的逻辑设计和编码错误。成立一个3—4人的代码审查小组，包括经验丰富的测试人员、被测程序的作者和其他程序员。被测程序的作者讲述程序的逻辑结构，大家发现问题可随时提问，以判断是否存在错误。方法检查算法实现的正确性。确定所编写的代码和定义的数据结构实现了模块或方法所要求的功能。检查模块接口的正确性。检查模块的参数个数、类型、顺序是否正确，确定返回值的正确性。调用其他方法接口的正确性。检查实参类型、数值、个数的正确性，特别是具有多态性的方法。检查返回值的状态，最好对每个被调用方法的返回值用显式代码做正确性检查，如果被调用方法出现异常或错误，程序应该给予反馈，并添加适当的出错处理代码。出错处理。模块代码要求能预见出错的条件，并设置适当的出错处理，这种出错处理应当是模块功能的一部分。若出现下列情况之一，则表明模块的错误处理功能不够完善：出错信息描述难以理解；错误信息的描述不足以对错误定位，不足以确定出错原因显示的错误信息与实际的错误原因不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预等保证表达式、SQL语句的正确性。表达式应该保证不含二义性，对于容易产生歧义的表达式或运算符优先级（如《、=、》、&&、||、++、--等）可以采用括号“（）”运算符避免二义性，这样一方面能够保证代码的正确可靠，同时也能够提高代码的可读性。检查常量或全局变量使用是否正确。标识符定义是否规范一致。保证