软件测试-教案课件.ppt

上传人:牧羊曲112 文档编号:3727816 上传时间:2023-03-17 格式:PPT 页数:80 大小:3.91MB
返回 下载 相关 举报
软件测试-教案课件.ppt_第1页
第1页 / 共80页
软件测试-教案课件.ppt_第2页
第2页 / 共80页
软件测试-教案课件.ppt_第3页
第3页 / 共80页
软件测试-教案课件.ppt_第4页
第4页 / 共80页
软件测试-教案课件.ppt_第5页
第5页 / 共80页
点击查看更多>>
资源描述

《软件测试-教案课件.ppt》由会员分享,可在线阅读,更多相关《软件测试-教案课件.ppt(80页珍藏版)》请在三一办公上搜索。

1、第四章 白盒测试及其用例设计,软件测试概论Software Testing韩启龙,RCIIP Software Testing,2,第4章 白盒测试及其用例的设计,4.1 白盒测试方法4.2 基本概念4.3 静态白盒测试4.4 动态白盒测试,RCIIP Software Testing,3,本章教学目标,理论环节学习理解白盒测试方法的基本概念学习理解白盒测试的覆盖理论学习掌握白盒测试的路径表达学习掌握白盒测试的基本路径测试法实践环节通过案例运用学习掌握覆盖问题的解决方法运用基本路径测试方法进行实际程序测试,RCIIP Software Testing,4,4.1 白盒测试方法,为什么要进行白盒

2、测试?如果所有软件错误的根源都可以追溯到某个唯一原因,那么问题就简单了。然而,事实上一个bug 常常是由多个因素共同导致的,如下图所示。,假设此时开发工作已结束,程序送交到测试组,没有人知道代码中有一个潜在的被 0 除的错误。若测试组采用的测试用例的执行路径没有同时经过x=0和y=5/x进行测试,显然测试工作似乎非常完善,测试用例覆盖了所有执行语句,也没有被 0 除的错误发生。,RCIIP Software Testing,5,白盒测试方法(续),白盒测试也称结构测试或逻辑驱动测试,是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例,主要用于软件或程序验证。白盒测试法检查

3、程序内部逻辑结构,对所有逻辑路径进行测试,是一种穷举路径的测试方法。但即使每条路径都测试过了,仍然可能存在错误。因为:穷举路径测试无法检查出程序本身是否违反了设计规范,即程序是否是一个错误的程序。穷举路径测试不可能查出程序因为遗漏路径而出错。穷举路径测试发现不了一些与数据相关的错误。,RCIIP Software Testing,6,白盒测试方法(续),采用白盒测试方法必须遵循以下几条原则,才能达到测试的目的:保证一个模块中的所有独立路径至少被测试一次。所有逻辑值均需测试真(true)和假(false)两种情况。检查程序的内部数据结构,保证其结构的有效性。在上下边界及可操作范围内运行所有循环。

4、白盒测试主要是检查程序的内部结构、逻辑、循环和路径。常用测试用例设计方法有:逻辑覆盖法(逻辑驱动测试)基本路径测试方法,RCIIP Software Testing,7,4.2 白盒测试的基本概念,4.2.1 控制流图4.2.2 环形复杂度4.2.3 图矩阵,RCIIP Software Testing,8,4.2.1 控制流图,控制流图(可简称流图)是对程序流程图进行简化后得到的,它可以更加突出的表示程序控制流的结构。控制流图中包括两种图形符号:节点和控制流线。节点由带标号的圆圈表示,可代表一个或多个语句、一个处理框序列和一个条件判定框(假设不包含复合条件)。控制流线由带箭头的弧或线表示,可

5、称为边。它代表程序中的控制流。,RCIIP Software Testing,9,常见结构的控制流图,其中,包含条件的节点被称为判定节点(也叫谓词节点),由判定节点发出的边必须终止于某一个节点,由边和节点所限定的范围被称为区域。,RCIIP Software Testing,10,控制流图样例,RCIIP Software Testing,11,复合条件的分解,对于复合条件,则可将其分解为多个单个条件,并映射成控制流图。,RCIIP Software Testing,12,4.2.2 环形复杂度,环形复杂度也称为圈复杂度,它是一种为程序逻辑复杂度提供定量尺度的软件度量。环形复杂度的应用可以将环

6、形复杂度用于基本路径方法,它可以提供:程序基本集的独立路径数量;确保所有语句至少执行一次的测试数量的上界。独立路径是指程序中至少引入了一个新的处理语句集合或一个新条件的程序通路。采用流图的术语,即独立路径必须至少包含一条在本次定义路径之前不曾用过的边。测试可以被设计为基本路径集的执行过程,但基本路径集通常并不唯一。,RCIIP Software Testing,13,计算环形复杂度的方法,环形复杂度以图论为基础,为我们提供了非常有用的软件度量。可用以下方法之一来计算环形复杂度:控制流图中区域的数量对应于环形复杂度。给定控制流图G的环形复杂度V(G),定义为 V(G)=E-N+2 其中,E是控制

7、流图中边的数量,N是控制流图中的节点数量。给定控制流图G的环形复杂度V(G),也可定义为 V(G)=P+1 其中,P是控制流图G中判定节点的数量。,RCIIP Software Testing,14,4.2.3 图矩阵,图矩阵是控制流图的矩阵表示形式。图矩阵是一个方形矩阵,其维数等于控制流图的节点数。矩阵中的每列和每行都对应于标识的节点,矩阵元素对应于节点间的边。通常,控制流图中的结点用数字标识,边则用字母标识。如果在控制流图中从第 i 个结点到第 j 个结点有一个标识为 x 的边相连接,则在对应图矩阵的第 i 行第 j 列有一个非空的元素 x。,RCIIP Software Testing,

8、15,图矩阵样例,RCIIP Software Testing,16,4.3 静态白盒测试,4.3.1 相关概念4.3.2 代码检查法4.3.3 审查,RCIIP Software Testing,17,4.3.1 相关概念,静态白盒测试是在不执行软件条件下有条理地仔细审查软件设计、体系结构和代码,从而找出软件缺陷的过程,有时称为结构化分析。,首要原因是尽早发现软件缺陷,以找出动态黑盒测试难以发现或隔离的软件缺陷。在开发过程初期让测试小组集中精力进行软件设计的审查非常有价值。另一个原因,为黑盒测试员在接受软件进行软件测试时设计和应用测试用例提供思路。他们可能不必了解代码的细节,但是通过听审查评

9、论,可以确定有问题或者容易产生软件缺陷的特性范围。,静态白盒测试的好处,RCIIP Software Testing,18,4.3.2 代码检查法,检查代码和设计的一致性代码对标准的遵循、可读性代码逻辑表达的正确性代码结构的合理性程序编写与编写标准的符合性程序中不安全、不明确和模糊的部分编程风格问题等,通过桌面检查,代码审查和走查方式,对以下内容进行检查:,RCIIP Software Testing,19,4.3.2 代码检查法,1词法和语法分析,2静态错误分析,基本技术,用于确定在源程序中是否有某类错误或危险结构,包括以下几种:,(1)类型和单位分析,对源程序的类型进行检查,分析程序中的类

10、型错误,(2)引用分析,对程序中变量的引用进行检查,发现引用异常错误(如变量在定义前被引用,变量定义后未被引用)。,(3)表达式分析,(4)接口分析,RCIIP Software Testing,20,4.3.3 审 查,审查方式,1正式审查基本要素,2同事审查,3走查,4检验,通用代码审查清单,RCIIP Software Testing,21,4.3.3 审 查,1正式审查基本要素,确定问题,遵守规则,准备,编写报告,审查的目的是找出软件的问题不仅是出错的项目,还包括遗漏项目。对象为代码或设计。,审查要遵守一套固定的规则,规则可能设定要审查的代码量,花费时间,哪些内容要做评价等。,每个参与

11、者都为审查做准备。根据审查的类型,参与者可能扮演不同的角色,需要了解自己的责任和义务。在审查过程中,大部分的问题是在准备期间发现的。,审查小组必须做出审查结果的书面总结报告,并使报告便于开发小组的成员使用。,RCIIP Software Testing,22,4.3.3 审 查,2同事审查,召集小组成员进行初次正式审查最简单的方法是通过同事审查的方式。这是要求最低的正式方式,有时称为伙伴审查。这种方法大体类似于“你看我的,我看你的”类型的讨论。同事审查常常仅在编写代码或设计体系结构的程序员,以及充当审查者的其他一两个程序员和测试员之间进行。这个小团体只是在一起审查代码,寻找问题和失误。为了保证

12、审查的高效率,所有的参与者要切实保证正式审查的4个关键基本要素:查找问题、遵守规则、审查准备和编写报告。,RCIIP Software Testing,23,4.3.3 审 查,3走查(Walkthrough),比同事审查更正规化的下一步。走查中编写代码的程序员向5人小组或者其它程序员和测试员组成的小组做正式陈述。审查人员应该在审查之前接到软件拷贝,以便检查并编写备注和问题,在审查过程中提问。审查人员之中至少有一位资深程序员是很重要的。陈述者逐行或者逐个功能地通读代码,解释代码为什么且如何工作。审查人员聆听叙述,提出有疑义的问题。由于公开陈述的参与人数要多于同事审查,因此,为审查做好准备和遵守

13、规则是非常重要的。同样重要的是审查之后,表述者编写报告说明发现了哪些问题,计划如何解决发现的软件缺陷。,RCIIP Software Testing,24,4.3.3 审 查,4检验(inspections),最正式的审查类型,具有高度组织化,要求每一个参与者都接受训练。检验与同事审查和走查的不同之处在于表述代码的人表述者(presenter)或者宣读(reader)不是原来的程序员。这就迫使他学习和了解要表述的材料,从而有可能在检验会议上提出不同的看法和解释。其余的参与者称为检验员(inspector),其职责是从不同的角度审查代码。有些检验员还同时被委任为会议协调员(moderator)和

14、会议记录员(recorder),以保证检验过程遵守规则及审查有效进行。,RCIIP Software Testing,25,4.3.3 审 查,通用代码审查清单,数据引用错误数据声明错误计算错误比较错误控制流程错误子程序参数错误输入/输出错误其他错误,RCIIP Software Testing,26,数据引用错误,A.是否引用了未初始化的变量?B.数组和字符串的下标是整数值吗?下标总是在数组和字符串大小范围之内吗?C.在检索操作或者应用数组下标时是否包含丢掉一个这样的潜在错误?D.是否在应该使用常量的地方使用了变量?E.变量是否被赋予不同类型的值?F.为引用的指针分配内存了吗?G.一个数据结

15、构是否在多个函数或者子程序中引用,在每一个引用中明确定义结构了吗?,RCIIP Software Testing,27,数据声明错误,A.所有变量都赋予正确的长度、类型和存储类了吗?B.变量是否在声明的同时进行了初始化?是否正确初始化并与其类型一致?C.变量有相似的名称吗?D.存在声明过、但从未引用或者只引用过一次的变量吗?E.在特定模块中所有变量都显式地声明了吗?,RCIIP Software Testing,28,计算错误,A.计算中是否使用了不同数据类型的变量,如整数与浮点数相加?B.计算中是否使用了数据类型相同但字节长度不同的变量?C.计算时是否了解和考虑到编译器对类型或长度不一致的变

16、量的转换规则?D.赋值的目的变量是否小于赋值表达式的值?E.在数值计算过程中是否可能出现溢出?F.除数或模是否可能为零?G.对于整型算术运算或某些计算,特别是除法的代码处理是否会丢失精度?H.变量的值是否超过有意义的范围?I.对于包含多个操作的表达式,求值次序是否混乱,运算优先级对吗?需要加括号使其清晰吗?,RCIIP Software Testing,29,比较错误,A.比较得正确吗?B.存在分数或者浮点数之间的比较吗?如果有,精度问题会影响比较吗?1.00000001和1.00000002极其接近,它们相等吗?C.每一个逻辑表达式都正确地表达了吗?逻辑计算如期进行了吗?求值次序有疑问吗?D

17、.逻辑表达式的操作数是逻辑值吗?,RCIIP Software Testing,30,控制流程错误,A.程序中的语句组是否对应?B.程序、模块、子程序和循环能否终止?如果不能,可以接受吗?C.可能存在永远不停的循环吗?D.循环可能从不执行吗?如果是这样,可能接受吗?E.对于多分支语句,索引变量能超出可能的分支数目吗?如果超出,该情况能正确处理吗?F.是否存在丢掉一个错误,导致意外进入循环,RCIIP Software Testing,31,子程序参数错误,A.子程序接收的参数类型和大小与调用代码发送的匹配吗?次序正确吗?B.如果子程序有多个入口点,引用的参数是否与当前入口点没有关系?C.常量是

18、否当作形参传递,意外在子程序中改动?D.子程序是更改了仅作为输入值的参数?E.每一个参数的单位是否与相应的形参匹配?F.如果存在全局变量,在所有引用子程序中是否有相似的定义和属性?,RCIIP Software Testing,32,输入/输出错误,A.软件是否严格遵守外设读写数据的专用格式?B.软件是否处理外设未连接、不可用、或者读写过程中存储空间占满等情况?C.软件以预期的方式处理预计的错误吗?D.检查错误提示信息的准确性、正确性、语法和拼写了吗?,RCIIP Software Testing,33,其他错误,A.软件是否使用其他外语?是否处理扩展ASCII字符?是否需用统一编码取代ASC

19、II?B.软件是否需要移植到其他编译器?C.是否考虑了兼容性,以使软件能够运行于不同数量的可用内存、不同的内部硬件、不同的外设等?D.程序编译是否产生警告或者提示信息?这些信息通常指示语句有疑问。,RCIIP Software Testing,34,REVIEW(20110329),白盒测试,白盒测试也称结构测试或逻辑驱动测试,是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例,主要用于软件或程序验证。,采用白盒测试方法必须遵循以下几条原则,才能达到测试的目的:保证一个模块中的所有独立路径至少被测试一次。所有逻辑值均需测试真(true)和假(false)两种情况。检查程序

20、的内部数据结构,保证其结构的有效性。在上下边界及可操作范围内运行所有循环。白盒测试主要是检查程序的内部结构、逻辑、循环和路径。常用测试用例设计方法有:逻辑覆盖法(逻辑驱动测试)基本路径测试方法,RCIIP Software Testing,35,REVIEW(20110329),控制流图(可简称流图)是对程序流程图进行简化后得到的,它可以更加突出的表示程序控制流的结构。,其中,包含条件的节点被称为判定节点(也叫谓词节点),由判定节点发出的边必须终止于某一个节点,由边和节点所限定的范围被称为区域。,RCIIP Software Testing,36,控制流图样例,REVIEW(20110329)

21、,对于复合条件,则可将其分解为多个单个条件,并映射成控制流图。,环形复杂度,图矩阵,RCIIP Software Testing,37,静态白盒测试是在不执行软件条件下有条理地仔细审查软件设计、体系结构和代码,从而找出软件缺陷的过程,有时称为结构化分析。,REVIEW(20110329),通过桌面检查,代码审查和走查方式,对以下内容进行检查:,检查代码和设计的一致性代码对标准的遵循、可读性代码逻辑表达的正确性代码结构的合理性程序编写与编写标准的符合性程序中不安全、不明确和模糊的部分编程风格问题等,RCIIP Software Testing,38,1正式审查基本要素,确定问题,遵守规则,准备,

22、编写报告,审查的目的是找出软件的问题不仅是出错的项目,还包括遗漏项目。对象为代码或设计。,审查要遵守一套固定的规则,规则可能设定要审查的代码量,花费时间,哪些内容要做评价等。,每个参与者都为审查做准备。根据审查的类型,参与者可能扮演不同的角色,需要了解自己的责任和义务。在审查过程中,大部分的问题是在准备期间发现的。,审查小组必须做出审查结果的书面总结报告,并使报告便于开发小组的成员使用。,REVIEW(20110329),RCIIP Software Testing,39,4.4 动态白盒测试,4.4.1 相关概念4.4.2 逻辑覆盖技术4.4.3 路径测试技术,RCIIP Software

23、Testing,40,4.4.1 相关概念,动态白盒测试,利用查看代码功能和实现方式得到的信息来确定哪些需要测试,哪些不需要测试。如何开展测试,从而设计和执行测试。,测试覆盖率,用于确定测试所执行到的覆盖项的百分比。其中的覆盖项是指作为测试基础的一个入口或属性,比如语句、分支、条件等。,RCIIP Software Testing,41,测试覆盖率,测试覆盖率可以表示出测试的充分性,在测试分析报告中可以作为量化指标的依据,测试覆盖率越高效果越好。但覆盖率不是目标,只是一种手段。,测试覆盖率包括功能点覆盖率和结构覆盖率:功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系

24、。结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等等。,4.4.1 相关概念,RCIIP Software Testing,42,4.4.2 逻辑覆盖技术,逻辑覆盖:是以程序内部的逻辑结构为基础的测试用例设计方法。,根据覆盖目标的不同,逻辑覆盖又可分为语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。语句覆盖:选择足够多的测试用例,使得程序中的每个可执行语句至少执行一次。判定覆盖:通过执行足够的测试用例,使得程序中的每个判定至少都获得一次“真”值和“假”值,也就是使程序中的每个取“真”分支和取“假”分支至少均经历一次,也称为“分支覆盖”。条件覆盖:设计足够多的测试

25、用例,使得程序中每个判定包含的每个条件的可能取值(真/假)都至少满足一次。,RCIIP Software Testing,43,判定/条件覆盖:设计足够多的测试用例,使得程序中每个判定包含的每个条件的所有情况(真/假)至少出现一次,并且每个判定本身的判定结果(真/假)也至少出现一次。满足判定/条件覆盖的测试用例一定同时满足判定覆盖和条件覆盖。组合覆盖:通过执行足够的测试用例,使得程序中每个判定的所有可能的条件取值组合都至少出现一次。满足组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判定/条件覆盖。路径覆盖:设计足够多的测试用例,要求覆盖程序中所有可能的路径。,4.4.2 逻辑覆盖技术,RCII

26、P Software Testing,44,4.4.2 逻辑覆盖技术,RCIIP Software Testing,45,void DoWork(int x,int y,int z)int k=0,j=0;if(x3)/语句块3,逻辑运算符有4个,它们分别是:!(逻辑非)、(逻辑或)、(逻辑与)(异或)。在位运算里面还有(位与)、(位或)的运算。,4.4.2 逻辑覆盖技术,RCIIP Software Testing,46,4.4.2 逻辑覆盖技术,RCIIP Software Testing,47,要实现DoWork函数的语句覆盖,只需设计一个测试用例就可以覆盖程序中的所有可执行语句。测试用

27、例输入为:x=4、y=5、z=5 程序执行的路径是:abd分析:语句覆盖可以保证程序中的每个语句都得到执行,但发现不了判定中逻辑运算的错误,即它并不是一种充分的检验方法。例如在第一个判定(x3)&(z10)中把“&”错误的写成了“|”,这时仍使用该测试用例,则程序仍会按照流程图上的路径abd执行。可以说语句覆盖是最弱的逻辑覆盖准则。,4.4.2 逻辑覆盖技术,1.语句覆盖,语句覆盖是最弱的逻辑覆盖,它仅要求设计足够多的测试用例,使程序中的每一条语句都执行一次即可。,RCIIP Software Testing,48,4.4.2 逻辑覆盖技术,2.判定覆盖,判定覆盖要求设计足够多的测试用例,使得

28、被测程序中每个判定表达式都执行一次“真”和一次“假”的运行。从而使程序的每一个分支至少都通过一次。因此判定覆盖也称为分支覆盖。,要实现DoWork函数的判定覆盖,需要设计两个测试用例。测试用例的输入为:x=4、y=5、z=5;x=2、y=5、z=5程序执行的路径分别是:abd;ace分析:上述两个测试用例不仅满足了判定覆盖,同时还做到语句覆盖。从这点看似乎判定覆盖比语句覆盖更强一些,但仍然无法确定判定内部条件的错误。例如把第二个判定中的条件y5错误写为y5,使用上述测试用例,照样能按原路径执行而不影响结果。因此,需要有更强的逻辑覆盖准则去检验判定内的条件。,RCIIP Software Tes

29、ting,49,说明:以上仅考虑了两出口的判断,我们还应把判定覆盖准则扩充到多出口判断(如Case语句)的情况。因此,判定覆盖更为广泛的含义应该是使得每一个判定获得每一种可能的结果至少一次。,4.4.2 逻辑覆盖技术,2.判定覆盖,RCIIP Software Testing,50,在实际程序代码中,一个判定中通常都包含若干条件。条件覆盖的目的是设计若干测试用例,在执行被测程序后,要使每个判定中每个条件的可能值至少满足一次。对DoWork函数的各个判定的各种条件取值加以标记。对于第一个判定(x3)&(z3 取真值记为T1,取假值记为-T1 条件z5):条件x=4 取真值记为T3,取假值记为-T

30、3 条件y5 取真值记为T4,取假值记为-T4,4.4.2 逻辑覆盖技术,3.条件覆盖,RCIIP Software Testing,51,条件覆盖(续),根据条件覆盖的基本思想,要使上述4个条件可能产生的8种情况至少满足一次,设计测试用例如下:,分析:上面这组测试用例不但覆盖了4个条件的全部8种情况,而且将两个判定的4个分支b、c、d、e也同时覆盖了,即同时达到了条件覆盖和判定覆盖。,RCIIP Software Testing,52,条件覆盖(续),说明:虽然前面的一组测试用例同时达到了条件覆盖和判定覆盖,但是,并不是说满足条件覆盖就一定能满足判定覆盖。如果设计了下表中的这组测试用例,则虽

31、然满足了条件覆盖,但只是覆盖了程序中第一个判定的取假分支c 和第二个判定的取真分支d,不满足判定覆盖的要求。,RCIIP Software Testing,53,判定/条件覆盖实际上是将判定覆盖和条件覆盖结合起来的一种方法,即:设计足够的测试用例,使得判定中每个条件的所有可能取值至少满足一次,同时每个判定的可能结果也至少出现一次。根据判定/条件覆盖的基本思想,只需设计以下两个测试用例便可以覆盖4个条件的8种取值以及4个判定分支。,4.4.2 逻辑覆盖技术,4.判定/条件覆盖,RCIIP Software Testing,54,判定/条件覆盖(续),分析:从表面上看,判定/条件覆盖测试了各个判定

32、中的所有条件的取值,但实际上,编译器在检查含有多个条件的逻辑表达式时,某些情况下的某些条件将会被其它条件所掩盖。因此,判定/条件覆盖也不一定能够完全检查出逻辑表达式中的错误。例如:对于第一个判定(x3)&(z3和z3为假,则编译器将不再检查z5)来说,若条件x=4满足,就认为该判定为真,这时将不会再检查y5,那么同样也无法发现这个条件中的错误。,RCIIP Software Testing,55,组合覆盖的目的是要使设计的测试用例能覆盖每一个判定的所有可能的条件取值组合。对DoWork函数中的各个判定的条件取值组合加以标记:1、x3,z3,z=10 记T1、-T2,第一个判定的取假分支 3、x

33、=10 记-T1、-T2,第一个判定的取假分支 5、x=4,y5 记T3、T4,第二个判定的取真分支 6、x=4,y5 记-T3、T4,第二个判定的取真分支 8、x!=4,y=5 记-T3、-T4,第二个判定的取假分支,4.4.2 逻辑覆盖技术,5.组合覆盖,RCIIP Software Testing,56,组合覆盖(续),根据组合覆盖的基本思想,设计测试用例如下:,分析:上面这组测试用例覆盖了所有8种条件取值的组合,覆盖了所有判定的真假分支,但是却丢失了一条路径abe。,RCIIP Software Testing,57,前面提到的5种逻辑覆盖都未涉及到路径的覆盖。事实上,只有当程序中的每

34、一条路径都受到了检验,才能使程序受到全面检验。路径覆盖的目的就是要使设计的测试用例能覆盖被测程序中所有可能的路径。根据路径覆盖的基本思想,在满足组合覆盖的测试用例中修改其中一个测试用例,则可以实现路径覆盖:,4.4.2 逻辑覆盖技术,6.路径覆盖,RCIIP Software Testing,58,路径覆盖(续),分析:虽然前面一组测试用例满足了路径覆盖,但并没有覆盖程序中所有的条件组合(丢失了组合3和7),即满足路径覆盖的测试用例并不一定满足组合覆盖。说明:对于比较简单的小程序,实现路径覆盖是可能做到的。但如果程序中出现较多判断和较多循环,可能的路径数目将会急剧增长,要在测试中覆盖所有的路径

35、是无法实现的。为了解决这个难题,只有把覆盖路径数量压缩到一定的限度内,如程序中的循环体只执行一次。在实际测试中,即使对于路径数很有限的程序已经做到路径覆盖,仍然不能保证被测试程序的正确性,还需要采用其他测试方法进行补充。,RCIIP Software Testing,59,白盒测试方法的比较,图中每一列代表白盒测试的一种方法,每一行定义一种测试特征。对于特定方法(列),行中的“Y”意思是该方法要求该测试特征。“N”表示没有要求。“implicit”意思是该测试特征暗中通过该方法的其他要求获得。,RCIIP Software Testing,60,逻辑覆盖的出发点是合理的、完善的。所谓“覆盖”,

36、就是想要做到全面而无遗漏,但逻辑覆盖并不能真正做到无遗漏。例如:我们不小心将前面提到的程序段中的 if(x3&z=3&z10)按照我们前面设计的测试用例(x的值取2或4)来看,逻辑覆盖对这样的小问题都无能为力。分析出现这一情况的原因在于:错误区域仅仅在x=3这个点上,即仅当x的值取3时,测试才能发现错误。面对这类情况,我们应该从中吸取的教训是测试工作要有重点,要多针对容易发生问题的地方设计测试用例。,4.4.2 逻辑覆盖技术,逻辑覆盖准则,RCIIP Software Testing,61,测试覆盖准则(续),ESTCA覆盖准则:(Error Sensitive Test Cases Anal

37、ysis)在容易发生问题的地方设计测试用例,即重视程序中谓词(条件判断)的取值。ESTCA覆盖准则是一套错误敏感用例分析规则。这一规则虽然并不完备,但在普通程序中却是有效的。原因在于这是一种经验型的覆盖准则,规则本身针对了程序编写人员容易发生的错误,或是围绕着发生错误的频繁区域,从而提高了发现错误的命中率。具体规则如下:规则1 对于A rel B型(rel可以是)的分支谓词,应适当的选择A与B的值,使得测试执行到该分支语句时,AB的情况分别出现一次。这是为了检测逻辑符号写错的情况,如将“AB”。,RCIIP Software Testing,62,测试覆盖准则(续),规则2 对于A rel C

38、型(rel可以是或时,应适当的选择A的值,使A=C+M。这是为了检测“差1”之类的错误,如“A1”错写成“A0”。规则3 对外部输入变量赋值,使其在每一个测试用例中均有不同的值与符号,并与同一组测试用例中其他变量的值与符号不同。这是为了检测程序语句中的错误,如应该引用某一变量而错成引用另一个常量。,RCIIP Software Testing,63,测试覆盖准则(续),LCSAJLCSAJ(Linear Code Sequence and Jump)的字面含义是线性代码序列与跳转。在程序中,一个LCSAJ是一组顺序执行的代码,以控制跳转为其结束点。LCSAJ的起点是根据程序本身决定的。它的起点

39、可以是程序第一行或转移语句的入口点,或是控制流可跳达的点。如果有几个LCSAJ首尾相接,且第一个LCSAJ起点为程序起点,最后一个LCSAJ终点为程序终点,这样的LCSAJ串就组成了程序的一条路径(LCSAJ路径)。一条LCSAJ程序路径可能是由2个、3个或多个LCSAJ组成的。,RCIIP Software Testing,64,测试覆盖准则(续),基于LCSAJ与路径的关系,提出了层次LCSAJ覆盖准则。它是一个分层的覆盖准则,可以概括的描述为:第一层 语句覆盖。第二层 分支覆盖。第三层 LCSAJ覆盖,即程序中的每一个LCSAJ都至少在测试中经历过一次。第四层 两两LCSAJ覆盖,即程序

40、中的每两个相连的LCSAJ组合起来在测试中都要经历一次。第n+2层 每n个首尾相连的LCSAJ组合在测试中都要经历一次。在实施测试时,若要实现上述的层次LCSAJ覆盖,需要产生被测程序的所有LCSAJ。,RCIIP Software Testing,65,4.4.3 路径测试,4.4.3.1 路径表达式4.4.3.2 基本路径测试方法4.4.3.3 循环测试方法4.4.3.4 产生测试用例,RCIIP Software Testing,66,4.4.3.1 路径表达式,为了满足路径覆盖,必须首先确定具体的路径以及路径的个数。我们通常采用控制流图的边(弧)序列和节点序列表示某一条具体路径,更为概

41、括的表示方法为:(1)弧a和弧b相乘,表示为ab,它表明路径是先经历弧a,接着再经历弧b,弧a和弧b是先后相接的。(2)弧a和弧b相加,表示为a+b,它表明两条弧是“或”的关系,是并行的路段。路径数的计算:在路径表达式中,将所有弧均以数值1来代替,再进行表达式的相乘和相加运算,最后得到的数值即为该程序的路径数。,RCIIP Software Testing,67,4.4.3.2 基本路径测试方法,路径测试就是从一个程序的入口开始,执行所经历的各个语句的完整过程。从广义的角度讲,任何有关路径分析的测试都可以被称为路径测试。完成路径测试的理想情况是做到路径覆盖,但对于复杂性大的程序要做到所有路径覆

42、盖(测试所有可执行路径)是不可能的。在不能做到所有路径覆盖的前提下,如果某一程序的每一个独立路径都被测试过,那么可以认为程序中的每个语句都已经检验过了,即达到了语句覆盖。这种测试方法就是通常所说的基本路径测试方法。,RCIIP Software Testing,68,基本路径测试方法(续),基本路径测试方法是在控制流图的基础上,通过分析控制结构的环形复杂度,导出执行路径的基本集,再从该基本集设计测试用例。基本路径测试方法包括以下4个步骤:(1)画出程序的控制流图。(2)计算程序的环形复杂度,导出程序基本路径集中的独立路径条数,这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。

43、(3)导出基本路径集,确定程序的独立路径。(4)根据(3)中的独立路径,设计测试用例的输入数据和预期输出。,RCIIP Software Testing,69,基本路径测试方法(续),void Sort(int iRecordNum,int iType)1 2 int x=0;3 int y=0;4 while(iRecordNum-0)5 6 If(iType=0)7x=y+2;8 else9 If(iType=1)10 x=y+10;11 else12 x=y+20;13 14,RCIIP Software Testing,70,基本路径测试方法(续),画出控制流图:如右图所示计算环形复杂

44、度:10(条边)-8(个节点)+2=4导出独立路径(用语句编号表示)路径1:414 路径2:46714 路径3:4691013414 路径4:4691213414,RCIIP Software Testing,71,基本路径测试方法(续),设计测试用例:,RCIIP Software Testing,72,4.4.3.3 循环测试方法,从本质上说,循环测试的目的就是检查循环结构的有效性。通常,循环可以划分为简单循环、嵌套循环、串接循环和 非结构循环4类。(1)测试简单循环。设其循环的最大次数为n,可采用以下测试集:跳过整个循环;只循环一次;只循环两次;循环 m 次,其中mn;分别循环 n-1、

45、n 和 n+1 次。,RCIIP Software Testing,73,循环测试方法(续),(2)测试嵌套循环。如果将简单循环的测试方法用于嵌套循环,可能的测试次数会随嵌套层数成几何级数增加。此时可采用以下办法减少测试次数:测试从最内层循环开始,所有外层循环次数设置为最小值;对最内层循环按照简单循环的测试方法进行;由内向外进行下一个循环的测试,本层循环的所有外层循环仍取最小值,而由本层循环嵌套的循环取某些“典型”值;重复上一步的过程,直到测试完所有循环。(3)测试串接循环。若串接的各个循环相互独立,则可分别采用简单循环的测试方法;否则采用嵌套循环的测试方法。(4)对于非结构循环这种情况,无法

46、进行测试,需要按结构化程序设计的思想将程序结构化后,再进行测试。,RCIIP Software Testing,74,Z路径覆盖下的循环测试方法,Z路径覆盖是路径覆盖的一种变体,它是将程序中的循环结构简化为选择结构的一种路径覆盖。循环简化的目的是限制循环的次数,无论循环的形式和循环体实际执行的次数,简化后的循环测试只考虑执行循环体一次和零次(不执行)两种情况,即考虑执行时进入循环体一次和跳过循环体这两种情况。,在循环简化的思路下,循环与判定分支的效果是一样的,即:循环要么执行、要么跳过。,RCIIP Software Testing,75,4.5 最少测试用例数计算,为实现测试的逻辑覆盖,必须

47、设计足够多的测试用例,并使用这些测试用例执行被测程序,实施测试。我们关心的是:对于某个具体的程序来说,至少需要设计多少个测试用例。这里提供一种估算最少测试用例数的方法。我们知道,结构化程序是由 3 种基本控制结构组成:顺序型(构成串行操作)、选择型(构成分支操作)和重复型(构成循环操作)。为了把问题化简,避免出现测试用例极多的组合爆炸,把构成循环操作的重复型结构用选择结构代替。这样,任一循环便改造成进入循环体或不进入循环体的分支操作了。,RCIIP Software Testing,76,最少测试用例数计算(续),用N-S图表示程序的3种基本控制结构:,图中A、B、C、D、S均表示要执行的操作

48、,P是可取真假值的谓词,Y表真值,N表假值。图中的(c)和(d)两种重复型结构代表了两种循环。在做了简化循环的假设以后,对于一般的程序控制流,我们只考虑选择型结构。事实上它已经能体现顺序型和重复型结构了。,RCIIP Software Testing,77,最少测试用例数计算(续),显然,要测试这个小程序,需要至少提供4个测试用例才能作到逻辑覆盖,使得ac、ad、bc及bd操作均得到检验。其实,这里的测试用力个数4是图中的第1个分支谓词引出的两个操作,及第2个分支谓词引出的两个操作组合起来而得到的,即 22=4。并且,这里的2是由于两个并列的操作,即1+1=2 而得到的。,例如,下图表达了两个

49、顺序执行的分支结构。当两个分支谓词P1和P2取不同值时,将分别执行a或b及c或d操作。,RCIIP Software Testing,78,最少测试用例数计算(续),对于一般的、更为复杂的问题,估算最少测试用例个数的原则也是同样的:如果在N-S图中存在有并列的层次A1、A2,A1和A2的最少测试用例个数分别为a1、a2,则由 A1、A2 两层所组合的 N-S图对应的最少测试用例数为a1a2。如果在N-S图中不存在有并列的层次,则对应的最少测试用例数由并列的操作数决定,即N-S图中除谓词之外的操作框的个数。,RCIIP Software Testing,79,最少测试用例数计算(续),例:如下图

50、所示的两个N-S图,至少需要多少个测试用例完成逻辑覆盖?,对于第一个N-S图:由于图中并不存在并列的层次,最少测试用例数由并列的操作数决定,即为1+1+1=3。对于第二个N-S图:由于图中没有包含并列的层次,最少测试用例数仍由并列的操作数决定,即为1+1+1+1+1=5。,RCIIP Software Testing,80,最少测试用例数计算(续),例:如下图所示的N-S图,至少需要多少个测试用例完成逻辑覆盖?,分析该N-S图:图中的2345和67是并列的两层。其中,2345层对应的最少测试用例数为1+1+1+1+1=5,67层对应的测试用例数为1+1+1=3,2345和67这两层组合后对应的

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 生活休闲 > 在线阅读


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号