软件測试计划模板
第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
|
电话
|
|
开发project师
|
|
|
|
|
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/3的Bug的速率正在下降并接近0
|
|
|
在最后的三天内没有发现错误等级为1/2/3类的Bug
|
|
第4章 资源需求
4.1培训资料
|
培训需求
|
培训内容
|
培训人员
|
開始时间
|
完毕时间
|
|
业务流程
|
|
|
|
|
|
安装配置
|
|
|
|
|
|
工具使用
|
|
|
|
|
4.2測试环境
4.2.1硬件測试环境
描写叙述建立測试环境所须要的设备、用途及软件部署计划。
“机型（配置）”：此处说明所需设备的机型要求以及内存、CPU、硬盘大小的最低要求。
“用途及特殊说明”：此设备的用途，如数据库server，webserver，后台开发等；如有特殊约束，如开放外部port，封闭某port，进行性能測试等，也写在此列；
“软件及版本号”：具体说明每台设备上部署的自开发和第三方软件的名称和版本号号，以便系统管理员依照此计划分配測试资源；
“估计空间”：说明第三方软件和应用程序的估计空间；
“环境约束说明”：建立此环境时的特殊约束。如须要开发外部訪问port，须要进行性能測试等。
|
平台1：SUN
|
|||||
|
机型（配置）
|
IP地址
|
操作系统
|
用途及特殊说明
|
软件及版本号
|
估计空间
|
|
SUN450
|
10.1.1.1
|
|
|
oracle8.1.2
|
2G
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
平台2：IBM
|
|||||
|
机型
|
IP地址
|
操作系统
|
用途
|
第三方软件及版本号
|
估计空间
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4.2.2软件測试环境
|
软件需求
|
用途
|
|
|
|
4.3測试工具
此项目将列出測试使用的工具以及用途：
|
測试工具
|
用途
|
|
自己主动測试工具
|
|
第5章 測试策略
5.1 总体測试策略
本节的目的是说明计划中使用的主要的測试过程。
使用里程碑技术在測试过程中验证每一个模块，測试人员在需求阶段參与測试工作，进行需求review、设计review、測试案例设计和測试开发，在系统开发完毕之后，正式运行測试。产品达到软件产品质量要求和測试要求后公布，并提交相关的測试文档。
5.2開始/中断/完毕标准
说明中断/開始/完毕測试的标准。
|
開始/中断/完毕測试
|
标准说明
|
|
開始測试标准
|
硬件环境可用且软件正确安装完毕
|
|
中断測试标准
|
安装无法正确完毕或程序的文档有相当多的失误或系统服务异常或发现Block Bug
|
|
完毕測试标准
|
完毕測试计划中的測试规划并达到程序和測试质量目标,并由Test Lead/R&D Manager确认
|
5.3測试类型
|
測试类型
|
是否採用
|
说明
|
|
功能測试
|
採用
|
依据系统需求文档和设计文档，检查产品是否正确实现了功能。
|
|
流程測试
|
採用
|
按操作流程进行的測试，主要有业务流程、数据流程、逻辑流程、正反流程，检查软件在按流程操作时是否可以正确处理
|
|
边界值測试
|
採用
|
选择边界数据进行測试，确保系统功能正常，程序无异常。
|
|
容错性測试
|
採用
|
检查系统的容错能力，错误的数据输入不会对功能和系统产生非正常的影响，且程序对错误的输入有正确的提示信息
|
|
异常測试
|
採用
|
检查系统是否能处理异常
|
|
启动停止測试
|
採用
|
检查每一个模块是否能正常启动停止、异常停止后是否能正常启动
|
|
安装測试
|
採用
|
检查系统是否能正确安装、配置
|
|
易用性測试
|
採用
|
检查系统是否易用友好
|
|
界面測试
|
採用
|
检查界面是否美观合理
|
|
接口測试
|
採用
|
检查系统是否能与外部接口正常工作
|
|
配置測试
|
採用
|
检查配置是否合理、配置是否正常
|
|
安全性和訪问控制測试
|
採用
|
应用程序级别的安全性：检查Actor仅仅能訪问其所属用户类型已被授权訪问的那些功能或数据。
系统级别的安全性：检查仅仅有具备系统和应用程序訪问权限的Actor才干訪问系统和应用程序。
|
|
性能測试
|
採用
|
提取系统性能数据，检查系统是否满足在需求中所规定达到的性能。
|
|
压力測试
|
採用
|
检查系统是否能承受大压力，測试产品应该可以在高强度条件下正常执行，不会出现不论什么错误。
|
|
兼容性測试
|
採用
|
对于 C/S 架构的系统来说，须要考虑client支持的系统平台。
对于 B/S 架构的系统来说须要考虑用户端浏览器的版本号。
|
|
割接/升级測试
|
採用
|
进行专门的割接測试或升级測试，提供project升级割接方案
|
|
文挡測试
|
採用
|
检查文档是否足够、描写叙述是否合理
|
|
回归測试
|
採用
|
检查程序改动后有没有引起新的错误、是否可以正常工作以及是否能满足系统的需求
|
5.4 測试技术
|
測试技术
|
是否採用
|
说明
|
|
里程碑技术
|
採用
|
里程碑的达成标准及验收方法在測试完后制订
|
|
自己主动測试技术
|
採用
|
核心业务流程採用自己主动測试技术
|
|
审评測试
|
採用
|
对软件产品功能说明文档和设计说明文档进行检查，在需求与设计阶段进行
|
|
编写測试用例
|
採用
|
在产品编码阶段编写測试用例
|
|
单元測试
|
不採用
|
由开发者进行
|
|
集成測试
|
採用
|
检測模块集成后的系统是否达到需求对业务流程及数据流的处理是否符合标准、系统对业务流处理是否存在逻辑不严谨及错误以及是否存在不合理的标准及要求。
|
|
确认測试
|
採用
|
在产品公布前，对比feature list 进行基本需求的确认，确认产品是否正确实现了功能。
|
|
系统測试
|
採用
|
包含性能測试、压力測试和回归測试
|
|
验收測试
|
不採用
|
由project实施人员进行
|
第6章 測试计划
6.1进度计划
在此章节，对各阶段的測试给出里程碑计划，包含阶段、里程碑、资源等。
6.1.1測试时间进度
|
測试阶段
|
開始时间
|
完毕时间
|
測试人员
|
阶段完毕标志
|
|
制定測试计划
|
|
|
|
|
|
需求Review
|
|
|
|
|
|
设计Review
|
|
|
|
|
|
设计測试用例
|
|
|
|
|
|
測试开发
|
|
|
|
|
|
測试环境准备
|
|
|
|
|
|
測试实施
|
|
|
|
|
|
功能測试
|
|
|
|
|
|
集成測试
|
|
|
|
|
|
性能測试
|
|
|
|
|
|
系统測试
|
|
|
|
|
|
验收測试
|
|
|
|
|
|
文档编写
|
|
|
|
|
6.1.2測试里程碑
|
里程碑
|
完毕时间
|
完毕标准
|
|
測试正式開始
|
|
完毕可接受性測试和烟雾測试
|
|
进行CVS LOCK
|
进行cvs lock
|
完毕全部里程碑測试和标准測试,測试种类包含确认測试和系统測试,且全部以发现的Bug等级为1/2/3的Bug已修复,最近内无发现新的Bug等级为1/2/3的Bug
|
|
产品Release
|
|
反复进行主路径測试和进行Bug检查測试,产品处于可交付状态并由測试经理和高级经理确认
|
6.2測试准备
6.2.1 測试环境准备
|
准备事项
|
開始时间
|
完毕时间
|
測试人员
|
阶段完毕标志
|
|
測试环境准备
|
|
|
|
|
6.2.2 安装測试
|
准备事项
|
開始时间
|
完毕时间
|
測试人员
|
阶段完毕标志
|
|
安装測试
|
|
|
|
|
6.2.3 烟雾測试
|
准备事项
|
開始时间
|
完毕时间
|
測试人员
|
阶段完毕标志
|
|
烟雾測试
|
|
|
|
|
6.3 详细測试实施任务和时间人员安排
|
測试功能点
|
開始时间
|
完毕时间
|
測试人员
|
说明
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
