软件检验与软件测试

软件检验与软件测试1第一页，共一百零六页，编辑于2023年，星期三9.1

检验与有效性验证的有关概念

检验和有效性验证（VerificationandValidation,V&V，也有人称为验证与确认）是整个软件生命周期中对各阶段（需求评审、设计评审、代码检查、产品测试）过程活动的结果检查和分析的过程，以确保软件既能符合定义中的要求，又能满足客户或用户的要求。Boehm给出了二者之间的不同：

•检验：是否正确地建立一个产品？

•有效性验证：是否建立了一个正确的产品？

检验（验证）的作用是检查软件是否符合它的描述中所定义的功能和非功能的需求。而有效性验证（确认）要说明软件是否最终满足用户的要求。如需求中的一些错误和遗漏可能在系统完全实现后才能发现。2第二页，共一百零六页，编辑于2023年，星期三在V&V过程中有两个系统检验和分析技术：

•软件检查检查各种文档，静态检验技术。

•软件测试动态检验技术，实现运行检验。下图给出了两个技术活动在软件过程中的位置：软件检查需求描述高层设计形式化描述详细设计软件实现原型软件测试静态、动态检验和有效性验证箭头指示的是该项技术活动在那个阶段使用3第三页，共一百零六页，编辑于2023年，星期三验证技术包括程序检查、自动化源代码分析和形式化检验。但静态技术只能检查程序及其描述之间的吻合程度（检验），不能够说明软件真的是有用的，也不能检验软件的非功能特性。只有通过测试才能验证系统的有效性。测试和调试是两个不同的过程：

•测试是一个发现软件缺陷（Defect）的过程。

•调试是一个对缺陷定位和修改的过程。如图所示：测试结果描述测试用例定位错误修改设计错误修改代码对程序再测试调试过程4第四页，共一百零六页，编辑于2023年，星期三9.2V&V规划该过程的规划应该在开发过程的早期开始。下图说明了测试计划如何从系统描述和设计中导出。有时也称之为V模型。需求描述实现系统设计详细设计单元测试子系统集成测试系统集成测试验收测试验收测试计划系统集成测试计划子系统集成测试计划单元测试计划5第五页，共一百零六页，编辑于2023年，星期三对测试的规划主要是制定测试过程标准。主要组成部分见下表：

软件测试计划的结构测试过程

描述测试过程的主要活动需求跟踪对每项需求都要单独测试测试的项目定义软件过程的产品需要进行测试的项目测试时间安排安排时间及相应资源测试程序记录记录测试结果，并对测试过程检查是否都已记录硬件和软件需求列出测试所要使用的软件工具和硬件设施

约束影响测试过程的约束（如人员、工具短缺）6第六页，共一百零六页，编辑于2023年，星期三9.3软件检查系统的软件测试过程很耗时间，成本是昂贵的。软件检查在程序完成之前就应进行。检查的对象是可以是系统模型、系统描述或源代码。要充分利用开发系统的知识和源表示形式的语义来发现错误。软件检查是一种有效的错误检测技术，能够在初始阶段发现绝大多数错误，有专家报告说明超过60%的程序错误是通过检查发现的。软件检查不仅包括程序检查，还包括对软件过程中生成的所有文档的的检查。由安博测试空间技术中心/提供7第七页，共一百零六页，编辑于2023年，星期三程序检查程序检查的目标是发现缺陷。缺陷可能是逻辑错误、错误的条件、或是与机构和项目标准不相符的问题。程序检查的过程是一个正式的过程，应该由4个人以上的小组来实行。教材P295列出了检查过程中的角色。下图列出了一般的程序检查过程：规划概览个人准备会议讨论修改缺陷后续行动检查过程仲裁者决定是否反复，最后要对审查清单签署意见8第八页，共一百零六页，编辑于2023年，星期三检查过程应该有一个程序员常出错误的核对清单，团队有经验的人员经过讨论建立该清单，并随着经验的积累丰富这个清单。不同的程序语言由于编译器提供的检查层次不同应该有不同的清单。教材P296列出了要检查的项目（数据、控制、I/O、接口、存储管理、异常管理等方面的缺陷）。专家建议检查过程不要超过两小时，否则缺陷检查的效率会大大降低。因此在程序开发过程中应该经常进行检查，每次选择一个相对较小的组件。管理者一定要将程序检查和人事评价严格分开，检查结果暴露的错误不能作为程序员事业评估的依据。要建立起一种鼓励发现错误、不会因为这些错误引来指责的良好的企业文化。9第九页，共一百零六页，编辑于2023年，星期三9.4自动静态分析静态程序分析器是一个软件工具（如Unix系统中用于C语言的Lint）。扫描源代码，通过解析程序文本识别缺陷。如：有不可到达的代码段、未初始化的变量或指针、未说明或使用的变量、可能的数组越界、参数类型或个数不匹配等。静态分析包括以下几个阶段：

•控制流分析找出并显示有多重出口或入口的循环以及不可到达的代码段（如无条件转移语句包围的一段代码；条件语句中不可能到达的条件）。

•数据使用分析突出显示变量的使用情况。也发现那些判定值从不发生改变的条件。10第十页，共一百零六页，编辑于2023年，星期三•接口分析检查函数或子程序说明和使用的一致性。强类型检查语言（Pascal、Java）编译器已包含该功能。接口分析能发现类型检查较弱的语言（如C或C++较小的子集）中的类型错误，也能发现已定义但未被调用的函数和子程序或从未使用过的函数结果。

•信息流分析找出输入变量和输出变量之间的依赖关系。显式地列出程序中使用的变量值的出处，能给出影响变量值的条件。

•路径分析找出所有可能的路径并列出在一条路径中执行的语句。11第十一页，共一百零六页，编辑于2023年，星期三信息流分析和路径分析产生大量的信息，是从不同视点展示这个程序。往往只用在检查程序不规则状态的部分。基于工具的分析不能替代程序检查。如：虽能发现未初始化的变量，但不能发现不正确的初始化；虽能发现形实参之间类型和个数不一致，但不能发现传递的值不正确等情况。因此需要动态测试。12第十二页，共一百零六页，编辑于2023年，星期三9.5

软件测试的目的和原则

1、软件测试的目的

案例1：1963年,美国,飞往火星的火箭爆炸,损失$10million。原因:FORTRAN循环：DO5I=1,3误写为DO5I=1.3

案例2：1994年秋天，迪斯尼公司发布了第一个面向儿童的多媒体光盘游戏LionKingAnimatedStorybook。销售额非常客观。然而，12月26日，圣诞节后的一天，迪斯尼公司的客户支持部电话开始响个不停。后来证实，迪斯尼公司没有对市场上投入使用的各种PC机型进行正确的测试。软件在用于开发游戏的系统中能正常工作，但在大众使用的常见系统中却不行。13第十三页，共一百零六页，编辑于2023年，星期三由以上两个案例不难看出，软件测试的重要性，小到游戏的瘫痪，大到投入上亿元的航天项目。引起软件缺陷的原因也多种多样，有的仅仅是一个小数点的错误，有的是跨平台的不兼容性……软件测试的工作量约占整个项目工作量的40％左右，对于要求极高的系统测试工作量还要成倍增加。微软Exchange2000和Windows2000中的人员结构

Exchange2000Windows2000

项目经理25人约250人开发人员140人约1700人测试人员350人约3200人测试人员/开发人员2.51.914第十四页，共一百零六页，编辑于2023年，星期三

为什么需要这么多人、花这么多代价进行测试？目的何在？

“证明程序正确！”对吗？

Myers对软件测试目的提出以下观点：（1）软件测试是为了发现错误而执行程序的过程。（2）一个好的测试用例能够发现至今尚未发现的错误。（3）一个成功的测试是发现了至今尚未发现的错误的测试。因此，测试阶段的基本任务应该是根据软件开发各阶段的文档资料和软件的结构，精心设计一组“高产”的测试用例，利用这些用例执行程序，找出软件中潜在的各种错误（Bug）和缺陷（Defect）。15第十五页，共一百零六页，编辑于2023年，星期三

2、软件测试的原则（1）测试用例不但应有输入数据，还应有预期的输出结果。这样便于对照检查，做到“有的放矢”。（2）测试用例不仅选用合理的输入数据，还要选择不合理的输入数据。这样能更多地发现错误，提高程序的可靠性。对于不合理的输入数据，要将反馈信息提供给用户。（3）除了检查程序是否做了它应该做的事，还可检查程序是否做了它不应该做的事。例如程序正确地打印出用户所需信息的同时还是否打印出用户并不需要的多余信息。（4）应制定测试计划并严格执行，排除随意性。

（5）长期保留测试用例，为以后进行的回归测试和维护提供方便。

16第十六页，共一百零六页，编辑于2023年，星期三

（6）对发现错误较多的程序段，应进行更深入的测试（二八原则），另外在修改错误过程中容易引入新的错误。（7）为了达到最有效的测试效果，测试最好由第三方来进行。3、测试阶段的信息流程

测试评价调试可靠性分析软件配置测试配置测试结果分析结果错误可提交软件错误率数据预期结果预完善17第十七页，共一百零六页，编辑于2023年，星期三

其中软件配置：需求说明书、设计说明书和源程序。测试配置：测试计划、测试工具、测试用例(Testcase)

和测试驱动程序(Driver)、桩程序(Stub)等。

4、测试方法

（1）黑盒(Black-box)法不考虑被测程序的内部结构和处理过程，只关心它的输入和输出是否能达到预期结果，因此也称为功能性测试。（2）白盒(White-box)法使用更细致的测试策略，检查被测程序的内部逻辑。黑盒测试法与白盒测试法互为补充，在测试的不同阶段使用以发现不同类型的错误。

18第十八页，共一百零六页，编辑于2023年，星期三

测试用例如何设计？是否考虑所有的数据域或所有的路径！穷尽测试(completetest)通常是不可能的。例如：(Black-box)

程序要求输入3个整形数据。若字长16位，则各种可能输入的排列组合共有

216×216×216≈3×1014

若程序执行一次需一毫秒，则对于所有合法输入的测试大约需用一万年！还未包含测试输入非法数据的情况。

19第十九页，共一百零六页，编辑于2023年，星期三

例：(White-box)

下图所示的程序中共有5201014条可能的执行通路，显然，每条通路都执行一遍是不现实的。

即使每条路径都测试了，程序仍可能有错，如一个升序程序编成了降序，穷尽测试也发现不了。循环20次20第二十页，共一百零六页，编辑于2023年，星期三9.6测试用例设计

白盒法和黑盒法是设计测试用例的基本策略，每一种策略对应着多个设计用例的技术，每种技术可达到一定的测试目的。

1、白盒技术被测对象基本上是源程序，以程序的内部逻辑结构为基础设计测试用例。原则是：

•

保证被测程序中每一条独立的路径至少执行一次。

•

保证所有判断的每一分支至少执行一次。

•

保证每一循环都在边界条件和可操作的范围内各执行一次。

•

验证内部数据结构以确保其有效性。21第二十一页，共一百零六页，编辑于2023年，星期三

（1）逻辑覆盖主要用于测试选择结构。

•

语句覆盖：每个语句至少执行一次。

Testcase:A=2,B=0,X=4.

问题：若AND错写为OR，或X>1

错写为X<1,则错误无法由上例测出。入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF22第二十二页，共一百零六页，编辑于2023年，星期三•

判定覆盖：每个判定的每个分支至少执行一次

Testcases:①A=3,B=0,X=3②A=2,B=1,X=1

问题：若X>1错写为X<1,

仍然无法被测出入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF23第二十三页，共一百零六页，编辑于2023年，星期三•

条件覆盖

使得每个判定的每个条件的取值至少执行一次。

Testcases:①A=2,B=0,X=4

（满足A>1,B=0;A=2,X>1)②A=1,B=1,X=1(满足A1,B0;A2,X1）问：条件覆盖包含判定覆盖？答:不一定。反例:①A=2,B=0,X=1②A=1,B=1,X=2入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF24第二十四页，共一百零六页，编辑于2023年，星期三

表面上看，条件覆盖标准测试了所有条件的取值，但事实并非如此（为什么？）。应该将条件表达式进行分解，以便有效的检查所有条件。如右图：A>1B=0X=X/AA=2X>1X=X+1TTTT•

判定/条件覆盖：即判定覆盖条件覆盖仍然有上述问题将前述例子的结构改为单个条件判定的嵌套结构25第二十五页，共一百零六页，编辑于2023年，星期三

•

条件组合覆盖：每个判定表达式中条件的各种可能组合都至少出现一次。

全部可能的条件组合为：①A>1,B=0②A>1,B0③A1,B=0④A1,B0⑤A=2,X>1⑥A=2,X1⑦A2,X>1⑧A2,X1Testcases:①A=2,B=0,X=4(TT)②A=2.B=1,X=1(FT)③A=1,B=0,X=2(FT)④A=1,B=1,X=1(FF)

问题：没有测试到（TF）的路径入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF26第二十六页，共一百零六页，编辑于2023年，星期三

•

路径覆盖每条可能的路径都至少执行一次。路径数目很大时，难以覆盖所有的路径。必须把覆盖路径数目压缩到一定限度。

•

路径覆盖条件组合覆盖

27第二十七页，共一百零六页，编辑于2023年，星期三（2）循环覆盖

要覆盖含有循环结构的所有路径是不可能的，可通过限制循环次数来测试。给出以下设计原则：

•

单循环设n为允许执行循环的最大次数，作以下测试：

①跳过循环；

②仅循环一次；

③循环m次，m<n；④分别循环n-1次，n次，n＋1次。

•

嵌套循环

①置外循环处于最小循环计数值，对内层进行单循环测试；②由里向外，回退到上一层循环测试。

•

并置循环若完全独立，采用单循环策略；若第一个循环的计数器作为第二个循环的初值，用嵌套循环策略。28第二十八页，共一百零六页，编辑于2023年，星期三（3）基本路径测试

由TomMcCabe提出的方法，可以解决覆盖程序路径庞大的难题。主要思想：

•

该方法把要覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。

•

它是在程序控制流图的基础上，分析控制结构的环路复杂性，导出基本可执行路径集，由此设计一组测试用例，保证对程序中的每一条可执行语句至少执行一次。

29第二十九页，共一百零六页，编辑于2023年，星期三

基本路径测试的步骤为：①以详细设计或源程序为基础导出程序的控制流图，简称为流图（flowgraph）,它是反映控制流程的有向图。其中小圆圈○为控制流图的一个结点，表示一个或多个无分支的PDL语句或源程序语句，表示控制流的箭头称为边或路径。

右图中显示了程序流程图及对应的流图：1030第三十页，共一百零六页，编辑于2023年，星期三

转换时注意：

•

一条边必须终止于一个结点，在选择结构中分支汇聚处即使无语句也应有一个汇聚结点。

•

如果判断中的条件表达式是复合条件，则需改为一系列只有单个条件的嵌套判断。如下图所示：31第三十一页，共一百零六页，编辑于2023年，星期三

②计算流图G的环路复杂性可以用3种方法计算：

•V(G)=封闭区域数＋1

其中封闭区域为边和结点圈定的区域，1为图形外的区域。

•V(G)=判定结点数＋1•V(G)=E-N+2

其中设E为流图的边数，N为节点数。例如，29页的流图V(G)=4。

32第三十二页，共一百零六页，编辑于2023年，星期三③确定只包含独立路径的基本路径集。一条独立路径是至少包含一条在其它独立路径中从未有过的边的路径，即至少包含一条新边。程序的环路复杂性给出了程序基本路径集中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。基本路径集不唯一。对于给定的流图，可以得到不同的基本路径。33第三十三页，共一百零六页，编辑于2023年，星期三

例如，在29页图示的控制流图中，一组独立的路径是

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组成了控制流图的一个基本路径集。④设计测试用例，确保基本路径集中的每一条路径的执行。必须注意，某些独立的路径往往不能以独立的方式被测试，即穿越路径所需的数据组合不能形成程序的正常流，在这种情况下，这些路径的测试必须作为另一条路径测试的一部分进行测试。34第三十四页，共一百零六页，编辑于2023年，星期三例：用基本路径测试方法对以下的程序（伪码描述）设计用例。Sort①

for(i=1;i<=n-1;i++)k=i；②

for(j=i+1;j<=n;j++)if(a[k]>a[j])k=jendfor

③

④

if(k!=i)swap(a[i],a[k])

⑦

endfor

⑤

⑥endSort35第三十五页，共一百零六页，编辑于2023年，星期三

Path1:1-7Path2:1-2-5-1-7Path3:1-2-5-6-1-7Path4:1-2-3-2-5-1-7Path5:1-2-3-4-2-5-6-1-7设计用例：输入（方案）预期输出结果通过路径

n=1排序表中只有一个数Path1n≥2且输入表已排序的输出表Path4

中已排序

n≥2且输入表已排序的输出表Path5

中未排序

Path2和Path3无法单独测试，但已包含在Path4和Path5中测试过了。36第三十六页，共一百零六页，编辑于2023年，星期三一小段C语言程序。voidfun(intiCount,intiType)1{2intx=0;3inty=0;4while(iCount-->0)5{6 if(0==iType)7 {x=y+2;break;}8 elseif(1==iType)9 {x=y+10;}10 else{x=y+20;}11}12}37第三十七页，共一百零六页，编辑于2023年，星期三9468101171238第三十八页，共一百零六页，编辑于2023年，星期三为了使基本路经测试自动化，称为图矩阵（graphmatrix）的数据结构很有用。PPt34页的流图可转化为如右图的连接矩阵。矩阵中的值为连接权值，可赋予如下属性：

•执行连接边的概率

•穿越连接的处理时间

•穿越连接时所需的内存

•穿越连接时所需的资源最简单的权值为1（有连接）或0（无连接）。1111111111

1234567

1234567连接矩阵结点连接到结点含有两个或两个以上项的行表示判定结点39第三十九页，共一百零六页，编辑于2023年，星期三

2、黑盒技术被测对象是功能独立的模块或构件，注重测试软件的功能需求。试图发现以下几类错误：

•不正确或遗漏的功能；

•

接口错误；

•

数据结构或外部数据库访问错误；

•

性能错误；

•

初始化和终止条件错误。几种具体的方法：（1）等价类划分主要思想：根据被测对象的功能说明和输入域，按合理的或不合理划分为若干等价类，为每个等价类设计一个测试用例，这样大大减少测试次数，提高测试效率。该方法步骤如下：40第四十页，共一百零六页，编辑于2023年，星期三

①划分等价类对被测程序功能说明的输入域或输出域划分等价类。以下是一些原则或经验：

•当规定了输入范围时可划分：

无效类[有效类]无效类

•当规定了输入数据必须遵循的规则时，可确定一个合理等价类（符合规则）和若干不合理等价类（可从各种角度违反规则）。例如：Windows文件名可以包含255个字符，但不能包含/、\、>、<、*、？、〝、|、:、;等字符，文件名的等价类划分为下表：输入条件合理等价类不合理等价类文件名字符个数1～2550个，≧256个文件名组成含合法字符含非法字符41第四十一页，共一百零六页，编辑于2023年，星期三•为便于设计用例，每个等价类可划分为更小的等价类。

•当规定了输入的一组值，且对不同值做不同处理时，每个允许的输入值是一个合理的等价类，另有一个不合理的等价类（任何一个不允许的输入值）。以上经验也适用于对输出信息的划分。例如在一个序列中搜索某个给定关键字的元素，它的输出有两个明显的等价划分：

•输入的关键字在这个序列中。

•输入的关键字不在这个序列中。42第四十二页，共一百零六页，编辑于2023年，星期三

②设计测试用例

•为每个等价类编号。

•设计一个测试用例，使其尽可能多地覆盖尚未被覆盖的合理等价类，重复这一步直到所有合理等价类都被覆盖。

•设计一个测试用例，使其只覆盖一个尚未被覆盖的不合理等价类，重复这一步直到所有不合理等价类都被覆盖。（2）边界值分析输入域的边界比中间更容易发现错误，是一种补充等价类划分的设计测试用例技术。（3）错误推测根据经验或直觉推测程序中可能存在的各种错误，有针对性的设计检查这些错误的测试用例。如：输入、输出数据为零的情况；输入表格为空或输入表格只有一行的情况。43第四十三页，共一百零六页，编辑于2023年，星期三（4）使用判定表如果功能说明中含有多个输入条件的逻辑组合，可以建立判定表，判定表的每一列对应一个测试用例。（5）状态测试基于状态转换图，选择测试用例。原则：

•每一种状态至少访问一次；

•测试最常见的状态转换。

•测试最不常用的分支；

•测试所有错误状态及其返回值；

•测试随机状态转换。在实际测试中，综合使用这些方法，以达到最有效的测试。44第四十四页，共一百零六页，编辑于2023年，星期三例：测试一个二分法的检索程序。二分法检索将检索空间划分成了三个部分，每个部分构成了一个等价类，选择这些等价类集合的边界值作为测试用例。再结合错误推测，考虑：

①检索序列中只有一个值，②序列长是奇数，

③序列长是偶数，

④检索的关键字不在检索序列中。

45第四十五页，共一百零六页，编辑于2023年，星期三二分法检索程序的测试用例输入数组（T）关键字（key）输出（Found,Location)1717true,1170false,??17,18,21,23,2917true,117,18,21,23,29,38,4141true,717,18,21,23,29,38,4123true,417,18,21,23,29,38,4121true,317,18,21,23,29,38,4129true,417,18,21,2320false,??46第四十六页，共一百零六页，编辑于2023年，星期三9.7

软件测试过程

下图列出了软件测试的步骤，包括各个测试活动之间的关系以及需要的信息。47第四十七页，共一百零六页，编辑于2023年，星期三1、单元测试

完成对最小的软件设计单元－软件构件或模块的测试。使用详细设计描述作为指南。对重要的控制路径进行测试以发现错误，多采用白盒测试技术。该步骤可以针对系统中多个构件或模块并行进行。（1）测试任务：

•模块接口

•局部数据结构

•重要的执行路径

•错误处理

•边界条件48第四十八页，共一百零六页，编辑于2023年，星期三

（2）测试环境

单元测试紧接在编码之后进行。但一个模块一般不能独立运行，测试时要对每个模块开发驱动程序（driver)和桩程序(stub)

。

•

驱动程序：接收测试数据，调用被测程序，打印结果。需正确定义驱动程序与被测模块的接口。

•

桩程序：用来模拟测试时缺少的被调用模块的活动。将来由被测程序调用的真正模块替代。桩程序的接口同真正模块一致，内部只做少量处理，（如响应调用请求，打印“进入－退出”消息，或直接传回所需数据）。

49第四十九页，共一百零六页，编辑于2023年，星期三2、集成测试也称为组装测试。对单个构件或模块的测试达到目标之后，将它们组合成一个能工作的系统。一般根据设计中建造的软件体系结构采用黑盒技术进行测试。

“单个模块能正常工作，组装起来不会有问题！”真的吗？

•

单元测试使用的驱动模块和桩模块，与它们所代替的真正模块并不完全等效，因此单元测试有不彻底、不严格的情况。

•

各个模块组装起来，穿越模块接口的数据可能会丢失。

•

一个模块的功能可能会对另一个模块的功能产生不利的影响。

•

各个模块的功能组合起来可能达不到预期的总的功能。

50第五十页，共一百零六页，编辑于2023年，星期三

•

单个模块可以接受的误差，组装起来可能积累和放大到不能接受的程度。

•

全局数据可能会出现问题。因此必须要进行集成测试，用于发现模块组装中可能出现的问题，最终构成一个符合要求的软件系统。深度优先自顶向下宽度优先渐增式三明治式集成的方法自底向上非渐增式

51第五十一页，共一百零六页，编辑于2023年，星期三

集成测试的具体方法与步骤设系统是构件组成的的层次结构。如图所示：

52第五十二页，共一百零六页，编辑于2023年，星期三（1）自顶向下集成（top-downintegration)53第五十三页，共一百零六页，编辑于2023年，星期三

与单元测试结合起来的自顶向下测试：54第五十四页，共一百零六页，编辑于2023年，星期三集成测试的步骤：①测试顶端模块（M)，用桩模块(S)替代直接下层模块。②根据深度优先或宽度优先的策略，每次用一个实际模块(M)代换一个桩。③每结合进一个模块后进行测试④全部或部分地重复以前做过的测试。MS1S2M1S3S4M2S255第五十五页，共一百零六页，编辑于2023年，星期三优点：能在早期发现高层模块接口、主要控制等方面的问题；初期的程序概貌可让人们较早地看到程序的主要功能，增强人们的信心。缺点：桩模块只是对低层模块的模拟，不能提供完整的信息，许多重要的测试须推迟进行；桩模块设计较多，测试开销大；早期不能并行工作，不能充分利用人力。56第五十六页，共一百零六页，编辑于2023年，星期三（2）自底向上集成(Bottom-upintegration)57第五十七页，共一百零六页，编辑于2023年，星期三自底向上集成步骤：①把底层模块（M)组合成族，每族实现一个子功能。②用驱动程序(D)输入测试数据，测试子功能族。③用实际模块(M)替代驱动程序，把子功能族组合成更大的族。④重复上述工作，直至系统整个结构都测试完毕。MMMMMMMMMMMMDDDDDD58第五十八页，共一百零六页，编辑于2023年，星期三优点：随着上移，驱动模块逐步减少，测试开销较小；容易设计测试用例；早期可以并行工作；底层模块的错误能较早发现。缺点：系统整体功能最后才能看到；全局性的问题发现较晚。59第五十九页，共一百零六页，编辑于2023年，星期三（3）三明治式集成（sandwichintegration)60第六十页，共一百零六页，编辑于2023年，星期三（4）一次性集成(big-bangintegration)

非渐增式测试。

优点：并行工作，充分利用人力。缺点：很难找出错误的原因；不易区分接口错误和其他类型错误。61第六十一页，共一百零六页，编辑于2023年，星期三集成策略的比较（Myers1979)自底向上自顶向下改进的自顶向下一次性集成三明治式改进的三明治式

集成早早早晚早早能产生基本运行程序的时间晚早早晚早早需要驱动程序是否是是是是需要桩程序否是是是是是工作的并行性中等低中等高中等高测试特殊路径能力容易难容易容易中等容易计划和控制顺序能力容易难难容易难难62第六十二页，共一百零六页，编辑于2023年，星期三微软的集成方法

微软的集成策略是由市场驱动的，基于尽快产生能运作的产品的需要，使得测试小组能随着开发人员对产品能做什么和应该做什么有更多的了解的同时，随时变动产品说明的特征。产品和项目按特征被划分成各部分，不同的小组负责不同的特征。里程碑的定义由特征的划分来决定，分为最重要的、需要的和最不重要的。最重要的特征首先被开发和集成，而每个里程碑包含了“缓冲时间”，处理意外的复杂性或延迟。如果进度必须缩减，则从产品中删掉最不关键的特征。下图显示了里程碑的演化：63第六十三页，共一百零六页，编辑于2023年，星期三64第六十四页，共一百零六页，编辑于2023年，星期三

3、系统测试

有如下过程：（1）

功能测试：检查集成的系统在运行时是否满足需求中指定的功能。单元测试和集成测试的重点是构件及构件间的交互。这里的测试不必知道正在执行哪个构件，但必须知道系统是作什么的。与功能相关的活动集合称为线程（thread），因此这里的功能测试有时称为线程测试。功能测试采用黑盒技术，测试用例从需求文档中产生。如，对一个文字处理系统的测试可以检查文档创建、文档修改、文档删除等功能。有时可分析需求的语义，用输入与输出之间或输入与转换之间的逻辑关系建立判定表来实现测试。

65第六十五页，共一百零六页，编辑于2023年，星期三

（2）性能测试：

针对的是非功能性需求，即测试的类型由非功能性需求的定义来决定。

•

强度测试（stresstest）评价系统在短时间内到达其极限时的表现。如一个系统设计成每秒最多处理300个事务。

•容量测试（volumetest)检查系统对大量数据的处理。

•恢复测试（environmentaltest)检查系统的容错（出错、故障、掉电等处理）能力，能否在指定时间内修正错误并重新启动系统。

•安全测试（securitytest)

测试系统的保护措施及数据与服务的完整性、保密性等。还有许多方面的测试，如对用户的响应时间、执行某个功能的运行时间的计时测试，系统的可用性测试等。

66第六十六页，共一百零六页，编辑于2023年，星期三（3）接口测试每个构件或子系统都有一个事先定义好了的接口供其它构件调用。接口有多种类型：

•参数接口：主要是数据和函数指针，由一个构件传递给另一个构件。

•共享内存接口：有一个被子系统共享的内存块。有存有取。

•程序接口：在接口中，有子系统封装的一组程序，这些程序可被其他子系统调用。

•消息传递接口：子系统通过消息传递请求其他子系统上的服务。接口测试的一般准则（下页）：67第六十七页，共一百零六页，编辑于2023年，星期三

接口测试的一般准则

•设计用例，对传给外部构件的参数选择取值范围的边界。

•当有指针从接口传递时，可用空指针来测试接口。

•当构件通过程序接口被调用时，设计一些容易引起构件失败的测试。

•在消息传递系统中进行强度测试。

•当构件间通过共享内存来交互时，设计一组测试用例，对激活构件的次序有所改变（如生产与消费数据的顺序）。静态技术在接口测试中有重要的价值。以上是开发人员以需求规约为依据、采用黑盒技术，通过对系统及其目标的理解而进行的测试。开发人员的理解需要用户的认可，因此还要进行以下用户确认的测试。68第六十八页，共一百零六页，编辑于2023年，星期三（3）验收测试：也称确认测试。指验收软件的有效性，使用户确信他们需要的就是这个系统。有时在实际环境中进行，有时在开发环境中进行。除了检查系统功能性能外，还要进行软件配置审查，包括文档的完整性、一致性、准确性的检查，是否具有维护阶段必需的细节。有2种测试策略：

•Alpha测试：软件交付用户后，用户在开发环境中由开发人员“指导”下进行的测试。

•

Beta测试：用户在目标环境（实际使用环境）下进行的测试。如微软的“WindowsXP”Beta2测试版由用户免费试用，半年后测试版作废。（4）安装测试：在实际环境中进行的测试。测试系统的完备性及可能被现场条件影响的那些功能或非功能性特性。69第六十九页，共一百零六页，编辑于2023年，星期三4、调试软件测试是一个系统地加以计划和说明的活动（定义测试策略、设计测试用例，根据预期结果评估测试结果）。调试（debugging）出现在成功的测试之后。调试的目的：寻找错误的原因并改正。调试的结果：（1）发现问题的原因并加以改正；（2）未能找到原因。需要假设一个原因，使用测试用例来验证这个假设，重复此过程直到改正错误。调试的方法：个人的经验与技巧。（1）蛮力法（bruteforce）（2）回溯法（backtracking）（3）原因排除法：演绎或归纳并引入二分法的概念。三种方法都可用手工或工具（如C++Test）实现。70第七十页，共一百零六页，编辑于2023年，星期三9.8

面向对象的测试1、面向对象测试的特点面向对象测试的整体目标（以最小的工作量发现最大数量的错误）与传统软件测试的目标是一致的。但是OO程序的性质改变了测试策略与战术。（1）传统测试主要是基于程序运行过程的，即选择一组输入数据运行被测程序，通过比较实际结果与预期结果从而判断程序是否有错。而OO程序中的对象通过发送消息启动相应的操作，并且通过修改对象的状态达到转化系统运行状态的目的。同时，在系统中还可能存在并发活动的对象，应此传统的测试方法应扩展。

71第七十一页，共一百零六页，编辑于2023年，星期三

（2）传统程序的复用以调用公共模块为主，运行环境是连续的。而面向对象复用很多是用继承实现的，子类继承过来的同名操作有新的语境，必须要重新测试。随着继承层次的加深，测试的工作量和难度也随之增加。由继承支持的多态的特性同样给测试带来了难度。（3）面向对象软件的开发是渐进、演化的开发，从分析、设计到实现使用相同的语义结构（如类、属性、操作、消息）。因此要扩大测试的视角。72第七十二页，共一百零六页，编辑于2023年，星期三

例如，在分析模型中定义了一个无用的属性，围绕着这个属性可能会带来以下错误：

在分析模型中：

•定义了一个与该属性有关的操作：

•导致了不正确的类关系：

•为共享属性和操作创建了不必要的子类：

•为适应该属性和操作刻画了其类和系统的行为。如果问题在分析阶段未被发现，再将错误继续传播，使得设计模型可能存在：

•与该类有关的不合适的子系统或进程的划分：

•与该无用属性有关操作的算法设计：

•与该无用属性有关操作的接口及消息模式。

73第七十三页，共一百零六页，编辑于2023年，星期三

如果问题在设计阶段仍未被检测到，并传送到编码活动中，则大量的工作将被花在生成那些实现一个不必要的属性、不必要的操作、不必要的消息通信以及很多其它相关问题的代码。由于分析设计模型不能被执行，所以不能进行传统意义上的测试。只能通过正式技术复审来检查分析模型和设计模型的一致性。

74第七十四页，共一百零六页，编辑于2023年，星期三

（4）面向对象开发工作的演化性使面向对象测试活动也具有演化性。每个构件产生过程中，单元测试随时进行，迭代的每一个构造都要进行集成测试，后期迭代还包括大量的回归测试，迭代结束时进行系统测试。是否设计模式的使用将减轻OO系统的繁重测试？Binder认为每次复用是一个新的使用语境，需要重新谨慎的测试。为了获得OO系统的高可靠性，可能需要更多的而不是更少的测试。75第七十五页，共一百零六页，编辑于2023年，星期三

2、面向对象的测试过程在面向对象系统中，

Sommerville认为测试可分为4个层次（教材P317）：（1）测试与对象关联的单个操作（传统的单元测试），白盒、黑盒测试方法相结合。

（2）测试单个对象类，黑盒测试原理不变。

（单元测试）

（3）测试对象集群，严格的自顶向下或自底向上的集成不适用于一组关联对象，应使用其他方法，如基于场景的测试。（集成测试）

（4）测试面向对象系统。根据系统需求进行验证与确认。76第七十六页，共一百零六页，编辑于2023年，星期三

（1）单元测试（对象或组成的小簇）

OO语境中，由于每个类或对象封装了属性和操作这些属性的服务，最小的可测试单位不是个体模块（单元的概念发生了变化），而是封装了多个操作的类或对象。类测试由封装在该类中的操作和类的状态行为驱动的。

Sommerville在比较面向对象系统和使用功能模型开发的系统之间的差别时指出：“对象作为一个单独的组件一般要比一个功能模块大”。类包含一组不同的操作，并且某个特殊操作可能作为类的一部分存在（如子类中继承的操作），因此，单元实际上是类或若干相关的类组成的小簇。77第七十七页，共一百零六页，编辑于2023年，星期三

单元测试不再孤立的测试单个操作，而是将操作作为类的一部分。例如：命令execute()粘贴命令execute()拷贝命令execute()

execute由基类定义并被一组子类继承，每个子类的execute被应用于每个子类定义的私有属性和操作的语境内，因此，仅在基类内测试execute是不充分的，应该在每个子类的语境内测试execute。当然，可在基类的测试要求和测试用例上添加新的要求和用例。78第七十八页，共一百零六页，编辑于2023年，星期三

单元测试若用于测试不发生请求的类（如“栈”类，其中操作有：pop()，push()，empty()）时，同样要设计驱动程序，封装在一个测试类（包）中，测试类负责运行测试用例并给出结果，每个测试用例用一个操作名表示；单元测试如果测试发生请求的类，则需要设计桩程序，封装在桩类中。单元测试主要的参考模型是：类图、类的状态图、活动图。

79第七十九页，共一百零六页，编辑于2023年，星期三

（2）集成测试（大簇、构件、子系统）

这里的构件或子系统应该与系统的体系结构相对应。集成测试主要以检查这些构件、子系统的接口为目的。对于类之间的集成，RogerS.Pressman认为面向对象软件没有明显的控制层次结构，传统的自顶向下和自底向上集成的测试策略没有太大意义。他提出了两种集成测试策略：

•基于线程的测试（thread-basedtesting）集成一组相互协作的对某个输入或事件作出响应的类，每个线程被分别测试，并使用回归测试以保证没有副作用产生。

•基于使用的测试（use-basedtesting）按层次测试系统。先测试不依赖服务器的独立类，如管理和显示数据的类，然后测试依赖独立类的其他类。逐步增加依赖类，直到测试完整个系统。

Sommerville提出基于用例或场景的测试（教材P319）也是一种有效方法。80第八十页，共一百零六页，编辑于2023年，星期三

对于子系统之间的集成，如果系统划分为层次结构，则可以按自顶向下或自底向上集成，同时也需设计驱动类和桩类。如：一个OO系统的结构为：用户界面(A)应用逻辑(B)访问数据库(C)网络通信(D)应用系统的一个结构

该系统可以采用自顶向下、自底向上或三明治式进行集成测试。见下图。81第八十一页，共一百零六页，编辑于2023年，星期三UI层桩桩UI层应用层桩桩UI层应用层数据库网络数据库层网络层驱动驱动数据库网络应用层驱动驱动UI层桩桩数据库层网络层驱动驱动自顶向下自底向上三明治式82第八十二页，共一百零六页，编辑于2023年，星期三TestATestBTestCTestDTestA、BTestB、CTestB、DTestA、B、C、D单元测试集成测试集成测试测试过程（UML活动图）

集成测试的参考模型是：顺序图、协作图、活动图（概念层）83第八十三页，共一百零六页，编辑于2023年，星期三

（3）确认测试在确认和系统测试层次，和传统的一样。对用户来讲，系统使用什么方法开发的不是主要问题。测试的内容主要集中于用户可见的动作和用户可识别的系统输出（用户可见的功能），以及系统性能、强度、安全、质量属性等方面的需求。测试人员应该根据需求规约和用例模型设计测试用例。

84第八十四页，共一百零六页，编辑于2023年，星期三

3、面向对象软件的测试用例设计

传统的测试用例设计是由软件的输入、加工、输出视图或个体模块的算法细节驱动的，面向对象测试关注于设计合适的操作序列以测试类的状态和用例的实现。（1）传统方法的可用性

白盒测试：测试类中定义的每个操作（方法），一个操作相当于传统方法中的函数或子程序。

黑盒测试：

•测试单个对象类：检查类的状态或行为确定是否存在错误。

•测试对象集群和整个系统的集成测试、确认测试。组件、子系统是黑盒。测试序列跟踪跨越类协作的操作流，即跟踪一个用例的实现。

85第八十五页，共一百零六页，编辑于2023年，星期三（2）类级测试用例设计（单元测试）着重于单个类及封装的操作。传统的白盒测试要保证所有程序中的语句至少执行一遍，所有的路径都要执行到。在测试对象时，完全的覆盖测试应该包括：

•测试对象类中的所有操作；

•测试对象所有属性的设置和访问；

•测试对象所有可能的状态，即模拟引起状态改变的事件。

可按照以下方法设计用例：86第八十六页，共一百零六页，编辑于2023年，星期三（Ⅰ）随机测试考虑一个银行应用程序，其中account类有下列操作：open，setup，deposit，withdraw，balance，summarize，creditLimit和close。但问题的性质隐含了一些限制（例如，账号必须在其它操作可应用前被打开，在所有操作完成后被关闭）。一个account实例的最小行为生命历史包括下面操作：

open，setup，deposit，withdraw，close

它们表示了account的最小测试序列。然而大量的其它行为可能在下面序列中发生：

open，setup，deposit，[deposit|withdraw|balance|summarize|creditLimit]n,withdraw

，close

一系列操作序列可以随机产生，例如：测试用例1：open，setup，deposit，deposit，balance，

summarize，withdraw，close87第八十七页，共一百零六页，编辑于2023年，星期三

测试用例2：open，setup，deposit，withdraw，

deposit，balance，creditLimit，withdraw，close

可随机选取其它的测试序列以测试该类对象不同的生命历史。（Ⅱ）划分测试可以减少测试类所需的测试用例的数量，采用与传统测试的等价划分相同的方式，即输入、输出被分类，为处理每个类别设计测试用例。划分类别的具体方法是：

•基于状态的划分基于类操作改变类状态的能力来对类操作分类。类中有的操作改变类的状态（如account类中的deposit和withdraw

），有的操作不改变类的状态（如balance，summarize和creditLimit

）。因此分别独立测试改变状态的操作和不改变状态的操作。88第八十八页，共一百零六页，编辑于2023年，星期三

•基于属性的划分根据操作使用的属性来划分类操作，即使用相同属性的操作划分在一个等价类中。如account类中，以属性creditLimit来定义划分，操作被定义成3个类别：①使用creditLimit的操作，②修改creditLimit的操作，③不使用或不修改creditLimit的操作。然后对每个划分设计测试序列。

•基于操作类别的划分如在account类中的操作可被分类为：初始化操作（open、setup)、计算操作（deposit，withdraw）、查询操作（balance，summarize，creditLimit）和终止操作（close）。89第八十九页，共一百零六页，编辑于2023年，星期三

（Ⅲ）从行为模型导出的测试类的STD可用于帮助导出测试类的动态行为的测试序列。下图是银行应用系统account类的STD。所涉及的测试应覆盖所有的状态，即操作序列应该导致account类的转换穿越所有允许的状态。90第九十页，共一百零六页，编辑于2023年，星期三测试用例1：open，deposit(initial)，withdrawal(final)，

close（最小测试序列）测试用例2：open，deposit(initial)，deposit，balance，credit，withdrawal(final)，close测试用例3：open，deposit(initial)，deposit，withdraw，accntInfo，withdrawal(final)，closesetupacctworkingacctnonworkingacctopendeposit(initial)depositbalance,

credit,accntInfowithdrawal(final)closewithdraw91第九十一页，共一百零六页，编辑于2023年，星期三

回想第9章气象台系统的例子，要测试气象台对象的所有状态，必须使用以下状态模型。应该测试到的状态序列的例子包括：

shutdown→waiting→shutdownwaiting→calibrating→testing→transmitting→waitingwaiting→collecting→waiting→summarising→transmitting→waiting

shutdownwaitingcalibratingtransmittingtestingsummarisingCollectingStartup()Shutdown()clockCollectiondonereportWeather()WeathersummarycompleteTestcompleteCalibrationOKTransmissiondoneTest()Calibrate()operation92第九十二页，共一百零六页，编辑于2023年，星期三

对对象类中的每个方法至少发送一个消息，使对象从α状态到ω状态，表明经过的所有方法均是可操作的。可以使用“宽度优先的方式”遍历STD：一个测试用例测试单个状态转换，当测试新的转换时，仅使用以前被测试过的转换。93第九十三页，共一百零六页，编辑于2023年，星期三

（3）类间测试用例设计（集成测试）测试类或构件被组装后相互之间能否正常交互完成指定的功能。使用use-case作为测试的主要驱动，时序图、协作图为测试提供帮助。和单个类一样，可通过应用随机和划分方法以及基于use-case场景和行为模型导出测试用例。

（Ⅰ）随机测试