软件测试方法论

1,软件测试工程师培训,软件测试方法论,2,主要内容,1软件测试方法概述2软件测试规范3软件测试用例设计黑盒测试4软件测试用例设计白盒测试5小结,3,1软件测试方法概述,1.1软件测试活动及信息流1.2测试方法1.3生成测试用例的信息来源1.4小结,4,1.1软件测试活动及信息流,测试是从大量的测试用例中选择有限的测试用例发现软件中的大部分缺陷的一种技术好的测试用例的4个特性：检测软件质量的有效性，是否能发现缺陷，或至少可能发现缺陷；可仿效的测试用例可以测试很多内容，因而减少测试用例的数量；经济性，测试用例的执行、分析和调试是否经济测试用例的可修改性，每次软件修改后对测试用例的维护成本,5,测试活动,6,测试活动,1测试条件取决于被测试验证的项目或事件。如等价划分、边界值分析、因果图等。测试条件是被测环境的描述，可以用多种方式描述：如简单的语言，表格项形式或类似于流图的图表形式；标识测试条件的活动最好与开发活动（即V模型左边的活动）并行开展,7,测试活动,2设计测试用例确定“怎样测试”。测试用例（testcase）是按一定顺序执行的与测试目标（testobject,测试理由或目的）相关的一系列测试。测试用例设计将产生许多测试所包括的输入值、期望结果及其他任何运行测试的有关信息，如环境要求。期望输出包括应输出或建立的内容，应修改或更新或应删除的内容。期望输出集可以是一个很大的集合。,8,测试活动,一个测试用例,9,测试活动,3开发测试用例包括准备测试脚本、测试输入、测试数据以及期望输出。测试脚本（testscript）是具有正规语法的数据和指令的集合，在测试执行自动工具使用中，通常以文件形式保存；必须先完成测试用例的先决条件（precondition），然后再执行测试。测试用例可能要求专门的硬件或软件，如网络环境或打印机等；期望输出可以组成成文件形式用于自动工具。对于手动测试，期望输出仅仅只是简单地记录在手工测试过程或脚本中。设置用于自动比较的期望输出比设置用于手工测试的期望输出复杂得多。在自动工具中要求每项内容都要拼写正确，而在手工测试中要求没这么严格。测试开发的任何工作可以提前进行（相对V模型左边的活动进行），以后可以节省时间。,10,测试活动,4执行测试用例对于手动测试来讲，测试者按事先准备好的手工过程进行测试，测试者输入数据、观察输出、记录发现的问题。对于自动测试，可能只需要启动测试工具，并告诉工具执行哪些测试用例；测试执行只能在软件开发完成后进行，即V模型右边的活动。,11,测试活动,5将测试结果与期望输出进行比较应该对每次测试的实际输出进行分析研究，判断软件功能是否正确。该验证可以是非正的测试者主观判断，也可以是将实际输出与期望输出进行严格准确的比较。一些信息比较，如可以在执行测试时进行显示屏幕上的信息，另一些输出比较，如修改数据库记录，只能在测试执行结束后进行。自动测试一般结合了这两种方法。,12,测试阶段的信息流,13,测试阶段的信息流,测试阶段的输入信息有两类：软件配置：这是测试的对象，包括需求说明书、设计说明书和被测的源程序等。测试配置：包括测试计划、测试步骤、测试用例（测试数据），以及具体实施测试的测试程序、测试工具等,14,1.2测试方法,静态方法动态方法黑盒测试白盒测试,15,静态方法和动态方法,静态方法的主要特征是在用计算机测试源程序时，计算机并不真正运行被测试的程序，只对被测程序进行特性分析。因此，静态方法常称为“分析”，静态分析是对被测程序进行特性分析的一些方法的总称。动态方法的主要特征是计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况(输入/输出的对应关系)进行分析。,16,黑盒测试,黑盒测试（BlackboxTesting）又称功能测试、数据驱动测试或基于规格说明的测试，是一种从用户观点出发的测试。用这种方法进行测试时，被测程序被当作一个黑盒，在不考虑程序内部结构和内部特性，测试者只知道该程序输入和输出之间的关系或程序的功能的情况下，依靠能够反映这一关系和程序功能的需求规格说明书考虑确定测试用例和推断测试结果的正确性。软件的黑盒测试被用来证实软件功能的正确性和可操作性。,17,白盒测试,白盒测试（WhiteboxTesting）又称结构测试、逻辑驱动测试或基于程序的测试。它依赖于对程序细节的严密检验，针对特定条件和/与循环集设计测试用例，对软件的逻辑路经进行测试。在程序的不同点检验“程序的状态”以判定其实际情况是否和预期的状态相一致。软件的白盒测试用来分析程序的内部结构。,18,白盒测试,白盒测试要求对某些程序的结构特性做到一定程度的覆盖，或者说是“基于覆盖的测试”。最为常见的程序结构覆盖有：语句覆盖：它要求被测程序的每一可执行语句在测试中尽可能都检验过，这是最弱的逻辑覆盖准则；分支覆盖或判定覆盖：要求程序中所有判定的分支尽可能得到检验；条件覆盖：当判定式中含有多个条件时，要求每个条件的取值均得到检验；判定条件覆盖：同时考虑条件的组合值及判定结果的检验；路径覆盖：只考虑对程序路径的全面检验。取得测试覆盖的方法程序插装,19,白盒测试,既然黑盒测试是测试软件与需求的一致性，为什么还要白盒测试？编程是容易发生逻辑错误和作出不正确的假设如对执行路径假设不正确，会产生设计错误，白盒测试能发现这样的错误录入错误是随机的,20,黑盒测试与白盒测试的比较,21,测试阶段与测试方法,22,1.3测试信息来源,基于软件规约生成测试用例基于软件设计生成测试用例基于程序生存测试用例,23,1.4小结,软件测试主要工作就是确定合适的测试用例；测试过程贯穿在整个软件开发活动中；测试方法：动态、静态、黑盒、白盒等,24,2软件测试用例设计黑盒测试,2.0概述2.1等价类划分2.2因果图2.3边值分析2.4判定表驱动测试2.5正交实验设计法2.6自动测试用例生成方法2.7小结,25,2.0概述,这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能测试或数据驱动测试。,26,黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误:是否有不正确或遗漏了的功能?在接口上，输入能否正确地接受?能否输出正确的结果?是否有数据结构错误或外部信息(例如数据文件)访问错误?性能上是否能够满足要求?是否有初始化或终止性错误?,黑盒测试目标,27,用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。但这是不可能的。,28,假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：可能采用的测试数据组：232232264如果测试一组数据需要1毫秒，一年工作36524小时，完成所有测试需5亿年。,29,2.1测试用例设计方法等价类划分,选取测试用例等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。在分析需求规格说明的基础上划分等价类，列出等价类表。,30,2.1.1等价类,所谓等价类是指某个输入域的集合。它表示，如果用集合中的一个输入条件作为测试数据进行测试不能发现程序中的错误，那么使用集合中的其它输入条件进行测试也不可能发现错误。也就是说，对揭露程序中的错误来说，集合中的每个输入条件是等效的。,31,有效等价类和无效等价类,在考虑等价类时，应该注意区别两种不同的情况：*有效等价类：有效等价类指的是对程序的规格说明是有意义的、合理的输入数据所构成的集合。在具体问题中，有效等价类可以有一个，也可以是多个。*无效等价类：无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。,32,等价类,输入条件有效等价类无效等价类输入条件：项数可以从1到999有效等价类为“1项数999”无效等价类为“项数999”,33,2.1.2经典例子,“输入三个整数作为三边的边长构成三角形。当此三角形为一般三角形、等腰三角形及等边三角形时，分别做计算”注意输入和输出条件,34,有效等价类,覆盖有效等价类的测试用例：abc覆盖等价类号码345（1）-（7）445（1）-（7），（8）455（1）-（7），（9）545（1）-（7），（10）444（1）-（7），（11）,35,无效等价类,36,2.1.3问题讨论,问题：给出下面的有效和无效等价类输入条件：“统计全国各省、市、自治区的人口”输入条件：“标识符应以字母开头”输入条件：长度为1-20的字符串输入条件：数据库中的值域,CHAR(20),NOTNULL,37,2.2测试方法因果图,采用因果图方法（Cause一EffectGraphics）能够帮助我们按一定步骤，高效率地选择测试用例，同时还能为我们指出，程序规格说明描述中存在着什么问题。,38,2.2.1因果图介绍,4种符号分别表示了规格说明中向4种因果关系因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。,39,关系,恒等：若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。“与”也可有任意个输入。,40,约束,输入状态相互之间还可能存在某些依赖关系某些输入条件本身不可能同时出现。输出状态之间也往往存在约束,41,输入条件约束类型,对于输入条件的约束有以下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。,42,输出条件约束类型,输出条件的约束只有：M约束（强制）：若结果a是1，则结果b强制为0。,43,2.2.2步骤,分析程序规格说明的描述中，哪些是原因，哪些是结果。原因常常是输入条件或是输入条件的等价类。而结果是输出条件。分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。,44,步骤,由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用若干个特殊的符号标明约束条件。把因果图转换成判定表。把判定表中每一列表示的情况写成测试用例。,45,2.2.3例子,软件规格说明书“第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L，如果第二列字符不是数字，则给出信息M。”,46,原因和结果,原因：1第一列字符是A；2第一列字符是B；3第二列字符是一数字。结果：21修改文件；22给出信息L；23给出信息M。,47,因果图和具有约束的因果图,11为中间节点；考虑到原因1和原因2不可能同时为1，因此在因果图上施加E约束。,48,判定表,根据因果图建立如下的判定表,表中8种情况的左面两列情况中，原因和原因同时为1，这是不可能出现的，故应排除这两种情况。表的最下一栏给出了6种情况的测试用例，这是我们所需要的数据。,49,2.2.4讨论,在较为复杂的问题中，这个方法常常是十分有效的，它能有力地帮助我们确定测试用例如果哪个开发项目在设计阶段就采用了判定表，也就不必再画因果图，而是可以直接利用判定表设计测试用例了。,50,2.3测试用例设计方法边值分析,在软件设计和程序编写中，常常对于规格说明中的输入域边界或输出域边界不够注意，以致形成一些差错。实践证明，在设计测试用例时，对边界附近的处理必须给予足够的重视，为检验边界附近的处理专门设计测试用例，常常取得良好的测试效果。,51,2.2.1边值分析遵循的原则,如果输入条件规定了取值范围，或是规定了值的个数，应以该范围的边界内及刚刚超出范围的边界外的值，或是分别对最大、最小个数及稍小于最小、稍大于最大个数作为测试用例。例如，如果程序的规格说明中规定：“重量在10公斤至50公斤范围内的邮件，其邮费计算公式为”。作为测试用例，我们应取10及50，还应取10.01,49.99,9.99及50.01等。如果另一问题规格说明规定：“某输入文件可包含1至255个记录，”，则测试用例可取1和255，还应取0及256等。,52,遵循以下几条原则,针对规格说明的每个输出条件使用前面的第（1）条原则。例如，某程序的规格说明要求计算出“每月保险金扣除额为0至116525元”，其测试用例可取000及11652、还可取一001及116526等。如果另一程序属于情报检索系统，要求每次”最多显示1条情报摘要”，这时我们应考虑的测试用例包括1和4，还应包括0和5等。,53,遵循以下几条原则,如果程序规格说明中提到的输入或输出域是个有序的集合（如顺序文件、表格等），就应注意选取有序集的第一个和最后一个元素作为测试用例。分析规格说明，找出其它的可能边界条件。,54,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人，输入数据的形式如图4。15所示。,55,学生考卷评分和成绩统计程序输入数据的形式,56,该程序应给出4个输出报告，即：按学生学号排序，每个学生的成绩（答对的百分比）和等级报告。按学生得分排序，每个学生的成绩。平均分数，最高与最低分之差。按题号排序，每题学生答对的百分比。,57,58,2.4判定表驱动测试,在一些数据处理问题中，某些操作是否实施依赖于多个逻辑条件的取值。也即在这些逻辑条件取值的组合所构成的多种情况下，分别执行不同的操作。处理这类问题的一个非常有力的分析和表达工具是判定表（DecisionTable）。,59,2.3.1例子1,一张关于科技书阅读指南的判定驱动表：3个问题8种情况,60,判定表组成,条件桩（ConditionStub）动作桩（ActionStub）条件项（ConditionEntity）动作项（ActionEntity）,61,规则及规则合并,任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，即条件项和动作项有多少列。化简就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系,两条规则合并成一条两条规则的进一步合并,62,一个规则合并的例子,一个规则合并的例子,63,2.3.2例子2,问题要求：”对功率大于50马力的机器、维修记录不全或已运行10年以上的机器，应给予优先的维修处理”假定，“维修记录不全”和“优先维修处理”均已在别处有更严格的定义按5步建立判定表,64,建立判定表的步骤,确定规则的个数。这里有3个条件，每个条件有两个取值，故应有2*2*2=8种规则。列出所有的条件茬和动作茬。填人条件项。为防止遗漏可从最后1行条件项开始，逐行向上填满乙如第三行是：YNYNYNYN第二行是：YYNNYYNN等等。,65,建立判定表的步骤,填人动作桩和动作顶。这样便得到形如图的初始判定表。,66,建立判定表的步骤,化简。合并相似规则后得到图。,67,2.3.3判定表在功能测试中的应用,一软件规格说明(1)当条件1和条件2满足，并且条件3和条件4不满足，或者当条件1、3和条件4满足时，要执行操作1。(2)在任一个条件都不满足时，要执行操作2。(3)在条件1不满足，而条件4被满足时，要执行操作3。,68,规则,只给出了16种规则中的4种,根据规格说明得到的判定表默许的规则,69,2.3.4判定表的优点和缺点,优点：它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。缺点：不能表达重复执行的动作，例如循环结构。其他？,70,使用判定表设计测试用例的Beizer条件,规格说明以判定表形式给出，或是很容易转换成判定表。条件的排列顺序不会也不应影响执行哪些操作。规则的排列顺序不会也不应影响执行哪些操作。每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。B。Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表，同样可以借以设计测试用例，只不过尚需增加其它的测试用例罢了。,71,2.5正交实验设计法,把软件功能测试作为实验的一种，从大量的实验点中选出适量有代表性的点，应用依据伽罗瓦理论导出的“正交表”，合理安排实验的一种科学的实验设计方法。从规约中找出影响其功能实现的操作对象和外部因素作为因子，因子的取值作为状态，构造因素分析表，利用正交表进行各因子的专题组合，构造有效的测试数据集，并由此建立因果图。,72,2.6自动测试用例设计,一些测试工具可以进行部分测试用例自动化，“测试输入生成工具”，该方法也可以用于某些场合，但自动工具不可能完全替代智力的测试活动；自动方式可以生成大量的测试用例，但他不区分哪些测试是最重要的。这些要求有创造力的智力活动只能由测试人员完成。所有测试生成工具依赖于生成测试的算法，工具比使用相同算法的测试人员的测试更彻底、更精确，但人工测试时可以考虑附加测试。,73,三种测试输入生成工具,基于代码测试输入生成基于界面测试生成基于规格说明测试生成,74,基于代码测试输入生成,通过检测软件代码结构生成测试输入。通过代码的路径由判断点确定的段组成。自动生成每个路径段逻辑覆盖条件的轮廓文件。与覆盖工具一起使用较好。只产生测试输入，还需要对测试输出进行比较，不能判断软件产生的输出是否正确，只是说明代码应该做什么。也不能发现丢失的代码另一种方法：可以生成满足较小变化测试准则的测试。变化测试（Mutationtest）是指代码或输入做较小的改变，检测系统是否可以正确地处理或测试稍微改变的版本。该方法可以检查系统的容错能力和测试套件的充分性。,75,基于界面测试生成,用于某些定义好的界面如GUI或Web应用生成测试。如果屏幕含有各种菜单、按钮及检查框，则工具生成访问每个控件的测试事例。还可以测试Internet和Intranet页面。工具可激活WWW页面的每个链接，然后对每页做相同的测试；该方法对于发现某类缺陷是有效的，可以部分生成期望输出，即连接存在或断开状况，但不能判断连接是否在正确的位置；该方法可以执行部分测试事例设计活动，产生测试输出，对于检测“roll-call”即某个东西确实在某处确实有用。手工测试非常枯燥，应该采用自动测试。,76,基于规格说明测试生成,在规格说明形式化并可被工具分析的前提下，基于规格说明测试工具可以生成测试输入及期望结果；如果面向对象规格说明足够严格的话，这种工具还可以进行面向对象规格说明的测试。例如，如果一个输入域的允许范围被严格定义，那么工具可以产生边界值以及有效等价类和无效等价类的样值。某些基于规格说明的工具可以进行结构化的英文规格说明或因果图的测试，可以发现一些规格说明的缺陷，如规格说明含混或冗长好处是检查软件应该做什么，而不是软件做了什么。从规格说明中推导测试用例越枯燥，则这类工具的潜力就越大。,77,自动测试用例生成的优点,自动化测试用例生成用于设计的繁琐部分，如激活每个菜单项或者从已知的数据范围计算边界值；可以生成针对源程序的一套完成的测试用例（代码、界面和规格说明）可以发现某种类型的缺陷，如丢失连接，非工作窗口项或者不符合规格说明的软件；,78,自动测试用例生成的限制,基于代码方法不能生成期望输出基于界面方法只能产生部分期望输出基于代码和基于界面方法不能发现规格说明的缺陷；基于规格说明的方法依赖于规格说明的质量；所有的方法可以产生大量的测试，而实际操作起来比较困难；测试前仍需要专家判断产生的测试的必要性，并考虑任何工具都无法产生的测试；,79,2.7小结,理解和熟练使用4种进行测试用例设计的方法：等价类划分、因果图、边值分析、判定表驱动；自动测试用例设计的原理和方法，,80,4、软件测试用例设计白盒测试,3.0概述3.1程序结构分析3.2逻辑覆盖3.3路径分析3.4域测试3.5程序插装3.6程序变异3.7小结,81,3.0概述,此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。,82,软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：对程序模块的所有独立的执行路径至少测试一次；对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；在循环的边界和运行界限内执行循环体；测试内部数据结构的有效性，等。,83,对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字。给出一个小程序的流程图，它包括了一个执行20次的循环。包含的不同执行路径数达520条，对每一条路径进行测试需要1毫秒，假定一年工作36524小时，要想把所有路径测试完，需3170年。,84,85,3.1程序结构分析基本路径测试,基本路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，设计测试用例的方法。设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。,86,3.1.1.程序的控制流图,符号为控制流图的一个结点，表示一个或多个无分支的PDL语句或源程序语句。箭头为边，表示控制流的方向。,87,在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。如果判断中的条件表达式是由一个或多个逻辑运算符(OR,AND,NAND,NOR)连接的复合条件表达式，则需要改为一系列只有单条件的嵌套的判断。,88,89,90,3.1.2.程序环路复杂性,程序的环路复杂性给出了程序基本路径集中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。从控制流图来看，一条独立路径是至少包含有一条在其它独立路径中从未有过的边的路径。,91,例如，在图示的控制流图中，一组独立的路径是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组成了控制流图的一个基本路径集。,92,3.1.2.导出测试用例,导出测试用例，确保基本路径集中的每一条路径的执行。根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到用逻辑覆盖方法。,93,每个测试用例执行之后，与预期结果进行比较。如果所有测试用例都执行完毕，则可以确信程序中所有的可执行语句至少被执行了一次。必须注意，一些独立的路径(如例中的路径1)，往往不是完全孤立的，有时它是程序正常的控制流的一部分，这时，这些路径的测试可以是另一条路径测试的一部分。,94,3.2逻辑覆盖,语句覆盖判定覆盖条件覆盖,判定条件覆盖条件组合覆盖路径覆盖。,逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。,95,例,96,97,98,99,100,3.2.1语句覆盖,语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。在图例中，正好所有的可执行语句都在路径L1上，所以选择路径L1设计测试用例，就可以覆盖所有的可执行语句。,101,测试用例的设计格式如下【输入的(A,B,X)，输出的(A,B,X)】为图例设计满足语句覆盖的测试用例是:【(2,0,4)，(2,0,3)】覆盖ace【L1】,102,3.2.2判定覆盖,判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖。对于图例，如果选择路径L1和L2，就可得满足要求的测试用例:,103,【(2,0,4)，(2,0,3)】覆盖ace【L1】【(1,1,1)，(1,1,1)】覆盖abd【L2】,104,如果选择路径L3和L4，还可得另一组可用的测试用例:【(2,1,1)，(2,1,2)】覆盖abe【L3】【(3,0,3)，(3,1,1)】覆盖acd【L4】,105,3.2.3条件覆盖,条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。在图例中，我们事先可对所有条件的取值加以标记。例如，对于第一个判断：条件A1取真为，取假为条件B0取真为，取假为,106,对于第二个判断：条件A2取真为，取假为条件X1取真为，取假为测试用例覆盖分支条件取值【(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),107,或测试用例覆盖分支条件取值【(1,0,3)，(1,0,4)】L3(b,e)【(2,1,1)，(2,1,2)】L3(b,e),108,3.2.4判定条件覆盖,判定条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断中的每个条件的可能取值至少执行一次。,109,测试用例覆盖分支条件取值【(2,0,4)，(2,0,3)】L1(c,e)【(1,1,1)，(1,1,1)】L2(b,d),110,and,or,111,3.2.5条件组合覆盖,条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。记A1,B0作A1,B0作A1,B0作A1,B0作,112,A2,X1作A2,X1作A2,X1作A2,X1作,113,测试用例覆盖条件覆盖组合【(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),114,3.3路径测试,路径测试就是设计足够的测试用例，覆