软件工程PPT电子教案课件-第十二章 软件测试.ppt_第1页
软件工程PPT电子教案课件-第十二章 软件测试.ppt_第2页
软件工程PPT电子教案课件-第十二章 软件测试.ppt_第3页
软件工程PPT电子教案课件-第十二章 软件测试.ppt_第4页
软件工程PPT电子教案课件-第十二章 软件测试.ppt_第5页
已阅读5页,还剩147页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

第十二章 软件测试,软件工程,引言,尽管软件质量保证是贯穿软件开发全过程的活动,但最关键的步骤是软件测试,软件测试是对软件规格说明、软件设计和编码的最后复审,目的是在软件产品交付之前尽可能发现软件中潜伏的错误。 测试(testing)是软件开发时期的最后一个阶段,也是软件质量保证中至关重要的一个环节。 本章主要讨论软件的测试,重点放在测试的策略与技术、纠错的策略与技术,以及多模块软件的测试内容与方法。,本章提要,测试的基本概念 黑盒测试 白盒测试 测试用例设计 多模块程序的测试策略 面向对象系统的测试,软件测试在软件生命周期中横跨两个阶段。 编码和单元测试 通常在编写出每个模块之后就对它做必要的测试(称为单元测试),模块的编写者和测试者是同一个人,属于软件生命周期的同一个阶段。 综合测试等其它测试 在单元测试结束之后,对软件系统还应该进行各种综合测试,这是软件生命周期中的另一个独立的阶段,通常由专门的测试人员承担这项工作。,测试的基本概念,大量统计资料表明,软件测试的工作量往往占软件开发总工作量的40%以上,在极端情况,测试那种关系人的生命安全的软件所花费的成本,可能相当于软件工程其他步骤总成本的35倍。因此,必须高度重视软件测试工作,绝不要以为写出程序之后软件开发工作就接近完成了,实际上,大约还有同样多的开发工作量需要完成。 仅就测试而言,它的目标是发现软件中的错误,但是,发现错误并不是我们的最终目的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件,因此,通过测试发现错误之后还必须诊断并改正错误,这就是调试的目的。调试是测试阶段最困难的工作。在对测试结果进行收集和评价的时候,软件所达到的可靠性也开始明朗了。,测试的基本概念,测试的定义 g.j.myers在他的名著软件测试技巧一书中,给出测试是为了发现错误而执行的程序的过程。 测试(testing)的目的与任务 目的:发现程序的错误 任务:通过执行程序,暴露潜在的错误 纠错(debugging)的目的与任务 目的:定位和纠正错误 任务:消除软件故障,保证程序的可靠运行,测试的基本概念,测试,评价,纠错,程序,测试结果,错误信息,测试数据,期望结果,改正信息,测试和纠错信息流程:,测试的基本概念,常把“测试纠错再测试再纠错”的过程称为“程序调试” 调试一般需要软件工具支持,称为调试程序(degugger) 现在的调试工具一般与编码、编译工具集成在一起,更全面的测试与纠错流程图,测试的基本概念,测试活动的输入 软件配置 软件需求规格说明、软件设计规格说明、源代码等; 测试配置 测试计划、测试用例、测试程序等; 测试工具 测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等。,测试的基本概念,测试的特性 挑剔性 抱着为证明程序有错的目的去测试 复杂性 设计合适的测试用例 需要细致和高度技巧 不彻底性 dijkstra 一句名言:“程序测试只能证明错误的存在,但不能证明错误不存在” 穷举测试既不可能也不可取 经济性 选择典型的测试用例进行适当的测试 不可随意提高测试的等级,测试的基本概念,测试的种类,测试的基本概念,测试的文档 测试计划 测试项目的名称 各项测试的目的、步骤和进度 测试用例的设计 测试报告 测试项目名称 实测结果与期望结果的比较 发现的问题 测试达到的效果,测试的基本概念,测试用例 = 测试数据 + 期望结果 ,测试结果 = 测试数据 + 期望结果 + 实际结果 ,测试方案包括具体的测试目的,应该输入的测试数据和预期的输出结果。 通常又把测试数据和预期的输出结果称为测试用例。,好的测试方案是高概率发现错误的方案, 成功的测试是发现了尚未发现的错误;,测试的文档,测试方案与软件可靠性有关,可靠性要求越高,测试的标准/等级就越高,测试的文档,(1)测试除了发现软件故障,还要检查软件是否满足了用户的需求。从用户的角度看,用户需求没有满足是最大的错误 (2)应该尽早准备测试计划,一般来说做完详细设计,就应该准备测试计划 (3)应该用不同的程序员进行测试。程序编写者只能算程序的调试者,程序员调试程序应看作编码的一部分,而不是真正的测试,测试的原则,(4)相信大部分软件错误集中在少数程序模块中,特别是那些难以理解的模块 (5)穷举测试是不可能的,因此在准备测试计划时要很好地设计测试用例 右图表示了包含4个选择分支和 一个至多重复20次的循环 该测试包括 51+52+520=1014次测试,测试的原则,(6)严格执行测试计划,排除测试的随意性。 (7)应当对每一个测试结果做全面检查。 (8)妥善保存测试计划、测试用例、出错统计和最终分析报告,为维护提供方便。,测试的原则,黑盒测试法把程序看成一个黑盒子,完全不考虑程序的内部结构和处理过程。 黑盒测试是在程序接口进行的测试,它只检查程序功能是否能按照规格说明书的规定正常使用,程序是否能适当地接收输入数据产生正确的输出信息,并且保持外部信息(如,数据库或文件)的完整性。黑盒测试又称为功能测试 黑盒测试法分为: 等价分类法 边界值分析法 错误猜测法 因果图法,黑盒测试,黑盒测试力图发现下述类型的错误: 功能不正确或遗漏了功能; 界面错误; 数据结构错误或外部数据库访问错误; 性能错误; 初始化和终止错误。 白盒测试在测试过程的早期阶段进行,而黑盒测试主要用于测试过程的后期。黑盒测试故意不考虑程序的控制结构,而把注意力集中于信息域。,黑盒测试,基本方法 完全不考虑程序的内部结构,只依据程序的规格说明来设计测试用例。 等价类划分方法把所有可能的输入数据,即程序的输入域划分成若干部分,然后从每一部分中选取少数有代表性的数据做为测试用例。 设计测试用例要经历 划分等价类(列出等价类表) 选取测试用例,等价分类法,划分等价类 等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其它值的测试。 等价类的划分有两种不同的情况: 有效等价类:是指对于程序的规格说明来说,是合理的,有意义的输入数据构成的集合。 无效等价类:是指对于程序的规格说明来说,是不合理的,无意义的输入数据构成的集合。 在设计测试用例时,要同时考虑有效等价类和无效等价类的设计。,等价分类法,划分等价类等价类的方法 (1)如果输入条件规定了取值范围,或值的个数,则可以确立一个有效等价类和两个无效等价类。 例如,在程序的规格说明中,对输入条件有一句话:“项数可以从1到999”,则有效等价类是“1项数999”,两个无效等价类是“项数1”或“项数999”。 (2)如果输入条件规定了输入值的集合,或者是规定了“必须如何”的条件,这时可确立一个有效等价类和一个无效等价类。 例如,在程序设计语言中对变量标识符规定为“以字母打头的串”。那么所有以字母打头的构成有效等价类,而不在此集合内(不以字母打头)的归于无效等价类。,等价分类法,(3)如果输入条件是一个布尔量,则可以确定一个有效等价类和一个无效等价类。 (4)如果规定了输入数据的一组值,而且程序要对每个输入值分别进行处理。这时可为每一个输入值确立一个有效等价类,此外针对这组值确立一个无效等价类,它是所有不允许的输入值的集合。 例如,在教师上岗方案中规定对教授、副教授、讲师和助教分别计算分数,做相应的处理。因此可以确定4个有效等价类为教授、副教授、讲师和助教,一个无效等价类,它是所有不符合以上身分的人员的输入值的集合。,等价分类法,(5)如果规定了输入数据必须遵守的规则,则可以确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。 例如,某语言规定“一个语句必须以分号;结束”。这时,可以确定一个有效等价类“以;结束”,若干个无效等价类“以:结束”、“以,结束”、“以空格结束”、“以lf结束”等。,等价分类法,确立测试用例 (1)在确立了等价类之后, 建立等价类表,列出所有划分出的等价类; 为每一个等价类规定一个唯一编号。 (2)再从划分出的等价类中按以下原则选择测试用例: 设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止; 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。,等价分类法,例12.1:某工厂公开招工,规定报名者年龄应在16周岁至35周岁之间(到2005年4月30日止)。出生年龄不在上述范围内,将拒绝接受,并显示“年龄不合格”等出错信息。,第一步:划分等价类:假定已知出生年月由6位数字字符表示,前4位代表年,后2为代表月,则可以划分为3个有效等价类,7个无效等价类。如下表:,等价分类法,第二步:设计有效等价类需要的测试用例。 第三步:为每一个无效等价类至少设计一个测试用例。,等价分类法,让几个有效等价类共用一个测试用例,可以减少测试次数,有利而无弊;但若干个无效等价类合用一个测试用例,就可能使错误漏检。就上例而言,假定把“195512”(对应无效等价类)和“196200”(对应无效等价类)合并为一个测试用例,例如“195500”,即使在测试过程中程序显示出“年龄不合格”的信息,仍不能证明程序对月份“00”的输入数据也具有识别和拒绝的功能。,边界值分析也是一种黑盒测试方法,是对等价类划分方法的补充。 人们从长期的测试工作经验得知,大量的错误是发生在输入或输出范围的边界上,而不是在输入范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。 例如,在数组容量、循环次数以及输入数据与输出数据的边界值附近程序出错的概率往往比较大。,边界值分析法,例如,在做三角形计算时,要输入三角形的三个边长:a、b和c。我们应注意到这三个数值应当满足a0、b0、c0、abc、acb、bca,才能构成三角形。但如果把六个不等式中的任何一个大于号“”错写成大于等于号“”,那就不能构成三角形。问题恰出现在容易被疏忽的边界附近。,边界值分析法,这里所说的边界是指,相对于输入等价类和输出等价类而言,稍高于其边界值及稍低于其边界值的一些特定情况。 使用边界值分析方法设计测试用例,首先应确定边界情况。应当选取正好等于、刚刚大于,或刚刚小于边界的值做为测试数据,而不是选取等价类中的典型值或任意值做为测试数据。,边界值分析法,例12.2,程序同例12.1。试用边界值分析法设计其测试用例。招工年龄的边界值分析(部分)。例如,为了只接受年龄合格的报名者。程序中可能设有语句: if(birthdate=197003 | birthdate=198904 ) write “valid age” else write “invalid age” 但如果编码时把以上语句中的“=”误写为“”,用上例中的所有测试用例都不能发现这种错误。,年龄对应输入:最大合格年龄:年月值为35周岁 最小合格年龄:年月值为16周岁 恰大于最大合格年龄:年月值比35周岁大1月 恰小于最小合格年龄:年月值比16周岁小1月,月份对应输入:最大月份:12 最小月份:01 恰大于最大月份:13 恰小于最小月份:00,边界值分析法,边界值分析法,把测试的重点放在各个等价类的边界上,选取刚好等于、大于或小于边界值的数据为测试数据,人们也可以靠经验和直觉推测程序中可能存在的各种错误,从而有针对性地编写检查这些错误的例子。这就是错误猜测法。 错误推测法的基本思想是:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据它们选择测试方案。 显然,它比前两种方法更多地依靠测试人员的直觉与经验。所以,一般都先用前两种方法设计测试用例,然后用猜错法补充一些例子作为辅助的手段。,错误猜测法,仍以上述的报名程序为例,还可以用错误猜测法补充一些测试用例: 出生年月为“0”。 漏送“出生年月”。 年月次序颠倒,例如将“197012”误输为“121970”。,错误猜测法,例:数据排序程序的测试,用边界值分析法设计以下测试用例: 输入表为空表; 输入表中仅有一个数据; 输入表为满表。 用错误猜测法补充如下用例: 输入表已经排好序; 输入表的数据顺序恰好于要求的顺序相反; 输入表中的数据完全相同,错误猜测法,因果图的适用范围 等价类划分和边界值分析方法都只是孤立地考虑各个输入数据的测试功能,而没有考虑考虑输入条件的各种组合引起的错误。 因果图能有效地检测输入条件的各种组合可能会引起的错误。可使用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来设计测试用例。 因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。,因果图法,用因果图生成测试用例的基本步骤 (1)分析软件规格说明描述中,哪些是原因(即输入条件或输入条件的等价类),哪些是结果(即输出条件),并给每个原因和结果赋予一个标识符。 (2)分析软件规格说明描述中的语义,找出原因与结果之间,原因与原因之间对应的是什么关系?根据这些关系,画出因果图。 (3)由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不可能出现。为表明这些特殊情况,在因果图上用一些记号标明约束或限制条件。,因果图法,(4)把因果图转换成判定表。 选择一个输出动作,使之处于“1”状态 在因果图上从后向前回溯,找出使此动作为“1”的各种输入条件组合 将每一个输入条件组合填入判定表中的一列,同时填入在此组合情况下各个输出动作的状态 选出下一输出动作,重复以上3步,直至最后一个输出动作做完为止 (5)把判定表的每一列拿出来作为依据,设计测试用例。,因果图法,在因果图中出现的基本符号 通常在因果图中用ci表示原因,用ei表示结果,各节点表示状态,可取值“0”或“1”。“0”表示某状态不出现,“1”表示某状态出现。,因果图法,主要的原因和结果之间的关系有:,因果图法,表示约束条件的符号 为了表示原因与原因之间,结果与结果之间可能存在的约束条件,在因果图中可以附加一些表示约束条件的符号。,因果图法,设计测试用例 因果图的测试用例设计步骤如下: (1) 分析规格说明中的输入作为因,输出作为果。 (2) 依据因果的处理语义画出因果图。 (3) 标出因果图的约束条件。 (4) 将因果图转换为因果图所对应的判定表。 (5) 根据判定表设计测试用例。,因果图法,利用因果图设计测试用例的实例 某规格说明:“第一列字符必须是a或者b,第二列字符必须是一个数字,第一、二两列都满足时修改文件,第一列不正确时给出信息l,第二列不正确时给出信息m。” (1) 分析规格说明并编号。 因:第一列字符是a 第一列字符是b,因果图法,因:第二列字符是数字,因果图法,因:第二列字符必须是一个数字,果:修改文件,因果图例,因果图法,(2)画出因果图,第1列不正确,第1、2列正确,第2列不是数字,互斥,(3)将因果图转换为判定表:遇到e约束记为x;条件和输出结果编号成立时记为1,否则记为0;表中每一列视为测试规则。,因果图法,1、2同时为1不可能,约束记为x,1、2同时为0,3不可能为0,22记为x,(4) 根据判定表的38列编写测试用例如下: 根据3列 输入:a3,a8 输出:修改文件 根据5列 输入:b4,b5 输出:修改文件 根据4列 输入:am,a? 给出信息m 根据6列 输入:bb,bc 给出信息m 根据7列 输入:m1,x6 给出信息l 根据8列 输入:xy,mn 给出信息m与l,因果图法,设要对一个自动饮料售货机软件进行黑盒测试。该软件的规格说明如下: “有一个处理单价为5角钱的盒装饮料的自动售货机软件。 (1)若投入1元或5角硬币,按下“可乐”或“雪碧”的按钮,则相应的饮料就送出来。 (2)若售货机没有零钱找,则一个显示“零钱找完”的红灯亮,这时在投入1元硬币并押下按钮后,饮料不送出来而且1元硬币也退出来; (3)若有零钱找,则显示“零钱找完”的红灯灭,在送出饮料的同时退还5角硬币。,因果图法,建议组合测试方法: (1) 在任何情况下都应使用边界值分析法,用这种方法设计的用例暴露程序错误能力强。设计用例时,应该既包括输入数据的边界情况又包括输出数据的边界情况。 (2) 必要时用等价类划分方法补充一些测试用例。 (3) 再用错误推测法补充测试用例。 (4) 检查上述测试用例的逻辑覆盖程度, 如未满足所要求的覆盖标准, 再增加例子。 (5) 如果需求说明中含有输入条件的组合情况, 则一开始就可使用因果图法。,黑盒测试,对软件设计的要求: 增加错误识别和处理功能 (防弹功能) 可抽取有共性的错误和处理方法形成单独的模块,软件除了完成该完成的用户要求的处理外,还要有作为一个高质量软件的必要的大量附加代码,它们对保证软件的可用、性、可靠性。,黑盒测试,白盒测试法的前提是可以把程序看成装在一个透明的白盒子里,也就是完全了解程序的结构和处理过程。这种方法按照程序内部的逻辑测试程序,检验程序中的每条通路是否都能按预定要求正确工作。 白盒测试又称为结构测试。 早期的白盒测试把注意力放在流程图的各个判定框,使用不同的逻辑覆盖标准来表达对程序进行测试的详尽程度。随着测试技术的发展,人们越来越重视对程序执行分支路径的考察,并且用程序图代替流程图来设计测试用例。,白盒测试,有选择地执行程序中某些最有代表性的通路是对穷举测试的唯一可行的替代办法。,白盒测试的分类 逻辑覆盖测试:基于流程图的判定框 控制结构测试:基于流程图的分支路径 基本路径测试 条件测试 数据流测试 循环测试 白盒测试的特点 基于流程图的判定框(判定框决定了程序的结构),白盒测试,根据程序的控制结构设计测试用例,原则: 保证模块中每一独立的路径至少执行一次 保证所有判断的每一分支至少执行一次 保证每一循环都在边界条件和一般条件下至少各执行一次 验证所有内部数据结构的有效性,白盒测试,是对一系列测试过程的总称,这组测试过程逐渐进行越来越完整的通路测试。 按测试数据执行(或叫覆盖)程序逻辑的程度可以划分成5个不同的等级,可得到不同的逻辑覆盖测试标准。,逻辑覆盖,逻辑覆盖测试的5种标准,逻辑覆盖,1、语句覆盖 语句覆盖的含义是,选择足够多的测试数据,使被测程序中每个语句至少执行一次。,(1) 先确定仅出现在条件中的变量的取值 (2) 再确定参与运算语句的条件变量值。(由运算语句往需要的条件方向推导出该变量的取值),本例中,首先确定b=0。然后根据条件可选a=2或b框的x1 。 得到测试用例:a=2,b=0,x=4,逻辑覆盖,2、判定覆盖(判整个判定表达式的值) 判定覆盖又叫分支覆盖,它的含义是,不仅每个语句必须至少执行一次,而且每个判定的每个分支都至少执行一次。,(1) 先确定执行的路径(分支) (2) 根据确定的分支条件构造测试用例。一般需要至少2组测试用例,本例中,首先确定测试要覆盖的分支路径sacbd和sabed 。 sacbd: a1,a2且b框的x1条件 测试用例:a=3,b=0,x=1 sabed: b0,a=2或b框的x1条件 测试用例:a=2,b=1,x=3,逻辑覆盖,3、条件覆盖 条件覆盖的含义是,不仅每个语句至少执行一次,而且使判定表达式中的每个条件都取到各种可能的结果。 条件覆盖通常比判定覆盖强。但也有可能相反的情况,即虽然每个条件都取得了不同的结果,判定表达式却始终只取一个值(各条件在条件表达式中还要进行逻辑或关系运算,导致最终表达式值可能始终不变),逻辑覆盖,(1) 先列出各判定节点中各条件的可能取值 (2) 分析各判定节点的条件取值,设计测试用例尽可能包含其可能的情况,本例a判定有 a1, a1, b=0, b0 条件 本例b判定有 a=2, a2, x1, x1 条件,整个判定表达式的各条件分别取值真/假值运算,但各条件的真假值间不做所有组合,测试用例1:a=2, b=0, x=4 测试用例2:a=1, b=1, x=1,逻辑覆盖,4、判定/条件覆盖 它的含义是,选取足够多的测试数据,使得判定表达式中的每个条件都取到各种可能的值,而且每个判定表达式也都取到各种可能的结果。,(1) 先列出各判定节点中各条件的可能取值 (2) 从可能取值中组合出各判定节点的“真”和“假”条件取值,据此设计测试用例,逻辑覆盖,5、条件组合覆盖,条件组合覆盖是更强的逻辑覆盖标准,它要求选取足够多的测试数据,使得每个判定表达式中条件的各种可能组合都至少出现一次。,判定中各条件的所有真假值间做组合,逻辑覆盖,(1) 列出各判定节点中各条件取值的组合 (2) 分析各判定节点中存在的包含及相同的关联条件,进行合并以减少各变量的取值个数 (3) 按简化后的取值组合设计测试用例,本例a判定有 a1, b=0 a1, b0 a1, b=0 a1, b0 本例b判定有 a=2, x1 a=2, x1 a2, x1 a2, x1,测试用例1:a=2, b=0, x=4 测试用例2:a=2, b=1, x=1,测试用例3:a=1, b=0, x=4 测试用例4:a=1, b=1, x=1,逻辑覆盖,基本路径测试是tom mccabe提出的一种白盒测试技术。使用这种技术设计测试用例时,首先计算过程设计结果的结构复杂度,并以该复杂度为指南定义执行路径的基本集合,从该基本集合导出的测试用例可以保证程序中的每条语句至少执行一次,而且每个判定在执行时都将分别取true(真)和false(假)值。,路径测试,程序图(流图) 程序的度量 算法复杂性:研究算法的效率,包括:时间和空间效率 结构复杂性:研究程序的清晰度和非结构化程度 程序图可用于研究程序的结构 程序图仅仅描绘程序的控制流程,它完全不表现对数据的具体操作以及分支或循环的具体条件。,路径测试,程序图是一种简化了的流程图。流程图中的各种框(包括加工框、判断框等)在程序图中都被简化为一个用圆圈表示的节点。用g=表示,n表示节点,e表示有向边,指明程序的流向。 在流图中用圆表示节点,一个圆代表一条或多条语句。程序流程图中的一个处理框序列和一个菱形判定框,可以映射成流图中的一个节点。流图中的箭头线称为边,它和程序流程图中的箭头线类似,代表控制流。在流图中一条边必须终止于一个节点,即使这个节点并不代表任何语句(实际上相当于一个空语句)。由边和节点围成的面积称为区域,当计算区域数时应该包括图外部未被围起来的那个区域。,路径测试,右图把程序流程图映射成程序图 (a)程序流程图;(b)程序图,路径测试,程序图的用途 以简明的方式考察程序的流程,便于对程序结构复杂度进行度量; 在设计测试用例时,便于了解测试数据对被测试程序各种路径的覆盖情况。,路径测试,pdl procedure:sort 1:do while records remain read record; 2: if record field 1=0 3: then process record; store in buffer; incremert counter; 4: else if recardfield2 = 0 5: then reset counter; 6: else process record; store in file; 7a: end if endif 7b:enddo 8:end,左分支-false 右分支-true,应将复合条件 分解为单个简单条件,路径测试,例:把程序过程设计/流程图映射成程序图,环域复杂度 程序的环域复杂度取决于它的程序图所包含的判定节点的数量。每个判定结构联系着一个选择或者循环,这两种结构越多,程序的复杂度就越高。 环域复杂度的计算: mecabe定义一个函数v(g)用于表示程序的结构复杂性,其中g表示被度量的程序图,v表示这个图的环域数。 v(g)=判定节点数+1 (1) =环域数 (2)(程序图周围的不封闭区域也算做一个环域) =nenv+2p (3) ne=有向图中的边数 nv=有向图中的节点数 p=有向图中不连通部分的数目 (程序图连通,p=1),路径测试,环域复杂度的作用 度量程序的测试难度。 环域数越大,测试和排错越难 限制模块的规模 当v(g)=10时,测试非常困难。用v(g)10来限制模块的最大规模。,路径测试,使用基本路径测试技术设计测试用例的步骤如下: 1根据过程设计结果画出相应的程序图 2计算程序图的环域复杂度 3确定线性独立路径的基本集合,路径测试,独立路径: 指至少引入程序的一个新处理语句集合或一个新条件的路径。独立路径至少包含一条在定义该路径之前不曾用过的边。 使用基本路径测试法设计测试用例时,程序的环域复杂度决定了程序中独立路径的数量,而且这个数是确保程序中所有语句至少被执行一次所需的测试数量的上界,路径测试,例:求平均值过程,环域复杂度为6,共有6条独立路径,1:初始化; 2:do while di-999 3: and total.input=min 6: and di 0 11:then ave=sum/total.valid; 12:else ave=-999; 13:endif,左分支-false 右分支-true,路径1:1-2-10-11-13 路径2:1-2-10-12-13 路径3:1-2-3-10-11-13 路径4:1-2-3-4-5-8-9-2- 路径5:1-2-3-4-5-6-8-9-2- 路径6:1-2-3-4-5-6-7-8-9-2- 路径4、5、6后面的省略号(.)表示,可以后接通过控制结构其余部分的任意路径(例如,10-11-13)。 通常在导出测试用例时,识别出判定节点是很有必要的。本例中节点2、3、5、6和10是判定节点。,路径测试,4设计可强制执行每条路径的测试用例 应该选取数据使得在测试每条路径时都适当地设置好了各个判定节点的条件。 测试用例:课后练习,路径测试,用条件测试技术设计出的测试用例,能够检查程序模块中包含的逻辑条件错误。一个简单条件是一个布尔变量或一个关系表达式,在布尔变量或关系表达式之前还可能有一个not(“”)算符。关系表达式的形式如下: e1关系算符e2 其中,e1和e2是算术表达式,而关系算符是下列算符之一:“”,“”,“”,“”,“”或“”。,条件测试,复合条件由两个或多个简单条件、布尔算符和括弧组成。布尔算符有or(“”),and(“&”)和not(“”)。不包含关系表达式的条件称为布尔表达式。 在上述种种条件测试技术的基础上,k.c.tai提出了一种被称为bro(branch and relational operalor)测试的条件测试策略。如果在条件中所有布尔变量和关系算符都只出现一次而且没有公共变量,则bro测试保证能发现该条件中的分支错和关系算符错。,条件测试,bro测试利用条件c的条件约束来设计测试用例。包含n个简单条件的复合条件c的条件约束定义为(d1,d2,dn),其中di(0in)表示条件c中第i个简单条件的输出约束。如果在条件c的一次执行过程中,c中每个简单条件的输出都满足d中对应的约束,则称c的这次执行覆盖了c的条件约束d。,条件测试,对于布尔变量b来说,b的输出约束指出,b必须是真(t)或假(f)。类似地,对于关系表达式来说,用符号,和指定表达式的输出约束。 例1:考虑下列条件 c1:b1&b2 其中,b1和b2是布尔变量。c1的条件约束形式为(d1,d2),其中d1和d2中的每一个都是“t”或“f”。值(t,f)是c1的一个条件约束,并由使b1值为真b2值为假的测试所覆盖。bro测试策略要求,约束集(t,t),(f,t),(t,f)被c1的执行所覆盖。如果c1因布尔算符错误而不正确,则至少上述约束集中的一个约束将迫使c1失败。,条件测试,例2,考虑下列条件 c2:b1 & ( e3 = e4 ) 其中,b1是布尔变量,e3和e4是算术表达式。c2的条件约束形式为(d1,d2),其中d1是“t”或“f”;d2是,=和和),(t,),(f,=),条件测试,数据的“定义-使用”测试 数据流测试方法根据程序中变量定义和使用的位置,选择程序的测试路径。为了说明数据流测试方法,假设已赋予程序每条语句一个唯一的语句号,而且每个函数都不修改它的参数或全局变量。对于语句号为s的语句, def(s)=x语句s包含变量x的定义 use(s)=x语句s使用变量x 如果s是if或循环语句,则它的def集为空,而它的use集取决于s的条件。如果存在从语句s到语句s的路径,而且在该路径中不包含x的任何其他定义,则称变量x在语句s中的定义在语句s仍然有效。,数据流测试,变量x的“定义-使用”链(或称为du链)的形式为x,s,s,其中s和s是语句号,x在集合def(s)和use(s)中,而且在语句s中对x的定义在语句s仍然有效。 一种简单的数据流测试策略要求,每个du链至少被覆盖一次,这种策略称为du测试策略。 该方法对包含嵌套if和循环语句的程序选择测试路径时非常有效。,数据流测试,循环测试是一种白盒测试技术,它专注于测试循环结构的有效性。在结构化的程序中通常只有三种循环,分别是简单循环、串接循环和嵌套循环。 1、简单循环 应该使用下列测试集来测试简单循环,其中n是允许通过循环的最大次数。 跳过循环。 只通过循环一次。 通过循环两次。 通过循环m次,其中mn-1。 通过循环n-1,n,n+1次。,循环测试,2、嵌套循环 b.beizer提出了一种能减少测试数的方法。 从最内层循环开始测试,把所有其他循环都设置为最小值。 对最内层循环使用简单循环测试方法,而使外层循环的迭代参数(例如,循环计数器)取最小值,并为越界值或非法值增加一些额外的测试。 由内向外,对下一个循环进行测试,但保持所有其他外层循环为最小值,其他嵌套循环为“典型”值。继续进行下去,直到测试完所有循环。,数据流测试,3、串接循环 如果串接循环的各个循环都彼此独立,则可以使用前述的测试简单循环的方法来测试串接循环。但是,如果两个循环串接,而且第一个循环的循环计数器值是第二个循环的初始值,则这两个循环并不是独立的。 当循环不独立时,建议使用测试嵌套循环的方法来测试串接循环。,数据流测试,软件测试 是保证软件质量的最后一道工序 是一项细致和充满技巧的工作,应选用优秀的人员来承担此重任。,综上,,软件测试,自己找程序熟悉各种测试用例的设计!,测试用例设计,软件调试是在进行了成功的测试之后才开始的工作。调试的任务是进一步诊断和改正程序中潜在的错误。 调试活动由两部分组成: 确定程序中可疑错误的确切性质和位置 对程序(设计,编码)进行修改,排除该错误 调试工作是一个具有很强技巧性的工作。调试是通过现象,找出原因的一个思维分析的过程。,软件的纠错,调试的步骤 (1)从错误的外部表现形式入手,确定程序中出错位置; (2)研究有关部分的程序,找出错误的内在原因; (3)修改设计的代码,以排除这个错误; (4)重复进行暴露了这个错误的原始测试或某些有关测试。,软件的纠错,从技术角度来看,查找错误的难度在于 现象与原因所处的位置可能相距甚远。 当其它错误得到纠正时,这一错误所表现出的现象可能会暂时消失,但并未实际排除。 现象实际上是由一些非错误原因(例如,舍入不精确)引起的。 现象可能是由于一些不容易发现的人为错误引起的。,软件的纠错,从技术角度来看,查找错误的难度在于 错误是由于时序问题引起的,与处理过程无关。 现象是由于难于精确再现的输入状态(例如,实时应用中输入顺序不确定)引起。 现象可能是周期出现的。在软、硬件结合的嵌入式系统中常常遇到。,软件的纠错,几种主要的调试方法,纠错 策略,试凑法,跟踪法,反向跟踪(回溯法),正向跟踪,推理法,归纳推理 演绎推理,软件的纠错,(1)试凑法(强行排错) 这种调试方法目前使用较多,效率较低。它不需要过多的思考,比较省脑筋。例如: 通过内存全部打印来调试,在这大量的数据中寻找出错的位置。 在程序特定部位设置打印语句,把打印语句插在出错的源程序的各个关键变量改变部位、重要分支部位、子程序调用部位,跟踪程序的执行,监视重要变量的变化。 自动调试工具。利用某些程序语言的调试功能或专门的交互式调试工具,分析程序的动态过程,而不必修改程序。 应用以上任一种方法之前,都应当对错误的征兆进行全面彻底的分析,得出对出错位置及错误性质的推测,再使用一种适当的调试方法来检验推测的正确性。,软件的纠错,(2)回溯/跟踪法调试 这是在小程序中常用的一种有效的调试方法。一旦发现了错误,人们先分析错误征兆,确定最先发现“症状”的位置。然后,人工沿程序的控制流程,向回追踪源程序代码,直到找到错误根源或确定错误产生的范围。 例如,程序中发现错误处是某个打印语句。通过输出值可推断程序在这一点上变量的值。再从这一点出发,回溯程序的执行过程。 反复考虑:“如果程序在这一点上的状态(变量的值)是这样,那么程序在上一点的状态一定是这样.”,直到找到错误的位置。,软件的纠错,(3)归纳法调试 归纳法是一种从特殊推断一般的系统化思考方法。归纳法调试的基本思想是:从一些线索(错误征兆)着手,通过分析它们之间的关系来找出错误。 收集有关的数据,列出所有已知的测试用例和程序执行结果。看哪些输入数据的运行结果是正确的,哪些输入数据的运行结果有错误。,软件的纠错,1)收集和组织数据 由于归纳法是从特殊到一般的推断过程,所以需要组织整理数据,以发现规律。常以3w1h形式组织可用的数据:,软件的纠错,“yes”描述出现错误的现象的3w1h; “no”作为比较,描述了没有错误的现象的3w1h。通过分析找出矛盾来。,2)提出假设 分析线索之间的关系,利用在线索结构中观察到的矛盾现象,设计一个或多个关于出错原因的假设。 如果一个假设也提不出来,归纳过程就需要收集更多的数据。此时,应当再设计与执行一些测试用例,以获得更多的数据。,软件的纠错,3)证明假设 把假设与原始线索或数据进行比较,若它能完全解释一切现象,则假设得到证明;否则,就认为假设不合理,或不完全,或是存在多个错误,以致只能消除部分错误。,软件的纠错,(4)演绎法调试 演绎法是一种从一般原理或前提出发,经过排除和精化的过程来推导出结论的思考方法。 首先根据已有的测试用例,设想及枚举出所有可能出错的原因做为假设; 然后再用原始测试数据或新的测试,从中逐个排除不可能正确的假设; 最后,再用测试数据验证余下的假设确是出错的原因。,软件的纠错,列举所有可能出错原因的假设:把所有可能的错误原因列成表。通过它们,可以组织、分析现有数据。 利用已有的测试数据,排除不正确的假设:仔细分析已有的数据,寻找矛盾,力求排除前一步列出所有原因。如果所有原因都被排除了,则需要补充一些数据(测试用例),以建立新的假设。 改进余下的假设:利用已知的线索,进一步改进余下的假设,使之更具体化,以便可以精确地确定出错位置。 证明余下的假设:做法同归纳法最后一步,软件的纠错,小程序可使用试探法、回溯法,大型程序使用归纳法或演绎法 发现错误的一般方法:固定错误确定错误源改正错误测试修改寻找类似错误,调试方法综述,软件的纠错,在调试方面,许多原则本质上是心理学方面的问题。调试由两部分组成,调试原则也分成两组。 (1)确定错误的性质和位置的原则 用头脑去分析思考与错误征兆有关的信息。 避开死胡同。 只把调试工具当做辅助手段来使用。利用调试工具,可以帮助思考,但不能代替思考。 避免用试探法,最多只能把它当做最后手段。,调试原则,软件的纠错,(2)修改错误的原则 在出现错误的地方,很可能还有别的错误。 修改错误的一个常见失误是只修改了这个错误的征兆或这个错误的表现,而没有修改错误的本身。 当心修正一个错误的同时有可能会引入新的错误。 修改错误的过程将迫使人们暂时回到程序设计阶段。 修改源代码程序,不要改变目标代码。,修改错误后应进行回归测试,软件的纠错,常用的纠错技术 插入打印语句 设置断点 掩蔽部分程序 蛮力纠错技术,注意: 调试完成后应删除多余的打印和注释语句,复原程序。,软件的纠错,软件测试分4个阶段: 单元测试:集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。 集成测试:把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。 确认测试:检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。 系统测试:把已经经过确认的软件纳入实际运行环境中,与其它系统成份组合在一起进行测试。,多模块程序的测试策略,软件测试各阶段,多模块程序的测试策略,程序错误的类型,语法错误 结构性错误:通常与数据或控制流有关 结构异常 结构不全 结构多余 功能性错误:与用户需求不相符合 接口错误 系统错误:系统程序本身有错或对系统使用不当,多模块程序的测试策略,多模块程序的测试策略,多模块程序的测试策略,测试步骤 从过程的观点考虑测试,在软件工程环境中的测试过程,实际上是顺序进行的四个步骤的序列。最开始,着重测试每个单独的模块,以确保它作为一个单元来说功能是正确的。因些,这种测试称为单元测试。单元测试大量使用白盒测试技术,检查模块控制结构中的特定路径,以确保做到完全覆盖并发现最大数量的错误。,接下来,必须把模块装配(即集成)在一起形成完整的软件包。在装配的同时进行测试,因此称为集成测试。集成测试同时解决程序验证和程序构造这两个问题。在集成过程中最常用的是黑盒测试用例设计技术,当然,为了保证覆盖主要的控制路径,也可能使用一定数量的白盒测试。在软件集成完成之后,还需要进行一系列高级测试(确认测试、系统测试)。必须测试在需求分析阶段确定下来的确认标准,确认测试是对软件满足所有功能的、行为的和性能的需求的最终保证。在确认测试过程中仅使用黑盒测试技术。,多模块程序的测试策略,单元测试 单元测试和编码属于软件工程过程的同一个阶段。在编写出源程序代码并通过了编译程序的语法检查之后,可以应用人工测试和计算机测试这样两种类型的测试,完成单元测试工作。这两种类型的测试各有所长,互相补充。 下面分别讨论人工测试和计算机测试的问题。,单元测试,代码审查 人工测试源程序可以由编写者本人非正式地进行,也可以由审查小组正式进行。后者称为代码审查,它是一种非常有效的程序验证技术,对于典型的程序来说,可以查出30%70%的逻辑设计错误和编码错误。 审查小组最好由下述四人组成: 组长,他应该是一个很有能力的程序员,而且没有直接参与这项工程; 程序的设计者; 程序的编写者; 程序的测试者。,单元测试,审查会还有一种形式,称为预排。由一个人扮演“测试者”,其它人扮演“计算机”,模拟计算机运行程序,由此发现和讨论问题。 预排需要事先准备测试用例。 实践表明,对于查找某些类型的错误来说,人工测试比计算机测试更有效;对于其他类型的错误来说则刚好相反。因此,人工测试和计算机测试是互相补充,相辅相成的,缺少其中任何一种方法都会使查找错误的效率降低。,单元测试,单元测试的重点 模块的接口 局部数据结构 重要的执行路径 出错处理路径 影响以上各项的边界条件,单元测试,测试软件 模块并不是一个独立的程序,因此必须为每个单元测试开发驱动程序(驱动模块)和(或)存根程序(“桩模块”)。 通常驱动程序也就是一个“主程序”,它接收测试数据,把这些数据传送给被测试的模块,并且印出有关的结果。 存根程序代替被测试的模块所调用的模块,因此存根程序也可以称为“虚拟子程序”。它使用被它代替的模块的接口,可能做最少量的数据操作,印出对入口的检验或操作结果,并且把控制归还给调用它的模块。,单元测试,集成测试是测试和组装软件的系统化技术,在把模块按照设计要求组装起来的同时进行测试 主要目标:发现与接口有关的问题。 由模块组装成程序时有两种方法 非渐增式测试方法:先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序 渐增式测试:把下一个要测试的模块同已经测试好的那些模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进来测试,集成测试,自顶向下集成 自顶向下的集成(结合)方法是一个日益为人们广泛采用的组装软件的途径。从主控制模块(主程序)开始,沿着软件的控制层次向下移动,从而逐渐把各个模块结合起来。在把附属于(以及最终附属于)主控制模块的那些模块组装到软件结构中去时,或者使用深度优先的策略,或者使用宽度优先的策略。,集成测试,具体过程由下述四个步骤完成: (1)对主控制模块进行测试,测试时用存根程序代替所有直接附属于主控制模块的模块; (2)根据选定的结合策略(深度优先或宽度优先),每次用一个实际模块代换一个存根程序(新结合进来的模块往往又需要新的存根程序); (3)在结合进一个模块的同时进行测试; (4)为了保证加入模块没有引进新的错误,可能需要进行回归测试(即,全部或部分地重复以前做过的测试)。 从第二步开始不断地重复进行上述过程,直到构造起完整的软件结构为止。,集成测试,自底向上集成 自底向上测试从“原子”模块(即在软件结构最低层的模块)开始组装和测试。因为是从底部向上结合模块,总能得到需要的下层模块处理功能,所以不需要存根程序。 用下述步骤可以实现自底向上的结合策略: (1)把低层模块组合成实现某个特定的软件子功能的簇; (2)写一个驱动程序(用于测试的控制程序),协调测试数据的输入和输出; (3)对由模块组成的子功能簇进行测试; (4)去掉驱动程序,沿软件结构自下向上移动,把子功能簇组合起来形成更大的子功能簇。 上述第2步到第4步实质上构成了一个循环。,集成测试,回归测试 每当一个新模块作为集成测试的一部分加进来的时候,软件就发生了变化:建立了新的数据流路径,可能出现了新的i/o操作,激活了新的控制逻辑。这些变化可能使原来工作正常的功能出现问题。在集成测试的范畴中,所谓回归测试是指重新执行已经做过的测试的某个子集,以保证上述这些变化没有带来非预期的副作用。 回归测试集(已执行过的测试用例的子集)包括下述三种不同的测试用例。 检测软件全部功能的代表性测试用例。 专门针对可能受修改影响的软件功能的附加测试。 针对被修改过的软件成分的测试。,集成测试,不同集成测试策略的比较 自顶向下测试方法的主要优点是不需要测试驱动程序,能够在测试阶段的早期实现并验证系统的主要功能,而且能在早期发现上层模块的接口错误。自顶向下测试方法的主要缺点是需要存根程序,可能遇到与此相联系的测试困难,低层关键模块中的错误发现较晚,而且用这种方法在早期不能充分展开人力。可以看出,自底向上测试方法的优缺点与上述自顶向下测试方法的优缺点刚好相反。,集成测试,混合策略 (1)衍变的自顶向下的增殖测试 首先对输入输出模块和引入新算法模块进行测试; 再自底向上组装成为功能相当完整且相对独立的子系统; 然后由主模块开始自顶向下进行增殖测试。 (2)自底向上自顶向下的增殖测试 首先对含读操作的子系统自底向上直至根节点模块进行组装和测试;然后对含写操作的子系统做自顶向下的组装与测

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论