测试计划编写

前言：

测试计划是测试中比不可少的一部分，一份完整的测试计划反应了整个项目的测试安排与测试进度，让项目在测试环节达到了可控的环节。需要注意的是，测试计划一般在大功能改动的时候需要用到，并不是每个周版本必须的。是否编写可根据项目需要，另外测试计划的编写时间，一般是你在了解了需求，分析完了需求后才开始编写。要不然你都不知道自己测试什么，怎么测试。

1. 测试目标：

根据xxx需求，提炼测试功能点、制定测试策略、评估测试 风险，预估编写测试用例、执行功能测试和回归测试的工作量，进行人员和进度 安排。

2. 测试范围：

功能模块：（需要结合实际情况）

3. 测试策略：

对需求中的功能改进进行完整测试，并根据应用场景和并发数考虑兼容性和 性能测试方案。 并需要指定出测试工具。

3.1 功能测试

见测试用例表

3.2 性能测试

3.3 系统兼容性测试

4. 测试资源

4.1 人员安排

4.2 测试环境

4.3 bug管理

5. 测试进度安排

5.1测试进度安排

任务	时间	执行人员	工作量
编写测试计划
测试环境准备
第一次功能测试
性能测试
回归测试
测试报告总结

5.2输出文档

测试计划
测试报告

6. 验收

6.1 测试验收标准

		1.完成所有类型测试
		2. 没有影响到用户业务使用的bug
		3. bug数量少于一定数量
		4. 功能业务，性能指标符合需求

6.2 产品上线标准

产品 checkelist
1. 已按照交互文档、需求文档完全的实现需求；
2.  符合交互稿的交互设计规范、符合视觉要求，已经通过设计评审；
3.  允许遗留可能会对用户正常使用造成一定影响的 normal 级缺陷，但应在 发布前告知项目组，并经风险评估一致同意发布后方可发布

7. 风险说明

主要包括三个方面：

1. 测试范围风险 （测试遗漏，需求变更）
2. 测试进度风险（预估量不准确，测试人员变动，其他业务工作，）
3. 产品质量风险（代码质量，测试人员能力）

比如：1. 上述工作量预估中对需求变更进行了一定的风险覆盖，但如果需求变更 超出目前预计，则可能导致编写测试用例和执行测试相关工作量增加、 测试进度延迟。。 2. 开发提交测试版本比该计划延迟的风险，发生此种情况时，执行测试的 时间应该合理顺延。 3.提交测试版本质量较低的风险，可能导致比该计划更多轮次的回归测试。
4.代码版本管理执行不力的风险，发生版本管理混乱的情况时，将只选取 一个稳定版本进行测试，不考虑中间版本的反复测试。一轮测试完成后， 再进行下一稳定版本的回归测试。 5. 云课堂所依赖的测试服务器环境，如果服务器端测试环境不稳定，会影 响开发提交测试版本和测试的进度

最后箴言：

每次我们测试的时候都可以用5W+H思考方法，

1）why——为什么要进行这些测试；

2）what一测试哪些方面，不同阶段的工作内容；

3）when一测试不同阶段的起止时间；

4）where一相应文档，缺陷的存放位置，测试环境等；

5）who一项目有关人员组成，安排哪些测试人员进行测试

6）how一-如何去做，使用哪些测试工县以及测试方法进行