软件测试技术基础知识-第一篇

1、测试技术基础培训 培训内容培训内容 第一章测试技术的发展历程 第二章测试基本概念 第三章基本测试技术 第一章测试技术的发展历程第一章测试技术的发展历程 60年代（软件工程建立前），为表明程序正 确而进行测试。 1972年，Bill Hetzel在North Carolina大学举 行第一次以软件测试为主题的正式会议。 1979年，Glenford MyersThe Art of Software Testing提出测试的目的是证伪。 第一章测试技术的发展历程第一章测试技术的发展历程 1981年，Bill Hetzel开设“Structured Software Testing”公共课 1988

2、年David Gelperin & Bill Hetzel 在 “Communications of the ACM”发表“The Growth of Software Testing”。 70年代后期至80年代中期的QA部门。 第一章测试技术的发展历程第一章测试技术的发展历程 1996年提出的测试能力成熟度TCMM （Testing Capability Maturity Model）、测试 支持度TSM（Testability Support Model）、测 试成熟度TMM（Testing Maturity Model）。 第二章测试基本概念第二章测试基本概念 2.1 软件测试的定义 2

3、.2 软件开发与软件测试 2.3 广义的软件测试 2.4 测试方法 2.5 测试策略 2.6 验收测试 2.7 第三方测试 2.1 软件测试的定义软件测试的定义 为什么会出现软件缺陷为什么会出现软件缺陷 导致软件缺陷最大的原因是产品说明书。导致软件缺陷最大的原因是产品说明书。 软件缺陷的第二大来源是设计方案。软件缺陷的第二大来源是设计方案。 编写代码编写代码 其他其他 其他其他 10% 软件产品说明软件产品说明 书（需求）书（需求） 56% 编写代码编写代码 7% 设计设计 27% 软件缺陷的修复费用软件缺陷的修复费用 从开始到计划、编制、测试、一直到公开使用的从开始到计划、编制、测试、一直到

4、公开使用的 过程中，都有可能发现软件缺陷。过程中，都有可能发现软件缺陷。 随着时间推移，修复软件缺陷的费用呈几何数级随着时间推移，修复软件缺陷的费用呈几何数级 地增长。地增长。 0 20 40 60 80 100 编制说明书设计阶段编写代码测试发布 软件缺陷在不同阶段发现时修改的费用示意图 2.1 软件测试的定义软件测试的定义 软件测试就是在软件投入运行前，对软件需 求分析、设计规格说明和编码的最终复审， 是软件质量保证的关键步骤。 软件生存期的各个阶段都可能产生错误。而 软件需求分析、设计和实现阶段是软件的主 要错误来源。 2.1 软件测试的定义软件测试的定义 软件测试的对象 软件测试不等于

5、程序测试。 需求规格说明、概要设计规格说明、详细设计规 格说明、源程序都是软件测试的对象。 软件测试贯串于软件定义和开发的整个期间。 2.1 软件测试的定义软件测试的定义 软件测试的分类 按测试用例设计方法： 白盒测试 黑盒测试。 按测试策略和过程： 单元测试、 集成测试、 确认测试、 系统测试。 2.1 软件测试的定义软件测试的定义 软件测试的原则 尽早地和不断地进行软件测试 避免测试自己的程序 执行测试计划，排除随意性 增量测试，由小到大 周密的测试用例（输入条件（合理、不合理）、 预期输出结果） 回归测试 出错统计和分析 2.2 软件开发与软件测试软件开发与软件测试 软件开发过程各环节的

6、关系软件开发过程各环节的关系 2.2 软件开发与软件测试软件开发与软件测试V模型模型 2.2 软件开发与软件测试软件开发与软件测试V模型模型 V模型：需求、功能、设计和编码的开发活 动随时间而进行，而相应的测试活动（即针 对需求、功能、设计和编码的测试）开展的 次序正好相反。 成功应用软件开发V模型的关键因素是设计 测试案例的时机。 2.2 软件开发与软件测试软件开发与软件测试V模型模型 V模型的问题： 误解：“测试是开发之后的一个阶段”、 “测试的对象就是程序本身”。 实际应用中容易导致需求阶段的错误一直 到最后验收阶段才被发现。 2.2 软件开发与软件测试软件开发与软件测试W模型模型 2.

7、2 软件开发与软件测试软件开发与软件测试W模型模型 W模型： 测试伴随整个开发周期。 测试的对象不仅仅是程序，还包括需求和 设计。 W模型应用： 相应开发活动完成，即可执行测试（例如： 需求分析完成，即可对需求进行测试）。 2.2 软件开发与软件测试软件开发与软件测试W模型模型 W模型未解决V模型中的部分问题： 需求、设计、编码串行进行，无法并行工 作。 未将测试流程的完整性表示出来。 2.2 软件开发与软件测试软件开发与软件测试H模型模型 测试流程： 测试准备活动：测试计划、测试设计、测 试开发。 测试执行活动：测试运行、测试评估。 2.2 软件开发与软件测试软件开发与软件测试H模型模型 H

8、模型： 测试不仅仅是测试执行，还包括其他活动。 测试是一个独立流程，贯穿产品整个周期， 于其他流程并发进行。 测试要尽早准备，尽早执行。 2.2 软件开发与软件测试软件开发与软件测试H模型模型 应用H模型的意义： 测试准备和测试执行分离，有利于资源调 配。降低成本，提高效率。 充分体现测试过程（不是技术）的复杂性。 有组织、结构化的独立流程，有助于跟踪 测试投入的流向。 2.2 软件开发与软件测试软件开发与软件测试 开发各阶段的测试工作开发各阶段的测试工作 2.3 广义的软件测试广义的软件测试 广义的软件测试是由确认、验证、测试3个方面组成。 确认（validation）：评估将要开发的软件产

9、品是否正确 无误、可行和有价值的。确认意味着确保一个待开发软件是 正确无误的，是对软件开发构想的检测。 验证（verification）：检测软件开发的每个阶段、每个步 骤的结果是否正确无误，是否与软件开发各阶段的要求 或期望的结果相一致。验证意味着确保软件会正确无误地实 现软件的需求，开发过程是沿着正确的方向进行的。 测试：与狭隘的测试概念统一。 2.3 广义的软件测试广义的软件测试 确认主要体现在计划阶段、需求分析阶段， 也会出现在测试阶段；验证主要体现在设计 阶段、编码阶段；测试主要体现在编码阶段 和测试阶段。 确认、验证、测试是相辅相成的。确认产生 验证和测试的标准，验证和测试帮助完成

10、确 认（特别在系统测试阶段）。 2.4 测试方法测试方法 2.4 测试方法测试方法 任何工程产品都可以使用以下的两种方法进 行测试： 已知产品的功能设计规格，可以进行测试 证明每个实现了的功能是否符合要求。（黑 盒测试）。 已知产品的内部工作过程，可以通过测试 证明每种内部操作是否符合设计规格的要求， 所有内部成分是否已经过检查。（白盒测 试）。 2.4 测试方法黑盒测试测试方法黑盒测试 2.4 测试方法黑盒测试测试方法黑盒测试 黑盒测试法把程序看成一个黑盒子，完全不 考虑程序内部结构和处理过程。 黑盒测试是在程序接口进行测试，它只是检 查程序功能是否按照规格说明书的规定正常 使用。 黑盒测试

11、又称功能测试。 2.4 测试方法黑盒测试测试方法黑盒测试 2.4 测试方法黑盒测试测试方法黑盒测试 典型黑盒测试方法 等价类划分 因果图 边界值分析 2.4 测试方法黑盒测试测试方法黑盒测试 黑盒主要是为了发现以下几类错误： 是否有不正确或遗漏了的功能？ 在接口上，输入能否正确地接受？能否输出正确 的结果？ 是否有数据结构错误或外部信息（例如数据文 件）访问错误？ 性能上是否能够满足要求？ 是否有初始化或终止性错误？ 2.4 测试方法白盒测试测试方法白盒测试 2.4 测试方法白盒测试测试方法白盒测试 白盒测试的前提是可以把程序看成装在一个 透明的白盒子里，也就是完全了解程序结构 盒处理过程，这

12、种方法按照程序内部逻辑测 试程序，检验程序中每条通路是否按预定要 求正确工作。 白盒测试又称结构测试。 2.4 测试方法白盒测试测试方法白盒测试 2.4 测试方法测试方法 静态测试 静态测试是指不利用计算机运行被测程序，而是通 过其他手段达到检测的目的。包括需求评审、设计 评审、代码审查等。 静态测试并不等同于人工测试，它也可以利用计算 机作为对被测程序进行特性分析的工具，而只是不 真正运行被测程序。 静态方法也常常被称为“分析”，静态测试是对被 测程序进行特性分析的方法的总称。 2.4 测试方法测试方法 代码审查(Code Inspections) 代码审查会的过程如下： （1）会前准备：如

13、组织者在会议开始之前把这个程序清单和 设计规范分发给小组的其他成员，以便在会议之前熟悉这些 材料。 （2）会议期间： a. 请程序员逐句地讲述程序的逻辑结构。 b. 根据常见程序错误检验单分析程序。 （3）会后检查：把已查出错误清单交程序员，并对修改结果 进行跟踪。 代码审查关注下列类型问题： （1）数据引用错误（2）数据说明（3）计算（4）比较 （5）控制流（6）接口（7）输入/输出（8）其它检查 2.4 测试方法测试方法 静态测试阶段的任务： （1）检查算法的逻辑正确性。 （2）检查模块接口的正确性。 （3）检查输入参数是否有合法性检查。 （4）检查调用其他模块的接口是否正确。 （5）检查

14、是否设置了适当的出错处理。 （6）检查表达式、语句是否正确，是否含有二义性。 （7）检查常量或全局变量使用是否正确。 （8）检查标识符的使用是否规范、一致。 （9）检查程序风格的一致性、规范性。 （10）检查代码是否可以优化，算法效率是否最高。 （11）检查代码注释是否完整，是否正确反映了代码的功能。 2.4 测试方法测试方法 静态测试可以完成以下工作： （1）发现下列程序的错误：错用局部变量和全局变量；未定义的变量、不 匹配的参数；不适当的循环嵌套或分支嵌套、死循环、不允许的递归； 调用不存在的子程序，遗漏标号或代码。 （2）找出以下问题的根源：从未使用过的变量；不会执行到的代码、从未 使用

15、过的标号；潜在的死循环。 （3）提供程序缺陷的间接信息：所用变量和常量的交叉应用表；是否违背 编码规则；标识符的使用方法和过程的调用层次。 （4）为进一步查找做好准备。 （5）选择测试用例。 （6）进行符号测试。 2.4 测试方法测试方法 2、动态测试 动态方法的主要特征是计算机必须真正运行 被测试的程序，通过输入测试用例对其运行 情况（即输入与输出的对应关系）进行分析， 达到检测的目的。 动态测试包括：单元测试、集成测试、系统 测试、用户的验收测试和回归测试。 2.4 测试方法测试方法 使用静态和动态测试进行结构和功能测试： 测试阶段执行人静态校验动态校验 可行性评审开发人员，用户 需求评审

16、开发人员，用户 设计评审开发人员 单元测试开发人员 集成测试开发人员，测试人员 系统测试开发人员在测试人员 的协助下完成 验收测试用户 2.5 测试策略测试策略 2.5 测试策略测试的数据流测试策略测试的数据流 2.5 测试策略单元测试测试策略单元测试 单元测试又称为模块测试，是针对程序模块 （软件设计的最小单位）来进行正确性检验 的测试工作。 软件单元测试的目的是检测程序模块对详 细设计说明书的符合程度；软件单元测试 依据是单元测试计划。 2.5 测试策略单元测试测试策略单元测试 软件单元测试由测试工程师编制测试用例进 行测试，及针对程序模块进行多次循环反复 的单元测试，并将测试结果记录在针

17、对单元 测试的软件测试报告上。 若程序模块通过单元测试，则按配置管理 规范所规定的标识方法进行标识。 2.5 测试策略单元测试测试策略单元测试 模块接口测试 局部数据结构测试 路径测试 错误处理测试 边界测试 2.5 测试策略单元测试的步骤测试策略单元测试的步骤 通常单元测试是在编码阶段进行的。在源程 序代码编制完成。经过评审和验证，确认没 有语法错误之后，就开始进行单元测试的测 试用例设计。 驱动模块：相当于所测模块的主程序。 桩模块：也叫做存根模块。用以代替所测 模块调用的子模块。 2.5 测试策略单元测试的环境测试策略单元测试的环境 2.5 测试策略测试策略单元测试完成单元测试完成 2.

18、5 测试策略集成测试测试策略集成测试 为什么要进行集成测试？ 实践表明，软件的一些模块能够单独地工作，但并不能保证 组装连接之后也肯定能正常工作。程序在某些局部反映不出 来的问题，在全局情况下有可能暴露出来，影响软件功能的 实现。可能的原因有以下几方面： （1）模块相互调用时引入了新的问题，例如数据可能没有正 确传递，一模块对另一模块产生了不利的影响等。 （2）几个子功能组合后不能实现预期的主功能。 （3）单个模块的误差累计达到了不可接受的程度。 （4）全局数据结构出现问题。 2.5 测试策略集成测试测试策略集成测试 集成测试(Integrated Testing)阶段是指每个模块完成单元测试

19、 后，需要按照设计时确定的程序结构图，把它们连接起来进 行集成测试。集成测试也称为综合测试、组装测试、联合测 试。 集成测试的对象： 经过单元测试的程序模块间调用关系和接 口数据。 集成测试的目的：找出与软件设计相关的程序结构，模块调 用关系，模块间接口方面的问题。 集成测试的测试依据：程序结构设计文档（包括概要设计说 明书、详细设计说明书等）。 集成测试的基本方案：非增量式测试、增量式测试。 2.5 测试策略集成中的组装方法测试策略集成中的组装方法 非增量式测试是采用一步到位的方法来构造测试： 对所有模块进行个别的单元测试后，按照程序 结构图将各模块连接起来，把连接后的程序当作一 个整体进行

20、测试。 非增量式测试的缺点： 当一次集成的模块较多时，这种测试容易出现 混乱，因为测试时可能发现了许多故障，为每一个 故障定位和纠正非常困难，并且在修正一个故障的 同时，可能又引入了新的故障，新旧故障混杂，很 难判定出错的具体原因和位置。 2.5 测试策略集成中的组装方法测试策略集成中的组装方法 A S3S4S5 d2 C d4 E d5 F d1 B s1 d3 s2 D A BCD EF A BCD EF （1）程序结构图 （3）集成测试示意图 （2）单元测试示意图 2.5 测试策略集成中的组装方法测试策略集成中的组装方法 增量式测试的集成是逐步实现的：逐次将未曾集成 测试的模块和已集成测

21、试的模块（或子系统）结合 成程序包，再将这些模块集成为较大系统，在集成 的过程中边连接边测试，以发现连接过程中产生的 问题。 按照不同的实施次序，增量式集成测试又可以分为 三种不同的方法： 自顶向下增量式测试 自底向上增量式测试 混合增量式测试 2.5 测试策略集成中的组装方法测试策略集成中的组装方法 自顶向下增量式测试 这种集成方式是将模块按系统的程序结构自顶向 下进行集成，即模块集成的顺序是首先集成主控 模块（主程序），然后沿控制层次向下进行集成。 从属于主控模块的按深度优先方式（纵向）或者 广度优先方式（横向）集成到结构中去。 深度优先方式的集成：首先集成在结构中的一个主控 路径下的所有

22、模块，主控路径的选择是任意的。 广度优先方式的集成：首先沿着水平方向，把每一层 中所有直接隶属于上一层的模块集中起来，直到最底 层。 2.5 测试策略集成中的组装方法测试策略集成中的组装方法 自顶向下增量式测试的步骤： （1）以主控模块为所测模块兼驱动模块，所有直属于主控模 块的下属模块全部用桩模块代替。 （2）采用深度优先或广度优先的策略，用实际模块替换相应 桩模块，再用桩模块代替实际模块的直接下属模块，与已测 试的模块或子系统集成为新的子系统。下层的桩模块一次一 次地被替换为真正的模块。 （3）进行回归测试（即重新执行以前做过的全部测试或部分 测试），排除集成过程中引起错误的可能。 （4）

23、判断是否所有的模块都已集成到系统中，是则结束测试， 否则转到（2）去执行。 2.5 测试策略集成中的组装方法测试策略集成中的组装方法 A B C D E F A S1 S2 S3 A B C D S4 S5 A B C D E F （1） （2） （3） 广度优先方式广度优先方式 2.5 测试策略集成中的组装方法测试策略集成中的组装方法 A B C S3 E A B C D E F A S1 S2 S3 A B S2 S3 E （1） （2） （3） 深度优先方式深度优先方式 （4） 2.5 测试策略集成中的组装方法测试策略集成中的组装方法 自底向上增量式测试自底向上增量式测试 这种集成方式是

24、将模块按系统的程序结构自底向上进行 集成，即从程序模块结构的最底层模块开始集成和测试。 由于是自底向上进行集成，对于一个给定层次的模块， 它的子模块（包括子模块的所有下属模块）已经集成并 测试完成，所以不再需要桩模块。在模块的测试过程中 需要从子模块得到的信息可以直接运行子模块得到。 2.5 测试策略集成中的组装方法测试策略集成中的组装方法 自底向上增量式测试的步骤： （1）由驱动模块控制最底层模块的并行测试。 （2）用实际模块代替驱动模块，与它已测试的 直属子模块集成为子系统。 （3）为子系统配备驱动模块，进行新的测试。 （4）判断是否已集成到达主控模块，是则结束 测试，否则执行（2）。 2

25、.5 测试策略集成中的组装方法测试策略集成中的组装方法 A B C D E F d2 C d1 E d3 F d4 B E d5 F D A B C D E F 2.5 测试策略集成中的组装方法测试策略集成中的组装方法 混合增殖式测试：对软件中、上层使用自顶向下，对 软件的中下层采用自底向上。 集成步骤： 首先对输入输出模块和引入新算法模块进行测 试； 再自底向上组装成为功能相当完整且相对独立的 子系统； 然后由主模块开始自顶向下进行增殖测试。 2.5 测试策略集成测试的组织和实施测试策略集成测试的组织和实施 集成测试是一种正规测试过程，必须精心计划,并与 单元测试的完成时间协调起来。在制定测

26、试计划时， 应考虑如下因素： 是采用何种系统组装方法来进行组装测试。 组装测试过程中连接各个模块的顺序。 模块代码编制和测试进度是否与组装测试的顺序 一致。 测试过程中是否需要专门的硬件设备。 2.5 测试策略集成测试完成的标志测试策略集成测试完成的标志 成功地执行了测试计划中规定的所有组装测 试。 修正了所发现的错误。 测试结果通过了专门小组的评审。 2.5 测试策略集成测试完成的标志测试策略集成测试完成的标志 2.5 测试策略确认测试测试策略确认测试 确认测试又称有效性测试。 任务是验证软件的功能和性能及其他特性是 否与用户的要求一致。 对软件的功能和性能要求在软件需求规格说 明中已经明确

27、规定。 2.5 测试策略确认测试的步骤测试策略确认测试的步骤 2.5 测试策略测试策略 确认测试中的有效性测试确认测试中的有效性测试 有效性测试是在模拟的环境（可能就是开发 的环境）下，运用黑盒测试的方法，验证所 测软件是否满足需求规格说明书列的需求。 在全部软件测试的测试用例运行完后，所有 的测试结果可以分为两类： 测试结果与预期的结果相符。 测试结果与预期的结果不符。 2.5 测试策略测试策略 确认测试中的软件配置复查确认测试中的软件配置复查 软件配置复查的目的是保证软件配置的所有 成分都齐全。 各方面的质量都符合要求。 具有维护阶段所必需的细节。 而且已经编排好分类的目录。 2.5 测试

28、策略系统测试测试策略系统测试 系统测试是将通过确认测试的软件，作为整 个基于计算机系统的一个元素，与计算机硬 件、外设、某些支持软件、数据和人员等其 他系统元素结合在一起测试。 在实际运行（使用）环境下，对计算机系统 进行一系列的组装测试和确认测试。 系统测试的目的在于通过与系统的需求定义 作比较，发现软件与系统定义不符合或与之 矛盾的地方。 2.5 测试策略系统测试测试策略系统测试 由于软件只是计算机系统中的一个组成部分，软件开发完成 之后，最终还要和系统中的硬件系统、某些支持软件、数据 信息等其他部分配套运行。因此，软件在投入运行以前需要 完成系统测试，以保证各组成部分不仅能单独的得到检验

29、， 而且在系统各部分协调工作的环境下也能正常工作。 系统测试实际上是针对系统中各个组成部分进行的综合性检 验。尽管每一个检验有特定的目标，然而所有的检测工作都 要验证系统中每个部分均已得到正确的集成，并能完成指定 的功能。 严格的说，系统测试超出了软件工程范围。通常这项工作并 不由系统开发人员或系统开发组织来承担，而是由软件用户 或软件开发机构委托独立测试机构来完成。 2.5 测试策略系统测试测试策略系统测试 系统测试与单元测试、集成测试的区别： （1）测试方法不同：系统测试属于黑盒测试，而单元测试大 量采用白盒测试，集成测试则是结合使用白盒与黑盒测试方 法。 （2）考察范围不同：单元测试主要

30、测试模块内部的接口、数 据结构、逻辑、异常处理等对象。集成测试主要测试模块之 间的接口和异常。系统测试主要测试整个系统相对于用户的 需求。 （3）评估基准不同：系统测试的评估基准是测试用例对需求 规格的覆盖率；而单元测试和集成测试的评估主要是代码的 覆盖率。 2.5 测试策略测试策略 系统测试的系统测试的15种测试类型种测试类型 功能（机能）测试：目标中的功能是否真正实现了。 批量测试：企图证明程序不能处理目标中指出的大 批数据。 强度测试：让程序在高负荷情况下运行（微软建议 72小时）。 可用性测试：界面友好、错误信息简明易懂。 安全性测试：设法破坏程序的保密检查。 2.5 测试策略测试策略

31、 系统测试的系统测试的15种测试类型种测试类型 性能测试：在一定工作负荷和配置条件下，系统响 应时间及处理速度。 存储量测试：测试程序所占用的内外存容量（静/动 态）。 配置测试：至少每一类和最大最小的设备配置情况 都要测试。 兼容/移植测试：对现有程序进行修改和补充后，要 进行此类测试。 可安装性测试：测试系统的安装过程。 2.5 测试策略测试策略 系统测试的系统测试的15种测试类型种测试类型 可靠性测试：如平均无故障时间（MTTF）， 需要模拟运行环境。 恢复测试：测试系统出错后如何恢复正常工 作的。 可维护性测试：对维护过程和难易程度进行 测试。 文档测试：审查文档的正确性，对文档中的

32、每个例子都要作为测试用例。 工序测试：测试操作工序的次序正确性。 2.5 测试策略系统测试完成测试策略系统测试完成 2.5 测试策略回归测试测试策略回归测试 2.5 测试策略测试策略测试和测试和测试测试 测试是由一个用户在开发环境下进行的测试, 也可以是开发机构内部的用户在模拟实际操 作环境下进行的测试。测试的目的是评价软 件产品的功能、可使用性、可靠性、性能和 支持，尤其注重产品的界面和特色。 测试可以从软件产品编码结束之时开始，或 在模块（子系统）测试完成之后开始，也可 以在确认测试过程中产品达到一定的稳定和 可靠程度之后再开始。 2.5 测试策略测试策略测试和测试和测试测试 测试是由软件

33、的多个用户在一个或多个用户的实 际使用环境下进行的测试。与测试不同的是，开 发者通常不在测试现场。测试的目的是衡量软件 产品的功能、可使用性、可靠性、性能和支持，尤 其注重产品的产品的支持性，包括文档、客户培训 和支持产品生产能力。 只有当测试达到一定的可靠程度时，才能开始测 试。它处在整个测试的最后阶段。同时，产品的所 有手册文本也应该在此阶段完全定稿 2.6 验收测试验收测试 验收测试是检验软件产品质量的最后一道工序。验 收测试是以用户为主的测试，同时软件开发人员也 有一定的参与。 验收测试由用户参加设计测试用例，使用用户界面 来输入测试数据，并分析测试的输出结果，一般使 用生产中的实际数

34、据进行测试。 在验收测试过程中，除了考虑软件的功能和性能外， 还应对软件的可移植性、兼容性、可维护性等进行 确认。 2.6 验收测试范围验收测试范围 软件验收测试应完成的工作包括： 明确验收项目，给定验收测试通过的标准。 确定测试方法。 决定验收测试的组织机构和可利用的资源。 选定测试结果分析方法。 制定验收测试计划并进行评审。 设计验收测试所用测试用例。 审查验收测试准备工作。 执行验收测试。 分析测试结果。 阐明验收测试结论，决定通过验收或是拒绝。 2.6 验收测试计划验收测试计划 可能包括的检验方面有以下一些： 功能测试（例如，完整的工资计算过程）。 逆向测试（例如，检验不符合要求数据而

35、引起出错的恢复 能力）。 特殊情况（例如，极限测试、不存在路径的测试）。 文档检查。 强度测试（例如，大批数据或多用户同时使用）。 恢复测试（例如，硬件故障或用户不良数据引起的一些情 况）。 可维护性评价。 用户操作测试（如启动、退出系统）。 用户友好性检验。 安全测试。 2.6 验收测试结果验收测试结果 确认测试的结果，确认测试的结果有两种情 况： 功能和性能与用户的要求一致，软件可以 接受。 功能和性能与用户的要求的差距。 2.7 第三方测试第三方测试 信息系统工程承建单位内部进行的自测被称 为第一方测试，业主单位对工程进行的测试 被称为第二方测试。与此相对应，由中立的 第三方测试机构对系

36、统进行的权威技术测试 被称为第三方测试。 国内的第三方测试工作始创于九十年初，经 过了近十年的孕育，以“千年虫”问题的检 验为契机，在二十世纪末开始快速发展。 2.7 第三方测试必要性第三方测试必要性 国外开发商质量控制能力较强，但在比较专 业的质量认证领域依然需要由第三方机构来 完成。 国内业主与开发商在信息技术与业务技术上 的信息不对称性。 国内还没有适应国情的、系列化协调配套 的、工程化的信息系统生产过程管理、质量 评测、控制技术的规范和法律规程指导。 2.7 第三方测试特点第三方测试特点 第三方测试具有明显的工程特性，主要包括 需求分析审查、设计审查、功能测试、性能 测试、安全性测试、

37、可靠性测试、易用性测 试、兼容性测试、可扩充性测试、文档测试 等。 2.7 第三方测试特点第三方测试特点 第三方测试以合同的形式制约了测试方，保 证了测试工作在一开始就具有客观性。 第三方能够从需求理解系统，从软件工程角 度把握系统，公平的评价系统中出现的问题。 第三方机构的权威性能够更好的协调用户与 开发方之间的关系。 2.7 第三方测试特点第三方测试特点 第三方测试不同于开发方的自测试。 避免开发人员的定势思维。 第三方测试的目的就是为尽量多地发现程 序中的错误而运行程序的过程，可以更多的 发现问题。 随着系统越做越大，开发方很难投入足够 的人力与物力进行测试工作，同时也缺乏专 业的测试工

38、具及丰富的工具使用经验。 2.7 第三方测试特点第三方测试特点 第三方测试不同于用户的自测试。 用户熟悉业务但不熟悉计算机领域知识， 很难对系统进行深入分析。 用户缺乏专用的测试工具。 第三方机构既往测试经验对测试的帮助。 2.7 第三方测试对象第三方测试对象 应用软件的确认测试、鉴定测试 工程项目的系统测试、验收测试 特殊项目/项目关键模块的单元测试 其他： 工程监理 ISO9000认证、CMM认证 2.7 第三方测试开展第三方测试开展 项目组成立 制定方案、规范、案例与计划 实施测试工作 问题报告 回归测试 测试总结、评估与测试报告 第三章基本测试技术第三章基本测试技术 3.1 测试生命周

39、期 3.2 测试计划 3.3 测试设计 3.4 测试开发 3.5 测试执行 3.6 测试评估 3.7 测试跟踪 3.1 测试生命周期测试生命周期 3.2 测试计划概述测试计划概述 测试目的 完成的标准 时间安排 明确的责任 测试用例库 测试工具 3.2 测试计划概述测试计划概述 所需机器时间 软/硬件配置 系统组装方式 记录手段 回归测试 3.2 测试计划具体内容测试计划具体内容 目的 测试项（对象） 测试类型 测试范围 测试过程 资源需求（硬件、软件、人力） 3.2 测试计划具体内容测试计划具体内容 文档的检验 进度安排 测试开始、结束准则 测试记录 回归测试的方法 测试的评估 缺陷跟踪 3.2 测试计划测试需求测试计划测试需求 业务功能 业务流程 数据库事务 域值合法性 用户界面 对象状态 窗口模式 菜单 标准尺寸的控件/文字 3.2 测试计划测试需求测试计划测试需求 性能 在少于3秒的情况下增加一个新顾客帐户 强度 当内存很低的情况下运行应用程序 为设计规定是1,000,000 条记录的系统增 加1,000,001条记录 3.2 测试计划测试需求测试计划测试需求 配置 显示驱动的兼容性 网络连接 安装 新安装（典型安装、定制安装） 升级安装 网络下载 3.3 测试设计测试设计测试过程测试过程 包括详细的步骤以确定测试需求是否被满足。 组成： 测试的先决条件 输入条件