第2章 软件测试策略与过程 2.1 软件测试的复杂性分析 2.2 软件测试方法与策略 2.3 单元测试 2.4 集成测试 2.5 确认测试

Presentation on theme: "第2章 软件测试策略与过程 2.1 软件测试的复杂性分析 2.2 软件测试方法与策略 2.3 单元测试 2.4 集成测试 2.5 确认测试"— Presentation transcript:

1 第2章 软件测试策略与过程 2.1 软件测试的复杂性分析 2.2 软件测试方法与策略 2.3 单元测试 2.4 集成测试 2.5 确认测试
第2章 软件测试策略与过程 2.1 软件测试的复杂性分析 2.2 软件测试方法与策略 2.3 单元测试 2.4 集成测试 2.5 确认测试 2.6 系统测试 2.7 验收测试 2.8 测试后的调试 2.9 面向对象的软件测试

2 本章教学目标 理解软件测试的复杂性 理解软件测试的方法与策略 明确单元测试的主要任务和过程 明确集成测试的方法和确认测试的准则
明确系统测试的八个领域测试要点 明确验收测试的主要内容和相关配置

3 2.1 软件测试的复杂性分析 Return 1、无法对程序进行完全测试 2、测试无法显示潜在的软件缺陷和故障
2.1 软件测试的复杂性分析 1、无法对程序进行完全测试 （1）测试所需要的输入量太大 （2）测试的输出结果太多 （3）软件实现的途径太多 （4）软件规格说明没有一个客观标准 2、测试无法显示潜在的软件缺陷和故障 ——通过软件测试只能报告软件已被发现的缺陷和故障，无法报告隐藏的软件故障。 3、存在的故障现象与发现的故障数量成正比 ——结论：应当对故障集中的程序段进行重点测试 Return

4 软件测试的复杂性分析（续） 4、不能修复所有的软件故障 5、软件测试的代价
——原因：没有足够的进行修复；修复的风险较大； 不值得修复；可不算做故障的一些缺陷；“杀虫剂现象”。 ——结论：关键是要进行正确的判断、合理的取舍，根据风险分析决定哪些故障必须修复，哪些故障可以不修复。 5、软件测试的代价 ——工作原则：就是如何将无边无际的可能性减小到一个可以控制的范围，以及如何针对软件风险做出恰当选择，去粗存精，找到最佳的测试量，使得测试工作量不多也不少，既能达到测试的目的，又能较为经济。

5 软件测试的复杂性分析（续） 图2-1 测试工作量和软件缺陷数量之间的关系 软件缺陷故障数量 测试工作量 测试中 测试后 测试费用
遗漏缺陷数目 优化测试量 图2-1 测试工作量和软件缺陷数量之间的关系

6 2.2 软件测试方法与策略 静态测试与动态测试 黑盒测试与白盒测试 软件测试过程 Return

7 软件测试策略 什么是软件测试策略？ ——是为软件工程过程定义的一个软件测试的模板，也就是把特定的测试用例方法放置进去的一系列步骤。
软件测试策略包含的特征： （1）测试从模块层开始，然后扩大延伸到整个基于计算机的系统集合中。 （2）不同的测试技术适用于不同的时间点。 （3）测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。 （4）测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。

8 软件测试充分性准则 对任何软件都存在有限的充分测试集合。
如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的。这一特性称为单调性。 即使对软件所有成分都进行了充分的测试，也并不表明整个软件的测试已经充分了。这一特性称为非复合性。 即使对软件系统整体的测试是充分的，也并不意味软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。 软件测试的充分性应该与软件的需求和软件的实现都相关。 软件越复杂，需要的测试数据就越多。这一特性称为复杂性。 测试得越多，进一步测试所能得到的充分性增长就越少。这一特性称为回报递减率。

9 2.2.1 静态测试与动态测试 1、静态测试 静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估。
静态测试与动态测试 1、静态测试 静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估。 静态测试包括代码检查 、静态结构分析 、代码质量度量 等。它可以由人工进行，也可以借助软件工具自动进行。 静态测试方法也可利用计算机作为对被测程序进行特性分析的工具，但与人工测试方式有着根本区别。另一方面，因它并不真正运行被测程序，只进行特性分析，这又与动态方法不同。所以，静态方法常常称为“分析”，静态测试是对被测程序进行特性分析方法的总称。

10 静态测试与动态测试（续） 代码检查 代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面。 代码检查的具体内容：变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等。 代码检查的优点：在实际使用中，代码检查比动态测试更有效率，能快速找到缺陷，发现30%～70%的逻辑设计和编码缺陷；代码检查看到的是问题本身而非征兆。 代码检查的缺点：非常耗费时间，而且代码检查需要知识和经验的积累。

11 静态测试与动态测试（续） 静态结构分析 静态结构分析主要是以图形的方式表现程序的内部结构。 例如函数调用关系图、函数内部控制流图。其中：
静态结构分析主要是以图形的方式表现程序的内部结构。 例如函数调用关系图、函数内部控制流图。其中： ——函数调用关系图以直观的图形方式描述一个应用程序中各个函数的调用和被调用关系； ——控制流图显示一个函数的逻辑结构，由许多节点组成，一个节点代表一条语句或数条语句，连接结点的叫边，边表示节点间的控制流向。

12 静态测试与动态测试（续） 代码质量度量 软件质量包括六个方面：功能性、可靠性、易用性、效率、可维护性和可移植性。软件的质量是软件属性的各种标准度量的组合。 针对软件的可维护性，目前业界主要存在三种度量参数：Line复杂度、Halstead复杂度和McCabe复杂度。其中Line复杂度以代码的行数作为计算的基准。Halstead以程序中使用到的运算符与运算元数量作为计数目标（直接测量指标），然后可以据以计算出程序容量、工作量等。McCabe复杂度 一般称为圈复杂度，它将软件的流程图转化为有向图，然后以图论来衡量软件的质量。

13 静态测试与动态测试（续） 静态测试阶段的任务： （1）检查算法的逻辑正确性。 （2）检查模块接口的正确性。
（3）检查输入参数是否有合法性检查。 （4）检查调用其他模块的接口是否正确。 （5）检查是否设置了适当的出错处理。 （6）检查表达式、语句是否正确，是否含有二义性。 （7）检查常量或全局变量使用是否正确。 （8）检查标识符的使用是否规范、一致。 （9）检查程序风格的一致性、规范性。 （10）检查代码是否可以优化，算法效率是否最高。 （11）检查代码注释是否完整，是否正确反映了代码的功能。

14 静态测试与动态测试（续） 静态测试可以完成以下工作：
（1）发现下列程序的错误：错用局部变量和全局变量；未定义的变量、不匹配的参数；不适当的循环嵌套或分支嵌套、死循环、不允许的递归；调用不存在的子程序，遗漏标号或代码。 （2）找出以下问题的根源：从未使用过的变量；不会执行到的代码、从未使用过的标号；潜在的死循环。 （3）提供程序缺陷的间接信息：所用变量和常量的交叉应用表；是否违背编码规则；标识符的使用方法和过程的调用层次。 （4）为进一步查找做好准备。 （5）选择测试用例。 （6）进行符号测试。

15 静态测试与动态测试（续） 2、动态测试 动态方法的主要特征是：
——计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况即输入与输出的对应关系进行分析，以达到检测的目的。 动态测试包括： （1）功能确认与接口测试 （2）覆盖率分析 （3）性能分析 （4）内存分析

16 黑盒测试和白盒测试 若测试规划是基于产品的功能，目的是检查程序各个功能是否能够实现，并检查其中的功能错误，则这种测试方法称为黑盒测试(Black-box Testing)方法。 ——黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。它是一种从用户观点出发的测试，一般被用来确认软件功能的正确性和可操作性。 若测试规划基于产品的内部结构进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分使用，则这种测试方法称为白盒测试(White-box Testing)方法。 ——白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试，一般用来分析程序的内部结构。

17 黑盒测试和白盒测试（续） 白盒测试 黑盒测试 两种测试方法从完全不同的角度出发， 反映了测试思路的两方面情况，适用于 不同的测试阶段。

18 黑盒测试和白盒测试（续） 1、黑盒测试 黑盒测试的基本观点是：任何程序都可以看作是从输入定义域映射到输出值域的函数过程，被测程序被认为是一个打不开的黑盒子，黑盒中的内容（实现过程）完全不知道，只明确要做到什么。 黑盒测试主要根据规格说明书设计测试用例，并不涉及程序内部构造和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。 黑盒测试的特点：（1）黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以使用。（2）黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。

19 黑盒测试和白盒测试（续） 输入 输出 黑盒测试是在程序接口进行测试，它只是检查程序功能是否按照规格说明书的规定正常使用。也被称为用户测试。

20 黑盒测试和白盒测试（续） 黑盒测试主要是为了发现以下几类错误： 是否有不正确或遗漏了的功能？
在接口上，输入能否正确地接受？能否输出正确的结果？ 是否有数据结构错误或外部信息访问错误？ 性能上是否能够满足要求？ 是否有初始化或终止性错误？ 黑盒测试的难点：在哪个层次上进行测试？ 黑盒测试的具体技术方法 ： 边界值分析法 等价类划分法 因果图法 决策表法

21 黑盒测试和白盒测试（续） 2、白盒测试 白盒测试将被测程序看作一个打开的盒子，测试者能够看到被测源程序，可以分析被测程序的内部结构，此时测试的焦点集中在根据其内部结构设计测试用例。 白盒测试要求是对某些程序的结构特性做到一定程度的覆盖，或者说这种测试是“基于覆盖率的测试”。 通常的程序结构覆盖有： 语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 路径覆盖

22 黑盒测试和白盒测试（续） 应用程序 白盒测试需要完全了解程序结构和处理过程， 它按照程序内部逻辑测试程序，检验程序中
每条通路是否按预定要求正确工作。也被称 为程序员测试。 应用程序

23 黑盒测试和白盒测试（续） 3、黑盒测试法和白盒测试法的比较 ？ X=2 y=2x Y=4 未知等式与已知等式 黑盒 白盒

24 黑盒测试和白盒测试（续） 黑盒测试： ——以用户的观点，从输入数据与输出数据的对应关系，即根据程序外部特性进行测试，而不考虑内部结构及工作情况。 ——黑盒测试技术注重于软件的信息域（范围），通过划分程序的输入和输出域来确定测试用例。 ——若外部特性本身存在问题或规格说明的规定有误，则应用黑盒测试方法是不能发现问题的。 白盒测试： ——只根据程序的内部结构进行测试。 ——测试用例的设计要保证测试时程序的所有语句至少执行一次，而且要检查所有的逻辑条件。 ——如果程序的结构本身有问题，比如说程序逻辑有错误或者有遗漏，那也是无法发现的。

25 黑盒测试和白盒测试（续） 项目 黑盒测试法 白盒测试法 规划 方面 功能的测试 结构的测试 优点 能确保从用户的角度出发进行测试
能对程序内部的特定部位进行覆盖测试 缺点 无法测试程序内部特定部位；当规格说明有误，则不能发现问题 无法检查程序的外部特性； 无法对未实现规格说明的程序内部欠缺部分进行测试 应用 范围 边界分析法 等价类划分法 决策表测试 语句覆盖，判定覆盖， 条件覆盖，判定/条件覆盖， 路径覆盖，循环覆盖， 模块接口测试

26 2.2.3 软件测试过程 图2-2 软件测试的过程流程 单元 测试 集成 确认 系统 * 这三个测试可能交叉与前后互换 被测模块 设计信息
软件测试过程 单元 测试 集成 确认 系统 * 这三个测试可能交叉与前后互换 被测模块 设计信息 单元 软件需求 其它元素 用户信息其它元素 * … 验收 交付用户 图2-2 软件测试的过程流程

27 软件测试过程（续） 单元测试：针对每个单元的测试， 以确保每个模块能正常工作为目标。
集成测试：对已测试过的模块进行组装，进行集成测试。目的在于检验与软件设计相关的程序结构问题。 确认（有效性）测试：是检验所开发的软件能否满足所有功能和性能需求的最后手段。 系统测试：检验软件产品能否与系统的其他部分（比如，硬件、数据库及操作人员）协调工作。 验收（用户）测试：检验软件产品质量的最后一道工序。主要突出用户的作用，同时软件开发人员也应有一定程度的参与。

28 一个实用软件测试过程 一种简单实用的软件测试过程模型 POCERM。 测试过程中必需的基本测试活动及其产生的结果：
拟定软件测试计划 (Plans) 编制软件测试大纲 (Outlines) 设计和生成测试用例 (test Case generation) 实施测试 (Execution) 生成软件测试报告 (software testing Reports) 软件问题报告SPR (Software Problem Report) 测试结果报告 (test result Reports)

29 一个实用软件测试过程（续） 基本特性： （1）计划性: 任务 人员 设备 时间 相关... （2）平行性: 开发 编码 || 测试 再测试
（3）完整性: 计划+大纲+用例+SPRs+... （4）重用性: 测试 再测试 回归测试 升级 多平台… （5）可重复性: SPRs 用例 大纲 再现Bugs （6）周期性: test cycles, regression, update （7）可管理性: well structured and organized QE group + well planned and prepared task

30 测试阶段 测试过程的三个主要的测试活动（计划、准备和实施） 可被分成五个阶段：
The planning and control phase－计划和控制阶段 The preparation phase－准备阶段 The specification phase－规范阶段 The execution phase－实施执行阶段 The completion phase－完成（收尾）阶段

31 测试的五个阶段 C S E P Plan & Control P&C Preparation Specification Execution
Completion

32 计划与控制阶段 它是整个测试过程中最重要的阶段，为实现可管理且高质量的测试过程提供基础 。 本阶段的主要工作内容： （1）拟定测试计划
（2）论证那些使开发过程难于管理和控制的因素 （3）明确软件产品的最重要部分 （风险评估）

33 准备阶段 开始本阶段的前提条件： —完成测试计划的拟定。 —需求规格说明书（第一版）的确定。 本阶段的主要工作内容：
—对需求规格说明书的仔细研究。 —将要测试的产品分解成可独立测试的单元。 —为每个测试单元确定采用的测试技术。 —为测试的下一个阶段及其活动制定计划。

34 规范阶段 本阶段的主要工作内容： —编写测试大纲/测试用例，测试脚本 —搭建测试环境 （测试数据库，软件环境，硬件环境）
测试用例描述的内容： —输入 —执行过程 —预期输出

35 实施执行阶段 根据测试大纲/测试用例/测试脚本进行测试 （1）根据测试大纲/测试用例进行测试，找出预期的测试 结果和实际测试结果之间的差异
（2）填写软件问题报告 （3）确定造成这些差异的原因： 产品有缺陷？规格说明书有缺陷？ 测试环境和测试下属部件有缺陷？测试用例设计不合理？ 测试报告——与管理层进行沟通的方式 已测试部分占产品多大的百分比？还有什么工作要做？ 找到了多少个问题或不足？测试的发展趋势如何？ 测试可以结束了吗？

36 完成阶段 本阶段的主要工作内容： —选择和保留测试大纲、测试用例、测试结果、测试工具。 —提交最终报告。 收尾工作的意义和重要性：
—产品如果升级或功能变更，或维护，只要对保留下来的 相关测试数只要作相应调整，就能够进行新的测试。

37 2.3 单元测试 单元测试的主要任务 单元测试的执行过程 Return

38 2.3.1 单元测试的主要任务 模块 单元测试针对每个程序的模块，主要测试5个方面的问题：
单元测试的主要任务 单元测试针对每个程序的模块，主要测试5个方面的问题： ——模块接口、局部数据结构、边界条件、独立的路径和错误处理。 模块 模块接口 局部数据结构 路径测试 出错处理 边界条件

39 单元测试的主要任务（续） 模块接口 这是对模块接口进行的测试，检查进出程序单元的数据流是否正确。模块接口测试必须在任何其它测试之前进行。
模块接口测试至少需要如下的测试项目： （1）调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配； （2）所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配； （3）是否修改了只做输入用的形式参数； （4）调用标准函数的参数在个数、属性、顺序上是否正确； （5）全局变量的定义在各模块中是否一致。

40 单元测试的主要任务（续） 局部数据结构 在模块工作过程中，必须测试模块内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。 对于局部数据结构，应该在单元测试中注意发现以下几类错误： （1）不正确的或不一致的类型说明。 （2）错误的初始化或默认值。 （3）错误的变量名，如拼写错误或书写错误。 （4）下溢、上溢或者地址错误。

41 单元测试的主要任务（续） 路径测试 在单元测试中，最主要的测试是针对路径的测试。测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。 常见的错误有： 误解的或不正确的算术优先级；混合模式的运算；错误的初始化；精确度不够精确；表达式的不正确符号表示。 针对判定和条件覆盖，测试用例还要能够发现如下错误： 不同数据类型的比较；不正确的逻辑操作或优先级；应当相等的地方由于精确度的错误而不能相等；不正确的判定或不正确的变量；不正确的或不存在的循环终止；当遇到分支循环时不能退出；不适当地修改循环变量。

42 单元测试的主要任务（续） 边界条件 边界测试是单元测试的最后一步，必须采用边界值分析方法来设计测试用例，认真仔细地测试为限制数据处理而设置的边界处，看模块是否能够正常工作。 一些可能与边界有关的数据类型如数值、字符、位置、数量、尺寸等，还要注意这些边界的首个、最后一个、最大值、最小值、最长、最短、最高、最低等特征。 在边界条件测试中，应设计测试用例检查以下情况： （1）在n次循环的第0次、1次、n次是否有错误。 （2）运算或判断中取最大值、最小值时是否有错误。 （3）数据流、控制流中刚好等于、大于、小于确定的比较值是否出现错误。

43 单元测试的主要任务（续） 出错处理 测试出错处理的重点是模块在工作中发生了错误，其中的出错处理设施是否有效。
检验程序中的出错处理可能面对的情况有： （1）对运行发生的错误描述难以理解。 （2）所报告的错误与实际遇到的错误不一致。 （3）出错后，在错误处理之前就引起系统的干预。 （4）例外条件的处理不正确。 （5）提供的错误信息不足，以至于无法找到错误的原因。

44 单元测试的执行过程 何时进行单元测试？单元测试常常是和代码编写工作同时进行的，在完成了程序编写、复查和语法正确性验证后，就应进行单元测试用例设计。 在单元测试时，如果模块不是独立的程序，需要设置一些辅助测试模块。辅助测试模块有两种： （1）驱动模块(Drive) 用来模拟被测试模块的上一级模块，相当于被测模块的主程序。它接收数据，将相关数据传送给被测模块，启动被测模块，并打印出相应的结果。 （2）桩模块(Stub) 用来模拟被测模块工作过程中所调用的模块。它们一般只进行很少的数据处理。 驱动模块和桩模块都是额外的开销，虽然在单元测试中必须编写，但并不需要作为最终的产品提供给用户。

45 单元测试的执行过程（续） 被测模块、驱动模块和桩模块共同构成了一个如下图所示的单元测试的测试环境： 测试用例 被测模块 驱动模块 测试结果
桩模块1 桩模块2 桩模块3 桩模块n 桩模块…

46 2.4 集成测试 非增量式测试 增量式测试 不同集成测试方法的比较 回归测试 Return

47 2.4.1 非增量式测试 非增量式测试是采用一步到位的方法来构造测试：
非增量式测试 非增量式测试是采用一步到位的方法来构造测试： ——对所有模块进行个别的单元测试后，按照程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试。 实例 采用非增量式测试方法进行集成测试 非增量式测试的缺点： ——当一次集成的模块较多时，非增量式测试容易出现混乱，因为测试时可能发现了许多故障，为每一个故障定位和纠正非常困难，并且在修正一个故障的同时，可能又引入了新的故障，新旧故障混杂，很难判定出错的具体原因和位置。

48 非增量式测试（续） （1）程序结构图 （2）单元测试示意图 （3）集成测试示意图 A B C D E F A S3 S4 S5 d2 C

49 2.4.2 增量式测试 增量式测试的集成是逐步实现的：
增量式测试 增量式测试的集成是逐步实现的： ——逐次将未曾集成测试的模块和已经集成测试的模块（或子系统）结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。 按照不同的实施次序，增量式集成测试又可以分为三种不同的方法： （1）自顶向下增量式测试 （2）自底向上增量式测试 （3）混合增量式测试

50 自顶向下增量式测试 自顶向下增量式测试表示逐步集成和逐步测试是按照结构图自上而下进行的，即模块集成的顺序是首先集成主控模块（主程序），然后依照控制层次结构向下进行集成。从属于主控模块的按深度优先方式（纵向）或者广度优先方式（横向）集成到结构中去。 深度优先方式的集成： ——首先集成在结构中的一个主控路径下的所有模块，主控路径的选择是任意的。 广度优先方式的集成： ——首先沿着水平方向，把每一层中所有直接隶属于上一层的模块集成起来，直到底层。

51 自顶向下增量式测试（续） 集成测试的整个过程由3个步骤完成： （1）主控模块作为测试驱动器。
（2）根据集成的方式（深度或广度），下层的桩模块一次一次地被替换为真正的模块。 （3）在每个模块被集成时，都必须进行单元测试。 重复第2步，直到整个系统被测试完成。 实例 按照广度优先方式进行集成测试 实例 按照深度优先方式进行集成测试

52 自顶向下增量式测试（续） 广度优先方式 （1） （2） （3） A B C D E F A S1 S2 S3 A B C D S4 S5 A

53 自顶向下增量式测试（续） 深度优先方式 （1） （2） （4） （3） A B C D E F A S1 S2 S3 A B S2 S3 E

54 自底向上增量式测试 自底向上增量式测试表示逐步集成和逐步测试的工作是按结构图自下而上进行的，即从程序模块结构的最底层模块开始集成和测试。
由于是从最底层开始集成，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经集成并测试完成，所以不再需要使用桩模块进行辅助测试。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。 实例 采用自底向上增量式测试方法进行集成测试

55 自底向上增量式测试（续） A B C D E F A B C D E F d4 B E d5 F D d1 E d2 C d3 F

56 混合增量式测试 混合增量式测试是把自顶向下测试和自底向上测试这两种方式结合起来进行集成和测试。这样可以兼具两者的优点，而摒弃其缺点。
常见的两种混合增量式测试方式： （1）衍变的自顶向下的增量式测试：基本思想是强化对输入/输出模块和引入新算法模块的测试，并自底向上集成为功能相对完整且相对独立的子系统，然后由主模块开始自顶向下进行增量式测试。 （2）自底向上-自顶向下的增量式测试：首先对含读操作的子系统自底向上直至根节点模块进行集成和测试，然后对含写操作的子系统做自顶向下的集成与测试。

57 2.4.3 不同集成测试方法的比较 1、非增量式测试与增量式测试的比较
不同集成测试方法的比较 1、非增量式测试与增量式测试的比较 非增量式测试的方法是先分散测试，然后集中起来再一次完成集成测试。假如在模块的接口处存在错误，只会在最后的集成测试时一下子暴露出来。 增量式测试是逐步集成和逐步测试的方法，把可能出现的差错分散暴露出来，便于找出问题和修改。而且一些模块在逐步集成的测试中，得到了较多次的考验，因此，可能会取得较好的测试效果。 结论：增量式测试要比非增量式测试具有一定的优越性。

58 不同集成测试方法的比较（续） 2、自顶向下与自底向上增量式测试的比较 自顶向下增量式测试：
——主要优点在于它可以自然的做到逐步求精，一开始就能让测试者看到系统的框架。 ——主要缺点是需要提供桩模块，并且在输入/输出模块接入系统以前，在桩模块中表示测试数据有一定困难。 自底向上增量式测试： ——优点在于，由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，生成测试数据也无困难。 ——主要缺点在于，直到最后一个模块被加进去之后才能看到整个程序（系统）的框架。

59 回归测试 什么是回归测试？ ——在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用或引发新的问题。 ——在更广的环境里，回归测试就是用来保证（由于测试或其他原因的）改动不会带来不可预料的行为或另外的错误。 回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。 回归测试集包括三种不同类型的测试用例： （1）能够测试软件的所有功能的代表性测试用例 （2）专门针对可能会被修改而影响软件功能的附加测试 （3）针对修改过的软件成分的测试

60 2.5 确认测试 1、确认测试的准则 确认测试也称为合格性测试，是检验所开发的软件是否能按用户提出的要求进行。软件确认要通过一系列证明软件功能和要求一致的黑盒测试来完成。 经过确认测试，应该为已开发的软件给出结论性评价： （1）经过检验的软件的功能、性能及其他要求均已满足需求规格说明书的规定，则可被认为是合格的软件。 （2）经过检验发现与需求说明书有相当的偏离，得到一个各项缺陷清单。 Return

61 确认测试（续） 2、配置审查的内容 确认测试过程的重要环节就是配置审查工作。其目的在于确保已开发软件的所有文件资料均已编写齐全，并得到分类编目，足以支持运行以后的软件维护工作。 配置审查的文件资料包括用户所需的以下资料： （1）用户手册 （2）操作手册 （3）设计资料 ——如：设计说明书、源程序以及测试资料（测试说明书、测试报告）等

62 2.6 系统测试 Return 为什么要进行系统测试？
2.6 系统测试 为什么要进行系统测试？ ——由于软件只是计算机系统中的一个组成部分，软件开发完成之后，最终还要和系统中的硬件系统、某些支持软件、数据信息等其他部分配套运行。因此，在投入运行前要完成系统测试，以保证各组成部分不仅能单独的得到检验，而且在系统各部分协调工作的环境下也能正常工作。 尽管每一个检验有特定的目标，然而所有的检测工作都要验证系统中每个部分均已得到正确的集成，并能完成指定的功能。 严格的说，系统测试超出了软件工程范围。通常这项工作并不由系统开发人员或系统开发组织来承担，而是由软件用户或软件开发机构委托独立测试机构来完成。 Return

63 恢复测试 恢复测试是通过各种手段，强制性地使软件出错，使其不能正常工作，进而检验系统的恢复能力。 恢复测试包含的内容：
——如果系统恢复是自动的（由系统自身完成），则应该检验：重新初始化、检验点设置机构、数据恢复以及重新启动是否正确。 ——如果这一恢复需要人为干预，则应考虑平均修复时间是否在限定的、可以接受的范围之内。

64 安全测试 安全测试的目的在于验证安装在系统内的保护机制能否在实际中保护系统且不受非法入侵，不受各种非法干扰。
在安全测试中，测试者扮演着试图攻击系统的个人角色： — 尝试去通过外部的手段来获取系统的密码 — 使用可以瓦解任何防守的客户软件来攻击系统 — 把系统“瘫痪”，使得其他用户无法访问 — 有目的地引发系统错误，期望在恢复过程中侵入系统 — 通过浏览非保密的数据，从中找到进入系统的钥匙 系统的安全测试要设置一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。

65 强度测试 从本质上来说，强度测试（也称压力测试-Stree Testing）的目的是要检测非正常的情形，测试是想要破坏程序。
强度测试需要在反常规数据量、频率或资源的方式下运行系统，以检验系统能力的最高实际限度。 举例： — 如果正常的中断频率为每秒5次，强度测试设计为每秒50次中断。 — 把输入数据的量提高一个数量级来测试输入功能会如何响应。 — 若某系统正常运行可支持200个终端并行工作，强度测试则检验1000个终端并行工作的情况。 — 运行大量的消耗内存或其他系统资源的测试实例。

66 性能测试 性能测试用来测试软件在系统集成中的运行性能，特别是针对实时系统和嵌入式系统，仅提供符合功能需求但不符合性能需求的软件是不能被接受的。 性能测试可以在测试过程的任意阶段进行，但只有当整个系统的所有成分都集成在一起后，才能检查一个系统的真正性能。 性能测试常常和强度（压力）测试结合起来进行，而且常常需要硬件和软件测试设备，这就是说，常常有必要在一种苛刻的环境中衡量资源的使用（比如，处理器周期）。

67 正确性测试 正确性测试检查软件的功能是否符合规格说明。 正确性测试的方法：
——枚举法，即构造一些合理输入，检查是否得到期望的输出。测试时应尽量设法减少枚举的次数，关键在于寻找等价区间，因为在等价区间中，只需用任意值测试一次即可。 ——边界值测试，即采用定义域或者等价区间的边界值进行测试。因为程序设计容易疏忽边界情况，程序也容易在边界值处出错。

68 可靠性测试 可靠性测试是从验证的角度出发，检验系统的可靠性是否达到预期的目标，同时给出当前系统可能的可靠性增长情况。
对可靠性性测试来说，最关键的测试数据包括失效间隔时间，失效修复时间，失效数量，失效级别等。根据获得的测试数据，应用可靠性模型，可以得到系统的失效率及可靠性增长趋势。 可靠性指标有时很难测试，通常采用平均无故障时间或系统投入运行后出现的故障不能大于多少数量这些指标来对可靠性进行评估。

69 兼容性测试 软件兼容性测试是检测各软件之间能否正确地交互和共享信息，其目标是保证软件按照用户期望的方式进行交互，使用其它软件检查软件操作的过程。 兼容性的测试通常需要解决以下问题： （1）新开发的软件需要与哪种操作系统、Web浏览器和应用软件保持兼容，如果要测试的软件是一个平台，那么要求应用程序能在其上运行。 （2）应该遵守哪种定义软件之间交互的标准或者规范。 （3）软件使用何种数据与其它平台、与新的软件进行交互和共享信息。

70 兼容性测试（续） 软件兼容的实例： 从Web页面剪切文字，然后在文字处理程序中打开的文档中粘贴。
从电子表格程序保存账目数据，然后在另一个完全不同的电子表格程序中读入这些数据。 使图形处理软件在同一操作系统下的不同版本正常工作。 使文字处理程序从联系人管理程序中读取姓名和地址，打印个性化的邀请函和信封。 升级到新的数据库程序，读入现存所有数据库，并能够像老版本一样对其中的数据进行处理。

71 兼容性测试（续） （1）向前兼容和向后兼容 兼容性通常有4种——向前兼容与向后兼容、不同版本间的兼容、标准和规范、数据共享兼容
向前兼容是指可以使用软件的未来版本，向后兼容是指可以使用软件的以前版本。并非所有的软件都要求向前兼容和向后兼容，这是软件设计者需要决定的产品特性。 使用文本文件可以对向前兼容和向后兼容作一个简单的演示：在Windows 98上用Notepad创建的文本文件，它可以向后兼容MS-DOS 1.0后的所有版本，它还可以向前兼容Windows 2000甚至以后的版本。

72 兼容性测试（续） MYDATE.TXT 向前兼容 向后兼容 在Windows 98 上运行的 Notepad 在MS-DOS1.0上运行的
Edit.exe 在Windows 3.1 上运行的 Notepad 在Windows 95 向后兼容 在Windows 2000 上运行的 WordPad 在未来操作系统 未知软件 向前兼容

73 兼容性测试（续） （2）不同版本间的兼容 不同版本间的兼容是指要实现测试平台和应用软件多个版本之间能够正常工作。 举例：
现在要测试一个流行的操作系统的新版本，当前操作系统上可能有数几十上百万现有程序，则新操作系统的目标是与它们百分之百兼容。因为不可能在一个操作系统上测试所有的软件程序，因此需要决定哪些是最重要的、必须进行的。对于测试新应用软件也一样，需要决定在哪个平台版本上测试，以及和什么应用程序一起测试。

74 兼容性测试（续） （3）标准和规范 适用于软件平台的标准和规范有两个级别——高级标准和低级标准。
高级标准是产品应当普遍遵守的，例如软件能在何种操作系统上运行？是互联网上的程序吗？它运行于何种浏览器？每一项问题都关系到平台，假若应用程序声明与某个平台兼容，就必须最受关于该平台的标准和规范。 低级标准是对产品开发细节的描述，从某种意义上说，低级标准比高级标准更加重要。

75 兼容性测试（续） （4）数据共享兼容 数据共享兼容是指要在应用程序之间共享数据，它要求支持并遵守公开的标准，允许用户与其他软件无障碍的传输数据。 实例： — 在Windows环境下，程序间通过剪切、复制和粘贴实现数据共享。在此状况下，传输通过剪贴板的程序来实现。若对某个程序进行兼容性测试就要确认其数据能够利用剪切板与其他程序进行相互复制。 — 通过读写移动外存实现数据共享，如软磁盘、U盘、移动硬盘等，但文件的数据格式必须符合标准，才能在多台计算机上保持兼容。

76 Web网站测试 Web网站的网页是由文字、图形、音频、视频和超级链接组成的文档。
对网站的测试包含许多方面，如配置测试、兼容测试、可用性测试、文档测试等；黑盒测试、白盒测试、静态测试和动态测试都有可能采用。 通常Web网站测试包含以下内容： （1）文字测试 （2）链接测试 （3）图像、图像测试 （4）表单测试 （5）动态内容测试 （6）数据库测试 （7）服务器性能及负载测试 （8）安全性测试

77 2.7 验收测试 验收测试的内容 软件配置和文档资料测试 Return

78 2.7.1 验收测试的内容 软件验收测试应完成的工作内容包括： （1）明确验收项目，规定验收测试通过的标准。 （2）确定测试方法。
验收测试的内容 软件验收测试应完成的工作内容包括： （1）明确验收项目，规定验收测试通过的标准。 （2）确定测试方法。 （3）决定验收测试的组织机构和可利用的资源。 （4）选定测试结果分析方法。 （5）指定验收测试计划并进行评审。 （6）设计验收测试所用的测试用例。 （7）审查验收测试准备工作。 （8）执行验收测试。 （9）分析测试结果。 （10）做出验收结论，明确通过验收或不通过验收。

79 验收测试的内容（续） 在验收测试计划当中，可能包括的检验方面有以下几种： 功能测试。如完整的工资计算过程。
逆向测试。如检验不符合要求数据而引起出错的恢复能力。 特殊情况。如极限测试、不存在的路径测试。 文档检查。 强度检查。如大批量的数据或者最大用户并发使用。 恢复测试。如硬件故障或用户不良数据引起的一些情况。 可维护性的评价。 用户操作测试。如启动、退出系统等。 用户友好性检验。 安全测试。

80 2.7.2 软件配置和文档资料测试 对文档的测试包括以下内容： （1）检查产品说明书属性 （2）检查是否完整 （3）检查是否准确
软件配置和文档资料测试 对文档的测试包括以下内容： （1）检查产品说明书属性 （2）检查是否完整 （3）检查是否准确 （4）检查是否精确 （5）检查是否一致 （6）检查是否贴切 （7）检查是否合理 （8）检查代码无关 （9）检查可测试性

81 2.8 测试后的调试 Return 软件调试和软件测试有完全不同的含义： ——测试的目的是显示存在错误。
2.8 测试后的调试 软件调试和软件测试有完全不同的含义： ——测试的目的是显示存在错误。 ——调试的目的是发现错误或导致程序失效的错误原因，并修改程序以修正错误。 通常情况是在测试以后紧接着要进行调试，调试是在测试发现错误后消除错误的过程。实际上这两项工作是交叉进行的。 Return

82 2.9 面向对象的软件测试 Return 1、面向对象的软件测试
2.9 面向对象的软件测试 1、面向对象的软件测试 面向对象软件测试的目标与传统测试一样，即用尽可能低的测试成本和尽可能少的测试用例，发现尽可能多的软件缺陷。面向对象的测试策略也遵循从“小型测试”到“大型测试”，即从单元测试到最终的功能性测试和系统性测试。 但面向对象技术所独有的封装、继承、多态等新特点给测试带来一系列新的问题，增加了测试的难度。与传统的面向过程程序设计相比，面向对象程序设计产生错误的可能性增大，或者使得传统软件测试中的重点不再那么突出，或者使得原来测试经验和实践证明的次要方面成为了主要问题。 Return

83 面向对象的软件测试（续） 2、面向对象的单元测试
与传统的单元不同，面向对象软件测试中的单元是封装的类和对象。每个类和类的实例（对象）包含了属性和操作这些属性的方法。 类包含一组不同的操作，并且某个或某些特殊操作可能作为一组不同的类的一部分而存在，测试时不再测试单个孤立的操作，而是测试操作类及类的一部分，单元测试的意义发生了较大的变化。 对面向对象软件的类测试等价于对面向过程软件的单元测试。传统的单元测试主要关注模块的算法和模块接口间数据的流动，即输入和输出；而面向对象软件的类测试主要是测试封装在类中的操作以及类的状态行为。

84 面向对象的软件测试（续） 3、面向对象的集成测试 面向对象的集成测试通常需要进行两级集成： （1）将成员函数集成到完整类中；
（2）将类与其它类集成。 对面向对象的集成测试有两种不同的策略： （1）基于线程的测试。集成针对回应系统的一个输入或事件所需的一组类，每个线程被集成并分别进行测试。 （2）基于使用的测试。首先测试独立的类，并开始构造系统，然后测试下一层的依赖类（使用独立类的类），通过依赖类层次的测试序列逐步构造完整的系统。

85 面向对象的软件测试（续） 4、面向对象的确认测试
与传统的确认测试一样，面向对象软件的有效性集中在用户可见的动作（事件驱动与过程）和用户可识别的系统输出（结果），通过测试检验软件是否满足用户的需求。 在面向对象的确认测试中，通常采用传统的黑盒测试方法，以证明软件功能和需求的一致性。

86 作业布置 P60 习题与思考 第2题、第4题、第6题