软件测试重点

1、第一章软件测试概述1、软件测试 是对软件需求分析、设计规格 说明和编码的最终复审， 是软件质量保证的 关键步骤。2、软件故障与硬件故障导致系统失效的比 例为： 10:13、软件缺陷的典型例子 ：（1）千年虫问题（银行计算利息为负数）（2）爱国者导弹防御系统（系统时钟错误 积累，使导弹延时， 美国的导弹误杀了美国 的士兵）（3）美国火星登陆事故（接口错误，没有 测试，导致飞船加速下降，撞成碎片）（4）Intel 奔腾芯片缺陷（计算错误，损失 巨大）（5）Windows 2000 安全漏洞（系统，网站 等受到攻击）（6）迪斯尼的圣诞节礼物（7）冲击波 ”计算机病毒4、软件缺陷产生的原因：（1）、开

2、发人员不太了解需求，软件需 求分析不够全面、准确是导致软件缺陷 的最主要原因。（2）、软件系统越来越复杂，开发人员 不太可能精通所有的技术 。（3）、技术文档普遍比较糟糕，文档本 身就有错误。（4）、软件需求、设计报告、程序经常 发生变更，每次变更都可能产生新的错 误。（5）、任何人在编程时都可能犯错误， 导致程序中有错误。（6）、人们常处于进度的压力之下，急 忙之下容易产生错误。（7）、人们过于自信， 不真实的 “没问题 将产生真正的问题 。（8）、软件设计和编码过程中的失误也 会导致软件缺陷的产生。（9）、但很多情况下，不正确的软件设 计是不正确的需求分析引起的，编码阶 段出现的错误则是由

3、需求分析和软件设 计不够完善、准确引起的。5、软件测试的目的和意义 软件测试的根本目的是以尽可能少的时间 和人力发现并改正软件中潜在的各种故障 及缺陷，提高软件的质量。6、软件测试原则：（1）尽早和不断测试（2）每个程序员都应当测试自己的程序 （份内之事） ，但是不能作为该程序已经 通过测试的依据（所以项目需要独立测 试人员）（3）完全测试是不可能的（ 4）测试能提高软件的质量， 但是提高 质量不能依赖测试（ 5）测试只能证明错误存在， 不能证明 错误不存在 （6）测试的主要困难是不知道如何进行 有效地测试，也不知道什么时候可以放 心地结束测试（7） 80-20 原则： 80的错误聚集在 20

4、的模块中，经常出错的模块改错后 还会经常出错（ 8）测试应当循序渐进， 不要企图一次 性干完，注意 “欲速则不达 ”7、软件测试过程（1）单元测试（模块测试） 目的 :检测程序模块中有无故障存在 对象 :软件设计的最小单位，与程序设计和 编程实现关系密切（2）集成测试（组装测试、子系统测试） 目的 :发现与接口有关的模块之间的问题 方法 ：非增式集成测试法和增式集成测试法 分类： 非增式集成测试法 对每一个模块进行单元测试 在此基础上按程序结构图将各模块连 接起来，把连接后的程序当作一个整体进行 测试 增式集成测试法 不断地把待测模块连接到已测模块集（或其子集 ）上，对待测模块进行测试，直到

5、最后一个模块测试完毕（3） 确认测试目的 ：对软件产品进行评估以确定其是否满 足软件需求的过程确认测试的结果 ： a.测试结果满足需求规格 说明； b.与需求规格有偏离。（ 4） 系统测试 目的 ：针对系统中各个组成部分进行的综合 性检验，证明系统的性能 测试人员要求 ： 系统开发人员不能进行系统测试。 系统开发组织不能负责系统测试。（5） 验收测试目的 ：向用户表明所开发的软件系统能够像 用户所预定的那样工作 主要任务 ： 明确规定验收测试通过的标准； 确定验收测试方法； 确定验收测试的组织和可利用的资源； 确定测试结果的分析方法； 制定验收测试计划并进行评审； 设计验收测试的测试用例； 审

6、查验收测试的准备工作； 执行验收测试； 分析测试结果，决定是否通过验收。8、软件开发过程 正规的软件开发过程一般包括六个阶段， 即：第一阶段 计划第二阶段 需求分析（开发人员和用户 共同决定）第三阶段 设计（包括概要设计和详细 设计）第四阶段 程序编写第五阶段 测试 （单元，集成，确认，验 收）第六阶段 运行和 / 维护 这六个阶段构成了软件的生存周期。9、软件测试与软件开发的关系 软件测试在软件开发中的作用：项目规划阶段： 负责整个测试阶段的监 控。需求分析阶段：确定测试需求分析，制 定系统测试计划。 测试需求分析是指产品生 存周期中测试所需的资源、配置、各阶段评 审通过的标准等。概要设计和

7、详细设计阶段： 制定集成测 试计划和单元测试计划。编码阶段： 开发相应的测试代码或测试 脚本。测试阶段：实施测试，并提交相应的测 试报告。10、软件测试在软件开发中的作用 测试在软件开发中占有重要地位 测试成本占有开发成本的近一半11、软件测试工具（1）、白盒测试工具 静态测试工具 职能 ：主要集中在需求文档、 设计文档以及 程序结构上， 可以进行类型分析、 接口分析、 输入输出规格说明分析等。工具 ： McCabe & Associates 公司开发的 McCabe Visual Quality ToolSet 分析工具； ViewLog 公司开发的 LogiScope 分析工具；

8、Software Research 公 司 开 发 的 TestWork/Advisor 分 析 工 具 及 Software Emancipation 公司开发的 Discover 分析工 具，北京邮电大学开发的 DTS 缺陷测试工 具等。动态测试工具职能 ：功能确认与接口测试、覆盖率分析、 性能分析、内存分析等工具 ： Compuware 公司开发的 DevPartner 软件、 Rational 公司研制的 Purify 系列等。（2）、黑盒测试工具工具 ：Rational 公司的 TeamTest，Compuware 公司的 QACenter 。分类： 功能测试工具和性能测试工具习题

9、11 什么是软件测试？软件测试的目的和意义 是什么？2 简述软件测试过程。3 简述软件测试过程 V 模型和软件测试过程 W 模型的主要区别。软件测试过程 V 模型 特点：非常明确地表明了测试的不同级别， 清晰地展示了软件测试与开发之间的关系。 软件开发是一个自顶向下逐步细化的过程， 软件测试则是一个自底向上逐步集成的过 程。软件测试过程 W 模型 形象的展示了开发与测试的并行，测 试贯穿与开发过程。第二章 黑盒测试1、黑盒测试 是一种常用的软件测试方法， 它将被测软件看作一个打不开的黑盒， 主要 根据功能需求设计测试用例，进行测试 黑盒测试的基本概念 黑盒测试是一种从软件外部对软件实施的 测试

10、，也称功能测试或基于规格说明的测 试。其基本观点是： 任何程序都可以看作是 从输入定义域到输出值域的映射， 这种观点 将被测程序看作一个打不开的黑盒， 黑盒里 面的内容 （实现 ）是完全不知道的，只知道软 件要做什么。 因无法看到盒子中的内容，所 以不知道软件是如何实现的， 也不关心黑盒 里面的结构， 只关心软件的输入数据和输出 结果。目的： 黑盒测试是从用户观点出发的测试， 其目的 是尽可能发现软件的外部行为错误。 在已知 软件产品功能的基础上，1）检测软件功能能否按照需求规格说明书 的规定正常工作，是否有功能遗漏；2）检测是否有人机交互错误，是否有数据 结构和外部数据库访问错误，是否能恰

11、当地接收数据并保持外部信息（如数据 库或文件）等的完整性；3）检测行为、性能等特性是否满足要求等；4）检测程序初始化和终止方面的错误等。优点 ：黑盒测试着眼于软件的外部特征， 通过 上述方面的检测， 确定软件所实现的功能是 否按照软件规格说明书的预期要求正常工 作.两个显著的优点： 黑盒测试与软件具体实现无关，所以如果软件实现发生了变化， 测试用例仍然可以 使用； 设计黑盒测试用例可以和软件实现同时 进行，因此可以压缩项目总的开发时间。2 几种常用的黑盒测试方法 等价类划分边界值分析法因果图法决策表法（ 1）等价类划分法 是一种典型的黑盒测试 方法，它完全不考虑程序的内部结构， 只根 据程序规

12、格说明书对输入范围进行划分， 把 所有可能的输入数据， 即程序输入域划分为 若干个互不相交的子集， 称为等价类， 然后 从每个等价类中选取少数具有代表性的数 据作为测试用例，进行测试。所谓等价类是指 输入域 的某个互不相交的 子集合，所有等价类的并便是整个输入域。等价类划分测试用例设计 在设计测试用例时应同时考虑有效 等价类和无效等价类测试用例的设计。 根据 等价类表设计测试用例，具体步骤如下：（1）为每个等价类规定一个唯一的编号。 （ 2） 设计一个新的测试用例，尽可能多地 覆盖尚未被覆盖的有效等价类，重复这一 步，直到测试用例覆盖了所有的有效等价 类。（ 3） 设计一个新的测试用例，使其覆

13、盖并 且只覆盖一个还没有被覆盖的无效等价类。 重复这一步， 直至测试用例覆盖了所有的无 效等价类。（2）、边界值分析法 大量的软件测试实践表明， 故障往往出现在 定义域或值域的边界上，而不是在其内部。 为检测边界附近的处理专门设计测试用例， 通常都会取得很好的测试效果。 因此边界值 分析法是一种很实用的黑盒测试用例方法， 它具有很强的发现故障的能力。边界条件1 边界是一些特殊情况。程序在处理大量中 间数值时都是正确， 但是在边界处可能出现 错误。边界条件就是软件计划的操作界限所在的边缘条件。2 一些可能与边界有关的数据类型有： 数值， 速度，字符，地址，位置，尺寸，数量等。在等价类划分基础上进

14、行边界值分析测试 的基本思想是， 选取正好等于、 刚刚大于或 刚刚小于等价类边界的值作为测试数据， 而 不是选取等价类中的典型值或任意值做为 测试数据。（3）、因果图法因果图法 是基于这样的一种 思想 ：一些程序 的功能可以用判定表 （或称决策表）的形式 来表示， 并根据输入条件的组合情况规定相 应的操作。因果图法的定义 ：是一种利用图解法分析输 入的各种组合情况， 从而设计测试用例的方 法，它适合于检查程序输入条件的各种组合 情况。采用因果图法设计测试用例的步骤：（1）根据程序规格说明书描述，分析并确 定因（输入条件）和果（输出结果或程序状 态的改变），画出因果图。（2）将得到的因果图转换为

15、决策表（判定 表）。（ 3 ）为决策表中每一列所表示的情况设计 一个测试用例。使用 因果图法的优点：（1）考虑到了输入情况的各种组合以及各 个输入情况之间的相互制约关系。（2）能够帮助测试人员按照一定的步骤， 高效率的开发测试用例。（3）因果图法是将自然语言规格说明转化 成形式语言规格说明的一种严格的方法， 可 以指出规格说明存在的不完整性和二义性。 因果图法测试用例的设计步骤 : （1）确定软件规格中的原因和结果。分析 规格说明中哪些是原因 （即输入条件或输入 条件的等价类） ，哪些是结果（即输出条件） ， 并给每个原因和结果赋予一个标识符。（2）确定原因和结果之间的逻辑关系。分 析软件规格

16、说明中的语义， 找出原因与结果 之间、原因与原因之间对应的关系，根据这 些关系画出因果图。（3）确定因果图中的各个约束。由于语法 或环境的限制，有些原因与原因之间、 原因 与结果之间的组合情况不可能出现。 为表明 这些特殊情况， 在因果图上用一些记号表明 约束或限制条件。（ 4 ）把因果图转换为决策表。（5）根据决策表设计测试用例。（4）、决策表法 在一个程序中， 如果输入输出比较多， 输入 之间和输出之间相互制约的条件比较多， 在 这种情况下适宜用决策表 ，可以很清楚的表 达它们之间的各种复杂关系。决策表决策表 是把作为条件的所有输入的各 种组合值以及对应输出值都罗列出来而形 成的表格。概念

17、：决策表是分析和表达多逻辑条件 下执行不同操作的情况的工具。优点：它能够将复杂的问题按照各种可 能的情况全部列举出来，简明并避免遗漏。 因此，利用决策表能够设计出完整的测试用 例集合。在一些数据处理问题当中，某些操 作的实施依赖于多个逻辑条件的组合，即： 针对不同逻辑条件的组合值， 分别执行不同 的操作。决策表很适合于处理这类问题。决策表通常由条件桩、 条件项、 动 作桩和动作项 4 部分组成。构造决策表可采用以下 5 个步骤： （1）列出所有的条件桩和动作桩。（2）确定规则的个数。（3）填入条件项。（4）填入动作项，得到初始决策表。（5）简化决策表，合并相似规则。 决策表测试法适用于具有以下

18、特征 的应用程序：if-then-else 逻辑突出；输入变量之间 存在逻辑关系；涉及输入变量子集的计算； 输入与输出之间存在因果关系。适用于使用决策表设计测试用例的条件： 规格说明以决策表形式给出，或较 容易转换为决策表。条件的排列顺序不会也不应影响执 行的操作。规则的排列顺序不会也不应影响执 行的操作。当某一规则的条件已经满足，并确 定要执行的操作后，不必检验别的 规则。如果某一规则的条件要执行多个操 作，这些操作的执行顺序无关紧要。3、黑盒测试方法的比较与选择 几种典型的黑盒测试方法，这些测试方 法的共同特点是，它们都把程序看作是 一个打不开的黑盒，只知道输入到输出 的映射关系，根据软件

19、规格说明设计测 试用例。在等价类分析测试中，通过等价类 划分来减少测试用例的绝对数量。 边界值分析方法则通过分析输入变 量的边界值域设计测试用例。 在因果图测试方法和决策表测试 中，通过分析被测程序的逻辑依赖 关系，构造决策表，进而设计测试 用例。4、黑盒测试工具介绍 黑盒测试是在已知软件产品应具有的功能 的条件下， 在完全不考虑被测程序内部结构 和内部特性的情况下， 通过测试来检测每个 功能是否都按照需求规格说明的规定正常 使用。黑盒测试工具又分为： 功能测试工具和 性能测试工具。 功能测试工具 : 功能测试工具主要用于 检测被测程序能否达到预期的功能要求并 能正常运行。 性能测试工具 :

20、性能测试工具主要用于 确定软件和系统性能。黑盒功能测试工具 ，如 Mercury Interactive 公司的 WinRunner ， IBM Rational 公司的 TeamTest 和 Robot ， Compuware 公 司 的 QACenter 等。第三章 软件测试用例设计1、黑盒测试方法： 等价类划分、边界值分 析、决策表测试 、 因果图法 白盒测试： 数据流测试、逻辑覆盖、路径测 试 面向对象测试： 有限状态机、 Petri 网、正交 阵列法、 UML 测试2、白盒测试 (White Box Testing,Glass Box Testing)又称为结构测试、逻辑驱动测试或

21、基于程序的测试。 一般用来分析程序的内部 结构。基于覆盖的测试技术 - 白盒测试要求对被 测程序的结构特性做到一定程度的覆盖， 并 以软件中的某类成分是否都已经得到测试 为准则来判断软件测试的充分性。 白盒测试的目的：白盒测试通过检查软件内部的逻辑结 构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点， 检查程序 的状态， 以确定实际运行状态与预期状态是 否一致。白盒测试的特点： 依据软件设计说明书进行测试； 对程序内部细节的严密检验； 针对特定条件设计测试用例； 对软件的逻辑路径进行覆盖测试。 白盒测试的实施过程：1. 测试计划阶段：2. 测试设计阶段： 依据程序设计说明书， 按照

22、一定规范化的方 法进行软件结构划分和设计测试用例。3. 测试执行阶段：4. 测试总结阶段：路径测试1)控制流图 程序流程图是一种程序控制结构的图 形表示方式。 在程序流程图上的处理框内常 常标明了处理要求或条件。控制流图：为了更加突出控制流的结 构， 需要对程序流程图做些简化， 这种简化 了的流程图称为控制流图。控制流图中的符号： 节点： 以标有编号的圆圈表示， 代表程序 流程图中矩形框所表示的处理、 菱形表示的 分支及多选择结构点。 控制流线： 以带箭头的直线或弧表示， 与 程序流程图中的数据流线是一致的， 表明了 控制的顺序。 控制流线通常标有名字， 如图 中所标的 a、b、c 等。程序流

23、程图 控制流图转换的原则如下 ： 控制流图中的每一个节点可以表示程序流 程图中矩形框所表示的处理； 菱形表示的两个甚至多个出口判断； 多条流线相交的汇合点。2） 基本路径测试法 是在程序控制流图的基 础上，通过分析控制构造的环路（圈）复杂 性，导出基本可执行路径集合，从而设计测 试用例的方法。逻辑覆盖语句覆盖 判定覆盖（分支覆盖） 条件覆盖判定 /条件覆盖条件组合覆盖 语句覆盖准则在测试中， 要求程序中的每条语句都得到 运行。在控制流图中，要求所有的语句都被 运行的充分必要条件是覆盖图中的所有节 点。语句覆盖准则的优缺点：优点 ：可以很直观地从源代码得到测试用 例，无须细分每条判定表达式。缺点

24、 ：由于这种测试方法仅仅针对程序逻辑 中显式存在的语句， 但对于隐藏的条件是无 法测试的。 如在多分支的逻辑运算中无法全 面的考虑。语句覆盖是最弱的逻辑覆盖。判定覆盖准则（分支覆盖）要求在测试中， 每个分支都至少获得一 次“真”和一次 “假”。在控制流图中，分支表 现为图中的一条有向边。分支（判定） 覆盖只能作到分支 （判定） 覆盖仍无法确定判断内部条件的错误。 判定覆盖优缺点：优点 ：分支（判定）覆盖具有比语句覆盖更 强的测试能力。同样分支（判定）覆盖也具 有和语句覆盖一样的简单性， 无须细分每个 判定就可以得到测试用例。缺点 ：往往大部分的分支（判定）语句是由 多个逻辑条件组合而成， 若仅

25、仅判断其整个 最终结果，而忽略每个条件的取值情况，必 然会遗漏部分测试路径。 判定覆盖仍是弱的 逻辑覆盖。条件覆盖 一个分支的条件是由谓词组成的。 单个谓词 称为原子谓词。（1）原子谓词覆盖准则（条件覆盖） 要求每个复合谓词所包含的每一个原 子谓词都至少获得一次 “真”和一次 “假”。即 要使每个判断中每个条件的可能取值至少 满足一次。条件覆盖优缺点：优点 ：增加了对条件判定情况的测试， 增加 了测试路径。缺点 ：原子谓词（条件）覆盖不一定包含分 支（判定）覆盖。原子谓词（条件）覆盖只 能保证每个条件至少有一次为真， 而不考虑 所有的判定结果。判定 /条件覆盖准则 要求不仅每个复合谓词所包含的

26、每一 个原子谓词都至少获得一次 “真 ”和一次 “假”，而且每个复合谓词本身也至少获得一 次“真”和一次 “假 ”。即使得判断中每个条件 的所有可能至少出现一次， 并且每个判断本 身的判定结果也至少出现一次。判定 /条件覆盖优缺点：优点 ：能同时满足判定、 条件两种覆盖标准。 缺点：分支-谓词（判定 /条件）覆盖准则的 缺点是未考虑条件的组合情况。从表面来 看，它测试了所有条件的取值。但实际并不 是这样。因为一些条件往往掩盖了另一些条 件。对于条件表达式 （A >1）&&（B=0） 来说， 只要 （A > 1）的测试为真，才需测试 （B=0） 的 值来确定此表达式的

27、值， 但是若 （A >1）的测 试值为假时，不需再测 （B=0） 的值就可确定 此表达式的值为假，因而 B=0 没有被检查。 同理，对于 （A=2）|（X > 1）这个表达式来说， 只要 （A=2） 测试结果为真，不必测试 （X >1） 的结果就可确定表达式的值为真。 所以对于 判定 /条件覆盖来说，逻辑表达式中的错误 不一定能够查得出来。条件组合覆盖准则要求每个谓词 （判定 ）中条件的各种可能 组合都至少出现一次。条件组合覆盖优缺点：优点 ：复合谓词（条件组合）覆盖准则满足 分支（判定）覆盖、原子谓词（条件）覆盖 和分支 -谓词（判定 /条件）覆盖准则，是前 述几种覆盖标准

28、中最强的。缺点 ：线性地增加了测试用例的数量。逻辑覆盖测试的 5 种标准几种覆盖准则间的关系白盒测试策略1：桌前检查 桌前检查是在程序员实现特定功能后， 进行 单元测试之前，对源代码进行的初步检查。 该项工作的参与人员为开发人员， 重点检查 编码、语句的使用等是否符合编码规范，并 根据编码规范调整自己的代码以符合编 码规范的要求。2：单元测试 单元测试也称作模块测试， 在传统结构化程 序中，以一个函数、过程为一个单元；在面 向对象编程过程中， 一般将类作为单元进行 测试。该项工作的参与人员为专门的白盒测 试人员。可采用白盒测试和黑盒测试相结合 的方法。3：代码评审 代码评审是在编码初期或编写过

29、程中采用 一种有同行参与的评审活动。 该项工作需要 所有开发小组共同参与， 通过大家共同阅读 代码或由程序编写者讲解代码， 其他同行边 听边分析问题的方法。 共同查看程序， 可以 找出问题， 使大家的代码风格一致或遵守编 码规范。4：同行评审在同行评审中， 由软件产品创建者的同行们 检查该工作产品， 识别产品的缺陷，改进产 品的不足。 主要用于检验工作产品是否正确 的满足了以往的工作产品中建立的规范， 如 需求或设计文档； 识别工作产品相对于标准 的偏差，包括可能影响软件可维护性的问 题； 向创建者提出改进建议； 促进参与者之 间的技术交流和学习等。根据 CMM 标准， 该项工作的参与人员为程

30、序员、设计师、 单 元测试工程师、维护者、需求分析师、编码 标准专家。至少需要开发人员，测试人员和 设计师。5：代码走查 代码走查由测试小组组织或者专门的代码 走查小组进行代码走查， 这时需要开发人员 提交有关的资料文档和源代码给走查人员， 并进行必要的讲解。代码走查往往根据 代 码检查单来进行， 代码检查单常常是根据 编码规范 总结出来的一些条目，目的是 检查代码是否按照编码规范来编写的。 当然，代码走查的最终目的还是为了发现代 码中潜在的错误和缺陷。 该项工作的参与者 为测试人员。 代码走查速度一般建议为：汇 编代码与 C 代码 150 行 / 小时， C+/Java 200-300 行/

31、 小时。6：静态分析 静态分析通常需要辅助工具支持， 通过提取 代码信息，进行统计，根据统计结果对源代 码进行质量评估。 代码规则检查也是静态分 析的一个方面。 该项工作的参与人员为测试小组3、面向对象的测试用例设计 有限状态机 Petri 网 正交阵列法 UML 软件测试 将开发分为面向对象分析（ OOA ），面向对 象设计（ OOD ），和面向对象编程（ OOP ） 三个阶段。正交阵列法 正交阵列法的应用范围： 正交表测试法适用于输入条件相互独 立，并且需要对输入 什么是正交测试法？正交测试源于正交试验设计方法。 正交试验设计方法是一种研究多因素 多水平的试验设计方法， 它根据正交性从全

32、面试验中挑选出部分有代表性的点进行试 验，这些有代表性的点具备了 “均匀分散， 齐整可比 ”的特点。正交试验设计方法一般使用已经造好 了的正交表格来安排试验并进行数据分析。正交测试法与正交试验设计方法类似 也使用已经造好了的正交表格来生成测试 用例，它简单易行，应用性较好。 什么是因素（ Factor ）在一项试验中， 凡欲考察的变量称为因 素（变量）。什么是水平（位级） （ Level） 在试验范围内， 因素被考察的值称为水 平（变量的取值） 。什么是正交表？ （ 源自古希腊 ） 正交表是一个二维表格，它的构成如下： 行数 （Runs） ：正交表中的行的个数，即试验 的次数。因素数 （Fac

33、tors） ：正交表中列的个数。 水平数 （Levels） ：任何单个因素能够取得的 值的最大个数。正交表中的包含的值为从 0 到 “水平数 -1”或从 1到“水平数 ”。 正交表的表示形式： L 行数 （水平数因素数 ） 正交表的正交性 1）每一列中各数字出现的次数都一样多； 2）任何两列所构成的各有序数对出现的次 数都一样多。正交测试用例设计步骤（ 1）确定测试中有多少个相互独立的变量， 这映射到表中的因素数（ Factors）。（2）确定每个变量可以取值的个数，这映 射到表中的水平数（ Levels ）。（ 3）选择一个最适合的正交表， 其因素数 >= 测试中的变量数， 各因素的水

34、平数 >=对应变 量的取值个数，另外，次数（ Run）最少。（4）把因素和值映射到表中。（5）为剩下的水平数选取值。（6）把次数中所描述的组合转化成测试用 例，再增加一些没有生成的但可疑的测试用 例。UML 软件测试1. 场景法 现在的软件几乎都是用事件触发来控 制流程的，事件触发时的情景即为场景。而 同一事件不同的触发顺序和处理结果就形 成了事件流。运用在软件设计中的场景法也可用在软件 测试中。两个概念：基本流和备选流。第四章 集成测试1、集成测试概念集成（ Integration ）是指把多个单元组 合起来形成更大的单元。集成测试（ Integration Testing）也叫组 装

35、测试或联合测试是在假定各个软件单元 已经通过了单元测试的前提下， 检查各个软 件单元之间的相互接口是否正确。一般情况，都采用黑盒测试，但随着 软件复杂度的增加，常常使用灰盒测试。 集成测试的目的和意义 集成测试有以下不可替代的特点：单元测试具有不彻底性， 对于模块间接 口信息内容的正确性、 相互调用关系是否符 合设计无能为力。 只能靠集成测试来进行保 障。同系统测试相比， 由于集成测试用例是 从程序结构出发的，目的性、针对性更强， 测试项发现问题的效率更高， 定位问题的效 率也较高；能够较容易地测试到系统测试用例难 以模拟的特殊异常流程， 从纯理论的角度来 讲，集成测试能够模拟所有实际情况；定

36、位问题较快， 由于集成测试具有可重 复强、对测试人员透明的特点，发现问题后 容易定位，所以能够有效地加快进度， 减少 隐患。 集成测试、单元测试与系统测试的差别集成测试方法集成测试的策略比较多， 如有基于功能 分解的集成， 基于调用图的集成， 基于路径 的集成，分层集成，高频集成，基于进度的 集成，基于风险的集成和基于使用的集成 等。一般的软件测试及软件工程中按照功能 分解将集成测试方法分为非渐增式集成 （大 爆炸集成），渐增式集成，三明治集成。 非渐增式集成优点：1. 可并行调试所有模块；2. 需要的测试用例数目少；3. 测试方法简单、易行。 非渐增式集成缺点：1. 不能对接口进行充分的测试

37、；2. 不能很好的对全局数据结构测试；3. 多错误定位比较困难；4. 即使测试通过，也会遗漏错误。 非渐增式集成使用范围： 1.只需修改或增加少数几个模块的前期产品 稳定的项目；2. 模块少，功能少，逻辑简单；3. 开发零缺陷的产品，产品质量和单元测试 质量相当高的产品。渐增式测试方法 不是独立地测试每个单元， 而是首先把下一个要被测试的单元同已经 测试过的单元集合组装起来，然后再测试， 在组装的过程中边连接边测试， 以发现连接 过程中产生的问题， 最后通过渐增式方法逐 步组装成要求的软件系统。分自顶向下和自底向上的集成。渐增式集成测试两个概念：驱动模块（ driver ）：用以模拟待测模块

38、的上级模块。桩模块 （ stub）：也称存根模块， 用以模 拟待测模块工作过程中所调用的模块。自顶向下集成的步骤：a. 对主控模块进行测试，测试时用桩模块代 替所有直接附属于主控模块的模块；b. 根据选定的结合策略（深度优先或宽度优 先），每次用一个实际模块代换一个桩模块；c. 在结合进一个模块的同时进行测试；d. 为了保证加入模块没有引进新的错误，可 能需要进行回归测试。从 2 开始不断重复进行上述过程， 直到构造 起完整的软件结构为止。自顶向下集成的优点 在测试的过程中，可以较早地验证主要 的控制和判断点。 选择深度优先组合方式， 可以首先实现 和验证一个完整的软件功能， 可先对逻辑输 入

39、的分支进行组装和测试， 检查和克服潜藏 的错误和缺陷， 验证其功能的正确性， 为此后主要分支 的组装和测试提供保证； 能够较早的验证功能可行性， 给开发者 和用户带来成功的信心； 只有在个别情况下，才需要驱动程序 （最多不超过一个） ，减少了测试驱动程序 开发和维护的费用； 可以和开发设计工作一起并行执行集成 测试，能够灵活的适应目标环境； 容易进行故障隔离和错误定位。 自顶向下集成的缺点： 在测试时需要为每个模块的下层模块提 供桩模块，桩模块的开发和维护费用大； 底层组件的需求变更可能会影响到全局 组件，需要修改整个系统的多个上层模块。 要求控制模块具有比较高的可测试性； 可能会导致底层模块特别是被重用的模 块测试不够充分。自顶向下集成的适用范围： 控制结构比较清晰和稳定的应用程序； 系统高层的模块接口变化的可能性比较 小； 产品的低层模块接口还未定义或可能会 经常因需求变更等原因被修改； 产品中的控制模