【教学课件】第五章软件测试工程

《【教学课件】第五章软件测试工程》由会员分享，可在线阅读，更多相关《【教学课件】第五章软件测试工程（192页珍藏版）》请在装配图网上搜索。

1、Click to edit Master title style,,Click to edit Master text styles,,Second Level,,Third Level,,Fourth Level,,Fifth Level,,第五章 软件测试工程,概述,,软件开发过程必须伴有质量保证活动。,,软件测试是软件质量保证的关键元素，代表了规约、设计和编码的最终检查。,,软件产品最大的成本是检测软,,件错误、修正软件错误的成本。,,,,在整个软件开发中，测试工作量,,一般占,30%～40%，甚至≥50%。,,,在人命关天的软件(如飞机控制、核反应堆等）测试所花费的时间往往是其它软

2、件工程活动时间之和的三到五倍,,软件测试是为了发现错误而执行程序的过程，或者说，软件测试是根据软件的规格说明（例如软件的功能、性能、运行环境等要求）以及程序内部结构而设计一批测试用例，并利用这些测试用例去运行程序，以发现软件错误的过程。,,,测试用例是为了测试软件而设计的一组数据，它应该包括输入的数据和预期输出的结果两部分。,,,测试用例={输入数据+预期结果},软件测试背景,软件是人编的—所以不完美,,实例:,,Intel,的,pentium,处理器,,1994,年,浮点除法缺陷,,2000,年,8,月,28,日，,1.13MHZ,处理器一个可能导致运行程序被挂起的执行指令问题,,1999,

3、年,12,月,3,日,,,美国航天局火星极地登陆飞船失踪,,1991,年爱国者导弹防御系统系统时钟错误积累造成跟踪系统失去精确度,,千年虫：世界各地解决,2000,年错误超过数亿美元,,质量管理领域权威人物,将质量定义为“决定产品性能和‘满意程度’的特征”,,,测试注重于产品的满意度。,,测试应针对这样一种情况：软件产品在一些特定的范围内不能满足客户的合理要求。,,通过,测试,过程可以评定,质量风险（可能的错误）,，了解被测试系统中存在的,错误模式（观察到的错误症状）,。,,软件测试是一个查找错误的过程，所以软件测试只能证明错误的存在，而不是证明程序无错，不能保证经过测试的程序一定没有错误。,

4、,软件测试仅仅是一个手段，根本的目的是为了纠错，即纠正软件中的错误，从而提高软件的质量。,,测试不可能发现所有错误，只能在有限的时间和经济条件下，尽可能地发现错误。,质量控制技术,质量控制活动分类,开发方法学,配置管理,验证技术,评 审,正确性验证,性能调试,组件测试,集成测试,系统测试,原子事务,模块冗余性,检 错,质量控制,避免错误,容 错,调 试,测 试,测试的目的与地位,,,在《软件测试技巧,》,中认为:,,1.测试是为了寻找错误而运行程序的过程。,,2.一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试。,,3.一个成功的测试是揭示了迄今为止尚未发现的错误的测试

5、。,指出:,,“,程序测试能证明错误的存在,但不能证明错误不存在,。”,,,测试的目的是发现程序中的错误,是为了,证明程序有错,而不是证明程序无错。,,把证明程序无错当作测试目的不仅是不正确的,,,完全做不到的，而且对做好测试没有任何益处，甚至是,十分有害,的。,,软件测试要设法使软件发生故障,,,暴露软件错误。,,,,测试的“成功”与“失败”：能够发现错误的测试是成功的测试，否则是失败的测试。,,“,测试的目的是说明程序正确地执行它应有的功能,” 这种说法正确吗？,,,例：程序Triangle，输入三个整数，表示一个三角形的三个边长，该程序产生一个结果，指出该三角形是等边三角形、等腰三角形还

6、是不等边三角形。,,为说明其能正确执行它的功能，可使用“测试用例”(3,4,5),(5,5,6),(6,6,6),,,程序都能给出正确结果，是否就可认为程序是正确的？,,,（两边之和必须大于第三边）,难以说清的软件缺陷,古谚： “一片树叶飘落在森林中没有人听见，谁能说它发出了声音？”,由于不能报告没有看见的问题，因此，没有看见就不能说存在软件缺陷。,,如果软件中的问题没有人发现，那么它算不算软件缺陷？”,只有看到了，才能断言软件缺陷，尚未,,发现的软件缺陷只能说是未知软件缺陷。,眼,,见,,为,,实,测试原则,,(1)所有的测试都应追溯到用户需求,,最严重的错误(从用户角度)是那些导致软件无法

7、满足需求的错误。,,程序中的问题根源,可能出现在开发前期的各阶段，纠正错误也必须追溯到前期工作。,,测试与开发前期工作的关系,决定软件与系统的配合关系,需求分析,概要设计,详细设计,编 码,单元测试,集成测试,确认测试,系统测试,开发前期出现错误的扩展,计划,需求,,分析,设,,计,编,,码,测,,试,A,A,B,软件生存期各阶段间需保持的正确性,用户要求,用户:,,我要什么?,运行结果,计算机:,,程序运行得,,到的结果,源程序,程序员:,,我要让计算,,机什么做?,设计说明书,设计员:,,我要让软件,,做什么?,需求说明书,分析员:,,我可以提,,供什么?,1,2,3,4,5,理解正确性

8、,,表达正确性,理解正确性,,设计正确性,,表达正确性,理解正确性,,编码正确性,运行正确性,,输入正确性,相符吗?,测试原则,,(2),应该尽早制定测试计划。,,,概要设计时应完成测试计划，详细的测试用例定义可在设计模型确定后开始，所有测试可在任何代码被产生之前进行计划和设计。,,,测试原则,,(3),应该由第三方进行测试工作。,,一个软件项目的开发人员不应该同时是该软件的测试人员，基于心理因素，人们往往不愿意否定自己的工作。,测试原则,,(4),穷举测试是不可能的。,,测试的最高目标是指发现错误的可能性最高的测试，所以，测试的关键技术是设计一组高产的测试用例，好的测试方案是尽可能发现至今为

9、止仍未发现的错误。从某种意义上说，测试是否成功，取决测试用例的选择。,测试原则,,(5)充分注意到错误的群集现象,,经验表明，测试发现的错误中有80%的错误很可能是由20%的程序模块造成的，这是一种错误群集性现象。也就是说，在程序段中，发现错误数目多的地方，则残存错误的数目也比较多，这一现象已为许多程序测试实践所证明。,测试原则,,(6)测试应该从“小规模”到“大规模”,,通常，最初的测试重点往往是放在单个的程序模块中，然后，进一步的测试重点放在集成的模块族，最后是对整个系统进行测试。随着测试的逐步深入展开，要集中测试容易出错的地方。,,软件测试流程,软件,,配置,测试,测试,,配置,测试,,

10、工具,结果,,分析,排错,可靠性,,分析,测试,,结果,错误,预期,,结果,出错率,,改正,,的软件,预测,,的可,,靠性,,需求规格说明书,,软件设计说明书,,被测源程序,测试计划,,测试用例,,(测试数据),,测试驱动程序,,软件配置：需求规格说明、设计说明书、源程序等。软件配置中还应包含测试配置。,,测试工具：为软件测试提供的某种服务程序。,,评价：测试结果与期望结果比较，如果有差异则往往程序有错，需要改正。,,可靠性预测有3种情况可以考虑：,,A.如果测试发现严重错误，则软件的质量和可靠性一定不高;,,B.如果测试结果是软件功能完成正常，发现的问题不是严重错误,也容易修改，则可能：（1

11、）软件质量和可靠性可以接受；（2）所进行的测试还不足以发现严重错误，错误被潜伏下来。,,C.测试没有发现任何错误，则极有可能是测试配置选择不当（测试用例没有选好），错误被深深地潜伏下来，这是极危险。,,软件测试对象,,软件测试的对象应包括需求分析与设计以及编码等所获得一切的文档和程序。,,软件测试方法,软件测试方法一般可以分成静态测试和动态测试等。,,,静态测试实际上是确认在给定的外部环境中软件的逻辑正确性，它应该包括需求规格说明和程序等的确认。,,,动态测试也称为机器测试，动态测试主要是通过动态分析以及程序测试来检查程序的执行状态，以确认程序的正确性。,,测试的方法与技术,软件测试的,,策略

12、和方法,静态测,,试方法,动态测,,试方法,人工测试方法,计算机辅助静,,态分析方法,白盒测试方法,黑盒测试方法,静态和动态测试,汽车的检查过程:,,踩油门,,看车漆,,打开前盖检查,,发动汽车,,听听发动机声音,,上路行使,静态测试,动态测试,静态测试：,基本特征是对软件进行,,分析、检查和审阅，不实,,际运行被测试的软件。,,,静态测试约可找出,30,～,70%,的逻辑设计错误,.,,对,需求规格说明书,、,软件设计说明书,、,源程序,做检查和,审阅,，,包括：,①,是否符合标准和规范；,②,通过,结构分析、流图分析、符号执行,指出软件缺陷,；,,,静态测试方法,,（1）人工测试方法。人工

13、测试就是通过人工阅读分析以及评审软件的文档、程序资料等等，以发现程序中的错误，尤其是一些设计上的逻辑错误在机器上不易发现，需要人工复查。根据统计，好的人工评审，可以发现30%到70%的编码或逻辑设计错误。,,（2）计算机辅助静态分析。为了提高测试的效率，人们可以设计一些分析工具对被测试的程序进行静态分析，从中提取一些信息。例如，检查程序中的局部变量和全局变量、参数的匹配、判断与循环的嵌套匹配、潜在的死循环、不执行的代码、过程调用层次等等。,,（3）程序正确性说明。程序正确性证明是试图找到某种方法，确切地证明程序是没有错误的。所谓证明，就是确信一个断言真实性的论证。这种证明可以形式化的或非形式化

14、。,动态测试：,通过运行软件来检验软件的动态行为和运行结果的正确性。,,,动态测试的两个基本要素：,,,被测试程序,,测试数据（测试用例）,动态测试方法,,(1)选取定义域有效值,或定义域,,外无效值.,,(2)对已选取值决定,预期的结果,,(3)用选取值执行程序,,(4),执行结果,与(2)结果相比,,,,不吻和则程序有错,.,,动态黑盒测试 —,闭着眼睛测试软件,软件,输入,不深入代码细节的测试方法称为动态黑盒测试。,,软件测试员充当客户来使用它。,输出,动态白盒测试 —,带上,X,光眼镜测试软件,?,?????????????,,250*(1+0.015)*((1+0.015)^360-

15、1)/0.015,250*(1+0.015)*((1+0.015)^360-1)/0.015,假如知道一个盒子包含一台计算机,而另一个,,盒子是人用纸笔计算,就会选择不同的测试用例,了解软件的运作方式会影响测试手段,穷举测试,,例:,输入 三条边长,黑盒测试,,可采用的测试用例数,,,(设字长16位),,执行时间: 设测试一次需1ms,,共需一万年.,=2 X2 X2 ≈3X10,16,16,16,14,穷举测试,白盒测试,,例:,,含4个分支,循环次数,,≤20,从A到B的可能,,路径,,,,执行时间: 设测试一次需2ms,,穷举测试需5亿年.,=5+5 +..+5 +5,,≈10,20

16、,1,2,19,14,A,B,第一次为5，第二次为5*5,,不论黑盒还是白盒测试都,不能,,进行穷尽测试,, 所以软件测试不可,,能发现程序中存在的所有错误, 因,,此需精心设计测试方案,,力争尽可,,能少的次数,测出尽可能多的错误,.,两种类型的测试,,,黑盒测试,,,又称:功能测试,,,数据驱动测试,,基于规格说明书的测试,,,白盒测试,,又称:开盒测试,,结构测试,,玻璃盒测试,,基于覆盖的测试.,,根据被测程序的逻辑结构设计测试用例;力求提高测试覆盖率;,黑盒测试与白盒测试比较,,,黑盒测试,是从用户观点，按,,规格说明书要求的输入数据与输,,出数据的对应关系设计测试用例,,,是根据程

17、序,外部特征,进行测试。,,,,,白盒测试,是根据程序,内部逻辑结构,进行测试。,黑盒测试与白盒测试优缺点比较,,,黑盒测试,,白盒测试,,,优,,点,缺,,点,性,,质,①适用于各阶段测试,,②从产品功能角度测试,,③容易入手生成测试数,,据,①可构成测试数据使特定程,,序部分得到测试,,②有一定的充分性度量手段,,③较多工具支持,①某些代码得不到测试,,②如果规格说明有误，,,则无法发现,,③不易进行充分性测试,①不易生成测试数据(通常),,②无法对未实现规格说明的,,部分进行测试,,③工作量大，通常只用于单,,元测试，有应用局限,是一种,确认,技术，回答:,,“,我们在构造一个正确,,的

18、系统吗？,”,是一种,验证,技术，回答:,,“,我们在正确地构造一个系,,统吗,？”,黑盒测试与白盒测试能发现的错误,,,C,B,A,D,-,只能用黑盒测试发现的错误,A,-,只能用白盒测试发现的错误,-,两种方法都能发现的错误,-,两种方法都不能发现的错误,B,C,D,,测试用例设计,,,选择测试用例是软件测试员最重要,,的一项工作。,,测试用例的属性:,,属性 描述,,name,测试用例的名称,,,location,可执行的完全路径名,,,input,输入数据或命令,,oracle,与测试输入相比较的期待测试结果,,log,测试生产的输出,程序测试举例,,例：程

19、序 Triangle， 输入三个整,,数，表示一个三角形的三个边,,长，该程序产生一个结果，指,,出该三角形是等边三角形、等,,腰三角形还是不等边三角形。,判断三角型的测试用例设计:,,输入数据 预期结果,,(1) 6;6;6 等边,,(2) 8;8;4 等腰,,(3) 4;5;6 一般,,,还应输入,非法数据：,,,0; 7; 9,,-7;3; 5,,a; 2; 7,等,白盒测试的测试用例设计,,,逻辑覆盖法,,(1)语句覆盖,,(2)判定覆盖,,(3)条件覆盖,,(4)判定/条件覆盖,,(5)条件组合覆盖,,(6)路径覆盖,,

20、(7)点覆盖,,(8)边覆盖,例:,PROCEDURE SAMPAL,,(A，B：REAL； VAR X：REAL);,,BEGIN,,IF (A>1) AND (B=0),,THEN X:=X/A,,IF (A=2) OR (X>1),,THEN X:=X+1,,END;,,开始,(A>1) AND (B=0),(A=2) OR (X>1),返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,(1)语句覆盖,,,使程序中每个语句至少执行一次,,,语句覆盖,,开始,(A>1) AND (B=0),(A=2) OR (X>1),返回,X=X/A,X=X+1,F,F,T,T,a

21、,b,d,c,e,,只需设计一个测试用例:,,输入数据：,A=2，B=0，X=4,,则覆盖ace,可以执行程序中的每一条语句,即达到了语句覆盖;,,,语句覆盖是,最弱,的逻辑覆盖,,(2)判定覆盖(分支覆盖),,,,,使每个判定的真假分支都至少执行一次,判定覆盖,,开始,(A>1) AND (B=0),(A=2) OR (X>1),返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,例:可设计两组测试用例:,,A=3，B=0 ，X=3 可覆盖,c、d,分支,,,A=2，B=1 ，X=1 可覆盖,b、e,分支,,两组测试用例可覆盖所有判定的真假,,分支。,,,语句覆盖仍是,弱,

22、的逻辑覆盖。,(3)条件覆盖,,,使每个判定的每个条件的可能取值至少执行一次,,第一判定表达式:,,设,条件 A>1,取真 记为,T1,,,假,T1,,,条件 B=1,取真 记为,T2,,,假,T2,,第二判定表达式:,,设,条件 A=2,取真 记为,T3,,,假,T3,,,条件 X>1,取真 记为,T4,,,假,T4,条件覆盖,,开始,(A>1) AND (B=0),(A=2) OR (X>1),返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,满足条件:,T1,T1,,,T2,T2,,T3,T3,,T4,T4,测试用例,,通过 满足的 覆盖,,A B X,

23、,,路径 条件 分支,,1 0 3 abe,T1,T2,T3,T4,b,,,e,,2 1 1 abe,T1,T2,T3,T4,b,,,e,,,两个测试用例,覆盖了四个条件八种可能,,取值,。,,未覆盖c、d分支,，不满足判定覆盖的要,,求.,,条件覆盖不一定包含判定覆盖,,判定覆盖也不一定包含条件覆盖,(4)判定/条件覆盖,,选取足够多的测试用例，使判断中的每个条件的所有可能取值至少执行一次，同时每个判断本身的所有可能判断结果至少执行一次.,,判定/条件,,覆盖,,开始,(A>1) AND (B=0),(A=2) OR (X>1),返

24、回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,满足条件:,T1,T1,,,T2,T2,,T3,T3,,T4,T4,测试用例,,通过 满足的 覆盖,,A B X,,,,路径 条件 分支,,2 0 4 ace,T1,T2,T3,T4,c,,,e,,2 1 1 abd,T1,T2,T3,T4,b,,,d,,,能同时满足判定、条件两种覆盖标准取值。,,测试用例,,通过 满足的 覆盖,,A B X,,路径 条件 分支,,2 0 3 ace T1,T2,T3,T4 c,e,,2 1 1 abe,T

25、1,T2,T3,T4,b,e,,1 0 3 abe,T1,T2,T3,T4 b,e,,1 1 1 abd,T1,T2,T3,T4 b,d,,,,,(5)条件组合覆盖,,,所有可能的条件取值组合至少执行一次,,,①,A>1, B=0,,,②,A>1, B≠0,,,③,A,≤,1, B=0,,,④,A,≤,1, B≠0,,,⑤,A=2, X>1,,,⑥,A=2, X,≤,1,,,⑦,A≠2, X>1,,,⑧,A≠2, X,≤,1,测试用例,,通过 满足的 覆盖,,ABX,,路径 条件 分支,,204,①⑤,,ace,T1,T2,T

26、3,T4 c,e,,211,②⑥,abe,T1,T2,T3,T4,b,e,,102,③⑦,abd,T1,T2,T3,T4 b,d,,111,④⑧,abd,T1,T2,T3,T4 b,d,,,它是这几种覆盖标准中最强的,,,,,(6)路径覆盖,,覆盖每一个可能的路径,,测试用例,,通过 满足的 覆盖,,A B X,,路径 条件 分支,,1 1 1 abd T1,T2,T3,T4 b,d,,1 1 2 abe,T1,T2,T3,T4,b,e,,3 0 1 acd,T1,T2,T3,T4 c,d,,2 0 4 ace,T1,T2,

27、T3,T4 c,e,,循环测试,,（1）简单循环测试,,假设n是允许通过循环的最大次数，应该进行下列的测试：,,跳过整个循环；,,只执行循环一次；,,执行循环两次；,,执行循环m次，其中，m＜n-1；,,执行循环n-1，n，n+1次。,,（2）嵌套循环测试,,如果把简单循环的方法直接用于嵌套循环，可能的测试次数会随着嵌套循环的层数的增加按几何级数增加，导致不现实的测试数目，可以进行下列的测试：,,从最内层循环开始测试，把其他循环都设置为最小值；,,对最内层循环使用简单测试方法，使外层循环的迭代参数取最小值（例如，循环计算器等），并且，为越界或非法值增加一些额外的测试；,,由内向外，对下一个

28、循环进行测试，保持它的所有外层循环为最小值，其他的嵌套循环取“典型”值。如此继续进行，直到测试完所有循环。,,,（3）串接循环测试,,如果串接循环的各个循环都彼此独立，则可以使用简单循环测试的方法来进行。但是，如果在两个串接循环中，第一个循环的循环计算器的值是第二个循环的初始值，则这两个循环并不是独立的。这时，建议使用嵌套循环测试方法来进行。,,基本路径测试法,,,通过分析由控制构造的环路的复杂性，导出基本路径集合，从而设计测试用例，保证这些路径至少通过一次。,,,基本路径测试步骤：,,,导出程序流程图的拓扑结构-流图,,(程序图),,计算流图G的环路复杂度V(G),,确定只包含独立路径的基本

29、路径集,,设计测试用例,导出程序流程图的拓扑结构,-,流图,,,1,2,3,6,4,5,7,10,11,a,节点,边,R4,区域,1,2,3,4,5,8,7,6,9,10,11,程序流程图,8,9,R1,R2,R3,计算流图G的环路复杂度V(G),,V(G)=区域个数=4,,V(G)=边的条数-节点个数+2=4,,,V(G)=判定节点个数+1=4,确定只包含独立路径的基本路径集,,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,,一条新路径必须包含一条新边。,,这

30、4条路径组成了一个基本路径集。4(环,,路复杂度V(G))是构成这个基本路径集的独立,,路径数的上界，也是设计,测试用例的数目。,,,设计测试用例，保证基本路径集中每条,,路径的执行。,黑盒测试的测试用例设计,,等价类划分法,,,把所有可能的输入数据(有效的,,和无效的)划分成若干个等价的子集,,(称为等价类)， 使得每个子集中的,,一个典型值在测试中的作用与这一,,子集中所有其它值的作用相同.,,可从每个子集中选取一组数据来测试程序,例:,某报表处理系统要求用户输入处理,,报表的日期，日期限制在2001年1,,月至2005年12月，即系统只能对该,,段期间内的报表进行处理，如日期,,不在此范

31、围内，则显示输入错误信,,息。,,系统日期规定由年、月的6位数字,,字符组成，前四位代表年，后两位,,代表月。,,如何用等价类划分法设计测试用例,,,来测试程序的日期检查功能？,,如何划分等价类？,,有效等价类,(,合理等价类,),,无效等价类,(,不合理等价类,),,,,,划分等价类的标准：,,覆盖,,不相交,,代表性,划分等价类的规则,(1),如果输入条件规定了取值范围，,,可定义一个有效等价类和两个无,,效等价类。,例,,输入值是学生成绩，范围是0～100,0 100,,有效,,等价类,,1≤成绩≤100,无效等价类,,成绩>100,,无效等价类,,成绩<0,～,划分等价

32、类的规则：,(2),如果输入条件代表集合的某,,个元素，则可定义一个有效,,等价类和一个无效等价类。,,划分等价类的规则：,(3),如规定了输入数据的一组值，且,,程序对不同输入值做不同处理，,,则每个允许的输入值是一个有,,效等价类，并有一个无效等价类,,(所有不允许的输入值的集合)。,,例：输入条件说明学历可为:,专科、本科、,,硕士、博士,四种之一，则分别取这四,,个值作为,四个有效等价类,，另外把四,,种学历之外的任何学历作为无效等价类,划分等价类的规则：,(4),如果规定了输入数据必须遵循的规,,则，可确定一个有效等价类（符合,,规则）和若干个无效等价类（从不,,同角度违反规则)。,

33、,,(5),如已划分的等价类各元素在程序中,,的处理方式不同，则应将此等价,,类进一步划分成更小的等价类。,用等价类划分法设计测试用例步骤：,(1)形成等价类表，每一等价类规定,,一个唯一的编号；,,(2)设计一测试用例，使其尽可能多,,地覆盖尚未覆盖的有效等价类，,,重复这一步骤，直到所有有效等,,价类均被测试用例所覆盖；,,(3)设计一新测试用例，使其只覆盖,,一个无效等价类，重复这一步骤,,直到所有无效等价类均被覆盖；,第一步：等价类划分,输入等价类 有效等价类 无效等价类,,报表日期的,,类型及长度,6位数字字符(1),有非数字字符 (4),,少于6个数字字符 (5

34、),,多于6个数字字符 (6),年份范围,在2001～2005,,之间 (2),小于2001 (7),,大于2005 (8),月份范围,在1～12之间(3),“报表日期”输入条件的等价类表,小于1 (9),,大于12 (10),第二步：,为有效等价类设计测试用例,,,对表中编号为1,2,3的3个有效等价类,,用一个测试用例覆盖：,,测试数据 期望结果 覆盖范围,200105,,等价类(1)(2)(3),,输入有效,第三步：为每一个无效等价类至少设,,计一个测试用例,,,,测试数据 期望结果 覆盖范围,001,MAY,等价类(4),输入无效,20015,等价类(5),输入无效

35、,2001005,等价类(6),输入无效,2000,05,等价类(7),输入无效,2008,05,等价类(8),输入无效,2001,00,等价类(9),输入无效,2001,13,等价类(10),输入无效,不能出现相同,,的测试用例,本例的10个等价类至,,少需要8个测试用例,例:,对招干考试系统“输入学生成绩”,,子模块设计测试用例,,招干考试分三个专业,准考证号第一位,,为专业代号,如: 1-行政专业,,,2-法律专业,,,3-财经专业.,,,,行政专业准考证号码为:110001～111215,,法律专业准考证号码为:210001～212006,,财经专业准考证号码为:310001～3140

36、15,,例:,准考证号码的等价类划分,,,有效等价类:,,,(1) 110001 ～ 111215,,(2) 210001 ～ 212006,,(3) 310001 ～ 314015,,,无效等价类:,,,(4) -,,,～ 110000,,(5) 111216 ～ 210000,,(6) 212007 ～ 310000,,(7) 314016 ～ +,,例:,计算给定月份中天数的方法接口(java):,,Class MyGregorianCalender{,,……,,public static in getNumDaysInMonth(int,,month,int year){…},,

37、……,,},,getNumDaysInMonth( ),方法有两个参数, 月和年,年份的有效输入是从0到,maxInt.,,等价类划分,即把,输入空间分解成一系列子域,，软件在一个子域内的行为应是等价的,。,,软件错误分为两类：,计算错误,,域错误,针对,计算错误的测试方法,,针对,域错误,的测试方法,:,测试,域边界,,划定的正确性,边界值分析法,,边界值分析法与等价类划分法区别,,(1),边界值分析不是从某等价类中,,随便挑一个作为代表，而是使,,这个等价类的每个边界都要作,,为测试条件。,,(2),边界值分析不仅考虑输入条件，,,还要考虑输出空间产生的测试,,情况,被测试,,子 域,测

38、试内点,测试外点,软件边界与悬崖很类似,边界条件类型,,,如果软件测试问题,,包含确定的边界,那,,么数据类型可能是:,,数值,,字符,,位置,,数量,,速度,,地址,,尺寸,,……,还要考虑数据类型的特征:,,第一个,/,最后一个,,最小值,/,最大值,,开始,/,完成,,空,/,满,,最慢,/,最快,,相邻,/,最远,,超过,/,在内,,……,测试边界线,,测试临近边界的合法数据,以及刚超过边界的非法数据.,,越界测试通常简单地加1或很小的数,,(对于最大值)和减1或很小的数(对于最小值).,,,,,输入,,条件,报表日,,期的类,,型及长,,度,1个数字字符,,5个数字字符,,7个数字字

39、符,,有1个非数字字符,,全部是非数字字符,,6个数字字符,显示出错,,显示出错,,显示出错,,显示出错,,显示出错,,输入有效,日期,,范围,月份,,范围,“报表日期”边界值分析法测试用,例,测试用例说明,测试数据,期望结果,选取理由,5,,20015,,2001005,,2001.5,,MAY---,,200105,月份为1月,,月份为12月,,月份<1,,月份>12,200101,,200112,,200100,,200113,200101,,200512,,200100,,200513,输入有效,,输入有效,,显示出错,,显示出错,输入有效,,输入有效,,显示出错,,显示出错,在有效范

40、围,,边界上选取,,数据,仅有1个合法字符,,比有效长度少1,,比有效长度多1,,只有1个非法字符,,6个非法字符,,类型及长度均有效,最小日期,,最大日期,,刚好小于最小日期,,刚好大于最大日期,最小月份,,最大月份,,刚好小于最小月份,,刚好大于最大月份,错误推测法,(error guessing),,根据经验来设计测试用例的方法。,,例如，数据测试中的:,,缺省值,,空白,,空值,,零值,,无,,,,状态测试,,,软件必须测试程序的状态及其转换。,,测试软件的逻辑流程,,建立状态转换图,,减少要测试的状态及转换的数量,空闲,等待用户,,输入命令,按下Esc键,,显示口令框,口令错误,,消

41、除,口令正确,,初始状态消失,空闲,等待用户,,输入命令,按下Esc键,口令正确,口令错误,不同形式的状态转换图,,,设置,2Bwatch,,上的时间的顺序图,:2Bwatch,用户,按下按钮1和2,:2Bwatch,输入,:2Bwatch,显示,:2Bwatch,时间,时间,按下按钮1,按下按钮2,按下按钮1和2,闪烁小时,闪烁分钟,增加分钟,刷新,提交更新时间,停止闪烁,2Bwatch,,设置时间功能的状态图和测试结果,,,按左按钮,,按右按钮,按左按钮,,按右按钮,4.,2分钟以后,测量时间,设置时间,电池没电,3.,按下左右按钮,5.,按下左右按钮/蜂鸣,8.,20年以后,7.,20年

42、以后,6.,2.,1.,激励因素,空集合,测量时间,1.初始变迁,测试的变迁,预期结果状态,按下左边按钮,测量时间,2.,同时按下两个按钮,设置时间,3.,等2分钟,测量时间,4.超时,……,……,……,失败状态测试,,找到测试软件失败的案例,。,,竞争条件和时序错乱,,重复,,压迫,,重负,应联合使用，同时进行,有效等价类和用来测试,getNumDaysInMonth(),方法所选的有效输入,,,有效,等价类,一个月有31天,非闰年,1901,7(七月),一个月有31天, 闰年,1904,7(七月),一个月有30天,非闰年,1901,6(六月),一个月有30天, 闰年,1904,6(六月),

43、一个月为28或29天,非闰年,1901,2(二月),月份,,输入值,年份,,输入值,一个月为28或29天, 闰年,2(二月),1904,用来测试getNumDaysInMonth()方法的附加边界值,,,等价类,可以被400整除的闰年,2000,2(二月),可以被100整除的非闰年,1900,2(二月),非正数无效月份,1291,0,正数无效月份,1315,13,月份,,输入值,年份,,输入值,因果图法,,,因果图适合于描述对于多种输入条件的组合，相应产生多个动作的形式来设计测试用例。,,因果图方法最终生成的是判定表。,,因果图方法实例,,某电力公司有A、B、C、D四类收费标准,,,并规定：,

44、,居民用电 <100度/月 按,A,类收费,,≥100度/月按,B,类收费,,动力用电 <10000度/月,非高峰,,B,类收费,,≥10000度/月,非高峰,,C,类收费,,<10000度/月, 高峰,,C,类收费,,≥10000度/月, 高峰,,D,类收费,,用因果图表明输入和输出间的逻辑关系,1,I,1,2,B,∨,∧,4,A,C,3,5,∧,D,I,4,I,3,I,2,∨,∧,∧,∧,∧,把因果图转换为判定表,组合条件,条件,,(,原因,),动作,,(,结果,),A,B,C,1,2,3,1,2,3,4,5,6,1,0,1,1,0,0,0,1,1,0,0,0,1,1,0,0,0,0,

45、1,0,0,0,0,1,1,0,4,1,0,1,0,5,0,0,1,1,D,0,0,0,1,1,0,0,1,0,0,0,0,测试用例,为判定表每一列设计一个测试用例:,1列 居民电,90度/月 A,,2列 居民电,110度/月 B,,3列 动力电,非高峰,8000度/月 B,,4列 动力电,非高峰,1.2万度/月 C,,5列 动力电, 高峰,0.9万度/月 C,,6列 动力电, 高峰,1.1万度/月 D,,,条件 测试用例 预期结果,,组合 (输入数据) (输出

46、动作),软件测试的过程,被测,,模块,单元,,测试,设计,,信息,集成,,测试,被测,,模块,单元,,测试,被测,,模块,单元,,测试,测试过,,的模块,确认,,测试,系统,,测试,软件,,需求,其它系,,统元素,装配好的软件,确认,,的软件,可运,,行的,,软件,软件测试的步骤,软件测试策略,单元测试,U,C,D,R,S,I,V,ST,集成测试,确认测试,系统测试,系统工程,软件需求分析,软件设计,代码编写,单元测试,,一.,单元测试的内容,,主要对模块的,五个基本特性,进行评价,,模块,错误处理,模块接口,局部数,,据结构,重要的,,执行路径,边界条件,1.常见错误类型,,,接口错误,,

47、I/O,错误,,数据结构错误,,算法错误,,比较及控制逻辑错误,,错误处理错误,2.,单元测试基本原则,,,,至少一次测试所有语句,,测试所有可能的执行或逻辑路径的组合,,测试每个模块的所有入口和出口,,,,,3.,确定单元测试数据集,,,,值域,,值类,,离散值,,值的次序集,(,测试顺序文件和,表,),,二.单元测试的方法,,单元测试一般为编码步骤的附属部分。,,模块不是独立的程序,自己不能运行,,,要靠其它部分来调用和驱动,要为每个,,单元测试开发两个软件:,,(1)驱动模块(驱动程序),:,相当于主模块,,(2)桩模块(测试存根、连接程序),,:,代替所测模块调用的子模块,单元测试的测

48、试环境举例:,,,,B,A,C,D,E,待测试模块,单元测试的测试环境举例:,,,被测模块,B,驱动模块,,(模拟模块,A,),桩模块(测试存根),,(模拟模块,E,),测试用例,测试结果,许多模块不能用简单的软件进行充分的单元测试, 此时, 完全的测试可放到集成测试阶段再进行。,,单元测试的测试环境举例:,,,实际软件,华氏到慑氏,,转换模块,温度数据,实际配置,测试用例数据,结果,,测试驱动软件,华氏到慑氏,,转换模块,结果,测试驱动际配置,单元测试的测试环境举例,温度显示模块,温度接口,,模块,实际配置,测试驱动实际配置,温度显示模块,程序员编写的桩模块,,(测试存根),温度值的测试文件

49、,结构性模式(structural,patterns,),,适配器模式,(,Adapter,)—,打包器,(,Wrapper,),,桥模式,(,Bridge,),—,句柄,(,Handle,),,组合模式,(,Composite,),,修饰模式,(,Decorator,)—,包装器,(,Wrapper,),,外观模式,(,Facade,),,轻量模式,,(,Flyweight,),,代理模式,—(,Proxy,),,,Implementor,OperationaImp( ),桥模式,(,Bridge,),,意图：将抽象部分和实现部分分离，使他们都可以独立地变化,,Abstraction,Con

50、textinterface( ),,ConcreteImplementorA,OperationaImp( ),,ConcreteImplementorB,OperationaImp( ),,RefinedAbstraction,支持多种窗口系统的设计,—,窗口与窗口实现分离,,Window,Raise( ),,DrawRact(…),,ApplicationWindow,,IconWindow,,DialogWindow,,MacWindowlmp,DeviceRaise( ),,DeviceRect(… ),,……,,PMWindowlmp,DeviceRaise( ),,DeviceRe

51、ct(… ),,……,,XWindowlmp,DeviceRaise( ),,DeviceRect(… ),,……,,Windowlmp,DeviceRaise( ),,DeviceRect(… ),,……,利用,Bridge设计,模式与未完成、未知或在测试,,另一组件时不可用组件的接口（UML类图）,,用户接口,,数据库户接口,,数据库户接口,,测试存根,,数据库,,可用,Bridge设计,模式实现测试存根，用户接口子系统访问测试不能访问的数据库子系统。,,将数据库接口和数据库实现分离开来。,集成测试(组装测试),,集成测试需考虑的问题:,,数据穿越接口可能丢失,.,,一模块可能破坏另一模块

52、功能,.,,子功能组装可能未产生所要求的,,主功能,.,,全程数据结构可能出问题,.,,误差累积问题,.,集成测试方法,,通常采用黑盒测试技术,,实施策略:,,非增量式系统集成,,,增量式系统,,集成,,,,,,,深度优先,,广度优先,自顶向下结合,,自底向上结合,一.非增量式系统集成,,一次就把所有通过了单元测试,,的模块组合在一起进行全程序的测,,试。,,缺点:,发现错误难以诊断定位,,,又称“莽撞测试”,。,,,二. 增量式系统集成,,,,从一个模块开始,测一次添加一个模块，边组装边测试，以发现与接口相联系的问题。,自顶向下结合方式举例:,,A,D,B,E,模块测试,,结合顺序,C,F,

53、深度优先:,A,、,B,、,E,、,C,、,D,、,F,广度优先:,A,、,B,、,C,、,D,、,E,、,F,自顶向下结合方式举例:,(,深度优先),,A,测试,A,S2,S1,S3,A,加入,B,S2,B,S3,S4,A,加入,E,S2,B,S3,E,A,加入,C,C,B,S3,E,加入,D,C,B,D,E,加入,F,C,B,D,E,A,A,F,S5,自底向上结合方式举例:,,A,C,B,D,F,E,E,d,1,C,d,3,F,d,4,B,d,2,E,D,d,5,F,自底向上结合方式举例:,,M,c,D,1,M,a,M,b,D,2,D,3,簇1,簇2,簇3,自顶向下 自底向上,,优

54、点,,可在测试早期 设计测试用例容易,,实现并验证系,,统主要功能,,不需驱动模块 不需桩模块,,缺点,需桩模块 只有到最后程序才,,能作为一个整体,,3.,混合集成测试方法,,一般对软件结构的上层使用自顶向下,,结合的方法,;,,对下层使用自底向上结合的方法,;,接口测试,,接口测试的目的是检查由于接口错误或者接口进行无效假设造成的系统缺陷。程序组件的接口有很多的类型，例如：,,参数接口。 主要是数据和函数指针等，它们由一个构件传递到另一个构件。,,共享内存接口。 有一个被子系统共享的内存块。由一个子系统把数据放在该内存中，然后被另一个子系统取出。,,程序接口。 由一个子

55、系统封装了的一组程序，这些程序可以被其他子系统调用。例如，对象（类）和抽象数据类型就存在这种接口。,,消息传递接口。 子系统通过消息传递来请求其他子系统的服务，返回的消息也包含了该服务的运行结果。例如，一些面向对象系统、客户机/服务器系统存在这种接口。,,,接口错误可以分成3类,：,,接口误用。调用者（组件）在调用其他组件时，接口使用不当而产生错误，例如，在使用参数接口时，参数类型和传递顺序以及参数个数不对等。,,接口误解。调用者（组件）误解了被调用组件的接口描述而产生错误，被调用组件没有按照预期的行为执行。,,计时错误。这类错误一般发生在实时控制系统中，系统使用了共享内存接口或者消息传递接口

56、而产生接口错误。例如，数据的生产和消费可能以不同的速度进行，由于生产者没有及时更新共享接口的信息导致消费者访问了过期的数据。,,,接口测试的一般准则：,,检查代码并明确地列出对外部构件的调用。对传给外部构件的参数值，应选择取值范围的边缘值作为测试用例，这样可能发现接口的不一致性。,,如果有指针从接口传递，应该用空指针参数来进行测试。,,如果通过程序接口调用构件，可以设计一些容易引起构件失败的测试。,,如果是通过消息传递到系统进行强度测试，应该设计大量的消息，可能发现计时错误。,,当构件之间是通过共享内存进行交互时，设计测试用例时，改变激活构件的次序，这样可能发现共享数据的生产和消费的顺序的错误

57、。,,,集成测试的标准应包括,：,,接口完整性。每一个模块集成到整个系统结构中，都要对它的内部和外部接口进行测试。,,功能有效性。为发现功能性错误进行的测试。,,信息内容。为发现与局部数据结构或者全局数据结构有关错误的测试。,,性能。为验证软件设计过程中建立的性能边界的测试。,,,回归测试,,在软件集成测试的过程中，每当一个模块加入到系统时，软件就发生变化，模块之间的影响也可能有改变。,,新的数据路径被建立，也可能出现新的输入/输出操作。很有可能激活新的控制逻辑，所有这些改变的因素可能会导致原来工作正常的系统产生错误。,,回归测试是对已经进行过测试的子集（模块）重新测试，以确保新添加的模块不会

58、对系统产生无法预料的副作用。,,确认测试,有效,,性,,测试,软件,,配置,,审查,管理,,机构,,裁决,选择测试人员,软件计划,用户文档,开发文档,源程序文本,支持环境,交用户,,,运行,,维护,测试,,报告,软件,,配置,构造测试用例,实际运行测试,专家,,鉴定,,会,,,,,,,,,有效性测试,,,通过,黑盒测试,,证实软件功能与,,用户需求是否一致.,,软件配置审查与验收,,,,确认,,测试,软件配,,置审查,主管部,,门批准,集成的软件,软件需求,用户文档,设计文档,源程序,测试文档,交付的,,软 件,确认的,,软 件,确认的,,配 置,,确认测试结果,,,测试完成后可能出现两

59、种情况:,,(1)测试与预期相符, 可接受。,,(2)不相符,列出软件缺陷表,与用户协商解,,决。,α测试和β测试,,α测试(Alpha),,在开发者的场所由用户进行,在开发,,者关注和控制的环境下进行。,,β测试(Beta),,最终用户在自己的场所进行,。,系统测试,,软件只是计算机系统的一个,,元素，软件最终要与其他系统元,,素（如新硬件、信息等)相结合，,,进行各种集成测试和确认测试.,,用于系统测试的测试类型:,,(1)恢复测试,,(2)安全性测试,,(3)强度测试,,(4)性能测试,(1)恢复测试,,以不同的方式强使软件出现故障,检测,,软件能否恰当地完成恢复.,,,自动恢复:,检测

60、重新初始化、,,检测点设置、,,数据恢复、,,重新启动等是否正确.,,人工干预恢复:,检测平均恢复时间是,,否在允许范围内.,(2)安全性测试,,设计测试用例,突破软件安全保护机构,,的安全保密措施,检验系统预防机制的,,漏洞.,,(3)强度测试,,设计测试用例, 检验系统能力最高能达到的实际限度, 让系统处于资源的异常数量、异常频率、异常批量的条件下测试系统的承受能力。一般比平常限度高5-10倍的限度做测试用例.,,,强度测试,是一种敏感性测试技术。在某种情况下, 包含在程序有效数据边界内的非常小范围的数据变动可能导致,极端的, 甚至错误的处理, 会使系统性能严重下降。,,,(4)性能测试,

61、设计测试用例，并记录软件运行性,,能，与性能要求比较，检验是否达到性,,能要求规格。,面向对象的软件测试,测试,目标,：在现实的时间跨度内应用可管理,,的工作量去发现最大可能数量的,,错误,基本目标不变，但由于,OO,程序的性质改变了,测试策略,,和测试战术,,更多的设计模式复用是否将减轻,OO,系统的繁重,测试？,,Binder,R.V.,在“,Object-Oriented Software Testing,”,中讨论改问题,:,,“,每次复用是一个新的使用语境,,,并且重新测试是谨慎的,.,为了获得面向对象系统的高可靠性,,,似乎可能需要更多而不是更少的测试,.”,OOA和OOD的 模型

62、,测试,,每个阶段的所有面向对象模型都应被测试。,OOA和OOD的模型不能被执行，对它们不能进行传统意义上的测试。,可通过技术复审检查,OOA和OOD的,,模型的正确性和一致性。,扩大测试的视角,面向对象测试策略,信息隐蔽对测试的影响,,封装和继承对测试的影响,面向对象程序的特点对软件测试的影响：,单元和集成测试策略必须有很大的改变,,测试用例的设计必须考虑,OO,软件的特征,1.,OO,的单元测试,一个类可以包含一组不同的操作，而一个特定,,的操作也可能存在于一组不同的类中。,不再孤,,立地测试单个操作,(,这是传统单元测试的视角,),,OO,软件的,类测试,等价于,传统的单元测试,.,,传

63、统软件的单元测试关注算法细节和模块接口,,间流动的数据,,,OO,软件的类测试是由封装在类中的操作和类的,,状态行为驱动的,单元概念,的变化—封装的类或对象作为最小,,的可测试单位,2.,OO,的集成测试,,,OO,软件没有层次的控制结构,传统的自顶向,,下和自底向上的集成策略没有意义.,OO,软件的集成两种策略:,,基于线程的测试,(,thread-based testing,),,,集成响应系统的一个输入或事件所需的一组类,,,每个线程被个体地集成和测试,,,通过回归测试保证没有副作用产生,;,,基于使用的测试,(use,-based testing,),,,通过测试几乎不使用服务器的类,

64、(,独立类,),来开始系统的构造,,,测试完独立类后,,,使用独立类按层逐步完成依赖类的测试直至完整的系统被构造,;,3.,OO,的确认测试,在确认和系统测试层次,类连接的细节消失.,和传统的确认测试一样,,,OO,软件的确认关注,,用户可见的动作和用户可识别的系统输出,.,,,为辅助确认测试的导出,,,应利用分析模型中的,,用例图提供的场景来提高交互需求中发现错误,,的可能性,,OO,软件的测试用例设计,每个测试用例应被唯一标识，并应显式地和与被,,测试类相关联,,测试的目的应被陈述,,对每个测试应开发一组测试步骤，包括：,,将被测试对象的一组,特定状态,,将被作为测试的结果使用的一组,消息

65、和操作,,当对象被测试时可能产生的一组异常,,一组外部条件,(,进行测试必须的软件外部环境的变化,),,将辅助理解或实现测试的补充信息,OO,软件的测试用例设计还处于成型期.,,Binder,R.V.在“,Essays on Object-Oriented Software Engineering,”,,中建议了对,OO,软件的测试用例设计的整体方法:,1. OO,概念的测试用例设计的含义,封装可能会成为测试的障碍,,,测试需要报告对象的具体和抽象状态，而封装,,使得对象的状态快照难于获得。,,继承，特别是多继承使测试复杂化,子类继承或重载的父类成员函数的测试问题,继承的成员函数是否都不需

66、要测试,?,,,对父类中已经测试过的成员函数,,,两种情况需要,,在子类中重新测试,:,,,继承的成员函数在子类中做了改动,;,,,成员函数调用了改动过的成员函数的部分,;,,例如,:,,,父类,Base,有,两个成员函数,Inherited(),和,Redefined(),,,,子类,Derived,只对,Redefined(),做了改动,.,,Derived,∷,Redefined(),—,需要重新测试,,,Derived,∷,Inherited(),—,如果它调用了,Redefined(),的,,语句,,,则需重新测试,,,否则不必,子类继承或重载的父类成员函数的测试问题,对父类的测试是否能够照搬到子类,?,,,上例中,:,,Base,∷,Redefined(),和,Derived,∷,Redefined(),已是,两个不同的成员函数,,,照理应对,Derived,∷,Redefined(),重新进行测试分析,,,设计测试用例,,,但由于它们的,相似性,,,只需在,Base,∷,Redefined(),的,测试要求和测试用例上添加对,Derived,∷,Redefined(),的