文档介绍：系统集成项目管理控制规范

XXXXXXXXXXX科技有限公司
编写测试计划目的
预算、资源限制和时间进度确定后,你就能声称自己拥有测试计划了吗?---------实际上还需要做更为细致的工作才能成功地管理测试项目。
编写测试计划能让我们有机会收集想法、观点和记忆。编写详细的测试计划能够使我们把知识转化为执行任务的具体方法。
编写计划也能增强我们与测试团队、开发团队及经理们进行交流。
测试计划的数量
假设你是测试负责人,负责单元测试、集成测试及系统测试阶段,因此你有三个不同的测试子项目需要计划和管理,这时你是编写一个测试计划,还是三个测试计划呢?这些子项目可能在以下这些方面有所区别。
不同的时间阶段
不同的方法学
不同的目标
不同的听众
测试计划模板
我们常常要使用制定的测试模版,它不仅是可以让我们在很少的时间内可以制定测试计划的工具,更重要的是它是一个主题的逻辑集合,这些集合正是我们测试工作所需要的。
根据项目的实际需要,我们可以自由地增加或删除主题
测试计划模板
1 概述
测试计划的概述部分要介绍测试项目,在概述中,要扼要地叙述目标、方法和目的。
也可以阐述被测系统的体系结构,或者说明这个测试工作怎样适应于其他可能已经执行、并发执行或将要执行的测试工作。
2 边界
测试计划的边界就是通过讨论要测试的或者不测试的内容、定义重要术语和与计划只想测试相关的简称,以及决定在什么地方和什么背景下进行相关的测试工作。
在测试计划边界中一般包括以下几个方面:
范围---在描述项目测试范围时,要很注意区分在项目过程中要处理的和不需要处理的事情。
定义---测试术语及短语的定义,在测试计划定义表中可以帮助队测试领域不熟悉的人弄清术语,并且有助于测试组每个人都以同样的定义集合来操作。
部署---描述打算执行测试的地点以及与其它部门之间的协调办法。
3 质量风险
如果项目计划中已经定义了质量风险,那么我们可以在测试计划中归纳或引用这些风险。
4 里程碑的推荐进度
大多数测试计划中都包含了测试项目中主要里程碑的进度安排,我们可以在项目工作分解结构中提取得到。
里程碑重点放在管理层可以看到的高级里程碑和交付产品上。
5 过渡
测试计划的这一部分指名了各个阶段开始和结束的必要标准,通常包括以下几个标准:
进入标准---指允许系统进入到具体测试阶段需要满足的条件。
继续标准---定义了那些在测试过程中高效地继续测试,而必须满足的条件和情况。
退出标准---退出标准解决如何决定什么时候完成测试的问题。
我们可以将每个标准按照典型的“绿”(完全满意)、“黄”(不完全满意,但可能不是问题)、“红”(不满意且造成主要问题)来划分等级,用数据来支持标记为“黄”、“红”的标准。
6 测试配置和环境
在测试计划的这个部分中记录用来执行测试的硬件、软件、网络等环境。
测试硬件分配计划通常包括测试目的或方法、需要的系统(包括数量及版本)、基础设施、时间范围、地点,以及特殊测试需要的其他硬件。
7 测试开发
测试计划的这部分将确定测试项目中的开发工作,如编写测试用例、开发测试工具、编写自动化测试脚本等。
在这里要描述测试组将如何创建这些对象,如果我们打算手工测试,那怎样编写测试用例;如果使用现有的测试工具,那要描述为什么选择该工具以及打算如何开发测试脚本;如果我们开发定制测试工具,那要描述功能是什么,打算怎样使用它们。
在测试计划中要确定自动化测试及手工测试在各测试阶段所占的比例。
8 测试执行
测试计划指出了影响测试执行的重要因素。
如果是资深测试小组测试一个运行良好的项目,那么在计划中一般会把这一块的大部分内容留给测试人员自由决定;如果是初级测试人员,特别是管理混乱的项目,在计划阶段了解得越深入,越能提前预料和解决可能出现的问题。
测试计划中的执行包括以下方面:
关键参与者
测试用例和缺陷跟踪
错误隔离和分类
发布管理
测试循环
测试时间
9 风险参数和不测事件
在这部分,说明在测试计划中可能存在使测试计划很难或者不可能执行的潜在的事件。例如,如果发现的BUG数量超常就需要开发人员的支持。
严格地说,好的开发过程大多数主张对风险管理实行全局管理方法,如果我们当前的项目拥有一个风险管理计划,那么可以在风险管理计划中提供,此处可省略。
10 变更历史
这部分记录到此为止测试计划的变更和修订。
11 参考文档
一般来说,测试计划会参考其它文档,比如设计规格说明、需求、测试包、任何质量风险分析文档,以及其他相关信息。
12 常见问题
在新手作为测试工程师和测试技术员