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