软件测试重点总结.ppt

《软件测试重点总结.ppt》由会员分享，可在线阅读，更多相关《软件测试重点总结.ppt（212页珍藏版）》请在三一办公上搜索。

1、1.1 什么是软件,1、软件的定义 与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。,2、软件的分类按照功能分：系统软件和应用软件按照技术架构分：单机版软件、C/S结构软件、B/S结构软件按照用户分：产品软件和项目软件按照开发的规模分：大、中、小,1.3 为什么要进行软件测试,软件总存在缺陷。只有通过测试，才可以发现软件缺陷。也只有发现了缺陷，才可以将软件缺陷从软件产品或软件系统中清理出去。软件中存在的缺陷给我们带来的损失是巨大的，这也说明了软件测试的必要性和重要性测试是所有工程学科的基本组成单元，自然也是软件开发的重要组成部分。测试人员水平越高，找到软件问题的时间就越早，

2、软件就越容易更正，产品发布之后越稳定，公司赚的钱也越多，微软就是一个典型的例子,1.4 什么是软件测试,1、软件测试的定义 软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码实现的最终审查，它是软件质量保证的关键步骤。通常对软件测试的定义有两种描述：定义1：软件测试是为了发现错误而执行程序的过程。定义2：在IEEE提出的软件工程标准术语中，软件测试被定义为：“使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别。”,1.4 什么是软件测试,1、软件测试的定义软件测试的正确定义 软件测试是由“验证（Verificati

3、on）”和“有效性确认（Validation）”活动构成的整体。验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。,1.4 什么是软件测试,2、软件测试的对象软件测试不等于程序测试。软件测试贯串于软件定义和开发的整个过程。软件开发过程中所产生的需求规格说明、概要设计规格说明、详细设计规格说明以及源程序都是软件测试的对象。,3、软件测试的原则尽早地和及时地测试；测试用例应当由测试数据和与之对应的预期结果这两部分组成；在程序提交测试后，应当由专门的测试人员进行测试；测试用例应包括合理的输入条件和不合理的输入条件；严格执行测

4、试计划，排除测试的随意性；充分注意测试当中的群体现象；应对每一个测试结果做全面的检查；保存测试计划、测试用例、出错统计和最终分析报告，为维护工作提供充分的资料。,第二章 软件测试的基本概念,主要内容：2.1 软件缺陷2.2 验证和确认2.3 软件测试分类2.4 软件测试阶段2.5 软件测试工作范畴,缺陷是质量的对立面,要了解什么是缺陷(defect)，就必须清楚“质量(Quality)”概念，因为缺陷是相对质量而存在的，违背了质量、违背了客户的意愿，不能满足客户的要求，就会引起缺陷或产生缺陷,2.1 软件缺陷,一、软件质量的内涵1、质量 质量是“产品或服务所满足明示或暗示需求能力的固有特性和特

5、征的集合”。,2.1 软件缺陷,一、软件质量的内涵2、软件质量 软件质量是软件产品满足规定的和隐含的与需求能力有关的全部特征和特性。包括：（1）软件产品质量满足用户要求的程度；（2）软件各种属性的组合程度；（3）用户对软件产品的综合反映程度；（4）软件在使用过程中满足用户要求的程度。,2.1 软件缺陷,一、软件质量的内涵3、软件质量模型,McCall软件质量模型,2.1 软件缺陷,一、软件质量的内涵3、软件质量模型,ISO 9126软件质量三层模型,2.1 软件缺陷,一、软件质量的内涵4、软件质量特性 功能性、易用性、可靠性、性能、容量 可测量性、可维护性、可移植性、可扩展性,2.1 软件缺陷

6、,一、软件质量的内涵5、软件质量的分类（1）软件质量的功能需求 软件质量的功能需求一般会在需求规格说明书等文档中给相应的描述。（2）软件质量的非功能需求 软件质量的非功能需求一般用下列特性描述：性能、有效性、可靠性、可维护性、兼容性、可扩展性、可移植性,2.1 软件缺陷,一、软件质量的内涵5、软件质量的分类（3）软件质量的用户需求能正常使用全部所需的功能，符合需求规格；功能强大，而且界面美观，易用；内容健康、有益于生活和工作。用户数据的安全、受保护和兼容；能及时得到新的产品或更完美的软件服务；软件可靠性很高，使用软件服务没有时间障碍,2.1 软件缺陷,一、软件质量的内涵5、软件质量的分类（4）

7、软件质量的企业需求 开发成本 可维护性 可扩展性 可移植性 兼容性,2.1 软件缺陷,二、软件缺陷1、软件缺陷的定义 软件缺陷（Bug）：任何程序、系统中的问题，和产品设计书的不一致性，不能满足用户的需求。IEEE(1983)729 软件缺陷一个标准的定义：从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。,2.1 软件缺陷,二、软件缺陷2、软件缺陷的表现功能、特性没有实现或部分实现设计不合理，存在缺陷实际结果和预期结果不一致运行出错，包括运行中断、系统崩溃、界面混乱数据结果不正确、精度不够用户不能接受的其他

8、问题，如存取时间过长、界面不美观,2.1 软件缺陷,二、软件缺陷3、软件缺陷产生的原因 微软开发者成功之路（之一）概括了以下7项主要原因：（1）项目期限的压力；（2）产品的复杂度；（3）沟通不良；（4）开发人员疲劳，压力过大或受到干扰；（5）缺乏足够的知识、技能和经验；（6）不了解客户的需求；（7）缺乏动力。,2.1 软件缺陷,二、软件缺陷4、软件缺陷的构成,图2-4 软件缺陷构成示意图,2.1 软件缺陷,二、软件缺陷5、修复软件缺陷的代价,软件缺陷随时间的推移带来的成本越来越大,2.2 验证和确认,一、验证和确认Verification：Are we building the product

9、 right？是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。验证产品满足规格设计说明书的一致性Validation：Are we building the right product?是否构造了正是用户所需要的软件？即是否正在做正确的事。验证产品所实现的功能是否满足用户的需求,2.2 验证和确认,二、评审 通过软件评审，可以更早地发现需求工程、软件设计等各个方面的问题，大大减少大量的后期返工，将质量成本从昂贵的后期返工转化为前期的缺陷发现。1、评审 评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。检验工作产品是否正确地

10、满足了以往工作产品中建立的规范。,2.2 验证和确认,二、评审2、评审分类管理评审技术评审文档评审流程评审,2.2 验证和确认,三、质量保证和测试的关系1、软件质量保证：是通过对软件产品有计划的进行评审和审计来验证软件是否合乎标准的系统工程。2、SQA的活动：提出软件质量要求；确定开发方案；阶段评审；测试管理文档化管理验证产品与相应文档和标准的一致性建立测量机制记录并生成报告,2.2 验证和确认,三、质量保证和测试的关系3、SQA与软件测试的关系 共同点：二者贯穿整个软件开发生命周期的流程。区别：SQA 是管理工作、审查对象是流程、强调以预防为主测试是技术工作、测试对象是产品、主要是以事后检查

11、关系：SQA指导测试、监控测试测试为SQA提供依据,2.3 软件测试的分类,2.3 软件测试的分类,按测试的对象或范围分类，如单元测试、文档测试、系统测试等）按测试目的分类，如功能测试、回归测试、性能测试、可靠性测试、安全性测试和兼容性测试等根据测试过程中被测软件是否被执行，分为静态测试和动态测试根据是否针对系统的内部结构和具体实现算法来完成测试，可分为白盒测试和黑盒测试,2.4 软件测试阶段,图2-8 软件测试阶段示意图,需求和设计审查,测试人员参与产品需求分析和系统设计，认真阅读有关文档，真正理解客户的需求和技术上的设计，检查需求说明书对产品描述的准确性、一致性等，检查系统设计的合理性和可

12、测试性等,单元测试,单元测试的对象是程序系统中的最小单元-模块或组件上，在编码阶段进行，针对每个模块进行测试，主要通过白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。多个模块可以平行地、对立地测试，通常要编写驱动模块和桩模块单元测试一般由编程人员和测试人员共同完成，而以开发人员为主单元测试包括代码评审，代码评审可以发现程序50%70%代码的缺陷。,集成测试,集成测试，也称组装测试、联合测试、子系统测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题 两种集成方式：一

13、次性集成方式和增殖式集成方式。,功能测试,功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用,系统测试,系统测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括恢复测试、安全测试、强度测试和性能测试等,验收测试&安装测试,验收测试的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样安装测试是指按照软件产品安装手册或相应的文档，在一个和用户使用该产品完全一样的环境

14、中或相当于用户使用环境中，进行一步一步的安装操作性的测试,2.5 软件测试的工作范畴,软件测试工作的组织与管理：制定测试策略、测试计划，确认所采用的测试方法与规范，控制测试进度，管理测试资源。测试工作的实施：编制符合标准的测试文档，搭建测试环境，开发测试脚本、与开发组织协作实现各阶段的测试活动,测试工作流程,3.1 白盒测试方法,白盒测试，也称结构测试或逻辑驱动测试，是已知程序的内部工作过程，清楚最终生成软件产品的计算机程序结构及其语句，按照程序的内部结构测试程序，测试程序内部的变量状态、逻辑结构、运行路径等，检验程序中的每条通路是否都能按预定要求正确工作，检查程序内部动作或运行是否符合设计规

15、格要求，所有内部成分是否按规定正常运行。,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

16、)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、语句覆盖【优点】：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。【缺点】：语句覆盖是最弱的逻辑覆盖。不能发现其中的逻辑错误。,一、逻辑覆盖法,2、判定覆盖 基本思想：设计足够多的测试用例，使得程序中的每个判定至少都获得一次“真”值和“假”值，也就是使程序中的每个取“真”分支和取“假”分支至少均经历一次，也称为“分支

17、覆盖”。,一、逻辑覆盖法,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、判定覆盖【优点】：判定覆盖具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。【缺点】：往往大部分的判定语句是由多个逻辑条件组合而成，若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。判定覆盖仍是弱的逻辑覆盖。,一、逻辑覆盖法,3、条件覆盖 基本思想：设计足够多的测试用例，使得程序中每个判定包含的每个条件的可能取值（真/假）都至少满

18、足一次。,一、逻辑覆盖法,3、条件覆盖,判断M表达式:条件 a0 取真 记为 T1 假 F1 条件 b0 取真 记为 T2 假 F2判断N表达式:条件 a1 取真 记为 T3 假 F3 条件 c1 取真 记为 T4 假 F4,一、逻辑覆盖法,3、条件覆盖,它覆盖了判定M的N分支和判断N的Y分支。,一、逻辑覆盖法,3、条件覆盖【优点】：增加了对条件判定情况的测试。【缺点】：条件覆盖不一定包含判定覆盖。例如，我们刚才设计的用例就没有覆盖判断M的Y分支和判断N的N分支。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。,一、逻辑覆盖法,4、判定条件覆盖 基本思想：设计足够多的测试用例，

19、使得程序中每个判定包含的每个条件的所有情况（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。,一、逻辑覆盖法,4、判定条件覆盖,按照判定条件覆盖的要求，我们设计的测试用例要满足如下条件：（1）所有条件可能至少执行一次取值；（2）所有判断的可能结果至少执行一次。,一、逻辑覆盖法,4、判定条件覆盖,一、逻辑覆盖法,4、判定条件覆盖【优点】：能同时满足判定、条件两种覆盖标准。【缺点】：判定/条件覆盖准则的缺点是未考虑条件的组合情况。,一、逻辑覆盖法,5、条件组合覆盖 基本思想：通过执行足够的测试用例，使得程序中每个判定的所有可能的条件取值组合都至少出现一次。,一、逻辑覆盖法

20、,5、条件组合覆盖设计组合条件如表所示：,一、逻辑覆盖法,5、条件组合覆盖条件组合覆盖的测试用例,一、逻辑覆盖法,5、条件组合覆盖【优点】：条件组合覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。【缺点】：线性地增加了测试用例的数量。,一、逻辑覆盖法,6、路径覆盖 基本思想：设计足够多的测试用例，要求覆盖程序中所有可能的路径。,一、逻辑覆盖法,6、路径覆盖,一、逻辑覆盖法,6、路径覆盖【优点】：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。【缺点】：需要设计大量、复杂的测试用例，使得工作量呈指数级增长，不见得把所有的条件组合都覆盖。,一、逻辑覆盖法,条件组合覆盖结合路径覆盖

21、,二、基本路径测试法,二、基本路径测试法,1、基本路径测试的思想基本路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。在程序控制流图的基础上，分析控制构造的环路复杂性，导出独立可执行路径集合，设计测试用例的方法。,二、基本路径测试法,2、基本路径测试的思想导出程序流程图的控制流图计算控制流图G的环路复杂性V(G)确定只包含独立路径的基本路径集设计测试用例,二、基本路径测试法,3、控制流图控制流图是对程序流程图进行简化后得到的，它可以更加突出的表示程序控制流的结构。控制流图中包括两种图形符号：结点和控制流线。结点由带标号的圆圈表示，可代表一个或多个语句、一个处理框序列和一

22、个条件判定框（假设不包含复合条件）。控制流线由带箭头的弧或线表示，可称为边。它代表程序中的控制流。,常见结构的控制流图,其中，包含条件的结点被称为判定结点，由判定结点发出的边必须终止于某一个结点，由边和结点所限定的范围被称为区域。,流图的画法,流图的画法,如果判断中的条件表达式是由一个或多个逻辑运算符连接的复合条件表达式，则需要改为一系列只有单个条件的嵌套的判断。,二、基本路径测试法,4、环路复杂度环形复杂度也称为圈复杂度，它是一种为程序逻辑复杂度提供定量尺度的软件度量。从程序的环形复杂度可导出基本路径集合中独立路径条数。独立路径是指程序中至少引入了一个新的处理语句集合或一个新条件的程序通路。

23、采用流图的术语，即独立路径必须至少包含一条在本次定义路径之前不曾用过的边。,计算环形复杂度的方法,环形复杂度以图论为基础，为我们提供了非常有用的软件度量。可用如下三种方法之一来计算环形复杂度：控制流图中区域的数量=环形复杂度。给定控制流图G的环形复杂度V(G)，定义为 V(G)=E-N+2 其中，E是控制流图中边的数量，N是控制流图中的节点数量。给定控制流图G的环形复杂度V(G)，也可定义为 V(G)=P+1 其中，P是控制流图G中判定节点的数量。,例如，在图示的控制流图中，一组独立的路径是path1：1-11path2：1-2-3-4-5-10-1-11path3：1-2-3-6-8-9-1

24、0-1-11path4：1-2-3-6-7-9-10-1-11路径 path1，path2，path3，path4组成了控制流图的一个基本路径集,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,（1）画出控制流图（2）计算环形复杂度（3）导出独立路径（用语句编号表示）（4）设计测试用例,（1）画出控制流图：（2）计算环形复杂度：10（条边）-

25、8（个节点）+2=4（3）导出独立路径（用语句编号表示）路径1：414 路径2：46714 路径3：4691013414 路径4：4691213414,（4）设计测试用例：,例 下面是选择排序的程序，其中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

26、 j=i+1;j list.n;j+)if(list.Vj list.Vk)k=j;/当前具最小关键码的对象 if(k!=i)Swap(list.Vi,list.Vk);/交换,（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）简单循环（2）嵌套循环（3）串接循环（4）不规则循环,三、循环测试,1.简单循环(迭代次数n)完全跳过循环 只经过循环一次 经过循环两次 经过循环m（m n）次 分别经过循环n-1,n,n+1 次,三、循环测试,2.嵌套循环在最里面的循环完成前面

27、所述的简单循环测试，同时设定外部循环的最小迭代次数逐步向外循环进行直到所有循环被测试,三、循环测试,2.嵌套循环,嵌套循环测试时各层循环控制变量的取值,三、循环测试,3.串行连接循环独立循环 可以分别看作简单循环测试依赖性循环 可以看作是嵌套循环4.其它非循环结构重新设计!,四、程序插装,程序插装是指在程序中设置断点或打印语句，在执行中了解程序中的一些动态特性。程序插装技术的研究涉及的问题：探测哪些信息。程序的什么位置设置探测点需要多少探测点,第三章 软件测试方法,主要内容：3.1 白盒测试方法3.2 黑盒测试方法3.3 静态测试和动态测试3.4 探查式测试3.5 测试用例设计,3.2 黑盒测

28、试方法,黑盒测试（也称功能测试或数据驱动测试）把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据需求规格说明书，检查程序的功能是否符合它的功能说明。,功能测试数据驱动测试,3.2 黑盒测试方法,黑盒测试常用于发现以下错误能否正确地接受输入数据，能否产生正确的输出信息；是否有不正确或遗漏的功能；功能操作逻辑的合理性；界面是否出错；安装过程中是否出现问题；系统初始化问题。,3.2 黑盒测试方法,常用的方法 等价类划分法 边界值分析法 判定表方法 因果图法 正交试验法 功能图法 错误推测法,3.2.1 等价类划分方法,将程序可能的输入数据分成若干个子集，从每个子集选取一

29、个代表性的数据作为测试用例，等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的分为有效等价类和无效等价类。在分析需求规格说明的基础上划分等价类，列出等价类表,设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。经过正反的测试才能确保软件具有更高的可靠性。,确定等价类的方法（1）,在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类,value,在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。,确定等价类的方法（2）,not member of set,

30、member of set,在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类,确定等价类的方法（3）,Boolean,Non-Boolean,确定等价类的方式(4),在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。,个人月收入-x 税率 x 101600 45%,确定等价类的方式(5),在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。,等价类测试用例-Example,等价类1:Integer等价类2:Decimal fraction等价类3

31、:Negative等价类4:Invalid input,根据等价类创建测试用例的步骤,a)建立等价类表，列出所有划分出的等价类：为每个等价类规定一个唯一的编号；设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类重复c)，最后使得所有有效等价类均被测试用例所覆盖；设计一个新的测试用例，使其只覆盖一个无效等价类。重复e)使所有无效等价类均被覆盖。,3.2.2 边界值分析方法,边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。设计方法

32、：确定边界情况（输入或输出等价类的边界）选取正好等于、刚刚大于或刚刚小于边界值作为测试数据,确定边界值的方法,如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。,确定边界值的方法（2）,如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。,Test cases for ABS(x):class x=0,ar

33、bitrary value x=100classes x=0,on boundary:x=0classes x=0,below and above:x=-1,x=1,正常值（有效类）:X1=123123边界值:X2=12345边界值:X3=1234567边界值:X4=1边界值:X5=0无效类的值:X6=-123123无效类的值:X7=asdasd其它?,示例2,测试 限制性用户输入：6位正整数,示例3,Test cases:任意的正常值:随机选择几个选项 边界值:选择所有选项 边界值:一个都不选边界值:选择一个选项,二进制,0 和 1,byte 由8 bits 构成,字由4 bytes构成,A

34、SCII Table,字符编辑域,DefaultEmptyBlankNullZeroNone,一些特殊的边界值,数值字符位置数量速度位置体积,First/last，First-1/Last+1Min/Max，Min-1/max+1Star/Finish，Start-1/Finish+1Empty/FullLess than empty/more than fullSlower/FasterLargest/SmallestOver/Under，just Over/Just UnderShortest/Longest,3.2.3 判定表方法,在实际应用中，许多输入是由多个因素构成，而不是单一因素，

35、这时就需要多因素组合分析。对于多因素，有时可以直接对输入条件进行组合设计，不需要进行因果分析，即直接采用判定表方法。一个判定表由“条件和活动”两部分组成，也就是列出了一个测试活动执行所需的条件组合，所有可能的条件组合定义了一系列的选择，而测试活动需要考虑每一个选择。,判定表元素,条件桩，列出问题的所有条件动作桩：列出可能针对问题所采取的操作条件项：针对所列条件的具体赋值动作项：列出在条件项（各种取值）组合情况下应该采取的动作。规则：任何一个条件组合的特定取值及其相应要执行的操作。,判定表方法步骤,列出所有的条件桩和动作桩；填入条件项；填入动作项，制定初始判定表；简化、合并相似规则或者相同动作,

36、示例 见表3-12和3-13,3.2.4 因果图法,1)因果图的适用范围 如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。,2)用因果图生成测试用例的基本步骤(1)分析软件规格说明描述中，哪些是原因(即输入条件或输入条件的等价类)，哪些是结果(即输出条件)，并给每个原因和结果赋予一个标识符。(2)分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系?根据这些关系，画出因果图。,(3)由于语法或环境限制，有些

37、原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。(4)把因果图转换成判定表。(5)把判定表的每一列拿出来作为依据，设计测试用例。,2)用因果图生成测试用例的基本步骤（续）,在因果图中出现的基本符号：通常在因果图中用Ci表示原因，用Ei表示结果，各结点表示状态，可取值“0”或“1”。“0”表示某状态不出现，“1”表示某状态出现。主要的原因和结果之间的关系有:,表示约束条件的符号 为了表示原因与原因之间，结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束条件的符号。,例如，有一个处理单价为5角钱的饮料的自动售货机软件测试

38、用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，押下橙汁或啤酒的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示零钱找完的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示零钱找完的红灯灭，在送出饮料的同时退还5角硬币。”,(1)分析这一段说明，列出原因和结果原因:1.售货机有零钱找 2.投入1元硬币 3.投入5角硬币 4.押下橙汁按钮 5.押下啤酒按钮建立中间结点，表示处理中间状态11.投入1元硬币且押下饮料按钮12.押下橙汁或啤酒的按钮13.应当找5角零钱并且售货机有零钱找14.钱已付清,结果：21.售货机零钱找完灯亮 22.退还

39、1元硬币 23.退还5角硬币 24.送出橙汁饮料 25.送出啤酒饮料(2)画出因果图。所有原因结点列在左边，所有结果结点列在右边。(3)由于 2 与 3，4 与 5 不能同时发生，分别加上约束条件E。(4)因果图(5)转换成判定表,例2：某个软件规格说明中包含以下要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改；但如果第一列字符不正确，则输出信息L；如果第二列字符不是数字，则输出信息M。,(1)分析这一段说明，列出原因和结果原因:C1.第一列字符是A C2.第一列字符是B C3.第二列字符是一个数字 建立中间结点，表示处理中间状态 11.第一列字符是A或B 结果

40、：E1.修改文件 E2.输出信息L E3.输出信息M,判定表,3.2.5 正交试验法,1、为什么要采用正交试验法？在许多应用系统的测试工作中，不会象判断三角形那样简单，而实际项目中输入条件的因素很多，而且每个因素也不能简单用“是”和“否”来回答。比如，微软Powerpoint程序的打印测试，也需要考虑4个因素，每个因素也有多个选项.打印范围分：全部、当前幻灯片、给定范围打印内容分：幻灯片、讲义、备注页、大纲视图打印颜色/灰度分:彩色、灰度、黑白打印效果分：幻灯片加框和幻灯片不加框。,实例,员工号（ID）。员工姓名（Name）。员工邮件地址（Mail Address）,信息系统中，员工信息查询功

41、能是常见的。例如，设有3个独立的查询条件，以获得特定员工的个人信息,3.2.6 功能图法,每个程序的功能通常由静态说明和动态说明组成静态说明描述了输入条件和输出条件之间的对应关系动态说明描述了输入数据的次序或者转移的次序。功能图法就是为了解决动态说明问题的一种测试用例的设计方法 功能图由状态迁移图（state transition diagram，STD）和逻辑功能模型（logic function model，LFM）构成,状态迁移图,状态迁移图，描述系统状态变化的动态信息动态说明，由状态和迁移来描述，状态指出数据输入的位置（或时间），而迁移则指明状态的改变。,如何设计测试用例,功能图法设计

42、测试用例，就是如何覆盖软件所表现出来的所有状态，可以转化为两个层次的测试用例从逻辑功能模型（决策表或因果图）导出局部测试用例，覆盖各个状态的各种输入数据的组合从状态迁移图导出整体的测试用例，以覆盖系统（程序）控制的逻辑路径功能图法是综合运用黑盒方法和白盒方法来设计测试用例，即整体上选用白盒方法路径覆盖、分支和条件覆盖等，而局部上选用的是黑盒方法决策表或因果图方法,3.2.7 错误推测法,人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。,

43、3.3 静态测试和动态测试,将需求和设计的评审也纳入测试的范畴，可以看作是广义测试静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审等静态分析的查错和分析功能是其他方法所不能替代的，可以采用人工检测和计算机辅助静态分析手段进行检测，但越来越多地采用工具进行自动化分析动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统信息，对系统行为进行验证。,3.4 探查式测试 1、传统的结构化测试先设计后运行；预先设计的测试用例可能不能起到应有的作用；,2、探查式测试边设计边运行；依靠测试人员在测试过程中的主动性和创造性；,3.4 探查式测试 3、探查式测试的作用可以设计更

44、有效的测试用例；可以作为传统的结构化测试的补充；尽可能多地发现有价值的缺陷；可以依据缺陷群集现象来确定测试重点。,3.4 探查式测试 4、探查式测试的步骤确定探查的范围和重点；拟出可能的探查方案（缺陷讨论会、攻击测试方法）；评估提出的探查方案，决定要采取的最佳方案；确定实施计划；实施探查方案，记录实施结果；判断是否进行下一轮探查。,3.4 探查式测试,5、缺陷讨论会,参会人员：测试人员、开发人员、用户、其他相关人员人数510人；主持人事先把会议议题通知参会人员；会上采取轮流发言制；确实没有新的设想提出或时间用完，结束会议。,3.4 探查式测试,6、攻击测试方法,（1）用户界面攻击输入和输出攻击

45、数据和计算攻击（2）系统接口攻击文件系统接口攻击软件系统接口攻击,良好测试用例的特征,可以最大程度地找出软件隐藏的缺陷可以最高效率的找出软件缺陷可以最大程度地满足测试覆盖要求既不过分复杂、也不能过分简单使软件缺陷的表现可以清楚的判定测试用例包含期望的正确的结果待查的输出结果或文件必须尽量简单明了不包含重复的测试用例测试用例内容清晰、格式一致、分类组织,测试用例设计考虑因素,具有代表性、典型性寻求系统设计、功能设计的弱点测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分析怎样使得这样的错误或者异常能够发生考虑用户实际的诸多使用场景示例1：P.313 示例2:P.315,14

46、.1.4 测试用例设计的基本原则,尽量避免含糊的测试用例尽量将具有相类似功能的测试用例抽象并归类尽量避免冗长和复杂的测试用例,3.5 测试用例设计,5、测试用例的设计原则（1）保证测试用例的明确性；（2）保证测试用例的代表性；（3）保证测试用例的简洁性；,4.1 测试过程模型,4.1.1 软件过程模型4.1.2 用V模型诠释软件测试过程4.1.3 W模型,4.1.1 软件过程模型,1、瀑布模型瀑布模型是将软件生命周期的各项活动，规定为按照固定顺序相连的若干个阶段性工作，形如瀑布流水，最终得到软件产品。优点：易于理解；调研开发的阶段性；强调早期计划及需求调查；确定何时能够交付产品及何时进行评审与

47、测试。缺点：需求调查分析只进行一次，不能适应需求变化；顺序的开发流程，使得开发中的经验教训不能反馈到该项目的开发中去；不能反映出软件开发过程的反复与迭代性；没有包含任何类型的风险评估；开发中出现的问题直到开发后期才能够显露，因此失去及早纠正的机会。,4.1.1 软件过程模型,2、原型模型根据客户需求在较短的时间内解决用户最迫切解决的问题，完成可演示的产品。这个产品只实现最重要功能，在得到用户的更加明确的需求之后，原型将丢弃。,快速原型开发模型,4.1.1 软件过程模型,3、增量模型和迭代模型 软件在实际开发过程中是按阶段进行的，逐步完善或深化系统的功能。,软件分阶段开发示意图,4.1.1 软件

48、过程模型,3、增量模型和迭代模型,IBM RUP,144,（1）、初始阶段,初始阶段的工作是将一个好的想法，发展为一个关于最终产品的构想，并定义产生的项目范围和业务用例。工作的重点在于理解所有的需求并决定开发的工作范围。,145,初始阶段要明确的内容主要包括：,项目的软件范围和边界条件。要明确可操作的概念、可接受的原则以及产品的部分详细说明。系统中最关键的业务用例。即系统应该为它的每个主要用户提供什么样的基本功能。,146,系统的大致构架，给出系统大致是什么样子。这个构架是试验性的，通常只是一个包括主要子系统的大致轮廓。产品的费用和实践计划，以及对产品风险的评估。在这个阶段的风险评估中，重点在

49、于确定最主要风险内容，以及风险的高低次序。,147,描述项目的主要需求、特征和约束的前景文档。初始的用例模型（大约是整个系统的10%-20%）。项目词汇表。初始项目计划。业务用例。风险评估文档和数据库。一个或者多个可抛弃原型。初始的构架文档。,初始阶段提交的产品主要包括：,148,生命目标里程碑主要评审的内容有：,项目相关人员是否就项目范围、成本估计和时间进度安排等达成一致。项目的需求理解是否准确有效。对于成本和进度安排的评估以及优先权、风险和开发过程的可信度如何。实际成本和计划成本的对比情况。已开发原型中系统构架的深度和广度是否已作为深入开发的基础。,149,（2）细化阶段,细化阶段的目标是

50、详细分析问题领域，说明产品的绝大多数业务用例，设计出合理的系统构架，给出开发项目计划，评价项目中最可能出现的风险元素。细化阶段是四个阶段中最关键的阶段。该阶段结束时，最困难的“工程”可以认为已结束。,150,工作的主要内容：,在细化阶段，根据项目的领域，大小和创新性，可能在一个或多个迭代中，建立一个可执行的架构。这一工作至少要处理初始阶段中识别的关键用例，关键用例通常也揭示了项目主要技术的风险。,151,细化阶段的成果是：,用例模型。定义所有已发现的用例，并完成至少 80 以上用例的描述，其中所有关键用例必须完成描述。补充需求，包括非功能性需求以及任何与特定用例无关的需求。创建可执行的构架基线