测试配比时间研究[这是2周前起草的一个临时文档，目前已经通过评审发布]

测试时间比例方案

1 项目周期中测试活动与开活动列表：

类型	开发活动	测试活动
设计	需求规格	需求规格说明书评审
	开发计划(MPP）里程碑时间确定	测试计划(MPP)里程碑时间确定
	概要设计	系统测试框架梳理
		测试需求提取
		系统测试方案
	项目开发计划	项目测试计划
	概要及详细设计	测试特性提取
实现	功能编码	测试用例设计
	提交测试	测试环境搭建
		功能测试(仅对基线需求验证)
		性能测试(仅对发布指标验证)
		补丁版本(仅对新增功能验证)
		数据升级测试(额外配比)
		双机冷备/热备测试(额外配比)
		容量规划测试(额外配比)
		修改现网问题单(额外配比)
		补丁版本全覆盖测试(额外配比)
	问题单修改	系统功能测试报告
		系统性能测试报告
		问题单回归策略
		测试用例增补
		测试过程度量数据收集
	CCB会议	CCB会议
总结	项目开发总结	项目测试总结

综述：

我们将项目开发过程中各阶段活动罗列如上表，其大体的时间配比关系可视为三个阶段：设计、实现、总结。测试计划定制时，仅对最终基线需求及性能发布指标进行分析、设计及执行工作。其余测试，如：数据库升级测试、双机热备/冷备测试、容量规划测试、兼容性测试、补丁版本全覆盖集验证等，均不在基本测试计划中予以考虑。如有相应发布需要，项目经理可向测试负责人申请额外的项目配比时间。

2 项目分类及时间配比策略：

1) 新增版本需求：按需求数量及复杂度配比

2) 修改现网问题：按额定最少时间配比

3) 模块结构调整：按功能调整影响及风险配比

4) 系统升级测试：按目标升级版本个数及是否存在历史升级参考配比

5) 复合属性版本：按照以上各因素影响矩阵配比

2.1 新增版本需求：(基本计划)

2.1.1 一般性项目

按项目实际需求配比，范围区间：1:1到1:1.2.。

2.1.2 补丁包项目

按项目实际需求配比，范围区间：1:1到1:1.2.。

1) 补丁版本基本测试：仅进行新增功能验证时间进行配比。

2) 补丁版本全覆盖测试(额外配比)：除对新增功能配比相应时间外，项目经理需向测试负责人申请追加全覆盖测试配比时间(参考新开发产品，模块第一轮测试时间)。

2.2 额外配比测试：(特殊功能)

额外配比测试公共约定：

1) 功能及性能测试设计前，项目经理需向测试负责人提供详细问题单缺陷分析文档或提供详细设计文档并组织有效系统培训；

2) 测试版本提交前，项目经理需向测试负责人提交该功能影响范围及测试重点说明；

3) 额外配比测试，最多转测次数为2轮；若超过2轮，项目经理需向测试负责人申请额外时间配比。

4) 测试结束标准已测试计划中对各轮次制定测试目标一致。若当前系统无法达到本轮测试目标，待本轮计划结束之日，项目经理需向测试负责人申请延长该阶段时间配比，并适当调整项目计划。

5) 其它标准请参考《测试提交规范2.0》产品转测标准及版本打回标准章节。

2.2.1 修改现网问题：(额外配比)

1) 功能缺陷：至少预留2天测试设计、2天测试执行、0.5天测试报告；

2) 性能调整：至少预留3天功能测试设计、1天性能测试设计、5天测试执行(包括：3-5性能测试)、0.5天测试报。

2.2.2 模块结构调整：(额外配比)

1) 功能调整：按新开发产品，模块第一轮测试时间进行配比。

2) 性能调整：至少预留3天功能测试设计、1天性能测试设计、5天测试执行(包括：3-5天稳定性测试)、0.5天测试报告。

2.2.3 系统升级测试 (额外配比)

1) 若存在历史升级记录，每个脚本至少预留0.5天测试设计、1天功能测试。

公式：升级测试额外配比时间=升级脚本的个数*1.5人天

若不存在历史升级记录，每个脚本至少预留0.5天测试设计、1.5天功能测试。公式：升级测试额外配比时间=升级脚本的个数*2人天

2) 若存在历史升级记录，需要从一个较早的版本升级到当前目标版本。每个脚本至少预留 0.8天测试设计、1.2天功能测试。

公式：升级测试额外配比时间=升级脚本的个数*2人天

3) 若不存在历史升级记录，每个脚本至少预留 0.8天测试设计、2.2天功能测试.公式：升级测试额外配比时间=升级脚本的个数*3人天