《软件测试计划模板》.docVIP

软件测试计划模板 第1章 引言 1.1目的 测试阶段任务、人员分配和时间安排、工作规范等。 测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。在计划目的中需要指明读者对象。 1.2名词解释 列出本计划中使用的专用术语及其定义 列出本计划中使用的全部缩略语全称及其定义 缩写词或术语 英文解释 中文解释 ? ? ? ? ? ? 1.3参考资料 1.4测试摘要 1.4.1 重点事项 1.4.2 争议事项 1.4.3 风险评估 技术文档的阅读，对被测系统可能存在的问题：系统设计，数据库设计，响应时间，计费策略，因测试环境不足可能存在的测试缺陷事先评估出来，以指导测试方案，进行有重点的测试． 1.4.4 时间进度 1.4.5 测试目标 测试计划中所有测试方法和模块已经执行通过 所有的测试案例已经执行过 所有的重要等级为1/2的Bug已经解决并由测试验证 ? 第2章 项目背景 2.1测试范围 功能测试、集成测试、系统测试、验收测试等。通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。 （1）简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。 （2）如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。 （3）列出可能会影响测试设计、开发或实施的所有风险或意外事件。 （4）列出可能会影响测试设计、开发或实施的所有约束。 ? 提示和技巧： 需要测试和特别注意测试那些部分？ 测试是否专么针对与某些问题的解决? 哪些部分不需要测试，为什么？ 哪些部分需要推迟测试,为什么? 是否要验证每个模块的稳定性？ 测试的优先级和先后顺序 ? 2.2测试目标 通常情况下项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。 2.3联系方式 E-mail和电话。 职务 姓名 E-Mail 电话 开发工程师 ? ? ? CVS Builder ? ? ? 开发经理 ? ? ? 测试负责人 ? ? ? 测试人员 ? ? ? 2.4风险及约束 ?由于客观存在的设备、网络等资源原因，使得测试不全面。明确说明哪些资源欠缺，产生什么约束 ?由于研发模式为现场定制，且上线时间压力大，使得测试不充分。明确说明在此中约束下，测试如何应对 ?只针对专门的客户群需求的测试。明确说明此约束下的客户群和业务范围。 2.5测试文档 2.5.1测试参考文档 作者 文档位置（CVS） 需求文档 ? ? 总体设计 ? ? 白皮书 ? ? 使用手册 ? ? 管理手册 ? ? 测试文档 ? ? API文档 ? ? ? ? ? 2.5.2测试提交文档 作者 文档位置（CVS） 《总体测试计划》 ? ? 《总体测试方案》（可根据项目情况进行裁剪） ? ? 测试用例 ? ? 《性能测试方案（报告）》 ? ? 《测试报告》 ? ? 《Readme》 ? ? 《产品操作手册(后台)》 ? ? 《产品操作手册(前台)》 ? ? 《产品安装维护手册》 ? ? 《产品错误代码说明文档》 ? ? ? 第3章质量目标 质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具，应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如，系统是否能够正式发行？在代码完成后，应该修复那些缺陷？在系统完成后那种类型的测试是最合适的？ 3.1产品质量目标 测试质量目标 确认者（如需说明） 测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确 ? 产品规定的操作和运行稳定 ? 3.2测试质量目标 测试质量目标 确认者（如需说明） 所有的测试案例已经执行过 ? 所有的自动测试脚本已经执行通过 ? 所有的重要等级为1/2的Bug已经解决并由测试验证 ? 每一部分的测试已经被Test Lead确认完成 ? 重要的功能不允许有等级为1/2/3的Bug ? 一般的功能或与最终使用者不直接联系的功能不允许有等级为1/2的bug,且bug等级为3的问题不得超过1/功能 ? 轻量的功能允许有少量2/3等级的错误 ? 发现错误等级为1/2/