测试技术基础-演示稿.ppt

《测试技术基础-演示稿.ppt》由会员分享，可在线阅读，更多相关《测试技术基础-演示稿.ppt（118页珍藏版）》请在装配图网上搜索。

1、软件测试工程师培训 （测试技术基础） 中国软件评测中心 高炽扬 培训内容 第一章 测试概述 第二章 测试基本概念 第三章 基本测试技术 第四章 测试中的若干问题 第一章 测试概述 1.1 软件测试的发展 1.2 广义的软件测试 1.3 软件的错误、缺陷与故障 1.1 软件测试的发展 60年代（软件工程建立前），为表明程序正确而 进行测试。 1972年， Bill Hetzel 在 North Carolina大学举行第 一次以软件测试为主题的正式会议。 1979年， Glenford Myers The Art of Software Testing 提出测试的目的是证伪。 1.1 软件测试的

2、发展 1981年， Bill Hetzel开设“ Structured Software Testing”公共课； 1988年 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 Mat

3、urity Model）。 1.2 广义的软件测试 广义的软件测试是由确认 、 验证 、 测试 3个方 面组成 。 确认 （ validation） ：评估将要开发的软件产品是否 正确无误 、 可行和有价值的 。 确认意味着确保一个 待开发软件是正确无误的 ， 是对软件开发构想的检 测 。 验证 （ verification） ：检测软件开发的每个阶段 、 每个步骤的结果是否正确无误 ， 是否与软件开发各 阶段的要求或期望的结果相一致 。 验证意味着确保 软件会正确无误地实现软件的需求 ， 开发过程是沿 着正确的方向进行的 。 测试：与狭隘的测试概念统一 。 1.2 广义的软件测试 确认：目的

4、是想证实在一个给定的外部 环境中软件的逻辑正确性 。 包括需求规 格说明的确认和程序的确认 。 程序确认 包括静态确认与动态确认 。 验证：试图证明在软件生存期各个阶段 ， 以及阶段间的逻辑协调性 、 完备性和正 确性 。 1.2 广义的软件测试 确认：保证所生产的软件可追溯到用户 需求的一系列活动 。 （ 生产的软件是否 正确 ） 验证：保证软件正确地实现了特定功能 的一系列活动 。 （ 生产软件的步骤是否 正确 ） 1.2 广义的软件测试 确认主要体现在计划阶段 、 需求分析阶 段 ， 也会出现在测试阶段；验证主要体 现在设计阶段 、 编码阶段；测试主要体 现在编码阶段和测试阶段 。 确认

5、 、 验证 、 测试是相辅相成的 。 确认 产生验证和测试的标准 ， 验证和测试帮 助完成确认 （ 特别在系统测试阶段 ） 。 1.3 软件的错误、缺陷与故障 错误：编码失误造成的问题 缺陷：需求与设计的不完善 故障：出现错误导致系统停止工作 第二章 测试基本概念 2.1 软件测试的定义 2.2 软件开发的模型 2.3 测试的目的和原则 2.4 测试的数据流 2.5 测试与软件开发的关系 2.6 测试方法 2.7 测试策略 2.8 验收测试 2.9 第三方测试 2.1 软件测试的定义 软件生存周期：需求定义和需求分析 、 软件设计 、 程序编码 、 软件测试 、 运行 维护 。 2.1 软件测

6、试的定义 软件测试就是在软件投入运行前，对软件 需求分析、设计规格说明和编码的最终复 审，是软件质量保证的关键步骤。 测试：为了发现软件中的错误而运行软件 的过程。 2.1 软件测试的定义 软件生存期的各个阶段都可能产生错误。 而软件需求分析、设计和实现阶段是软件 的主要错误来源。 软件测试在软件生存期中，跨越两个阶段： 一个是编码与单元测试阶段，另一个是综 合测试阶段，即测试阶段。 2.1 软件测试的定义 软件测试的对象 软件测试不等于程序测试 。 软件测试贯串于软件定义和开发的整个期间 。 需求规格说明 、 概要设计规格说明 、 详细设 计规格说明 、 源程序都是软件测试的对象 。 2.1

7、 软件测试的定义 软件测试的分类 按测试用例设计方法：白盒测试 、 黑盒测试 。 按测试策略和过程：单元测试 、 集成测试 、 确认测试 、 系统测试 。 2.2 软件开发的模型 测试的活动应该与软件开发同步进行。 测试的执行是在软件已编制完成后进行。 及早发现软件的缺陷可以降低软件开发的 成本 。 2.2 软件开发的模型 V模型 用户 需求获取 需求定义 需求分析 需求分析书 概要设计 概要设计书 详细设计 详细设计书 编码 程序 单元测试 已测试模块 集成测试 已集成软件 确认测试 已确认软件 系统测试 软件产品 评审 评审 评审 评审 静态 检查 评审 评审 评审 制定测试案例 需 求

8、分 析 2.2 软件开发的模型 V模型 V模型：需求、功能、设计和编码的开发 活动随时间而进行，而相应的测试活动 （即针对需求、功能、设计和编码的测试） 开展的次序正好相反。 成功应用软件开发 V模型的关键因素是设 计测试案例的时机 。 2.2 软件开发的模型 V模型 V模型的问题： 误解： “ 测试是开发之后的一个阶段 ” 、 “ 测试的对象就是程序本身 ” 。 实际应用中容易导致需求阶段的错误一直到 最后验收阶段才被发现 。 2.2 软件开发的模型 W模型 需求分析 需求测试 概要设计 功能测试 详细设计 设计测试 集成 集成测试 确认 确认测试 交付 系统测试 编码 单元测试 2.2 软

9、件开发的模型 W模型 W模型： 测试伴随整个开发周期 。 测试的对象不仅仅是程序 ， 还包括需求和设 计 。 W模型应用： 相应开发活动完成 ， 即可执行测试 （ 例如： 需求分析完成 ， 即可对需求进行测试 ） 。 2.2 软件开发的模型 W模型 W模型未解决 V模型中的部分问题： 需求 、 设计 、 编码串行进行 ， 无法并行工作 。 不同层次之间的测试除时间上的先后关系外 ， 还存在触发 、 反复 、 迭代 、 增量等关系 。 未将测试流程的完整性表示出来 。 2.2 软件开发的模型 H模型 测试流程： 测试准备活动：需求分析 、 测试计划 、 测试 分析 、 测试编码 、 测试验证 。

10、 测试执行活动：测试运行 、 测试报告 、 测试 分析 。 测试准备 测试执行 测试流程 其他流程（如设计流程） 测试就绪点 2.2 软件开发的模型 H模型 H模型： 测试不仅仅是测试执行 ， 还包括其他活动 。 测试是一个独立流程 ， 贯穿产品整个周期 ， 于其他流程并发进行 。 测试要尽早准备 ， 尽早执行 。 测试根据被测物的不同是分层次的 。 2.2 软件开发的模型 H模型 应用 H模型的意义： 测试准备和测试执行分离 ， 有利于资源调配 。 降低成本 ， 提高效率 。 充分体现测试过程 （ 不是技术 ） 的复杂性 。 有组织 、 结构化的独立流程 ， 有助于跟踪测 试投入的流向 。

11、2.3 软件测试的目的和原则 测试的目的是寻找错误，并且是尽最大可 能找出最多的错误。 观点 1：好的测试方案是极可能发现迄今为 止尚未发现的错误的测试方案。 观点 2：成功的测试是发现了至今为止尚未 发现的错误的测试。 测试无法说明错误不存在， 只能说明软件错误已出现。 2.3 软件测试的目的和原则 验证用户需求 发现软件缺陷 改进开发过程 目的 ：在软件分 发到最终用户手 中之前，发现并 解决软件缺陷 尽早地和不断地进行软件测试 避免测试自己的程序 执行测试计划，排除随意性 增量测试，由小到大 周密的测试用例（输入条件（合理、不合 理）、预期输出结果） 回归测试 出错统计和分析 2.3 软

12、件测试的目的和原则 2.4 测试的数据流 测试 结果 分析 排错 可靠性 分析 改正的软件 预测可靠性 错误 测试结果 出错率数据 预期结果 测试工具 软件配置 测试配置 回归测试 2.5 测试与软件开发的关系 软件测试与开发过程的关系 概要设计 说明书 详细设计 说明书 源程序 代码 单元 测试 集成 测试 确认 测试 需求分析 说明书 需求分析 设计 编程 确认测试 集成测试 单元测试 2.5 测试与软件开发的关系 软件测试与开发的并行性 需求分析 概要设计 需求评审 概要设计评审 详细设计 设计走查 编码 编码走查 单元测试 各子模块 测试计划 测试过程 测试评审 集成测试 系统测试 项

13、目阶段任务的里程碑 2.5 测试与软件开发的关系 完整的开发流程 项目规划 项目详细分析 代码编写 测试需求分析 系统测试计划 集成测试计划 单元测试计划 产品发布 系统测试 集成测试 单元测试 测试代码编写 项目需求分析 项目概要分析 2.5 测试与软件开发的关系 开发各阶段的测试工作 项目规划阶段： 确定专人负责测试阶段监控 。 需求分析阶段： 制定测试需求分析 、 系统测试计划 ， 经评审后 成为配置管理项 。 测试所需要的资源 、 配置 、 每阶段评判通过标 志进行规约 。 2.5 测试与软件开发的关系 开发各阶段的测试工作 详细设计和概要设计阶段： 确保集成测试计划和单元测试计划完成

14、 。 测试计划完成后 ， 对参考的设计文档进行修改 。 编码阶段 编写测试代码 。 （ 测试人员 、 专人 ） 测试阶段 测试人员执行测试 。 完成测试报告 。 2.6 测试方法 白盒测试 黑盒测试 两种测试方法从不同的角度出发， 反映了软件的不同侧面，也适用于 不同的开发环境 2.6 测试方法 任何工程产品都可以使用以下的两种方 法进行测试： 已知产品的功能设计规格 ， 可以进行测试证 明每个实现了的功能是否符合要求 。 （ 黑盒 测试 ） 。 已知产品的内部工作过程 ， 可以通过测试证 明每种内部操作是否符合设计规格的要求 ， 所有内部成分是否已经过检查 。 （ 白盒测 试 ） 。 2.6

15、 测试方法黑盒测试 黑盒测试法把程序看成一个黑盒子，完全 不考虑程序内部结构和处理过程。 黑盒测试是在程序接口进行测试，它只是 检查程序功能是否按照规格说明书的规定 正常使用。 黑盒测试又称功能测试。 2.6 测试方法黑盒测试 黑盒主要是为了发现以下几类错误： 是否有不正确或遗漏了的功能 ？ 在接口上 ， 输入能否正确地接受 ？ 能否输出 正确的结果 ？ 是否有数据结构错误或外部信息 （ 例如数据 文件 ） 访问错误 ？ 性能上是否能够满足要求 ？ 是否有初始化或终止性错误 ？ 2.6 测试方法黑盒测试 输入 输出 黑盒测试又称 功能测试 、数据驱动测试或 基于规格说明的测试，也可称为 用户测

16、试 ， 主要应用于快速应用开发环境 2.6 测试方法白盒测试 白盒测试的前提是可以把程序看成装在 一个透明的白盒子里，也就是完全了解 程序结构盒处理过程，这种方法按照程 序内部逻辑测试程序，检验程序中每条 通路是否按预定要求正确工作。 白盒测试又称结构测试。 2.6 测试方法白盒测试 使用白盒测试方法 ， 主要想对程序模块 进行如下的检查： 对程序模块的所有独立的执行路径至少测试 一次 。 对所有的逻辑判定 ， 取 “ 真 ” 与取 “ 假 ” 的 两种情况都能至少测试一次 。 在循环的边界和运行界限内执行循环体 。 测试内部数据结构的有效性等 。 2.6 测试方法白盒测试 白盒测试又称 结构

17、测试 、逻辑驱动测试或 基于程序本身的测试，也可称为 程序员测 试 ，主要应用于结构化开发环境 应用程序 2.7 测试策略 集成 测试 确认 测试 系统 测试 单元 测试 被测模块 单元 测试 被测模块 单元 测试 被测模块 已 集 成 的 软 件 已 确 认 的 软 件 可 交 付 的 软 件 测 试 通 过 的 模 块 设 计 信 息 软 件 需 求 系 统 其 它 元 素 软件测试的过程 2.7 测试策略 单元测试 单元测试又称为模块测试 ， 是针对程序模块 （ 软件设计的最小单位 ） 来进行正确性检验 的测试工作 。 软件单元测试的目的是检测程序模块对 详 细设计说明书 的符合程度；软

18、件单元测试 依据是 单元测试计划 。 2.7 测试策略 单元测试 软件单元测试由测试工程师编制测试用例进 行测试 ， 及针对程序模块进行多次循环反复 的单元测试 ， 并将测试结果记录在针对单元 测试的 软件测试报告 上 。 若程序模块通过单元测试 ， 则按 配置管理 规范 所规定的标识方法进行标识 。 2.7 测试策略单元测试的内容 模块接口测试 局部数据结构测试 路径测试 错误处理测试 边界测试 模块接口 出错处理 独立路径 边界条件 局部数据 模块 2.7 测试策略单元测试的步骤 通常单元测试是在编码阶段进行的 。 在 源程序代码编制完成 。 经过评审和验证 ， 确认没有语法错误之后 ，

19、就开始进行单 元测试的测试用例设计 。 驱动模块：相当于所测模块的主程序 。 桩模块：也叫做存根模块 。 用以代替所测模 块调用的子模块 。 2.7 测试策略单元测试的环境 测试用例 驱动模块 桩模块 2 被测模块 测试结果 桩模块 1 桩模块 n 2.7 测试策略单元测试 单元测试 单元测试 单元测试 单元测试 单元测试 2.7 测试策略 集成测试 软件集成测试又称组装测试 ， 即对程序模块 采用自顶向下或自底向上组装起来 ， 对系统 的接口进行正确性检验的测试工作 。 软件集成测试由项目经理组织软件测试工程 师依据 概要设计说明书 和 集成测试计 划 进行 。 2.7 测试策略 集成测试

20、测试人员应提交针对软件集成测试的 软件 测试报告 ， 项目经理负责对软件集成测试 结果的进行确认 。 通过集成测试 ， 则按 配置管理规范 所规 定的标识方法进行标识 。 2.7 测试策略集成测试 集成测试 ， 通常是在单元测试的基础上 ， 需要将所有模块按照设计要求组装成为系 统 。 这时需要考虑的问题是： 在把各个模块连接起来的时候 ， 穿越模块接口 的数据是否会丢失 。 一个模块的功能是否会对另一个模块的功能产 生不利的影响 。 各个子功能组合起来 ， 能否达到预期要求的父 功能 。 全局数据结构是否有问题 。 单个模块的误差累积起来 ， 是否会放大 ， 从而 达到不能接受的程序 。 2

21、.7 测试策略集成中的组装方法 一次性组装 /整体拼装：使用这种方式 ， 首 先对每个模块分别进行模块测试 ， 然后再 把所有模块组装在一起进行测试 ， 最终得 到要求的软件系统 。 可以并行调试所有模块 ， 因此充分利用人力 ， 加快工作进度 。 接口错误发现晚 。 错误定位困难 。 2.7 测试策略集成中的组装方法 增殖式组装 /渐增式组装：首先对一个个模 块进行模块测试 ， 然后将这些模块逐步组装 成较大的系统 ， 在组装的过程中边连接边测 试 ， 以发现连接过程中产生的问题 。 自顶向下的增殖方式：是一种日益为人们广泛 采纳的组装软件途径 ， 原型法开发中应用广泛 。 自底向上的增殖方

22、式：总能得到下层模块的处 理功能支持 ， 所以不需要存根程序 。 混合增殖式测试：对软件中 、 上层使用自顶向 下 ， 对软件的中下层采用自底向上 。 2.7 测试策略集成测试的组织和实施 集成测试是一种正规测试过程 ， 必须精心计 划 ， 并与单元测试的完成时间协调起来 。 在 制定测试计划时 ， 应考虑如下因素： 是采用何种系统组装方法来进行组装测试 。 组装测试过程中连接各个模块的顺序 。 模块代码编制和测试进度是否与组装测试的顺序 一致 。 测试过程中是否需要专门的硬件设备 。 2.7 测试策略集成测试完成的标志 成功地执行了测试计划中规定的所有组 装测试。 修正了所发现的错误。 测试

23、结果通过了专门小组的评审。 2.7 测试策略集成测试 单元测试 单元测试 单元测试 单元测试 单元测试 集 成 测 试 2.7 测试策略确认测试 确认测试又称有效性测试 。 任务是验证软件的功能和性能及其他特 性是否与用户的要求一致 。 对软件的功能和性能要求在软件需求规 格说明中已经明确规定 。 2.7 测试策略确认测试的步骤 选择测试人员 设计测试用例 软件计划 实际运行测试 用户文档 开发文档 源程序文本 支持环境 有效 性 测试 软件 配置 审查 管理 机构 裁决 专家 鉴定 会 测试报告 软件配置 交用户 运行维护 2.7 测试策略 确认测试中的有效性测试 有效性测试是在模拟的环境

24、（ 可能就是开 发的环境 ） 下 ， 运用黑盒测试的方法 ， 验 证所测软件是否满足需求规格说明书列的 需求 。 在全部软件测试的测试用例运行完后 ， 所 有的测试结果可以分为两类： 测试结果与预期的结果相符 。 测试结果与预期的结果不符。 2.7 测试策略 确认测试中的软件配置复查 软件配置复查的目的是保证软件配置的 所有成分都齐全 。 各方面的质量都符合要求 。 具有维护阶段所必需的细节 。 而且已经编排好分类的目录 。 2.7 测试策略系统测试 系统测试是将通过确认测试的软件 ， 作为 整个基于计算机系统的一个元素 ， 与计算 机硬件 、 外设 、 某些支持软件 、 数据和人 员等其他系

25、统元素结合在一起测试 。 在实际运行 （ 使用 ） 环境下 ， 对计算机系 统进行一系列的组装测试和确认测试 。 系统测试的目的在于通过与系统的需求定 义作比较 ， 发现软件与系统定义不符合或 与之矛盾的地方 。 2.7 测试策略 系统测试的 15种测试类型 功能 （ 机能 ） 测试：目标中的功能是否真 正实现了 。 批量测试：企图证明程序不能处理目标中 指出的大批数据 。 强度测试：让程序在高负荷情况下运行 。 可用性测试：界面友好 、 错误信息简明易 懂 。 安全性测试：设法破坏程序的保密检查 。 性能测试：在一定工作负荷和配置条件下 ， 系统响应时间及处理速度 。 存储量测试：测试程序所

26、占用的内外存容 量 （ 静 /动态 ） 。 配置测试：至少每一类和最大最小的设备 配置情况都要测试 。 兼容 /移植测试：对现有程序进行修改和补 充后 ， 要进行此类测试 。 可安装性测试：测试系统的安装过程 。 2.7 测试策略 系统测试的 15种测试类型 可靠性测试：如平均无故障时间 （ MTTF） ， 需要模拟运行环境 。 恢复测试：测试系统出错后如何恢复正常 工作的 。 可维护性测试：对维护过程和难易程度进 行测试 。 文档测试：审查文档的正确性 ， 对文档中 的每个例子都要作为测试用例 。 工序测试：测试操作工序的次序正确性 。 2.7 测试策略 系统测试的 15种测试类型 2.7

27、测试策略系统测试 系统测试 2.7 测试策略回归测试 单元测试 集成测试 确认测试 系统测试 回归测试 2.7 测试策略 测试和 测试 测试是由一个用户在开发环境下进行的 测试 ， 也可以是开发机构内部的用户在模 拟实际操作环境下进行的测试 。 测试的 目的是评价软件产品的功能 、 可使用性 、 可靠性 、 性能和支持 。 测试是由软件的多个用户在一个或多个 用户的实际使用环境下进行的测试 。 与 测试不同的是 ， 开发者通常不在测试现场 。 2.8 验收测试 项目经理负责组织验收组进行最终验收测试 。 验收组应由项目组成员 、 用户代表 、 监理代 表等组成 。 验收测试原则上在顾客所在地进

28、 行 ， 但如经顾客同意也可以在公司内模拟用 户环境进行 。 2.8 验收测试 验收测试根据合同 、 需求规格说明书 或 验收测试计划 对成品进行验收测试 。 对于通过验收测试的软件产品 /参照 配置 管理规范 中所规定的标识方法更改测试状 态 ， 同时项目经理负责编制 验收报告 。 2.8 验收测试范围 软件验收测试应完成的工作包括： 明确验收项目 ， 给定验收测试通过的标准 。 确定测试方法 。 决定验收测试的组织机构和可利用的资源 。 选定测试结果分析方法 。 制定验收测试计划并进行评审 。 设计验收测试所用测试用例 。 审查验收测试准备工作 。 执行验收测试 。 分析测试结果 。 阐明

29、验收测试结论 ， 决定通过验收或是拒绝 。 2.8 验收测试计划 可能包括的检验方面有以下一些： 功能测试 （ 例如 ， 完整的工资计算过程 ） 。 逆向测试 （ 例如 ， 检验不符合要求数据而引起出错的恢复能力 ） 。 特殊情况 （ 例如 ， 极限测试 、 不存在路径的测试 ） 。 文档检查 。 强度测试 （ 例如 ， 大批数据或多用户同时使用 ） 。 恢复测试 （ 例如 ， 硬件故障或用户不良数据引起的一些情况 ） 。 可维护性评价 。 用户操作测试 （ 如启动 、 推出系统 ） 。 用户友好性检验 。 安全测试 。 2.8 验收测试结果 确认测试的结果， 确认测试的结果有两种情 况： 功

30、能和性能与用户的要求一致，软件可以接受。 功能和性能与用户的要求的差距。 验收测试 在通过了系统的有效性测试及软件配置审查之后， 就应开始系统的验收测试。验收测试是以用户为 主的测试。 2.9 第三方测试 信息系统工程承建单位内部进行的自测被称为 第一方测试，业主单位对工程进行的测试被称 为第二方测试。与此相对应，由中立的第三方 测试机构对系统进行的权威技术测试被称为第 三方测试。 国内的第三方测试工作始创于九十年代初，经 过了近十年的孕育，以“千年虫”问题的检验 为契机，在二十世纪末开始快速发展。 2.9 第三方测试必要性 国外开发商质量控制能力较强，但在比较专 业的质量认证领域依然需要由第

31、三方机构来 完成。 国内业主与开发商在信息技术与业务技术上 的信息不对称性。 国内还没有适应国情的、系列化协调配套的、 工程化的信息系统生产过程管理、质量评测、 控制技术的规范和法律规程指导。 2.9 第三方测试特点 第三方测试具有明显的工程特性，主要 包括需求分析审查、设计审查、功能测 试、性能测试、安全性测试、可靠性测 试、易用性测试、兼容性测试、可扩充 性测试、文档测试等。 2.9 第三方测试特点 第三方测试以合同的形式制约了测试方， 保证了测试工作在一开始就具有客观性。 第三方能够从需求理解系统，从软件工 程角度把握系统，公平的评价系统中出 现的问题。 第三方机构的权威性能够更好的协调

32、用 户与开发方之间的关系。 2.9 第三方测试特点 第三方测试不同于开发方的自测试。 避免开发人员的定势思维。 第三方测试的目的就是为尽量多地发现程序 中的错误而运行程序的过程，可以更多的发 现问题。 随着系统越做越大，开发方很难投入足够的 人力与物力进行测试工作，同时也缺乏专业 的测试工具及丰富的工具使用经验。 2.9 第三方测试特点 第三方测试不同于用户的自测试。 用户熟悉业务但不熟悉计算机领域知识，很 难对系统进行深入分析。 用户缺乏专用的测试工具。 第三方机构既往测试经验对测试的帮助。 2.9 第三方测试原则 委托原则 独立公正原则 依法原则 回避原则 保密原则 2.9 第三方测试对象

33、 应用软件的确认测试、鉴定测试 工程项目的系统测试、验收测试 特殊项目 /项目关键模块的单元测试 其他： 工程监理 ISO9000认证、 CMM认证 2.9 第三方测试开展 项目组成立 制定方案、规范、案例与计划 实施测试工作 问题报告 回归测试 测试总结、评估与测试报告 第三章 基本测试技术 3.1 测试生命周期 3.2 测试计划 3.3 测试设计 3.4 测试开发 3.5 测试执行 3.6 测试评估 3.7 测试跟踪 3.1 测试生命周期 测试计划 测试设计 测试开发 测试执行 测试评估 3.2 测试计划概述 测试目的 完成的标准 时间安排 明确的责任 测试用例库 测试工具 3.2 测试计

34、划概述 所需机器时间 软 /硬件配置 系统组装方式 记录手段 回归测试 3.2 测试计划具体内容 目的 测试项（对象） 测试类型 测试范围 测试过程 资源需求（硬件、软件、人力） 3.2 测试计划具体内容 文档的检验 进度安排 测试开始、结束准则 测试记录 回归测试的方法 测试的评估 缺陷跟踪 应有规确保所有 的测试结果都得 到记录 3.2 测试计划测试需求 业务功能 业务流程 数据库事务 域值合法性 用户界面 对象状态 窗口模式 菜单 标准尺寸的控件 /文字 3.2 测试计划测试需求 性能 在少于 3秒的情况下增加一个新顾客帐户 强度 当内存很低的情况下运行应用程序 为设计规定是 1,000

35、,000 条记录的系统增加 1,000,001条记录 3.2 测试计划测试需求 配置 显示驱动的兼容性 网络连接 安装 新安装（典型安装、定制安装） 升级安装 网络下载 3.3 测试设计 测试过程 包括详细的步骤以确定测试需求是否 被满足。 组成： 测试的先决条件 输入条件 被执行的动作 期待的结果 证实期待结果的方法 3.3 测试设计单元测试用例 模块接口 局部数据结构 独立的路径 边界条件 出错处理 3.3 测试设计黑盒测试用例 功能不对或遗漏 界面错误 数据结构或外部数据库访问错误 性能错误 初始化和终止错误 3.3 测试设计白盒测试用例 保证一个模块中的所有独立路径至少 被使用一次 对

36、所有逻辑值均需测试真和假 在上下边界及可操作范围内运行所有 循环 检查内部数据结构以确保其有效性 3.3 测试设计循环测试用例 简单循环 嵌套循环 串接循环 非结构循环 3.3 测试设计 GUI测试用例 窗口 下拉菜单与鼠标 数据项 3.4 测试开发 功能的自动化测试工具 性能的自动化测试工具中的开发 3.5 测试执行 概述 目标 执行测试 查看测试结果 研究并组织对测试结果进行评估 记录缺陷 输入 测试过程和测试用例 输出 测试日志 缺陷报告 3.5 测试执行 记录结果 测试日志信息 执行测试过程 评估意外的结果 记录缺陷 3.5 测试执行 错误等级 5级：灾难性的 系统崩溃、数据被破坏 4

37、级：很严重的 数据被破坏 3级：严重的 特性不能运行，无法替代 2级：中等的 特性不能运行，可替代 1级：烦恼的 提示不正确，报警不确切 0级：轻微的 表面化的错误，拼写错等 3.5 测试执行 记录格式 3.5 测试执行 记录格式 3.5 测试执行 记录格式 3.6 测试评估 概述 目标 提交测试过程的衡量标准 产生缺陷报告和测试覆盖的总结报告 输入 测试日志 缺陷报告 输出 测试覆盖程度 缺陷分析报告 3.6 测试评估 测试覆盖率 基于覆盖策略的系统测试 验证所有需求的完成情况 验证每行代码的执行情况 基于测试需求的 测试过程 覆盖功能和设计的需求 验证一个测试需求对应的测试过程 3.6 测

38、试评估 缺陷分析 软件质量 缺陷分析是提供验证软件质量的手段之一 测试需求的覆盖程度决定了软件测试的质量 如何 实例报告 缺陷分配 缺陷趋向 缺陷状态 遗留缺陷对软件的影响 3.7 测试跟踪 记录测试事件或用户问题 分析原因，定位错误 进行软件修改 修改结果的跟踪 第四章 测试中的若干问题 4.1 对测试的误解 4.2 测试的改进方法 4.3 测试工程师的素质 4.4 测试格言 4.1 对测试的误解 如果发布出去的软件有质量问题 ， 那是软 件测试人员的错 。 软件测试技术要求不高 ， 至少比编程容易 多了 。 软件测试随便找一个能力差的人就能做 。 有时间就多测试一些 ， 来不及就少测试一

39、些 。 软件测试是测试人员的事 ， 与开发人员无 关 。 设计实现测试 ， 软件测试是开发后期 的一个阶段 。 4.2 测试的改进方法 外聘更多的测试人员 。 将原有的开发人员抽调做测试工作 。 加强对测试和开发人员在软件测试方面的 专业培训 。 购买或者自主开发一些测试工具 。 将测试工作外包 。 4.3 测试工程师应具备的素质 人是测试工作中最有价值也是最重要的 资源 让那些经验最少的新手、没有效率的开 发者或不适合干其他工作的人去做测试 工作，是一种目光短浅的行为 4.3 测试工程师应具备的素质 沟通能力 移情能力 技术能力 自信心 外交能力 幽默感 4.3 测试工程师应具备的素质 很强

40、的记忆力 耐心 怀疑精神 自我督促 洞察力 分析与表达力 4.4 测试格言 测试自己的程序是不可能的 。 派最好的人去做测试 。 保证在软件设计中可测性是一个重要的目 标 。 在一个系统的设计中 ， 每个模块应该只被 集成到系统中一次 。 不要改变程序 ， 使测试更容易 （ 除非这个 修改使永久的 ） 。 测试像大多数其他活动一样 ， 必须在开始 的时候有目标 。 4.4 测试格言 在测试中 ， 一个最难的问题就是知道什么 时候测试可以结束 。 每个测试用例的一个必需的部分使对预期 输出的描述 。 避免不可重复的或无用的测试 。 既要写有效输入条件的测试用例 ， 也要写 无效输入条件的测试用例 。 当软件的某个部分所发现的缺陷数目上升 时 ， 那么存在更多的未发现的缺陷数的可 能性也上升了 。 谢谢