评价通过所有单元测试用例课件

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,1.1,什么是软件,1,、软件的定义,与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。,2,、软件的分类,按照功能分：系统软件和应用软件,按照技术架构分：单机版软件、,C/S,结构软件、,B/S,结构软件,按照用户分：产品软件和项目软件,按照开发的规模分：大、中、小,1.1 什么是软件1、软件的定义2、软件的分类,1.3,为什么要进行软件测试,软件总存在缺陷。只有通过测试，才可以发现软件缺陷。也只有发现了缺陷，才可以将软件缺陷从软件产品或软件系统中清理出去。,软件中存在的缺陷给我们带来的损失是巨大的，这也说明了软件测试的必要性和重要性,测试是所有工程学科的基本组成单元，自然也是软件开发的重要组成部分。,测试人员水平越高，找到软件问题的时间就越早，软件就越容易更正，产品发布之后越稳定，公司赚的钱也越多，微软就是一个典型的例子,1.3 为什么要进行软件测试软件总存在缺陷。只有通过测试，才,1.4,什么是软件测试,1,、软件测试的定义,软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码实现的最终审查，它是软件质量保证的关键步骤。通常对软件测试的定义有两种描述：,定义,1,：,软件测试是为了发现错误而执行程序的过程。,定义,2,：,在,IEEE,提出的软件工程标准术语中，软件测试被定义为：“使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别。”,1.4 什么是软件测试1、软件测试的定义,1.4,什么是软件测试,1,、软件测试的定义,软件测试的正确定义,软件测试是由“验证（,Verification,）”和“有效性确认（,Validation,）”活动构成的整体。,验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性,“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。,1.4 什么是软件测试1、软件测试的定义,1.4,什么是软件测试,2,、,软件测试的对象,软件测试不等于程序测试。,软件测试贯串于软件定义和开发的整个过程。,软件开发过程中所产生的需求规格说明、概要设计规格说明、详细设计规格说明以及源程序都是软件测试的对象。,1.4 什么是软件测试2、软件测试的对象,3,、,软件测试的原则,尽早地和及时地测试；,测试用例应当由测试数据和与之对应的预期结果这两部分组成；,在程序提交测试后，应当由专门的测试人员进行测试；,测试用例应包括合理的输入条件和不合理的输入条件；,严格执行测试计划，排除测试的随意性；,充分注意测试当中的群体现象；,应对每一个测试结果做全面的检查；,保存测试计划、测试用例、出错统计和最终分析报告，为维护工作提供充分的资料。,3、软件测试的原则,第二章 软件测试的基本概念,主要内容：,2.1,软件缺陷,2.2,验证和确认,2.3,软件测试分类,2.4,软件测试阶段,2.5,软件测试工作范畴,第二章 软件测试的基本概念主要内容：,缺陷是质量的对立面,要了解什么是缺陷,(defect)，就必须清楚“质量(Quality),”概念，因为缺陷是相对质量而存在的，违背了质量、违背了客户的意愿，不能满足客户的要求，就会引起缺陷或产生缺陷,缺陷是质量的对立面 要了解什么是缺陷(de,2.1,软件缺陷,一、软件质量的内涵,1,、质量,质量,是,“,产品或服务所满足,明示,或,暗示,需求能力的,固有特性,和特征的集合,”,。,2.1 软件缺陷一、软件质量的内涵,2.1,软件缺陷,一、软件质量的内涵,2,、软件质量,软件质量,是软件产品满足规定的和隐含的与需求能力有关的全部特征和特性。包括：,（,1,）软件产品质量满足用户要求的程度；,（,2,）软件各种属性的组合程度；,（,3,）用户对软件产品的综合反映程度；,（,4,）软件在使用过程中满足用户要求的程度。,2.1 软件缺陷一、软件质量的内涵,2.1,软件缺陷,一、软件质量的内涵,3,、软件质量模型,McCall,软件质量模型,2.1 软件缺陷一、软件质量的内涵 McCall软件质量模型,2.1,软件缺陷,一、软件质量的内涵,3,、软件质量模型,ISO 9126,软件质量三层模型,2.1 软件缺陷一、软件质量的内涵 ISO 9126,2.1,软件缺陷,一、软件质量的内涵,4,、软件质量特性,功能性、易用性、可靠性、性能、容量,可测量性、可维护性、可移植性、可扩展性,2.1 软件缺陷一、软件质量的内涵,2.1,软件缺陷,一、软件质量的内涵,5,、软件质量的分类,（,1,）软件质量的功能需求,软件质量的功能需求一般会在需求规格说明书等文档中给相应的描述。,（,2,）软件质量的非功能需求,软件质量的非功能需求一般用下列特性描述：,性能、有效性、可靠性、可维护性、兼容性、可扩展性、可移植性,2.1 软件缺陷一、软件质量的内涵,2.1,软件缺陷,一、软件质量的内涵,5,、软件质量的分类,（,3,）软件质量的用户需求,能正常使用全部所需的功能，符合需求规格；,功能强大，而且界面美观，易用；,内容健康、有益于生活和工作。,用户数据的安全、受保护和兼容；,能及时得到新的产品或更完美的软件服务；,软件可靠性很高，使用软件服务没有时间障碍,2.1 软件缺陷一、软件质量的内涵,2.1,软件缺陷,一、软件质量的内涵,5,、软件质量的分类,（,4,）软件质量的企业需求,开发成本,可维护性,可扩展性,可移植性,兼容性,2.1 软件缺陷一、软件质量的内涵,2.1,软件缺陷,二、软件缺陷,1,、软件缺陷的定义,软件缺陷（,Bug,）：,任何程序、系统中的问题，和产品设计书的不一致性，不能满足用户的需求。,IEEE(1983)729,软件缺陷一个标准的定义：,从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；,从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。,2.1 软件缺陷二、软件缺陷,2.1,软件缺陷,二、软件缺陷,2,、软件缺陷的表现,功能、特性没有实现或部分实现,设计不合理，存在缺陷,实际结果和预期结果不一致,运行出错，包括运行中断、系统崩溃、界面混乱,数据结果不正确、精度不够,用户不能接受的其他问题，如存取时间过长、界面不美观,2.1 软件缺陷二、软件缺陷,2.1,软件缺陷,二、软件缺陷,3,、软件缺陷产生的原因,微软开发者成功之路（之一）,概括了以下,7,项主要原因：,（,1,）项目期限的压力；,（,2,）产品的复杂度；,（,3,）沟通不良；,（,4,）开发人员疲劳，压力过大或受到干扰；,（,5,）缺乏足够的知识、技能和经验；,（,6,）不了解客户的需求；,（,7,）缺乏动力。,2.1 软件缺陷二、软件缺陷,2.1,软件缺陷,二、软件缺陷,4,、软件缺陷的构成,其他,6%,软件产品说明书（需求）,54%,编写代码,15%,设计,25%,图,2-4,软件缺陷构成示意图,2.1 软件缺陷二、软件缺陷软件产品说明书（需求）设计25%,2.1,软件缺陷,二、软件缺陷,5,、修复软件缺陷的代价,0,20,40,60,80,100,编制说明书,设计阶段,编写代码,测试,发布,软件缺陷随时间的推移带来的成本越来越大,2.1 软件缺陷二、软件缺陷020406080100编制说明,2.2,验证和确认,一、验证和确认,Verification,：,Are we building the product right,？,是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。,验证产品满足规格设计说明书的一致性,Validation,：,Are we building the right product?,是否构造了正是用户所需要的软件？即是否正在做正确的事。,验证产品所实现的功能是否满足用户的需求,2.2 验证和确认一、验证和确认,2.2,验证和确认,二、评审,通过软件评审，可以更早地发现需求工程、软件设计等各个方面的问题，大大减少大量的后期返工，将质量成本从昂贵的后期返工转化为前期的缺陷发现。,1,、评审,评审,是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进,。,检验工作产品是否正确地满足了以往工作产品中建立的规范,。,2.2 验证和确认二、评审,2.2,验证和确认,二、评审,2,、评审分类,管理评审,技术评审,文档评审,流程评审,2.2 验证和确认二、评审,2.2,验证和确认,三、质量保证和测试的关系,1,、软件质量保证：,是通过对软件产品有计划的进行评审和审计来验证软件是否合乎标准的系统工程。,2,、,SQA,的活动：,提出软件质量要求；,确定开发方案；,阶段评审；,测试管理,文档化管理,验证产品与相应文档和标准的一致性,建立测量机制,记录并生成报告,2.2 验证和确认三、质量保证和测试的关系,2.2,验证和确认,三、质量保证和测试的关系,3,、,SQA,与软件测试的关系,共同点：,二者贯穿整个软件开发生命周期的流程,。,区别：,SQA,是,管理,工作、审查对象是,流程,、强调以,预防,为主,测试是,技术,工作、测试对象是,产品,、主要是以,事后检查,关系：,SQA,指导测试、监控测试,测试为,SQA,提供依据,2.2 验证和确认三、质量保证和测试的关系,2.3,软件测试的分类,方法,目标,/,特性,单元测试,系统测试,验收测试,性能测试,强壮性测试,功能测试,白盒测试,黑盒测试,测试阶段或层次,适用性测试,可靠性测试,集成测试,安全性测试,2.3 软件测试的分类方法目标/特性单元测试系统测试验收测试,2.3,软件测试的分类,按测试的对象或范围分类，如单元测试、文档测试、系统测试等）,按测试目的分类，如功能测试、回归测试、性能测试、可靠性测试、安全性测试和兼容性测试等,根据测试过程中被测软件是否被执行，分为静态测试和动态测试,根据是否针对系统的内部结构和具体实现算法来完成测试，可分为白盒测试和黑盒测试,2.3 软件测试的分类按测试的对象或范围分类，如单元测试、文,2.4,软件测试阶段,图,2-8,软件测试阶段示意图,2.4 软件测试阶段图2-8 软件测试阶段示意图,需求和设计审查,测试人员参与产品需求分析和系统设计，认真阅读有关文档，真正理解客户的需求和技术上的设计，检查需求说明书对产品描述的准确性、一致性等，检查系统设计的合理性和可测试性等,需求和设计审查 测试人员参与产品需求分析和系统设,单元测试,单元测试的对象是程序系统中的最小单元,-,模块或组件上，在编码阶段进行，针对每个模块进行测试，主要通过白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。多个模块可以平行地、对立地测试，通常要编写驱动模块和桩模块,单元测试一般由编程人员和测试人员共同完成，而以开发人员为主,单元测试包括代码评审，代码评审可以发现程序,50%,70%,代码的缺陷。,单元测试 单元测试的对象是程序系统中的最小单元-,集成测试,集成测试，也称组装测试、联合测试、子系统测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题,两种集成方式：一次性集成方式和增殖式集成方式。,集成测试 集成测试，也称组装测试、联合测试、子系,功能测试,功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用,功能测试 功能测试一般须在完成集成测试后进行，而,系统测试,系统测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括恢复测试、安全测试、强度测试和性能测试等,系统测试 系统测试是将软件放在整个计算机环境下，,验收测试,&,安装测试,验收测试,的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样,安装测试,是指按照软件产品安装手册或相应的文档，在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中，进行一步一步的安装操作性的测试,验收测试&安装测试验收测试的目的是向未来的用户表明系统能够,2.5 软件测试的工作范畴,软件测试工作的组织与管理,：制定测试策略、测试计划，确认所采用的测试方法与规范，控制测试进度，管理测试资源。,测试工作的实施,：编制符合标准的测试文档，搭建测试环境，开发测试脚本、与开发组织协作实现各阶段的测试活动,2.5 软件测试的工作范畴,测试工作流程,测试工作流程,3.1,白盒测试方法,白盒测试，也称,结构测试,或,逻辑驱动测试,，是已知程序的内部工作过程，清楚最终生成软件产品的计算机程序结构及其语句，按照程序的内部结构测试程序，测试程序内部的变量状态、逻辑结构、运行路径等，检验程序中的每条通路是否都能按预定要求正确工作，检查程序内部动作或运行是否符合设计规格要求，所有内部成分是否按规定正常运行。,3.1 白盒测试方法白盒测试，也称结构测试或逻辑驱动测试，是,3.1,白盒测试方法,白盒测试主要用于,单元测试,白盒测试的,基本原则,有：,对程序模块中所有独立路径至少测试一次；,对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；,对程序进行边界检查；,检验内部数据结构的有效性。,3.1 白盒测试方法白盒测试主要用于单元测试,3.1,白盒测试方法,目前最常用的方法有：,逻辑覆盖法,：包括语句覆盖、判定覆盖、条件覆盖、判定,/,条件覆盖、条件组合覆盖、路径覆盖。,基本路径测试法,3.1 白盒测试方法 目前最常用的方法有：,一、逻辑覆盖法,例：实现一个简单的数学运算,Dim a,b As Integer,Dim c As Double,If(a0 And b0)Then,c=c/a,End if,If(a1 or c1)Then,c=c+1,End if,c=b+c,一、逻辑覆盖法例：实现一个简单的数学运算,一、逻辑覆盖法,1,、语句覆盖,基本思想：设计足够多的测试用例，使得程序中的每个可执行语句至少执行一次。,路径：,P1,（,124,）,P2,（,125,）,P3,（,134,）,P4,（,135,）,测试用例,:,a=2,，,b=1,，,c=6,一、逻辑覆盖法1、语句覆盖路径：P1（124）P2（125）,一、逻辑覆盖法,1,、语句覆盖,【,优点,】,：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。,【,缺点,】,：语句覆盖是最弱的逻辑覆盖。不能发现其中的逻辑错误。,一、逻辑覆盖法1、语句覆盖,一、逻辑覆盖法,2,、判定覆盖,基本思想：设计足够多的测试用例，,使得程序中的每个判定至少都获得一次“真”值和“假”值，也就是使程序中的每个取“真”分支和取“假”分支至少均经历一次，也称为“分支覆盖”。,一、逻辑覆盖法2、判定覆盖,一、逻辑覆盖法,2,、判定覆盖,测试用例,:,a=2,，,b=1,，,c=6,a=-2,，,b=-1,，,c=-3,测试用例,:,a=1,，,b=1,，,c=0,a=2,，,b=-1,，,c=6,一、逻辑覆盖法2、判定覆盖 测试用例:测试用例:,一、逻辑覆盖法,2,、判定覆盖,【,优点,】,：,判定覆盖具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。,【,缺点,】,：,往往大部分的判定语句是由多个逻辑条件组合而成，若仅仅判断其整个最终结果，而,忽略每个条件的取值,情况，必然会遗漏部分测试路径。判定覆盖仍是,弱,的逻辑覆盖。,一、逻辑覆盖法2、判定覆盖,一、逻辑覆盖法,3,、条件覆盖,基本思想：,设计足够多的测试用例，使得程序中每个判定包含的每个条件的可能取值（真,/,假）都至少满足一次。,一、逻辑覆盖法3、条件覆盖,一、逻辑覆盖法,3,、条件覆盖,判断,M,表达式,:,条件,a0,取真 记为,T1,假,F1,条件,b0,取真 记为,T2,假,F2,判断,N,表达式,:,条件,a1,取真 记为,T3,假,F3,条件,c1,取真 记为,T4,假,F4,一、逻辑覆盖法3、条件覆盖判断M表达式:,一、逻辑覆盖法,3,、条件覆盖,测试用例,覆盖条件,具体取值条件,a=2,b=-1,c=-2,T1,F2,T3,F4,a0,b1,c=1,a=-1,b=2,c=3,F1,T2,F3,T4,a0,a1,它覆盖了判定,M,的,N,分支和判断,N,的,Y,分支。,一、逻辑覆盖法3、条件覆盖测试用例覆盖条件具体取值条件a=2,一、逻辑覆盖法,3,、条件覆盖,【,优点,】,：增加了对条件判定情况的测试。,【,缺点,】,：条件覆盖不一定包含判定覆盖。例如，我们刚才设计的用例就没有覆盖判断,M,的,Y,分支和判断,N,的,N,分支。条件覆盖只能保证每个条件至少有一次为真，而,不考虑所有的判定结果。,一、逻辑覆盖法3、条件覆盖,一、逻辑覆盖法,4,、判定,条件覆盖,基本思想：,设计足够多的测试用例，使得程序中每个判定包含的每个条件的所有情况（真,/,假）至少出现一次，并且每个判定本身的判定结果（真,/,假）也至少出现一次。,一、逻辑覆盖法4、判定条件覆盖,一、逻辑覆盖法,4,、判定,条件覆盖,按照判定条件覆盖的要求，我们设计的测试用例要满足如下条件：,（,1,）所有条件可能至少执行一次取值；,（,2,）所有判断的可能结果至少执行一次。,判断,M,判断,N,一、逻辑覆盖法4、判定条件覆盖 按照判定条件覆,一、逻辑覆盖法,4,、判定,条件覆盖,判断,M,判断,N,测试用例,覆盖条件,覆盖判断,a=2,b=1,c=6,T1,T2,T3,T4,M,的,Y,分支,N,的,Y,分支,a=-1,b=-2,c=-3,F1,F2,F3,F4,M,的,N,分支,N,的,N,分支,一、逻辑覆盖法4、判定条件覆盖判断M判断N测试用例覆盖条件,一、逻辑覆盖法,4,、判定,条件覆盖,【,优点,】,：,能同时满足判定、条件两种覆盖标准。,【,缺点,】,：判定,/,条件覆盖准则的缺点是未考虑,条件的组合,情况。,一、逻辑覆盖法4、判定条件覆盖,一、逻辑覆盖法,5,、条件组合覆盖,基本思想：,通过执行足够的测试用例，使得程序中每个判定的所有可能的条件取值组合都至少出现一次。,一、逻辑覆盖法5、条件组合覆盖,一、逻辑覆盖法,5,、条件组合覆盖,设计,组合条件,如表所示：,编号,覆盖条件取值,判定条件取值,具体条件取值,1,T1,T2,M,取,Y,a0,b0,2,T1,F2,M,取,N,a0,b=0,3,F1,T2,M,取,N,a0,4,F1,F2,M,取,N,a=0,b1,c1,6,T3,F4,N,取,Y,a1,c=1,7,F3,T4,N,取,Y,a1,8,F3,F4,N,取,N,a=1,c 0),5 ,6 If(iType=0),7x=y+2;,8 else,9 If(iType=1),10 x=y+10;,11 else,12 x=y+20;,13 ,14,（,1,）画出控制流图,（,2,）计算环形复杂度,（,3,）导出独立路径（用语句编号表示）,（,4,）设计测试用例,void Sort(int iRecordNum,（,1,）画出控制流图：,（,2,）计算环形复杂度：,10,（条边）,-8,（个节点）,+2=4,（,3,）导出独立路径（用语句编号表示）,路径,1,：,414,路径,2,：,46714,路径,3,：,4691013414,路径,4,：,4691213414,4,6,7,9,10,12,13,14,（1）画出控制流图：467910121314,输入数据,预期输出,测试用例,1,irecordnum=0,itype=0,x=0,y=0,测试用例,2,irecordnum=1,itype=0,x=0,y=0,测试用例,3,irecordnum=1,itype=1,x=10,y=0,测试用例,4,irecordnum=1,itype=2,x=0,y=20,（,4,）设计测试用例：,输入数据预期输出测试用例1irecordnum=0 x=,例,下面是选择排序的程序，其中,datalist,是数据表，它有两个数据成员：一是元素类型为,Element,的数组,V,，另一个是数组大小,n,。算法中用到交换两数组元素内容的操作,Swap(),：,void SelectSort(datalist list),/,对表,list.V0,到,list.Vn-1,进行排序,n,是表当前长度。,for(int i=0;i list.n-1;i+),int k=i;,/,在,list,中找具有最小关键码的对象,for(int j=i+1;j list.n;j+),if(list.Vj list.Vk)k=j;,/,当前具最小关键码的对象,if(k!=i)Swap(list.Vi,list.Vk);,/,交换,例 下面是选择排序的程序，其中datali,（,1,）路径,1,，,3,（,2,）路径,1,，,2,，,4,，,6,（,3,）路径,1,，,2,，,4,，,7,（,4,）路径,1,，,2,，,5,，,8,，,3,（,5,）路径,1,，,2,，,5,，,9,，,3,（1）路径1，3,三、循环测试,目标,:,在循环内部及边界上执行测试,（,1,）,简单循环,（,2,）,嵌套循环,（,3,）,串接循环,（,4,）,不规则循环,三、循环测试目标:在循环内部及边界上执行测试（1）简单循,三、循环测试,1.,简单循环,(,迭代次数,n),完全跳过循环,只经过循环一次,经过循环两次,经过循环,m,（,m n,）次,分别经过循环,n-1,n,n+1,次,三、循环测试1.简单循环(迭代次数n),三、循环测试,2.,嵌套循环,在最里面的循环完成前面所述的简单循环测试，同时设定外部循环的最小迭代次数,逐步向外循环进行,直到所有循环被测试,三、循环测试2.嵌套循环,三、循环测试,2.,嵌套循环,测试项,最外层循环次数,中间层循环次数,最内层循环次数,最内层,最小值,最小值,不同值,中间层,最小值,不同值,典型值,最外层,不同值,典型值,典型值,嵌套循环测试时各层循环控制变量的取值,三、循环测试2.嵌套循环测试项最外层循环次数中间层循环次数最,三、循环测试,3.,串行连接循环,独立循环,可以分别看作简单循环测试,依赖性循环,可以看作是嵌套循环,4.,其它非循环结构,重新设计,!,三、循环测试3.串行连接循环,四、程序插装,程序插装,是指在程序中设置断点或打印语句，在执行中了解程序中的一些动态特性。,程序插装技术的研究涉及的问题：,探测哪些信息。,程序的什么位置设置探测点,需要多少探测点,四、程序插装 程序插装是指在程序中设置断点或打,第三章 软件测试方法,主要内容：,3.1,白盒测试方法,3.2,黑盒测试方法,3.3,静态测试和动态测试,3.4,探查式测试,3.5,测试用例设计,第三章 软件测试方法主要内容：,3.2,黑盒测试方法,黑盒测试,（,也称功能测试或数据驱动测试,）,把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据需求规格说明书，检查程序的功能是否符合它的功能说明。,功能测试,数据驱动测试,客户需求,事件驱动,输入,输出,3.2 黑盒测试方法黑盒测试（也称功能测试或数据驱动测试）把,3.2,黑盒测试方法,黑盒测试常用于发现以下错误,能否正确地接受输入数据，能否产生正确的输出信息；,是否有不正确或遗漏的功能；,功能操作逻辑的合理性；,界面是否出错；,安装过程中是否出现问题；,系统初始化问题。,3.2 黑盒测试方法黑盒测试常用于发现以下错误,3.2,黑盒测试方法,常用的方法,等价类划分法,边界值分析法,判定表方法,因果图法,正交试验法,功能图法,错误推测法,3.2 黑盒测试方法常用的方法,3.2.1,等价类划分方法,将程序可能的输入数据分成若干个子集，从每个子集选取一个代表性的数据作为测试用例,，,等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的,分为,有效等价类,和,无效等价类,。,在分析需求规格说明的基础上划分等价类，列出等价类表,设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。经过正反的测试才能确保软件具有更高的可靠性。,3.2.1 等价类划分方法将程序可能的输入数据分成若干个子集,确定等价类的方法（,1,）,在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类,in range,greater than range,less than range,value,greater than value,less than value,确定等价类的方法（1）在输入条件规定了取值范围或值的个数的情,在输入条件规定了输入值的集合或者规定了,“,必须如何,”,的条件的情况下，可以确立一个有效等价类和一个无效等价类。,确定等价类的方法（,2,）,not member of set,member of set,在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情,在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类,确定等价类的方法（,3,）,Boolean,Non-Boolean,在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无,确定等价类的方式,(4),在规定了输入数据的一组值,(,假定,n,个,),，并且程序要对每一个输入值分别处理的情况下，可确立,n,个有效等价类和一个无效等价类。,个人月收入,-x,税率,x=1600 0%,1600 x 2100 5%,500 =x 3600 10%,3600 =x 6600 15%,6600 =x 21600 20%,21600 =x 101600 45%,确定等价类的方式(4)在规定了输入数据的一组值(假定n个),确定等价类的方式,(5),在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类,(,符合规则,),和若干个无效等价类,(,从不同角度违反规则,),。,确定等价类的方式(5)在规定了输入数据必须遵守的规则的情况,等价类测试用例,-Example,等价类,1:Integer,等价类,2:Decimal fraction,等价类,3:Negative,等价类,4:Invalid input,等价类测试用例-Example等价类1:Integer,根据等价类创建测试用例的步骤,a),建立等价类表，列出所有划分出的等价类：,为每个等价类规定一个唯一的编号；,设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类,重复,c),，最后使得所有有效等价类均被测试用例所覆盖；,设计一个新的测试用例，使其只覆盖一个无效等价类。,重复,e),使所有无效等价类均被覆盖。,输入条件,有效等价类,无效等价类,根据等价类创建测试用例的步骤a)建立等价类表，列出所有划分,3.2.2,边界值分析方法,边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。,人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。,设计方法：,确定边界情况（输入或输出等价类的边界）,选取正好等于、刚刚大于或刚刚小于边界值作为测试数据,3.2.2 边界值分析方法边界值分析也是一种黑盒测试方法，是,确定边界值的方法,如果输入条件规定了值的范围，则应取,刚达到,这个范围的边界的值，以及,刚刚超越,这个范围边界的值作为测试输入数据。,如果输入条件规定了值的个数，则用,最大个数、最小个数、比最小个数少一、比最大个数多一的数,作为测试数据。,a,b,a,b,确定边界值的方法如果输入条件规定了值的范围，则应取刚达到这个,确定边界值的方法（,2,）,如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。,如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。,Test cases for ABS(x):,class x=0,arbitrary value x =100,classes x=0,on boundary:x =0,classes x=0,below and above:x =-1,x=1,确定边界值的方法（2）如果程序的规格说明给出的输入域或输出域,正常值（有效类）,:X1=123123,边界值,:X2=12345,边界值,:X3=1234567,边界值,:X4=1,边界值,:X5=0,无效类的值,:X6=-123123,无效类的值,:X7=asdasd,其它,?,示例,2,测试 限制性用户输入：,6,位正整数,无效值,:X8=000123,X9=asd123,X10=Empty,正常值（有效类）:X1=123123示,示例,3,Test cases:,任意的正常值,:,随机选择几个选项 边界值,:,选择所有选项 边界值,:,一个都不选边界值,:,选择一个选项,示例3Test cases:,二进制,Term,取值范围,Bit,Nibble,Byte,Word,Kilo,Mega,Giga,Tera,0 or 1,0-15 ,0-255,0-65535 or 0-4294967295,1024,1048576,1073741824,1099511627776,0,和,1,byte,由,8 bits,构成,字由,4 bytes,构成,二进制Term 取值范围Bit0 or 10 和 1,by,ASCII Table,Character,ASCII Value,Character,ASCII Value,Null,Space,/,0,1,2,9,;,A,0,32,47,48,49,50,57,58,64,65,B,Y,Z,a,b,y,z,66,89,90,91,96,97,98,121,122,123,ASCII TableCharacterASCII Valu,字符编辑域,Default,Empty,Blank,Null,Zero,None,字符编辑域Default,一些特殊的边界值,数值,字符,位置,数量,速度,位置,体积,First/last,，,First-1/Last+1,Min/Max,，,Min-1/max+1,Star/Finish,，,Start-1/Finish+1,Empty/Full,Less than empty/more than full,Slower/Faster,Largest/Smallest,Over/Under,，,just Over/Just Under,Shortest/Longest,一些特殊的边界值数值First/last，First-1/,3.2.3,判定表方法,在实际应用中，许多输入是由多个因素构成，而不是单一因素，这时就需要,多因素组合分析,。,对于多因素，有时可以直接对输入条件进行组合设计，不需要进行因果分析，即,直接采用判定表方法,。,一个判定表由“,条件和活动,”两部分组成，也就是列出了一个测试活动执行所需的条件组合，所有可能的条件组合定义了一系列的选择，而测试活动需要考虑每一个选择。,3.2.3 判定表方法在实际应用中，许多输入是由多个因素构成,判定表元素,条件桩,，列出问题的所有条件,动作桩,：列出可能针对问题所采取的操作,条件项,：针对所列条件的具体赋值,动作项,：列出在条件项（各种取值）组合情况下应该采取的动作。,规则,：任何一个条件组合的特定取值及其相应要执行的操作。,判定表元素条件桩，列出问题的所有条件,判定表方法步骤,列出所有的条件桩和动作桩；,填入条件项；,填入动作项，制定初始判定表；,简化、合并相似规则或者相同动作,示例 见表,3-12,和,3-13,判定表方法步骤列出所有的条件桩和动作桩；示例 见表3-12和,3.2.4,因果图法,1),因果图的适用范围,如果在测试时必须考虑,输入条件的各种组合,，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。,3.2.4 因果图法1)因果图的适用范围,2),用因果图生成测试用例的基本步骤,(1),分析软件规格说明描述中，哪些是原因,(,即输入条件或输入条件的等价类,),，哪些是结果,(,即输出条件,),，并给每个原因和结果赋予一个标识符。,(2),分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系,?,根据这些关系，画出因果图。,2)用因果图生成测试用例的基本步骤,(3),由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。,(4),把因果图转换成判定表。,(5),把判定表的每一列拿出来作为依据，设计测试用例。,2),用因果图生成测试用例的基本步骤（续）,(3)由于语法或环境限制，有些原因与原因之间，原因与结果,在因果图中出现的基本符号：,通常在因果图中用,Ci,表示原因，用,Ei,表示结果，各结点表示状态，可取值,“,0,”,或,“,1,”,。,“,0,”,表示某状态不出现，,“,1,”,表示某状态出现。,主要的原因和结果之间的关系有,:,在因果图中出现的基本符号：通常在因果图中用Ci,表示约束条件的符号,为了表示原因与原因之间，结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束条件的符号。,表示约束条件的符号 为了表示原因与原因之间，结果,例如，有一个处理单价为,5,角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：,若投入,5,角钱或,1,元钱的硬币，押下,橙汁,或,啤酒,的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示,零钱找完,的红灯亮，这时在投入,1,元硬币并押下按钮后，饮料不送出来而且,1,元硬币也退出来；若有零钱找，则显示,零钱找完,的红灯灭，在送出饮料的同时退还,5,角硬币。,”,例如，有一个处理单价为5角钱的饮料的,(1),分析这一段说明，列出原因和结果,原因,:,1.,售货机有零钱找,2.,投入,1,元硬币,3.,投入,5,角硬币,4.,押下橙汁按钮,5.,押下啤酒按钮,建立中间结点，表示处理中间状态,11.,投入,1,元硬币且押下饮料按钮,12.,押下,橙汁,或,啤酒,的按钮,13.,应当找,5,角零钱并且售货机有零钱找,14.,钱已付清,(1)分析这一段说明，列出原因和结果原因:1.售货机,结果：,21.,售货机,零钱找完,灯亮,22.,退还,1,元硬币,23.,退还,5,角硬币,24.,送出橙汁饮料,25.,送出啤酒饮料,(2),画出因果图。,所有原因结点列在左,边，所有结果结点列在右边。,(3),由于,2,与,3,，,4,与,5,不能同时发生，,分别加上约束条件,E,。,(4),因果图,(5),转换成判定表,结果：21.售货机零钱找完灯亮,例,2,：某个软件规格说明中包含以下要求：第一列字符必须是,A,或,B,，第二列字符必须是一个数字，在此情况下进行文件的修改；但如果第一列字符不正确，则输出信息,L,；如果第二列字符不是数字，则输出信息,M,。,例2：某个软件规格说明中包含以下要求：第一列字符必须是A或,(1),分析这一段说明，列出原因和结果,原因,:,C1.,第一列字符是,A,C2.,第一列字符是,B,C3.,第二列字符是一个数字,建立中间结点，表示处理中间状态,11.,第一列字符是,A,或,B,结果：,E1.,修改文件,E2.,输出信息,L,E3.,输出信息,M,(1)分析这一段说明，列出原因和结果原因:C1.第一列,判定表,序号,1,2,3,4,5,6,原因,C1,1,0,0,1,0,0,C2,0,1,0,0,1,0,C3,1,1,1,0,0,0,结果,E1,1,1,0,0,0,0,E2,0,0,1,0,0,0,E3,0,0,0,1,1,1,判定表序号123456原因C1100100C2010010C,3.2.5,正交试验法,1,、,为什么要采用正交试验法？,在许多应用系统的测试工作中，不会象判断三角形那样简单，而实际项目中输入条件的因素很多，而且每个因素也不能简单用“是”和“否”来回答。比如，微软,Powerpoint,程序的打印测试，也需要考虑,4,个因素，每个因素也有多个选项,.,打印范围分：全部、当前幻灯片、给定范围,打印内容分：幻灯片、讲义、备注页、大纲视图,打印颜色,/,灰度分,:,彩色、灰度、黑白,打印效果分：幻灯片加框和幻灯片不加框。,3.2.5 正交试验法1、为什么要采用正交试验法？,实例,员工号（,ID,）。,员工姓名（,Name,）。,员工邮件地址（,Mail Address,）,信息系统中，员工信息查询功能是常见的。例如，设有,3,个独立的查询条件，以获得特定员工的个人信息,实例员工号（ID）。信息系统中，员工信息查询功能是常,3.2.6,功能图法,每个程序的功能通常由静态说明和动态说明组成,静态说明描述了输入条件和输出条件之间的对应关系,动态说明描述了输入数据的次序或者转移的次序,。,功能图法,就是为了解决动态说明问题的一种测试用例的设计方法,功能图由,状态迁移图,（,state transition diagram,，,STD,）和,逻辑功能模型,（,logic function model,，,LFM,）构成,3.2.6 功能图法每个程序的功能通常由静态说明和动态说明组,状态迁移图,状态迁移图,，描述系统状态变化的动态信息,动态说明，由状态和迁移来描述，状态指出数据输入的位置（或时间），而迁移则指明状态的改变。,状态迁移图状态迁移图，描述系统状态变化的动态信息动态说明,如何设计测试用例,功能图法设计测试用例，就是如何覆盖软件所表现出来的所有状态，可以转化为两个层次的测试用例,从逻辑功能模型（决策表或因果图）导出局部测试用例，覆盖各个状态的各种输入数据的组合,从状态迁移图导出整体的测试用例，以覆盖系统（程序）控制的逻辑路径,功能图法是综合运用黑盒方法和白盒方法来设计测试用例，即整体上选用白盒方法,路径覆盖、分支和条件覆盖等，而局部上选用的是黑盒方法,决策表或因果图方法,如何设计测试用例功能图法设计测试用例，就是如何覆盖软件所表现,3.2.7,错误推测法,人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是,错误推测法,。,错误推测法的基本想法是：,列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例,。,3.2.7 错误推测法人们也可以靠经验和直觉推测程序中可能存,3.3,静态测试和动态测试,将需求和设计的评审也纳入测试的范畴，可以看作是广义测试,静态测试,包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审等,静态分析的查错和分析功能是其他方法所不能替代的，可以采用,人工检测,和,计算机辅助静态分析,手段进行检测，但越来越多地采用工具进行自动化分析,动态测试,是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统,信息，对系统行为进行验证。,3.3 静态测试和动态测试将需求和设计的评审也纳入测试的范畴,3.4,探查式测试,1,、传统的结构化测试,先设计后运行；,预先设计的测试用例可能不能起到应有的作用；,2,、探查式测试,边设计边运行；,依靠测试人员在测试过程中的主动性和创造性；,3.4 探查式测试 2、探查式测试,3.4,探查式测试,3,、探查式测试的作用,可以设计更有效的测试用例；,可以作为传统的结构化测试的补充；,尽可能多地发现有价值的缺陷；,可以依据缺陷群集现象来确定测试重点。,3.4 探查式测试,3.4,探查式测试,4,、探查式测试的步骤,确定探查的范围和重点；,拟出可能的探查方案（,缺陷讨论会、攻击测试方法,）；,评估提出的探查方案，决定要采取的最佳方案；,确定实施计划；,实施探查方案，记录实施结果；,判断是否进行下一轮探查。,3.4 探查式测试,3.4,探查式测试,5,、缺陷讨论会,参会人员：测试人员、开发人员、用户、其他相关人员,人数,510,人；,主持人事先把会议议题通知参会人员；,会上采取轮流发言制；,确实没有新的设想提出或时间用完，结束会议。,3.4 探查式测试5、缺陷讨论会参会人员：测试人员、开发人,3.4,探查式测试,6,、攻击测试方法,API,文件系统、网络通信接口,操作系统,用户界面,应用软件产品,系统接口,用户,用户,（,1,）用户界面攻击,输入和输出攻击,数据和计算攻击,（,2,）系统接口攻击,文件系统接口攻击,软件系统接口攻击,3.4 探查式测试6、攻击测试方法API 文件系统、网络,良好测试用例的特征,可以最大程度地找出软件隐藏的缺陷,可以最高效率的找出软件缺陷,可以最大程度地满足测试覆盖要求,既不过分复杂、也不能过分简单,使软件缺陷的表现可以清楚的判定,测试用例包含期望的正确的结果,待查的输出结果或文件必须尽量简单明了,不包含重复的测试用例,测试用例内容清晰、格式一致、分类组织,良好测试用例的特征可以最大程度地找出软件隐藏的缺陷,测试用例设计考虑因素,具有代表性、典型性,寻求系统设计、功能设计的弱点,测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分析怎样使得这样的错误或者异常能够发生,考虑用户实际的诸多使用场景,示例,1,：,P.313,示例,2:P.315,测试用例设计考虑因素具有代表性、典型性,14.1.4,测试用例设计的基本原则,Zhu.Kerry,尽量避免含糊的测试用例,尽量将具有相类似功能的测试用例抽象并归类,尽量避免冗长和复杂的测试用例,14.1.4 测试用例设计的基本原则Zhu.Kerrygm,3.5,测试用例设计,5,、测试用例的设计原则,（,1,）保证测试用例的明确性；,（,2,）保证测试用例的代表性；,（,3,）保证测试用例的简洁性；,3.5 测试用例设计5、测试用例的设计原则,4.1,测试过程模型,4.1.1,软件过程模型,4.1.2,用,V,模型诠释软件测试过程,4.1.3 W,模型,4.1 测试过程模型 4.1.1 软件过程模型,4.1.1,软件过程模型,1,、瀑布模型,瀑布模型是将软件生命周期的各项活动，规定为按照固定顺序相连的若干个阶段性工作，形如瀑布流水，最终得到软件产品。,优点：,易于理解；调研开发的阶段性；强调早期计划及需求调查；确定何时能够交付产品及何时进行评审与测试。,缺点：需求调查分析只进行一次，不能适应需求变化；顺序的开发流程，使得开发中的经验教训不能反馈到该项目的开发中去；不能反映出软件开发过程的反复与迭代性；没有包含任何类型的风险评估；开发中出现的问题直到开发后期才能够显露，因此失去及早纠正的机会。,4.1.1 软件过程模型1、瀑布模型,问题定义,分析研究,需求分析,软件设计,编码,测试,维护,定义阶段,开发阶段,维护阶段,瀑布开发模型,问题定义分析研究需求分析软件设计编码测试维护定义阶段开发阶段,4.1.1,软件过程模型,2,、原型模型,根据客户需求在较短的时间内解决用户最迫切解决的问题，完成可演示的产品。这个产品只实现最重要功能，在得到用户的更加明确的需求之后，原型将丢弃。,需求分析,原型开发,原型评价,最终设计,系统实现,用户反馈,快速原型开发模型,4.1.1 软件过程模型2、原型模型需求分析原型开发原型评,4.1.1,软件过程模型,3,、增量模型和迭代模型,软件在实际开发过程中是按阶段进行的，逐步完善或深化系统的功能。,软件分阶段开发示意图,4.1.1 软件过程模型3、增量模型和迭代模型软件分阶段开,4.1.1,软件过程模型,3,、增量模型和迭代模型,增量开发,迭代开发,4.1.1 软件过程模型3、增量模型和迭代模型增量开发迭代,IBM RUP,IBM RUP,144,（,1,）、初始阶段,初始阶段的工作是将一个好的想法，发展为一个关于最终产品的构想，并定义产生的项目范围和业务用例。,工作的重点在于,理解所有的需求并决定开发的工作范围。,144（1）、初始阶段初始阶段的工作是将一个好的想法，发展为,145,初始阶段要明确的内容主要包括：,项目的软件范围和边界条件。要明确可操作的概念、可接受的原则以及产品的部分详细说明。,系统中最关键的业务用例。即系统应该为它的每个主要用户提供什么样的基本功能。,145初始阶段要明确的内容主要包括：项目的软件范围和边界条件,146,系统的大致构架，给出系统大致是什么样子。这个构架是试验性的，通常只是一个包括主要子系统的大致轮廓。,产品的费用和实践计划，以及对产品风险的评估。在这个阶段的风险评估中，重点在于确定最主要风险内容，以及风险的高低次序。,146系统的大致构架，给出系统大致是什么样子。这个构架是试验,147,描述项目的主要需求、特征和约束的前景文档。,初始的用例模型（大约是整个系统的,10%-20%,）。,项目词汇表。,初始项目计划。,业务用例。,风险评估文档和数据库。,一个或者多个可抛弃原型。,初始的构架文档。,初始阶段提交的产品主要包括：,147描述项目的主要需求、特征和约束的前景文档。初始阶段提交,148,生命目标里程碑主要评审的内容有：,项目相关人员是否就项目范围、成本估计和时间进度安排等达成一致。,项目的需求理解是否准确有效。,对于成本和进度安排的评估以及优先权、风险和开发过程的可信度如何。,实际成本和计划成本的对比情况。,已开发原型中系统构架的深度和广度是否已作为深入开发的基础。,148生命目标里程碑主要评审的内容有：项目相关人员是否就项目,149,（,2,）细化阶段,细化阶段的目标是详细分析问题领域，说明产品的绝大多数业务用例，设计出合理的系统构架，给出开发项目计划，评价项目中最可能出现的风险元素。,细,化阶段是四个阶段中最关键的阶段。该阶段结束时，最困难的“工程”可以认为已结束。,149（2）细化阶段细化阶段的目标是详细分析问题领域，说明产,150,工作的主要内容：,在细化阶段，根据项目的领域，大小和创新性，可能在一个或多个迭代中，建立一个可执行的架构。这一工作至少要处理初始阶段中识别的关键用例，关键用例通常也揭示了项目主要技术的风险。,150工作的主要内容：在细化阶段，根据项目的领域，大小和创新,151,细化阶段的成果是：,用例模型。定义所有已发现的用例，并完成至少,80,以上用例的描述，其中所有关键用例必须完成描述。,补充需求，包括非功能性需求以及任何与特定用例无关的需求。,创建可执行的构架基线。,一个修正后的风险表和商业用例。,一份整个项目的开发规划，包括粗略项目规划，显示“迭代”以及对每个迭代的评估准则。,指明被使用过程的更新过的开发用例。,用户手册的初始版本（可选）。,151细化阶段的成果是：用例模型。定义所有已发现的用例，并完,152,细化阶段结束是第二个重要的里程碑：,生命周期体系架构里程碑,。,此刻，检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。主要的审核标准包括：,152 细化阶段结束是第二个重要的里程碑：生命,153,产品的蓝图是否稳定；,体系结构是否稳定；,可执行的演示版是否显示风险要素已被处理和可靠的解决；,构建阶段的计划是否足够详细和精确；是否被可靠的审核基础支持；,如果当前计划在现有的体系结构环境中被执行而开发出完整系统，是否所有的风险承担人同意该蓝图是可实现的；,实际的费用开支与计划开支是否可以接受。,153产品的蓝图是否稳定；,154,（,3,）构造阶段,构造阶段是一个制造产品的过程，在这个阶段中逐步完善构想、构架和计划，直到将构架基线逐渐发展成完善的系统产品，并完全准备好移交给她的用户群为止。,构造阶段是最消耗资源的阶段，它会消耗掉整个项目开发中的大部分资源，所以这个阶段的重点在于管理资源和控制操作上，目的是优化