测试计划与测试管理

《测试计划与测试管理》由会员分享，可在线阅读，更多相关《测试计划与测试管理（103页珍藏版）》请在金锄头文库上搜索。

1、第七章 测试计划与测试管理7.1 测试文档和测试计划 7.1.1 测试计划概述 7.1.2 测试计划的主要内容 7.1.3 编写合适有效的测试计划必须考虑 的问题7.1.1测试计划概述 什么是测试计划：测试计划包含项目范围 内的测试目的和测试目标的有关信息。此 外，测试计划还将确定实施和执行测试时 所使用的策略以及所需资源；以及对测试 风险等做出预先的计划和安排 测试计划包括测试主计划和阶段计划。 项目开始时制订测试主计划。根据开发的 迭代过程和测试主计划对测试计划进行细 化，制订各个阶段的测试计划。 测试计划概述（续）制定测试计划的目的 一个计划一定是为了某种目的而产生的 ，对于软件质量管理

2、而言，制定测试计划 的目的主要有3个。 1使软件测试工作进行更顺利 2促进项目参加人员彼此的沟通 3使软件测试工作更易于管理测试计划概述（续）制定测试计划的原则 制定测试计划是软件测试中最有挑战性 的一个工作。以下原则将有助于制定测试 计划工作。 1制定测试计划应尽早开始 2保持测试计划的灵活性 3保持测试计划简洁和易读 4尽量争取多渠道评审测试计划 5计算测试计划的投入7.1.2 测试计划的主要内容 1 范围 1.1 标识 1.2 系统概述 1.3 文档概述 1.4 与其它计划的关系 2 引用文档 3 软件测试环境 3.1 软件项 3.2 硬件和固件项 3.3 权限 3.4 安装、测试与控制

3、4 正式合格性测试 4.X （CSCI 名称和项目唯一标 识号） 4.X.1 总体测试要求 4.X.2 测试类 4.X.3 测试级 4.X.4 测试定义 4.X.4.Y （测试名称和项目唯一 标识号） 4.X.5 测试进度 5 数据记录、整理和分析测试计划主要内容(续) 1 范围 1.1 标识 列现本文档的： a 已批准的标识号； b 标题； c 缩略语； d 本文档适用的系统和计算机软件配置项（ CSCI）。如果本文档适用于系统中所有的CSCI ，则也要说明。并用标题、缩略语和标识号写 出适用的CSCI。 CSCI是计算机软件配置项(Computer Software Configurati

4、on Item), CSC是计算机软件部件(Computer Software Component), CSU是计算机软件单元(Computer Software Unit). HWCI (HardWare Configuration Item) 硬件配置项.项目测试过程中会产生许许多多的工作成果，例如 测试计划文档、测试用例以及自动化测试执行脚本 和测试缺陷数据等，他们都应当被保存起来，以便 查阅和修改。这些纳入配置管理范畴的工作成果统 称为配置项(Configuration Item，CI)，每个配置项 的主要属性有：名称、标识符、文件状态、版本、 作者、日期等。测试计划主要内容(续) 1

5、.2 系统概述 概述本文档所适用的系统和CSCI 的用途。 1.3 文档概述 概述本文档的用途和内容。 1.4 与其它计划的关系 概述本计划与其它项目测试计划的关系。测试计划主要内容(续) 2 引用文档 按文档号和标题列出本文档引用的所有文档。 3 软件测试环境 分节标识和描述为执行正式合格性测试所使用 资源（软件、固件和硬件）的实现和控制计划 。为减少重复，对在软件测试环境和软件工程 环境中均用到的资源，可以引用在“软件开计划” 文档中有关的软件工程环境的描述。测试计划主要内容(续) 3.1 软件项 标识用于执行正式合格性测试的软件项（如，操 作系统、编译器、编码审核器、动态路径分析器 、测

6、试驱动器、预处理器、测试数据产生器、后 处理器），描述并说明每个软件项的用途、保密 处理和安全性问题。 3.2 硬件和固件项 标识用于软件测试环境的计算机硬件、接口设备 和固件项。描述并说明每个项目的用途、保密处 理和安全性问题。测试计划主要内容(续) 3.3 权限 标明软件测试环境相关的每个项目的专利和权 限。 3.4 安装、测试与控制 本节应标识承制方为安装和测试每个项目所制 订的计划，还应要描述承制方为控制和维护软 件测试环境而制订的计划。 人员人数、经验和专长。他们是全职、兼职、业余 还是学生？ 设备计算机、测试硬件、打印机、测试工具等。 办公室和实验室空间在哪里？空间有多大？怎样排列

7、？ 软件字处理程序、数据库程序和自定义工具等。 其他资源软盘、电话、参考书、培训资料等。测试计划主要内容(续)测试计划主要内容(续) 4 正式合格性测试 分节对每个正式合格性测试进行说明，并描述软 件测试计划对每个CSCI 作正式合格性测试的要 求。 4.X （CSCI 名称和项目唯一标识号） 从4.1 节开始编号。用名称和项目的唯一标识号 标识CSCI。 4.X.1 总体测试要求 从4.1.1 开始编号。描述用于所有正式合格性测 试或用于一组正式合格性测试的要求。例如：每 个正式合格性测试都需要满足下列一般要求：测试计划主要内容(续) a 测量CSCI 的大小和执行时间； b 用假设值、最大

8、值和错误值作为输入对CSCI 进行测试。 c 对CSCI 进行错误判断和出错恢复的测试，包 括相关的错误信息。 对不同的实际问题应外加相应的专门测试。例如 ，验证雷达跟踪要求的正式合格性测试需满足下 列要求： （1）对特定环境条件的组合，用模拟数据对 CSCI 进行测试； （2）用从该环境中提取的“真实数据”作为输入， 对CSCI 进行测试。测试计划主要内容(续) 4.X.2 测试类 从4.1.2 节开始编号。描述要进行的正式合格性测试 的种类或类型（如：强度测试、时间性测试、错误输 入测试、最大能力测试等）。 4.X.3 测试级 从4.1.3 节开始编号。描述要进行的正式合格性测试 的级别，

9、例如： aCSCI 级（如果需要，也可划分为CSC 或CSU 级 ）：评测与CSCI 要求的符合程度； bCSCI 到CSCI 集成级：评测与CSCI 外部接口要 求的符合程度；测试计划主要内容(续) cCSCI 到HWCI 集成级：评测与CSC 外部接口要 求的符合程度； d系统级：评测与整个系统CSCI 要求的符合程度。 4.X.4 测试定义从4.1.4 节开始编号。分节标识和描述 用于CSCI 的各项正式合格性测试。 4.X.4.Y （测试名称和项目唯一标识号） 从4.1.4.1 节开始编号。用测试名和项目唯一标识号标 识正式合格性测试。 本切要给出下列用于测试的信息，这些信息的一部分

10、或全部可以用图表给出，如： a 测试对象； b 特殊要求（如：48 小时设备连续运行）； c 测试级；测试计划主要内容(续) d 测试种类或类型； e 在软件需求规格说明中规定的合格性方法； f 该测试所涉及的软件需求规格说明对CSCI 工程需求的 交叉引用； g 该测试所涉及的接口需求规格说明对CSCI 接口需求的 交叉引用； h 记录的数据类型； i 假定和约束条件。 4.X.5 测试进度 说明或引用本文档4.X.4 的测试进度。 5 数据记录、整理和分析 分节描述按本测试计划所作测试的数据整理和分析过程。 并说明根据数据整理和分析得到的信息和结果。数据记录 、整理和分析的结果应清楚地显示

11、出是否达到测试目标。7.1.3 编制合适有效的测试计划考虑 的问题 1 了解手头的任务和相关的测试目标 2 考虑风险 3 根据功能优先级安排测试工作 4 规划测试环境1了解手头的任务和相关的测试目标 Step1:了解手头的任务、它的范围和与之关联 的测试目标,必须对实现测试目标过程中起作用的 每个细节都清楚。 How to understand? 理解系统：功能需求+非功能需求 涉及整个系统的讨论会和文档（对系统要 解决的问题的有关讨论、高层次的商业需求陈 述、产品管理的案例研究和商业案例） 及早介入（测试经理等）：增加对客户需求、客 户问题、潜在的风险和功能的理解 理解企业文化和过程 测试组

12、和开发组独立还是一体化？ 测试方法是否适应“极限编程”的方法？了解手头的任务和相关的测试目标（续）实现的范围（测试范围） 测试的期望 管理层对测试的期望？ 客户期望的测试类型？（验收测试？遵从的方法 ？预定的里程碑？可交付使用的含义？） 吸取教训：以前的测试工作中学到了什么？（确 定测试策略、设定实际的测试预期） 工作量大小：初步估计项目的复杂度的工作量 解决方案的类型：最终是实现了最复杂的解决方 案？较短时间开发、更划算的解决方案？（决定 采用的测试类型）了解手头的任务和相关的测试目标（续） 技术选择： 实现技术？引起的问题？架构？系统类型？（确定测 试策略、选择测试工具） 预算（确定测试类

13、型、测试工作量） 时间表：系统测试的时间？截止日期？调整测 试时间表 获得测试环境所需的硬件和软件？ 评估、购买和实现测试工具 分阶段的解决方案（迭代开发？发行许多版本 ？）2考虑风险 软件测试人员要明确地指出计划过程中的风险 ，并与测试管理员和项目管理员交换意见。这 些风险应该在测试计划中明确指出，在进度中 予以考虑。有些风险是真正存在的，而有些最 终证实是无所谓的，重要的是尽早明确指出， 以免在项目晚期发现时感到惊慌。 风险分析是一项十分艰巨的工作，尤其是第一 次尝试进行时更是如此，但是以后会好起来， 而且也值得这样做。考虑风险(续) 一般而言，大多数测试小组都会发现自己的资源 有限，不可

14、能穷尽测试软件所有方面。如果能勾 画出风险的轮廓，将有助于测试人员排定待测试 项的优先顺序，并且有助于集中精力去关注那些 极有可能发生失效的领域。下面是一些潜在的问 题和风险的例子： 不现实的交付日期 与其他系统的接口 处理巨额现金的特征 极其复杂的软件 有过缺陷历史的模块 发生过许多或者复杂变更的模块 安全性、性能和可靠性问题 难于变更或测试的特征考虑风险(续) 确定测试策略时了解项目风险，每个项目 都有一系列的风险，其中某些风险的级别 可能比另一些风险高。（风险级别的排列 考虑了损失发生的可能性和损失带来的影 响的严重程度） 风险分类和来源 风险评估 降低风险的测试策略考虑风险(续) 风险

15、分析（续） 风险分析所提供的信息，有助于测试经理 作出决定： 根据技能的高低、需要的工作量、风险和质量 目标分配测试人员降低风险的测试策略 把测试工作的重点放在系统中可能会引起 绝大多数问题的那些部分。 测试经理必须确定风险最大的部分、最可能出 现问题的部分、最易失灵的功能 对风险低和影响小的功能，只执行必须的 测试工作，并可为新手提供积累经验的机 会。 产生可预测的、更高质量的测试结果3 制定测试策略(续) 根据功能优先级安排测试工作 最需要的功能的最先开发和测试 根据不同的标准划分优先级 风险最高到最低 复杂度最高到最低 客户的需要（市场和销售） 预算的限制 时间的限制 人员限制（特殊需求？谁来做？） 综合使用以上方法，得到一个功能的总体价值 ，并进行排序，得到功能优先级表。4 规划测试环境 测试环境：支持测试工作的所有物质元素 测试数据、硬件、软件、网络和设备 测试环境必须反映软件最终运行环境的基线配置 设计测试环境 获得客户环境的样本（os,支撑软件，硬件） 确定是否需要一个归档机制来存储测试后生成的大文件（日志） 确定网络特性（带宽、网络协议等） 确定服务