软件测试重点(DOC)

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

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

3、正的问 题。(8)、软件设计和编 码过程中的失误也 会导致软件缺陷的 产生。(9)、但很多情况5、软件测试的目的和 意义 软件测试的根本目的 是以尽可能少的时间 和人力发现并改正软 件中潜在的各种故障 及缺陷，提高软件的质 6、软件测试原则：(1)尽早和不断测 试(2)每个程序员都 应当测试自己的程序(份内之事)，但 是不能作为该程序 已经通过测试的依 据(所以项目需要独 立测试人员)(3)完全测试是不 可能的(4)测试能提高软 件的质量，但是提高 质量不能依赖测试(5)测试只能证明 错误存在，不能证明 错误不存在(6)测试的主要困 难是不知道如何进 行有效地测试，也不 知道什么时候可以 放心

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

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

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

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

8、公司开发 的 LogiScope分析工 具；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)根据程序规格说 明书描述，分析并确定 因(输入条件)和果(输 出结果或程序状态的

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

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

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

18、(5)简化决策表，合 并相似规则。决策表测试法适用 于具有以下特征的 应用程序：if-then-else 逻辑 突出；输入变量之间存 在逻辑关系；涉及输入 变量子集的计算；输入 与输出之间存在因果 关系。适用于使用决策表设 计测试用例的条件：?规格说明以决策表 形式给出，或较容 易转换为决策表。?条件的排列顺序不 会也不应影响执行 的操作。?规则的排列顺序不 会也不应影响执行 的操作。?当某一规则的条件 已经满足，并确定 要执行的操作后， 不必检验别的规 则。?如果某一规则的条 件要执行多个操 作，这些操作的执 行顺序无关紧要。3、黑盒测试方法的比 较与选择几种典型的黑盒测 试方法，这些测试方

19、 法的共同特点是，它 们都把程序看作是 一个打不开的黑盒， 只知道输入到输出 的映射关系，根据软 件规格说明设计测 试用例。在等价类分析测试 中，通过等价类划 分来减少测试用例 的绝对数量。边界值分析方法则 通过分析输入变量 的边界值域设计测 试用例。在因果图测试方法 和决策表测试中， 通过分析被测程序 的逻辑依赖关系， 构造决策表，进而 设计测试用例。4、黑盒测试工具介绍 黑盒测试是在已知软 件产品应具有的功能 的条件下，在完全不考 虑被测程序内部结构 和内部特性的情况下， 通过测试来检测每个 功能是否都按照需求 规格说明的规定正常 使用。黑盒测试工具又 分为：功能测试工具和 性能测试工具。

20、功能测试工具：功 能测试工具主要用于 检测被测程序能否达 到预期的功能要求并 能正常运行。性能测试工具：性 能测试工具主要用于 确定软件和系统性能。 黑盒功能测试工具，如Mercury Interactive 公 司的 WinRunner , IBM Rational 公司的 TeamTest 和 Robot, Compuware 公司的 QACenter 等。第三章软件测试用例设计 1、黑盒测试方法：等 价类划分、边界值分 析、决策表测试、因果 图法白盒测试：数据流测 试、逻辑覆盖、路径测 试面向对象测试：有限状 态机、Petri网、正交 阵列法、UML测试2、白盒测试(White Box

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

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

23、一致的，表明了控 制的顺序。控制流线通 常标有名字，如图中所标的a、b、c等。程序流程图-控制 流图转换的原则如下： 控制流图中的每一个 节点可以表示程序流 程图中矩形框所表示 的处理；菱形表示的两个甚至 多个出口判断； 多条流线相交的汇合 点。2）基本路径测试法是 在程序控制流图的基 础上，通过分析控制构 造的环路（圈）复杂性, 导出基本可执行路径 集合，从而设计测试用 例的方法。逻辑覆盖语句覆盖判定覆盖（分支覆盖）条件覆盖判定/条件覆盖条件组合覆盖语句覆盖准则在测试中，要求程序 中的每条语句都得到 运行。在控制流图中， 要求所有的语句都被 运行的充分必要条件 是覆盖图中的所有节 点。语句覆

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

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

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

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

28、强的。缺点：线性地增加了测 试用例的数量。逻辑覆盖测试的5种标 准人ft KMU相力I或王，l行一次3,龄TIT,儡丁学防一WOHL足处汽 EE； HL金子宣乜：*ftJ看台啊a ivm颦luiD 包M. 另1MHiIfl作i方所 R几种覆盖准则间的关 系白盒测试策略1:桌前检查桌前检查是在程序员 实现特定功能后，进行 单元测试之前，对源代 码进行的初步检查。该 项工作的参与人员为 开发人员，重点检查编 码、语句的使用等是否 符合编码规范，并根据编码规范调整自己 的代码以符合编码规 范的要求。2:单元测试单元测试也称作模块 测试，在传统结构化程 序中，以一个函数、过 程为一个单元；在面向 对象

29、编程过程中，一般 将类作为单元进行测 试。该项工作的参与人 员为专门的白盒测试 人员。可采用白盒测试 和黑盒测试相结合的 方法。3:代码评审代码评审是在编码初 期或编写过程中采用 一种有同行参与的评 审活动。该项工作需要 所有开发小组共同参 与，通过大家共同阅读 代码或由程序编写者 讲解代码，其他同行边 听边分析问题的方法。 共同查看程序，可以找 出问题，使大家的代码 风格一致或遵守编码 规范。4:同行评审在同行评审中，由软件 产品创建者的同行们 检查该工作产品，识别产品的缺陷，改进产品 走查小组进行代码走 的不足。主要用于检验查，这时需要开发人员工作产品是否正确的 满足了以往的工作产 品中建

30、立的规范，如需 求或设计文档；识别工 作产品相对于标准的 偏差，包括可能影响软 件可维护性的问题；向 创建者提出改进建议； 促进参与者之间的技 术交流和学习等。根据 CMM标准，该项工作 的参与人员为程序员、 设计师、单元测试工程 师、维护者、需求分析 师、编码标准专家。至 少需要开发人员，测试 人员和设计师。5:代码走查 代码走查由测试小组 组织或者专门的代码 提交有关的资料文档 和源代码给走查人员， 并进行必要的讲解。代 码走查往往根据代码 检查单来进行，代码 检查单常常是根据编 码规范总结出来的一 些条目，目的是检查代 码是否按照编码规 范来编写的。当然， 代码走查的最终目的 还是为了发

31、现代码中 潜在的错误和缺陷。该 项工作的参与者为测 试人员。代码走查速度 一般建议为：汇编代码 与C代码150行/小 时，C+/Java 200-300 行/小时。6:静态分析静态分析通常需要辅 助工具支持，通过提取 代码信息，进行统计， 根据统计结果对源代 码进行质量评估。代码 规则检查也是静态分 析的一个方面。该项工 作的参与人员为测试 小组3、面向对象的测试用 例设计有限状态机 Petri网 正交阵列法 UML软 件测试将开发分为面向对象 分析（OOA）,面向对 象设计（OOD）,和面 向对象编程（OOP）三 个阶段。正交阵列法的应用范 围：正交表测试法适 用于输入条件相互独 立，并且需

32、要对输入 什么是正交测试法？正交测试源于正 交试验设计方法。正交试验设计方 法是一种研究多因素 多水平的试验设计方 法，它根据正交性从全 面试验中挑选出部分 有代表性的点进行试 验，这些有代表性的点 具备了均匀分散，齐 整可比”的特点。正交阵列法正交测试法与正正交试验设计方 法一般使用已经造好 了的正交表格来安排 试验并进行数据分析。交试验设计方法类似 也使用已经造好了的 正交表格来生成测试 用例，它简单易行，应 用性较好。什么是因素（Factor）在一项试验中，凡 欲考察的变量称为因 素（变量）。什么是水平（位级）（Level）在试验范围内，因 素被考察的值称为水 平（变量的取值）。 什么是

33、正交表？（源自 古希腊） 正交表是一个二维表 格，它的构成如下： 行数（Runs）:正交表中 的行的个数，即试验的 次数。因素数（Factors）:正交 表中列的个数。水平数（Levels）:任何 单个因素能够取得的 值的最大个数。正交表 中的包含的值为从0到水平数-1”或从1到 水平数”。正交表的表示形式：L 行数（水平数因素数） 正交表的正交性1）每一列中各数字出 现的次数都一样多；2）任何两列所构成的 各有序数对出现的次 数都一样多。正交测试用例设计步骤（1）确定测试中有多 少个相互独立的变量， 这映射到表中的因素 数（Factors）。（2）确定每个变量可以取值的个数，这映射 到表中的

34、水平数(Levels)。(3)选择一个最适合 的正交表，其因素数= 测试中的变量数，各因 素的水平数 =对应变 量的取值个数，另外， 次数(Run)最少。(4)把因素和值映射 到表中。(5)为剩下的水平数 选取值。(6)把次数中所描述 的组合转化成测试用 例，再增加一些没有生 成的但可疑的测试用 例。UML软件测试1 .场景法现在的软件几乎 都是用事件触发来控 制流程的，事件触发时 的情景即为场景。而同 一事件不同的触发顺 序和处理结果就形成 了事件流。运用在软件设计中的 场景法也可用在软件 测试中。两个概念：基本流和备 选流。场景法测试设计方法* 飒生证明.谁述出桓斤的基本流取讨项各话就*

35、垠庭事事渔和苫齿不选沈生成不同的场景；时M一个埔器生盛相由的扇酰用俏，* 时按值的胡有却，用用;复由，表持步余的泅区用策，麻试 用催债定后.M*一今例I试用例晚定前it独抠第四章集成测试1、集成测试概念集成(Integration )是指把 多个单元组合起来形 成更大的单元。集成测试(Integration Testing ) 也叫组装测试或联合 测试是在假定各个软 件单元已经通过了单 元测试的前提下，检查 各个软件单元之间的 相互接口是否正确。一般情况，都采 用黑盒测试，但随着软 件复杂度的增加，常常 使用灰盒测试。集成测试的目的和意 义集成测试有以下不可 替代的特点：单元测试具有不 彻底性

36、，对于模块间接 口信息内容的正确性、 相互调用关系是否符 合设计无能为力。只能 靠集成测试来进行保 障。同系统测试相比， 由于集成测试用例是 从程序结构出发的，目 的性、针对性更强，测 试项发现问题的效率 更高，定位问题的效率 也较高；能够较容易地测 试到系统测试用例难 以模拟的特殊异常流 程，从纯理论的角度来 讲，集成测试能够模拟 所有实际情况；定位问题较快，由 于集成测试具有可重 复强、对测试人员透明 的特点，发现问题后容 易定位，所以能够有效 地加快进度，减少隐 患。集成测试、单元测试与 系统测试的差别荒滥矍不模央内都 的程序由 近料雅月的篌区隹戛忸 和功度J.的懦课轮必 啃接外将说 明

37、士*用白含 料试点计集骐柑艮枇梅阿的 集曲.笆曲 用黄感挽出与软件袅 的行序啮梅-愕场河 用美琮.蒋比同徒口b士 向月胤看开暗枸 故依音则白令与 网制常试方欣， 果用校考县宜古 洛力舞郎|祠泵嗜迪试抬个裁 驻.总括 聚茹中的 警件等鼾整个廉购却 网的货作.有效件商 试条垄结甲祖济I1 异以明 书.需求罪畲号试集成测试方法集成测试的策略比较多，如有基于功能 分解的集成，基于调用 图的集成，基于路径的 集成，分层集成，高频 集成，基于进度的集 成，基于风险的集成和 基于使用的集成等。一 般的软件测试及软件 工程中按照功能分解 将集成测试方法分为 非渐增式集成（大爆炸 集成），渐增式集成， 三明治集

38、成。非渐增式集成优点：1 .可并行调试所有模 块；2 .需要的测试用例数目 少；3 .测试方法简单、易行。 非渐增式集成缺点：1 .不能对接口进行充分 的测试；2 .不能很好的对全局数 据结构测试；3 .多错误定位比较困 难；4 .即使测试通过，也会 遗漏错误。非渐增式集成使用范 围：1 .只需修改或增加少数 几个模块的前期产品 稳定的项目；2 .模块少，功能少，逻 辑简单；3 .开发零缺陷的产品， 产品质量和单元测试 质量相当高的产品。渐增式测试方法不是 独立地测试每个单元， 而是首先把下一个要 被测试的单元同已经 测试过的单元集合组 装起来，然后再测试， 在组装的过程中边连 接边测试，以发

39、现连接 过程中产生的问题，最 后通过渐增式方法逐 步组装成要求的软件 系统。分自顶向下和自底 向上的集成。渐增式集成测试 两个概念：驱动模块 （driver）:用以模拟待 测模块的上级模块。桩模块（stub）:也称存根模块，用以模 拟待测模块工作过程 中所调用的模块。自顶向下集成的步骤： a.对主控模块进行测 试，测试时用桩模块代 替所有直接附属于主 控模块的模块；b.根据选定的结合策略 （深度优先或宽度优先），每次用一个实际 模块代换一个桩模块； c.在结合进一个模块的 同时进行测试；d.为了保证加入模块没 有引进新的错误，可能 需要进行回归测试。从2开始不断重复进行 上述过程，直到构造起

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