测试计划书模板

密级：      

****项目

测试计划书

中创软件工程股份有限公司

二ОО*年**月**日

文件修订记录

变更版本	修订日期	原因与修改情况描述	位置（页/段落/章节号	修订人	审核人

目  录

1.    概述    2

1.1.    编写目的    2

1.2.    项目背景    2

1.3.    定义    2

1.4.    参考资料    2

2.    测试规划    2

2.1.    主要测试内容及预期提交测试时间    2

2.2.    可复用的测试用例    3

2.3.    测试估算（方法一）    3

2.4.    测试估算（方法二）    4

2.5.    测试进度安排及人力资源要求    5

2.6.    昆山分包    6

2.7.    测试工具应用计划    6

2.8.    本次测试不涉及内容    7

3.    测试策略及方案    7

3.1.    架构测试    7

3.2.    业务功能测试    8

3.3.    系统性能测试    8

3.4.    安全性和访问控制测试    9

3.5.    安装测试    10

4.    测试规范    11

4.1.    测试管理规范    11

4.2.    测试规范    12

5.    测试环境    12

5.1.    系统架构    12

5.2.    测试环境要求    12

5.3.    测试选用环境：    12

5.4.    测试环境补充说明：    13

1.概述

1.1.编写目的

    说明编写测试计划的目的，并指出预期的读者。

1.2.项目背景

a.软件名称：待测试的软件系统的名称（版本号）；

b.测试类别：□集成测试     □系统测试     □集成测试+系统测试

             □其他                      

c.承担测试任务的单位或部门：

d.人员

●项目经理：

●测试负责人：

e.办公地点是否与开发异地：□是     □否

f.测试项目类型：□产品    □项目

1.3.定义

    列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.4.参考资料

    此小节应完整地列出测试计划中其他部分所引用的所有文档。如：

a.与本测试相关的该项目的项目资料，如需求说明书、设计说明书等；

b.与本测试有关的其他版本的有关资料；

c.测试使用的国家标准、行业指标、公司规范和质量手册等等；

d.其他资料。

2.测试规划

2.1.主要测试内容及预期提交测试时间

（如制定测试计划时无法从项目组获得相关信息，本章节可裁剪）

序号	主要测试内容	预期提交 测试时间	特殊说明
1.	系统主要技术框架
2.

2.2.可复用的测试用例

（如制定测试计划时无法确定，本章节可裁剪）

序号	可复用的测试用例	需要修改调整的内容	节约的测试工作量（人月）	特殊说明
1.
2.
3.

2.3.测试估算（方法一）

测试工作量及测试人力投入估算提供二种方法，可任选。

2.3.1.估算假设

项目	估算值	备注
集成测试用例完成标准	测试用例的密度应不少于12个/KLOC	QMS质量体系要求
系统测试用例完成标准	测试用例的密度应不少于10个/KLOC	QMS质量体系要求
本测试遵循的测试用例完成标准	测试用例的密度应不少于（？）个/KLOC	项目负责人、测试负责人确定
测试用例设计生产率	（？）个/人天	测试负责人确定
测试用例执行生产率	（？）个/人天	测试负责人确定
测试周期（天）	（？）天	根据项目计划估算测试时间段

2.3.2.功能测试工作量估算

本章节可以用Excel文件作为附件。按项目估算的代码行进行测试工作量估算，如果代码行估算发生重大调整，测试需要重新估算）

序号	主要测试内容	规模 (KLOC)	测试用例数(个)	测试用例设计工作量 (人天)	测试执行工作量(人天)	测试工作量小计 （人天）
1.
2.
3.
4.
合计

2.3.3.性能测试工作量估算

本章节可以用Excel文件作为附件。

序号	主要测试内容	测试方案及用例设计、结果分析工作量(人天)	脚本调试及测试执行工作量(人天)	性能测试工作量小计（人天）
1.
2.
3.
4.
合计

2.3.4.估算结果

估算项目	估算值	说明
功能测试工作量合计（人天）	测试用例设计工作量+测试执行工作量	与项目组统一估算的测试工作量对比，使估算趋于合理
性能测试工作量合计（人天）	测试方案及用例设计、结果分析工作量+脚本调试及测试执行工作量	与采用Delphi法，由专家按项目性能测试要求估算的结果进行对比，使估算趋于合理
测试设计人员需求量（人）	测试设计工作量/测试周期	估算需要投入的中高级测试设计人员
测试执行人员需求量（人）	测试执行工作量/测试周期	估算需要投入的初级测试执行人员

2.4.测试估算（方法二）

测试工作量及测试人力投入估算提供二种方法，可任选。

2.4.1.估算假设

根据项目的特征，选择一种划分方式，从而确定测试所占工作量比例。

1.按生命周期模型划分

项目分类	需求	设计	开发	测试	交付	维护	管理
瀑布模型	10.08%	11.75%	54.36%	17.49%	4.46%	1.86%	12.10%
增量模型	10.90%	14.41%	44.93%	23.16%	4.71%	1.88%	7.21%

2.按项目规模划分

项目分类	需求	设计	开发	测试	交付	维护	管理
大型	10.68%	16.82%	41.72%	24.79%	3.19%	2.80%	9.80%
中型	13.74%	16.47%	38.14%	21.09%	7.46%	3.10%	13.01%
小型	13.%	17.57%	28.25%	13.13%	18.82%	8.34%	12.59%

2.4.2.估算结果

估算项目	估算值	说明
功能测试工作量合计（人天）	总工作量*测试所占工作量比例	比例需按项目实际情况分析情况，考虑因素包括：测试难度，测试人员水平，开发质量
性能测试工作量合计（人天）		采用Delphi法，由专家按项目性能测试要求估算
测试设计人员需求量（人）		测试设计与测试执行按1:2或1:3比例计算，需考虑因素：测试难度，测试进度要求
测试执行人员需求量（人）

2.5.测试进度安排及人力资源要求

此处与项目重大里程碑严格对应，对应每个项目子里程碑，测试需要做哪些工作，如无对应工作安排，可填写“无”，类似于评审、做测试方案等工作也最好规划好。

项目重大里程碑	项目子里程碑		测试需完成工作及提交物	测试负责人员	已到位测试人员	需补充测试人员
	名称	起止时间

2.6.昆山分包

（本章节可裁剪，无昆山分包或昆山项目不适用）

2.6.1.分包模式：

□借调昆山测试人员

□部分功能模块测试分包

□系统整体测试分包

□测试执行分包

2.6.2.分包计划

序号	起止时间	分包内容	特殊说明
1.
2.

2.7.测试工具应用计划

分类	项目	具体工具	应用范围说明	需要支持
公司引进工具	自动化功能测试	Rational Robot
		Rational functional Tester
	性能测试	Rational Robot
		Rational Performance Tester
	单元测试	Rational PurifyPlus
	测试管理工具	Rational TestManager
	测试缺陷管理	Rational ClearQuest
开源工具	单元测试	Junit
自行开发工具
其他	性能测试	Loadrunner

2.8.本次测试不涉及内容

序号	测试不涉及内容	不涉及原因	特殊说明
1.
2.

3.测试策略及方案

根据本次测试的内容和目的，论述测试策略及方案，对不涉及的测试内容可裁剪。

本节可以文档附件的形式描述，不限格式。

3.1.架构测试

（如不进行架构测试，本章节可裁剪）

架构测试，主要是为了降低系统在可用性、易管理性、性能、可靠性、可伸缩性和安全性等方面的风险，利用系统原型，对系统主要架构、关键技术、核心数据设计、统一规范等进行的测试，在项目早期阶段确认系统能否满足用户需求及对产品的定位。架构测试由产品研发团队组织，相关人员参与，特别是需要尽早获得客户的反馈和认可。

目前公司在架构测试方面需要进行的工作主要有：

1.验证系统整体架构是否满足需求：

2.验证应用主要技术实现的可行性

3.验证系统核心数据设计的合理性：

4.应用架构易维护性、易扩展性的测试和验证：

5.项目组统一规范的测试和验证：

3.1.1.测试目标及通过准则

3.1.2.测试技术及方法

3.1.3.测试需求及用例

3.1.3.1.需求1

3.1.3.2.需求N

3.1.4.特殊说明

3.2.业务功能测试

3.2.1.测试目标及通过准则

3.2.2.测试技术及方法

3.2.3.测试需求及用例

3.2.3.1.需求1

3.2.3.2.需求N

3.2.4.特殊说明

3.3.系统性能测试

性能测试原则上不可裁剪，如确实无对应工具支撑，可暂不进行。

3.3.1.测试目标及通过准则

3.3.2.测试技术及方法

3.3.3.测试需求及用例

3.3.3.1.负载测试

3.3.3.2.压力测试

3.3.3.3.稳定性测试

3.3.3.4.容量测试

3.3.4.特殊说明

3.4.安全性和访问控制测试

安全性和访问控制测试侧重于安全性的两个关键方面：

应用程序级别的安全性，包括对数据或业务功能的访问

系统级别的安全性，包括对系统的登录或远程访问。

应用程序级别的安全性可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。

3.4.1.测试目标及通过准则

3.4.2.测试技术及方法

3.4.3.测试需求及用例

3.4.3.1.需求1

3.4.3.2.需求N

3.4.4.特殊说明

3.5.安装测试

安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下。例如，进行首次安装、升级、完整的或自定义的安装 都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。

如不需要制作安装包，本章节可裁剪。

3.5.1.测试目标及通过准则

3.5.2.测试技术及方法

3.5.3.测试需求及用例

3.5.3.1.需求1

3.5.3.2.需求N

3.5.4.特殊说明

4.测试规范

（本章节可裁剪或增加新的章节，建议按事业部、或者领域、行业确定测试测试标准与规范。如果与事业部统一标准规范一致，可注明参见《****事业部测试标准及管理规范》。如有不同，可补充。）

4.1.测试管理规范

4.1.1.测试用例组织及管理

4.1.2.提交内部测试流程

4.1.3.提交用户测试流程

如不涉及用户测试，本章节可裁剪。

4.2.测试规范

4.2.1.界面测试规范

4.2.2.流程测试规范

4.2.3.报表测试规范

5.测试环境

5.1.系统架构

项目	描述说明
系统架构
开发语言
其他

5.2.测试环境要求

硬件		软件
硬件平台		操作系统
CPU		数据库系统
内存		应用服务器
硬盘		中间件
其他		浏览器
		其他

（填表说明: 如果涉及到多个环境，则将所有的环境都列在表中）

5.3.测试选用环境：

组成部分	依赖的环境分类	功能测试主要环境	功能测试其他环境1	……	性能测试环境
产品组成部分1	操作系统
	数据库系统
	应用服务器
	中间件
	浏览器
	其他
产品组成部分2	操作系统
	数据库系统
	应用服务器
	中间件
	浏览器
	其他
……	……
备注	-	重点测试、执行所有用例			与生产环境差异对比

 (填表说明：如果被测产品由多个部分组成，而这些部分需要依赖于不同的环境,则分别列在第一列中，如InforGuard的MA\\MC\\MT。依赖的环境分类中，填写此产品组成部分依赖的项，如操作系统、数据库、JDK等。后面表示测试中计划具体要测哪几套组合方式，如功能测试主要环境中列出Windows平台、Oracle数据库等等。如果组合的套数太多，也可以另起一行编写。)

5.4.测试环境补充说明：

（在此小节中列出一些关于测试环境的补充说明，形式不限。例如，如果测试环境需要网络拓扑图可以添加类似下面的图表）

模板修订历史信息Revision history information

*A – 增加  M – 修改  D – 删节

变更版本	日期	图表、表格、段落号	A/M/D	原因与修改情况描述	修订人	审核人
V1.0	2007/3/13		A	新增，参考原测试方案模板及RUP模板	柯能江
V2.0	2008/2/29		M	全部修改	高峰	田丽娃
V2.1	2010/6/18	1.2章节	M	增加办公地点、测试项目类型描述	李峰	田丽娃