ISO软件开发文档模板_测试计划编写指南.docVIP

Software Project Plan 测试计划编写指南 版本 1.0 修订历史记录 日期 版本 说明 作者 2002/9/04 1.0 创建 Century 目录 1. 介绍 5 1.1 文档目的 5 1.2 文档摘要 5 1.3 文档历史和变更 5 2. 背景 5 2.1 系统视图和目标 5 2.2 联系方式 6 2.3 相关信息保存的位置 6 3. 质量目标 6 4. 测试策略 6 4.1 整体策略 6 4.2 测试范围 6 5. 测试方法 6 5.1 里程碑技术 7 5.2 测试文档（测试用例） 7 5.3 测试实施过程 7 5.3.1 测试系统接受条件 7 5.3.2 测试时间表 7 5.4 稳定阶段测试 8 5.4.1 稳定阶段摘要 8 5.4.2 测试遍数 8 5.4.3 项目结束 8 5.5 自动测试策略 8 5.6 集成测试策略 8 5.7 内容测试 8 5.8 性能测试和压力测试 9 5.9 兼容性测试 9 6. 测试组织 9 6.1 测试团队结构 9 6.2 功能划分 10 7. 资源需求 10 7.1 培训需求 10 7.2 硬件需求 10 7.3 软件需求 10 7.4 办公空间需求 10 8. 时间进度安排 10 9. 缺陷处理 10 9.1 数据库管理 10 9.2 缺陷处理过程 11 10. 测试过程控制 11 10.1 缺陷数据分析 11 10.2 测试工作周报 11 11. 风险分析 11 12. 系统发布 11 测试计划编写指南 介绍 测试计划编写指南有两类潜在的受众。首先，测试负责人使用它作为指导方针编写测试计划。测试计划编写完成后，将作为整个团队（包括开发人员和测试人员）沟通的基础。 测试项目开始时，应该完成测试计划的大部分内容。项目开始后，由于测试情况有变化，可能导致测试计划文档变化。如果文档有明显的变化，必须在文档中添加变更历史来记载这些变化。 文档目的 测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。 文档摘要 这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员（比如经理或开发项目的负责人）。 提示和技巧： 在写这一节时，考虑一下你的计划在那些地方可能会引起反对。这个计划跟以前的计划相比，有什么不同的地方。测试项目与系统开发计划的关系等。 使用列表的格式，可以将问题按重要程度罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在。 文档历史和变更 [作者] – [日期] – [文档的当前状态，上版本以来所作的主要变化] 背景 系统视图和目标 系统视图对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。系统目标是帮助实现系统视图的重要指标。系统视图和目标对实现整个项目计划来说是至关重要的。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。 通常情况下视图和项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。 提示和技巧： 为什么视图对客户是重要的？ 你如何向客户表达这种视图？ 你将做什么来保证你是在向实现视图的方向前进? 在你回答这些问题之后，你就可以将视图转换成测试导向的目标？ 联系方式 列出项目参与人员的联系方式包括 E-mail 和电话。 相关信息保存的位置 测试服务器的相关信息 测试文档保存的位置 测试工具保存的位置 质量目标 围绕软件质量，有几种不同的说法。第一个是质量是一种绝对的标准，对所有的系统必须等同处理。事实上，质量是相对的而且是和产品相关的概念。例如，多媒体产品的质量目标倾向于精美的表示和适当的内容，而应用系统可能倾向于易用性、健壮性和适用于不同的任务。质量目标可能是动态的。在项目进行过程中，会由于市场压力、新的机会和功能改变而重新设定质量目标。 另一种有关软件质量的说法是，定义和衡量系统质量是测试部门一个部门的事。实际上，建立质量标准是所有职能部门共同努力的结果。测试、开发、系统使用部门、用户教育、系统支撑必须为建立和维护系统的质量标准做出自己的贡献。每个部门必须对自己最了解的部