软件测试方法论.ppt

单击此处编辑母版标题样式,,单击此处编辑母版文本样式,,第二级,,第三级,,第四级,,第五级,,,*,软件测试工程师培训,,软件测试方法论,,,1,主要内容,,1 软件测试方法概述,,2 软件测试规范,,3 软件测试用例设计－黑盒测试,,4 软件测试用例设计－白盒测试,,5小结,,,2,,1 软件测试方法概述,,1.1 软件测试活动及信息流,,1.2 测试方法,,1.3 生成测试用例的信息来源,,1.4 小结,,3,,1.1 软件测试活动及信息流,,测试是从大量的测试用例中选择,有限,的测试用例,发现软件中的大部分缺陷,的一种技术,,好的测试用例的4个特性：,,检测软件质量的有效性,，是否能发现缺陷，或至少可能发现缺陷；,,可仿效的测试用例可以测试很多内容，因而,减少测试用例的数量,；,,经济性,，测试用例的执行、分析和调试是否经济,,测试用例的可修改性,，每次软件修改后对测试用例的维护成本,,4,,测试活动,,,5,,测试活动,,1 测试条件取决于被测试验证的项目或事件如等价划分、边界值分析、因果图等测试条件是被测环境的描述，可以用多种方式描述：如简单的语言，表格项形式或类似于流图的图表形式；标识测试条件的活动最好与开发活动（即V模型左边的活动）并行开展,,6,,测试活动,,2 设计测试用例确定“怎样测试”。

测试用例（test case）是按一定顺序执行的与测试目标（test object, 测试理由或目的）相关的一系列测试测试用例设计将产生许多测试所包括的输入值、期望结果及其他任何运行测试的有关信息，如环境要求期望输出包括应输出或建立的内容，应修改或更新或应删除的内容期望输出集可以是一个很大的集合7,,测试活动,,一个测试用例,,8,,测试活动,,3 开发测试用例包括准备测试脚本、测试输入、测试数据以及期望输出测试脚本（test script）是 具有正规语法的数据和指令的集合，在测试执行自动工具使用中，通常以文件形式保存；必须先完成测试用例的先决条件（precondition），然后再执行测试测试用例可能要求专门的硬件或软件，如网络环境或打印机等；期望输出可以组成成文件形式用于自动工具对于手动测试，期望输出仅仅只是简单地记录在手工测试过程或脚本中设置用于自动比较的期望输出比设置用于手工测试的期望输出复杂得多在自动工具中要求每项内容都要拼写正确，而在手工测试中要求没这么严格 测试开发的任何工作可以提前进行（相对V模型左边的活动进行），以后可以节省时间9,,测试活动,,4 执行测试用例 对于手动测试来讲，测试者按事先准备好的手工过程进行测试，测试者输入数据、观察输出、记录发现的问题。

 对于自动测试，可能只需要启动测试工具，并告诉工具执行哪些测试用例； 测试执行只能在软件开发完成后进行，即V模型右边的活动10,,测试活动,,5 将测试结果与期望输出进行比较应该对每次测试的实际输出进行分析研究，判断软件功能是否正确该验证可以是非正的测试者主观判断，也可以是将实际输出与期望输出进行严格准确的比较一些信息比较，如可以在执行测试时进行显示屏幕上的信息，另一些输出比较，如修改数据库记录，只能在测试执行结束后进行自动测试一般结合了这两种方法11,,测试阶段,的信息流,,12,,测试阶段,的信息流,测试阶段的输入信息有两类：,,软件配置：这是测试的对象，包括需求说明书、设计说明书和被测的源程序等测试配置：包括测试计划、测试步骤、测试用例（测试数据），以及具体实施测试的测试程序、测试工具等,,,13,,1.2 测试方法,,静态方法,,动态方法,,黑盒测试,,白盒测试,,14,,静态方法和动态方法,,静态方法的主要特征是在用计算机测试源程序时，计算机并不真正运行被测试的程序，只对被测程序进行特性分析因此，静态方法常称为“分析”，静态分析是对被测程序进行特性分析的一些方法的总称。

动态方法的主要特征是计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况(输入/输出的对应关系)进行分析15,,黑盒测试,,黑盒测试（Black—box Testing）又称功能测试、数据驱动测试或基于规格说明的测试，是一种从用户观点出发的测试用这种方法进行测试时，被测程序被当作一个黑盒，在不考虑程序内部结构和内部特性，测试者只知道该程序输入和输出之间的关系或程序的功能的情况下，依靠能够反映这一关系和程序功能的需求规格说明书考虑确定测试用例和推断测试结果的正确性软件的黑盒测试被用来证实软件功能的正确性和可操作性16,,白盒测试,,白盒测试（White—box Testing）又称结构测试、逻辑驱动测试或基于程序的测试它依赖于对程序细节的严密检验，针对特定条件和/与循环集设计测试用例，对软件的逻辑路经进行测试在程序的不同点检验“程序的状态”以判定其实际情况是否和预期的状态相一致软件的白盒测试用来分析程序的内部结构17,,白盒测试,,白盒测试要求对某些程序的结构特性做到一定程度的覆盖，或者说是“基于覆盖的测试” 最为常见的程序结构覆盖有 ：,,语句覆盖：它要求被测程序的每一可执行语句在测试中尽可能都检验过，这是最弱的逻辑覆盖准则；,,分支覆盖或判定覆盖：要求程序中所有判定的分支尽可能得到检验；,,条件覆盖：当判定式中含有多个条件时，要求每个条件的取值均得到检验；,,判定／条件覆盖：同时考虑条件的组合值及判定结果的检验；,,路径覆盖：只考虑对程序路径的全面检验。

取得测试覆盖的方法——程序插装,,,,18,,白盒测试,,既然黑盒测试是测试软件与需求的一致性，为什么还要白盒测试？,,编程是容易发生逻辑错误和作出不正确的假设,,如对执行路径假设不正确，会产生设计错误，白盒测试能发现这样的错误,,录入错误是随机的,,19,,黑盒测试与白盒测试的比较,,,,,黑 盒 测 试,,,白 盒 测 试,,测 试 规 划,,,根据用户的规格说明，即针对命令、信息、报表等用户界面及体现它们的输入数据与输出数据之间的对应关系，特别是针对功能进行测试根据程序的内部结构，比如语句的控制结构，模块间的控制结构以及内部数据结构等进行测试特点,,优 点,,能站在用户立场上进行测试能够对程序内部的特定部位进行覆盖测试缺 点,,,不能测试程序内部特定部位如果规格说明有误，则无法发现无法检验程序的外部特性无法对未实现规格说明的程序内部欠缺部分进行测试方 法 举 例,,基于图的测试,,等价类划分,,边值分析,,比较测试,,,语句覆盖,,判定覆盖,,条件覆盖,,判定/条件覆盖,,基本路径覆盖,,循环覆盖,,模块接口测试,,,20,,测试阶段与测试方法,,测试阶段,目的,执行者,测试方法,单元测试,查找独立模块中逻辑错误、数据错误和算法错误,软件工程师,白盒测试,集成测试,查找模块之间接口错误,软件工程师,,测试人员,白盒测试、自顶向下或,自底向上,确认测试,,确认软件是否满足软件需求,测试人员,黑盒测试,,模拟用户操作,系统测试,对系统中各个组成部分进行综合性检验,测试人员,黑盒测试,,模拟用户操作,回归测试,确认软件变更后是否仍满足软件需求,测试人员,黑盒测试,,模拟用户操作,α测试与β测试,,用户,黑盒测试,,模拟用户操作,验收测试,确认软件是否满足用户需求,用户、项目组,,测试人员,黑盒测试,,模拟用户操作,,21,,1.3测试信息来源,,基于软件规约生成测试用例,,基于软件设计生成测试用例,,基于程序生存测试用例,,22,,1.4小结,,软件测试主要工作就是确定合适的测试用例；,,测试过程贯穿在整个软件开发活动中；,,测试方法： 动态、静态、黑盒、白盒等,,,23,,2软件测试用例设计－黑盒测试,2.0 概述,,2.1 等价类划分,,2.2 因果图,,2.3 边值分析,,2.4 判定表驱动测试,,2.5 正交实验设计法,,2.6 自动测试用例生成方法,,2.7 小结,,,24,,2.0 概述,这种方法是把,测试对象,看做,一个黑盒子,，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。

黑盒测试又叫做,功能测试,或,数据驱动测试,25,,黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误:,,,是否有不正确或遗漏了的功能,?,,在接口上，,输入能否正确地接受,?,能否输出正确的结果,?,,,是否有数据结构错误或外部信息,(例如数据文件),访问错误,?,,,性能上是否能够满足要求,?,,,是否有初始化或终止性错误,?,黑盒测试目标,,26,,用黑盒测试发现程序中的错误，必须在,所有可能的输入条件和输出条件,中确定测试数据，来检查程序是否都能产生正确的输出但这是,不可能,的27,,假设一个,程序,P,有,输入量,X,和,Y,及,输出量,Z,在字长为32位的计算机上运行若,X,、,Y,取整数，按黑盒方法进行穷举测试：,,可能采用的,,测试数据组：,,2,32,×,2,32,,,＝,2,64,,,如果测试一,,组数据需要1毫秒，一年工作,365,×,,24,小时，完成所有测试,需5亿年28,,2.1 测试用例设计方法－,等价类划分,选取测试用例,,等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例在分析需求规格说明的基础上划分等价类，列出等价类表。

29,,2.1.1 等价类,,所谓等价类是指某个输入域的集合它表示，如果用集合中的一个输入条件作为测试数据进行测试不能发现程序中的错误，那么使用集合中的其它输入条件进行测试也不可能发现错误也就是说，对揭露程序中的错误来说，集合中的每个输入条件是等效的30,,有效等价类和无效等价类,,在考虑等价类时，应该注意区别两种不同的情况：,,*有效等价类：有效等价类指的是对程序的规格说明是有意义的、合理的输入数据所构成的集合在具体问题中，有效等价类可以有一个，也可以是多个无效等价类：无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合对于具体的问题，无效等价类至少应有一个，也可能有多个31,,等价类,,输入条件 有效等价类 无效等价类,,输入条件：…项数可以从1到999…,,有效等价类为,“,1〈项数〈999,”,,,无效等价类为,“,项数<1,”,及,“,项数>999,”,,,,,32,,2.1.2 经典例子,,“,输入三个整数作为三边的边长构成三角形当此三角形为一般三角形、等腰三角形及等边三角形时，分别做计算…”,,注意输入和输出条件,,33,,有效等价类,,覆盖有效等价类的测试用例：,,a b c 覆盖等价类号码,,3 4 5 （1）--（7）,,4 4 5 （1）--（7），（8）,,4 5 5 （1）--（7），（9）,,5 4 5 （1）--（7），（10）,,4 4 4 （1）--（7），（11）,,34,,无效等价类,,,35,,2. 1.3 问题讨论,,问题：给出下面的有效和无效等价类,,输入条件：,“,…统计全国各省、市、自治区的人口…”,,输入条件：,“,标识符应以字母开头…,”,,,输入条件：长度为1-20的字符串,,输入条件：数据库中的值域, CHAR(20), NOT NULL,,36,,2. 2 测试方法－,因果图,采用因果图方法（Cause一Effect Graphics）能够帮助我们按一定步骤，高效率地选择测试用例，同时还能为我们指出，程序规格说明描述中存在着什么问题。

37,,2. 2.1,因果图,介绍,,,4种符号分别表示了规格说明中向4种因果关系,,,因果图中使用了简单的逻辑符号，以直线联接左右结点左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现38,,关系,,①恒等：若ci是1，则ei也是1；否则ei为0②非：若ci是1，则ei是0；否则ei是1③或：若c1或c2或c3是1，则ei是1；否则ei为0或,”,可有任意个输入④与：若c1和c2都是1，则ei为1；否则ei为0与,”,也可有任意个输入39,,约束,,输入状态相互之间还可能存在某些依赖关系,,,某些输入条件本身不可能同时出现输出状态之间也往往存在约束,,,40,,输入条件约束类型,,对于输入条件的约束有以下4类：,,① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0③ O约束（唯一）；a和b必须有一个，且仅有1个为1④R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。

41,,输出条件约束类型,,输出条件的约束只有：,,M约束（强制）：若结果a是1，则结果b强制为042,,2.,2.2 步骤,,①分析程序规格说明的描述中，哪些是原因，哪些是结果原因常常是输入条件或是输入条件的等价类而结果是输出条件②分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的,“,因果图,”,43,,步骤,③由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的为表明这些特定的情况，在因果图上使用若干个特殊的符号标明约束条件④把因果图转换成判定表⑤把判定表中每一列表示的情况写成测试用例44,,2. 2.3 例子,,软件规格说明书,,,“,第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改但如果第一列字符不正确，则给出信息L，如果第二列字符不是数字，则给出信息M45,,原因和结果,,原因：,,1,——,第一列字符是A；,,2,——,第一列字符是B；,,3,——,第二列字符是一数字结果：,,21,——,修改文件；,,22,——,给出信息L；,,23,——,给出信息M46,,因果图和,具有约束的因果图,,11为中间节点；,,考虑到原因1和原因2不可能同时为1，因此在因果图上施加E约束。

47,,判定表,,根据因果图建立如下的判定表,,表中8种情况的左面两列情况中，原因①和原因②同时为1，这是不可能出现的，故应排除这两种情况表的最下一栏给出了6种情况的测试用例，这是我们所需要的数据48,,2. 2.4 讨论,,在较为复杂的问题中，这个方法常常是十分有效的，它能有力地帮助我们确定测试用例,,,如果哪个开发项目在设计阶段就采用了判定表，也就不必再画因果图，而是可以直接利用判定表设计测试用例了,49,,2. 3 测试用例设计方法－,边值分析,在软件设计和程序编写中，常常对于规格说明中的输入域边界或输出域边界不够注意，以致形成一些差错实践证明，在设计测试用例时，对边界附近的处理必须给予足够的重视，为检验边界附近的处理专门设计测试用例，常常取得良好的测试效果50,,2.,2.1 边值分析遵循的原则,,①,如果输入条件规定了取值范围，或是规定了值的个数，应以该范围的边界内及刚刚超出范围的边界外的值，或是分别对最大、最小个数及稍小于最小、稍大于最大个数作为测试用例例如，如果程序的规格说明中规定：,“,重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……”作为测试用例，我们应取10及50，还应取10.01,49.99,9.99及50.01等。

如果另一问题规格说明规定：,“,某输入文件可包含1至255个记录，,……”,，则测试用例可取1和255，还应取0及256等51,,遵循以下几条原则,②针对规格说明的每个输出条件使用前面的第（1）条原则例如，某程序的规格说明要求计算出“每月保险金扣除额为0至1165．25元”，其测试用例可取0．00及1165．2、还可取一0．01及1165．26等如果另一程序属于情报检索系统，要求每次”最多显示1条情报摘要”，这时我们应考虑的测试用例包括1和4，还应包括0和5等52,,遵循以下几条原则,③如果程序规格说明中提到的输入或输出域是个有序的集合（如顺序文件、表格等），就应注意选取有序集的第一个和最后一个元素作为测试用例④分析规格说明，找出其它的可能边界条件53,,2.,2.2,例子,某一为学生考试试卷评分和成绩统计的程序，其规格说明指出了对程序的要求：,,程序的输入文件由80个字符的一些记录组成，这些记录分为三组：,,① 标题,,这一组只有一个记录，其内容为输出报告的名字②试卷各题标准答案记录,,每个记录均在第80个字符处标以数字,“,2,”,该组的第一个记录的第1至第3个字符为题目编号（取值为1一999）。

第10至第59个字符给出第1至第50题的答案（每个合法字符表示一个答案）该组的第2，第3……个记录相应为第51至第100，第101至第150，…题的答案③每个学生的答卷描述,,该组中每个记录的第80个字符均为数字,“,3,”,每个学生的答卷在若干个记录中给出如甲的首记录第1至第9字符给出学生姓名及学号，第10至第59字符列出的是甲所做的第1至第50题的答案若试题数超过50，则第2，第3……纪录分别给出他的第51至第100，第101至第150……题的解答然后是学生乙的答卷记录若学生最多为200人，输入数据的形式如图415所示54,,,学生考卷评分和成绩统计程序输入数据的形式,,,55,,,该程序应给出4个输出报告，即：,,①按学生学号排序，每个学生的成绩（答对的百分比）和等级报告②按学生得分排序，每个学生的成绩③平均分数，最高与最低分之差④按题号排序，每题学生答对的百分比56,,,,,57,,2.,4 判定表驱动测试,,在一些数据处理问题中，某些操作是否实施依赖于多个逻辑条件的取值也即在这些逻辑条件取值的组合所构成的多种情况下，分别执行不同的操作处理这类问题的一个非常有力的分析和表达工具是判定表（Decision Table）。

58,,2. 3.1 例子1,,一张关于科技书阅读指南的判定驱动表：3个问题8种情况,,59,,判定表组成,,条件桩（Condition Stub）,,动作桩（Action Stub）,,条件项（Condition Entity）,,动作项（Action Entity）,,60,,规则及规则合并,,任何一个条件组合的特定取值及其相应要执行的操作称为规则在判定表中贯穿条件项和动作项的一列就是一条规则显然，判定表中列出多少组条件取值，也就有多少条规则，即条件项和动作项有多少列化简,就是规则合并,有两条或多条规则,,具有相同的动作，,,并且其条件项之间,,存在着极为相似的关系,,两条规则合并成一条 两条规则的进一步合并,,61,,一个规则合并的例子,,一个规则合并的例子,,62,,2. 3.2 例子2,,问题要求：”……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器，应给予优先的维修处理……”,,,假定，“维修记录不全”和“优先维修处理”均已在别处有更严格的定义,,,按5步建立判定表,,,63,,建立判定表的步骤,,①确定规则的个数这里有3个条件，每个条件有两个取值，故应有2*2*2=8种规则。

②列出所有的条件茬和动作茬③填人条件项为防止遗漏可从最后1行条件项开始，逐行向上填满乙如第三行是： Y N Y N Y N Y N第二行是： Y Y N N Y Y N N,等等64,,建立判定表的步骤,,④填人动作桩和动作顶这样便得到形如图的初始判定表65,,建立判定表的步骤,,⑤化简合并相似规则后得到图66,,2.,3.3 判定表在功能测试中的应用,,一软件规格说明,,(1)当条件1和条件2满足，并且条件3和条件4不满足，或者当条件1、3和条件4满足时，要执行操作12)在任一个条件都不满足时，要执行操作23)在条件1不满足，而条件4被满足时，要执行操作367,,规则,,只给出了16种规则中的4种,,根据规格说明得到的判定表,默许的规则,,,68,,2.3.4 判定表的优点和缺点,,优点：它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏缺点：不能表达重复执行的动作，例如循环结构其他？？,,69,,使用判定表设计测试用例的Beizer条件,①规格说明以判定表形式给出，或是很容易转换成判定表②条件的排列顺序不会也不应影响执行哪些操作。

③规则的排列顺序不会也不应影响执行哪些操作④每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则⑤如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合其实对于某些不满足这几条的判定表，同样可以借以设计测试用例，只不过尚需增加其它的测试用例罢了70,,2.5正交实验设计法,,把软件功能测试作为实验的一种，从大量的实验点中选出适量有代表性的点，应用依据伽罗瓦理论导出的“正交表”，合理安排实验的一种科学的实验设计方法从规约中找出影响其功能实现的操作对象和外部因素作为因子，因子的取值作为状态，构造因素分析表，利用正交表进行各因子的专题组合，构造有效的测试数据集，并由此建立因果图71,,2.6 自动测试用例设计,,一些测试工具可以进行部分测试用例自动化，“测试输入生成工具”，该方法也可以用于某些场合，但自动工具不可能完全替代智力的测试活动；,,自动方式可以生成大量的测试用例，但他不区分哪些测试是最重要的这些要求有创造力的智力活动只能由测试人员完成所有测试生成工具依赖于生成测试的算法，工具比使用相同算法的测试人员的测试更彻底、更精确，但人工测试时可以考虑附加测试。

72,,三种测试输入生成工具,,基于代码测试输入生成,,基于界面测试生成,,基于规格说明测试生成,,73,,基于代码测试输入生成,,通过检测软件代码结构生成测试输入通过代码的路径由判断点确定的段组成自动生成每个路径段逻辑覆盖条件的轮廓文件与覆盖工具一起使用较好只产生测试输入，还需要对测试输出进行比较，不能判断软件产生的输出是否正确，只是说明代码应该做什么也不能发现丢失的代码,,另一种方法：可以生成满足较小变化测试准则的测试变化测试（Mutation test）是指代码或输入做较小的改变，检测系统是否可以正确地处理或测试稍微改变的版本该方法可以检查系统的容错能力和测试套件的充分性74,,基于界面测试生成,,用于某些定义好的界面如GUI或Web应用生成测试如果屏幕含有各种菜单、按钮及检查框，则工具生成访问每个控件的测试事例还可以测试Internet和Intranet页面工具可激活WWW页面的每个链接，然后对每页做相同的测试；该方法对于发现某类缺陷是有效的，可以部分生成期望输出，即连接存在或断开状况，但不能判断连接是否在正确的位置；,,该方法可以执行部分测试事例设计活动，产生测试输出，对于检测“roll-call”即某个东西确实在某处确实有用。

手工测试非常枯燥，应该采用自动测试75,,基于规格说明测试生成,,在规格说明形式化并可被工具分析的前提下，基于规格说明测试工具可以生成测试输入及期望结果；如果面向对象规格说明足够严格的话，这种工具还可以进行面向对象规格说明的测试例如，如果一个输入域的允许范围被严格定义，那么工具可以产生边界值以及有效等价类和无效等价类的样值某些基于规格说明的工具可以进行结构化的英文规格说明或因果图的测试，可以发现一些规格说明的缺陷，如规格说明含混或冗长,,好处是检查软件应该做什么，而不是软件做了什么从规格说明中推导测试用例越枯燥，则这类工具的潜力就越大76,,自动测试用例生成的优点,,自动化测试用例生成用于设计的繁琐部分，如激活每个菜单项或者从已知的数据范围计算边界值；,,可以生成针对源程序的一套完成的测试用例（代码、界面和规格说明）,,可以发现某种类型的缺陷，如丢失连接，非工作窗口项或者不符合规格说明的软件；,,77,,自动测试用例生成的限制,,基于代码方法不能生成期望输出,,基于界面方法只能产生部分期望输出,,基于代码和基于界面方法不能发现规格说明的缺陷；,,基于规格说明的方法依赖于规格说明的质量；,,所有的方法可以产生大量的测试，而实际操作起来比较困难；,,测试前仍需要专家判断产生的测试的必要性，并考虑任何工具都无法产生的测试；,,78,,2.7小结,,理解和熟练使用4种进行测试用例设计的方法：等价类划分、因果图、边值分析、判定表驱动；,,自动测试用例设计的原理和方法，,,79,,4、 软件测试用例设计－白盒测试,3.0 概述,,3.1 程序结构分析,,3.2 逻辑覆盖,,3.3 路径分析,,3.4 域测试,,3.5 程序插装,,3.6 程序变异,,3.7 小结,,,80,,,3.0 概述,此方法,把测试对象看做一个透明的盒子,，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。

通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致因此白盒测试又称为结构测试或逻辑驱动测试81,,软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：,,对程序模块的,所有独立的执行路径,至少测试一次；,,对,所有的逻辑判定,，,取“,真,”与取“,假,”的两种情况都至少测试一次,；,,在循环的边界和运行界限内执行循环体；,,测试,内部数据结构的有效性,，等82,,对一个具有,多重选择和循环嵌套,的程序，,不同的路径数目可能是天文数字,给出一个小程序的流程图，它包括了一个执行,20,次的循环包含的不同执行路径数达,5,20,条，对每一条路径进行测试需要1毫秒，假定一年工作,365,×,24,小时，要想把所有路径测试完，需3170年83,,,84,,3.1程序结构分析－基本路径测试,基本路径测试方法把覆盖的路径数压缩到一定限度内，,程序中的循环体最多只执行一次,它是在程序控制流图的基础上，,分析控制构造的环路复杂性,，,导出基本可执行路径集合,，,设计测试用例的,方法设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次85,,3.1.1. 程序的控制流图,符号,○,为控制流图的一个结点，表示一个或多个无分支的,PDL,语句或源程序语句。

箭头为边，表示控制流的方向86,,在选择或多分支结构中，分支的汇聚处应有一个汇聚结点边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域如果判断中的条件表达式是由一个或多个逻辑运算符,(OR, AND, NAND, NOR),,连接的复合条件表达式，则需要改为一系列,只有单条件的嵌套的判断,87,,,,,88,,,89,,3.1.2. 程序环路复杂性,程序的环路复杂性给出了,程序基本路径集中的独立路径条数,，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界从控制流图来看，一条独立路径是至少包含有一条在其它独立路径中从未有过的边的路径90,,例如，在图示的控制流图中，一组独立的路径是,path1：1 - 11path2：1 - 2 - 3 - 4 - 5 - 10 - 1 - 11path3：1 - 2 - 3 - 6 - 8 - 9 - 10 - 1 - 11path4：1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11,,路径 path1，path2，path3，path4组成了控制流图的一个基本路径集91,,3.1.2. 导出测试用例,导出测试用例，,确保基本路径集中的每一条路径的执行,。

根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到 —,用逻辑覆盖方法,92,,每个,测试用例执行之后,，,与预期结果进行比较,如果所有测试用例都执行完毕，则可以确信程序中所有的可执行语句至少被执行了一次必须注意，一些独立的路径,(如例中的路径1)，,往往不是完全孤立的，有时它是程序正常的控制流的一部分，这时，这些路径的测试可以是另一条路径测试的一部分93,,3.2 逻辑覆盖,,语句覆盖,,,判定覆盖,,,条件覆盖,,,判定－条件覆盖,,,条件组合覆盖,,,路径覆盖,逻辑覆盖是以,程序内部的逻辑结构为基础,的设计测试用例的技术它属白盒测试94,,,95,,,96,,,97,,,98,,,99,,3.2.1语句覆盖,,语句覆盖就是设计若干个测试用例，运行被测程序，使得,每一可执行语句至少执行一次,在图例中，正好所有的可执行语句都在,路径L1,上，所以选择,路径 L1,设计测试用例，就可以覆盖所有的可执行语句100,,测试用例的设计格式如下【输入的,(,A,,,B,,,X,)，,输出的,(,A,,,B,,,X,),】,,为图例设计满足,语句覆盖,的测试用例是:,【(2, 0, 4)，(2, 0, 3)】,,,覆盖 ace【L1】,,101,,3.2.2判定覆盖,判定覆盖就是设计若干个测试用例，运行被测程序，使得,程序中每个判断的取真分支和取假分支至少经历一次,。

判定覆盖又称为,分支覆盖,对于图例，如果选择,路径L1,和,L2,，就可得满足要求的测试用例:,,102,,【(2, 0, 4)，(2, 0, 3)】,覆盖 ace【L1】,【(1, 1, 1)，(1, 1, 1)】,覆盖 abd【L2】,,103,,如果选择路径L3和L4，还可得另一组可用的测试用例:,【(2, 1, 1)，(2, 1, 2)】,覆盖 abe【L3】,【(3, 0, 3)，(3, 1, 1)】,覆盖 acd【L4】,,104,,3.2.3条件覆盖,条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中,每个判断的每个条件的可能取值至少执行一次,在图例中，我们事先可对所有条件的取值加以标记例如，,,对于第一个判断：,,条件,A＞1,取真为 ，取假为 条件,B＝0,取真为 ，取假为,,105,,对于第二个判断：,,条件,A＝2,取真为 ，取假为 条件,X＞1,取真为 ，取假为,,,测试用例,,覆盖分支,,条件取值,,【(2, 0, 4)，(2, 0, 3)】,L1(c, e),,,【(1, 0, 1)，(1, 0, 1)】,L2(b, d),,【(2, 1, 1)，(2, 1, 2)】,L3(b, e),,,106,,,或,,,测 试 用 例,,覆盖分支,,条件取值,,【(1, 0, 3)，(1, 0, 4)】,L3(b, e),,【(2, 1, 1)，(2, 1, 2)】,L3(b, e),,,,,107,,3.2.4判定－条件覆盖,判定－条件覆盖就是设计足够的测试用例，使得,判断中每个条件的所有可能取值至少执行一次,，同时,每个判断中的每个条件的可能取值至少执行一次,。

108,,,测 试 用 例,,覆盖分支,,条件取值,,【(2, 0, 4)，(2, 0, 3)】,L1(c, e),,【(1, 1, 1)，(1, 1, 1)】,L2(b, d),,109,,,and,or,,110,,条件组合覆盖,条件组合覆盖就是设计足够的测试用例，运行被测程序，使得,每个判断的所有可能的条件取值组合至少执行一次,记 ① A＞1, B＝0 作  ② A＞1, B≠0 作  ③ A≯1, B＝0 作,,④ A≯1, B≠0 作,,111,,,⑤ A＝2, X＞1 作 ⑥ A＝2, X≯1 作 ⑦ A≠2, X＞1 作 ⑧ A≠2, X≯1 作,,,112,,,测 试 用 例,,覆盖条件,,覆盖组合,,【(2, 0, 4), (2, 0, 3)】,(L1),①, ⑤,,【(2, 1, 1), (2, 1, 2)】,(L3),②, ⑥,,【(1, 0, 3), (1, 0, 4)】,(L3),③, ⑦,,【(1, 1, 1), (1, 1, 1)】,(L2),④, ⑧,,113,,3.3 路径测试,路径测试就是设计足够的测试用例，,覆盖程序中所有可能的路径,。

测 试 用 例,,通过路径,,覆盖条件,,【(2, 0, 4), (2, 0, 3)】,ace (L1),,,【(1, 1, 1), (1, 1, 1)】,abd,,(L2),,,【(1, 1, 2), (1, 1, 3)】,abe,,(L3),,,【(3, 0, 3), (3, 0, 1)】,acd,,(L4),,,,,,,114,,,3.2.1条件测试路径选择,当程序中判定多于一个时，形成的分支结构可以分为两类：,嵌套型分支结构,和,连锁型分支结构,对于,嵌套型分支结构,，若有,n,个判定语句，需要,n,+1,个测试用例；,,对于,连锁型分支结构,， 若有,n,个判定语句，需要有,2,n,个测试用例，覆盖它的,2,n,条路径当,n,较大时将无法测试115,,,116,,3.2.2循环测试路径选择,循环分为4种不同类型：,,简单循环,,连锁循环,,嵌套循环,,非结构循环,117,,,118,,(1),简单循环,①,零次循环,：从循环入口到出口 ②,一次循环,：检查循环初始值 ③,二次循环,：检查多次循环 ④,m,次循环： 检查在多次循环 ⑤ 最大次数循环、比最大次数多一次、少一次的循环。

119,,(2),,嵌套循环,① 对最内层循环做简单循环的全部测试所有其它层的循环变量置为最小值；,,② 逐步外推，对其外面一层循环进行测试测试时保持所有外层循环的循环变量取最小值，所有其它嵌套内层循环的循环变量取“典型”值③ 反复进行，直到所有各层循环测试完毕④ 对全部各层循环同时取最小循环次数，或者同时取最大循环次数,,,120,,如果各个循环,互相独立,，则可以用与简单循环相同的方法进行测试但如果几个循环不,是互相独立,的，则需要使用测试嵌套循环的办法来处理3）连锁循环,,,121,,(4),非结构循环,这一类循环应该使用结构化程序设计方法重新设计测试用例122,,3.4 域测试,,基于程序结构的测试方法,,针对域错误，对输入空间进行分析，选择适当的测试点，检验输入空间中的每个输入是否产生正确的结果假设限制过多，难以运用到实际中123,,3.5 符号测试,,另辟途径解决测试用例选择问题基于代数运算执行测试，是测试和验证的折衷方法,,124,,3.6 程序插装,,借助往被测程序中插入操作来实现测试目的的方法125,,3.7 程序变异,,是一种错误驱动测试，针对某类特定程序错误实现测试。

程序强变异,,程序弱变异,,126,,3.8 小结,,白盒测试方法分类,,基本路径测试,,逻辑覆盖测试,,路径测试,,,127,,专题,小结,软件测试用例设计－黑盒测试测试的关键就是确定正确的测试用例本部分详细介绍几种软件测试用例设计方法：,等价类划分,、,因果图,、,边值分析,、,判定表驱动测试,和测试用例自动生成原理和方法128,,专题,小结,软件测试用例设计－白盒测试,,程序结构分析,,逻辑覆盖测试,,路径,,129,,专题,小结,学习要求：,,理解软件开发过程中每一阶段的软件测试方法，理解他们的作用和意义能够根据问题选择正确的软件测试方法,,熟练掌握软件测试用例的设计方法，将设计得到的测试用例编到软件测试用例表中，根据软件测试用例表进行软件测试、填写软件测试记录结合实际的测试用例设计过程，理解自动测试用例的原理和方法130,,专题,小结,训练：,,测试用例的设计,,编制软件测试用例表，进行软件测试,,131,,谢谢!,,,132,。