一般在产品需求确认、测试需求分析完成后进行测试计划编写。
测试计划应该包含的内容——
测试范围:明确需要测试那些模块。产品的具体业务需求有哪些,产品是web端的还是移动端的,还是都有。
测试策略:明确怎么测。对不同业务需求具体要有哪些测试类型、测试场景、测试方法等等。
资源安排:测试人员的安排,测试环境是怎样的,测试工具的选择。
进度安排:明确什么时候开始测试,预计要测试多久,以便和开发计划、上线计划衔接。
发布标准:测试完成和产品上线需要满足的条件,以便项目内所有角色都有一致认可的目标。
风险预防:对整个测试过程中可能出现的风险,以及当这些风险发生时的应对措施提前进行考虑和准备并在测试计划中体现出来。
测试计划模板
1 引言
1.1 编写目的
1.2 预期读者
1.3 参考资料
2 测试范围
3 测试策略
3.1 功能测试策略
3.2 系统兼容性测试
3.3 性能测试
4 测试资源
4.1 测试人员
4.2 测试环境
4.3 bug管理工具
5 进度安排
5.1 测试进度及工作量估算
5.2 输出文档
6 发布标准
6.1 测试完成标准
6.2 产品发布标准
7 风险说明
说明
进度安排
项目的里程碑
1、开发节点
2、提测节点
3、上线节点
测试进度依赖于开发进度和提交测试的时间,并且直接影响预期的上线时间。
评估因素
1、业务复杂度
2、测试复杂度
3、产品质量要求
4、人员数量能力
进度安排
1、评估工作量
比如冒烟测试的工作量,大概有几轮回归测试以及工作量,性能测试的工作量等。
2、分配人力
对测试人员的分工进行安排,明确职责。比如,谁进行功能测试,谁负责性能测试等。
3、预估时间
预估测试工作开始和结束的时间节点。比如,预计什么时候能够开始性能测试、预计什么时候完成第二轮回归测试等。
输出文档
1、测试计划
2、测试用例
3、bug数据
4、测试报告
发布标准
测试完成的标准和产品发布的标准这两个测试目标之间既有关联,又不完全相同,都需要在项目团队内达成一致共识。
测试完成是产品发布的前提,但是产品上线前,还有其他一些需要完成的工作。
测试完成标准
1、测试计划中包含的所有测试类型都已经完成
2、没有影响用户正常使用的bug
3、允许遗留影响较小的bug,但是bug数要少于一定值
4、服务端性能满足设计目标
以上标准都是针对测试工作本身的要求。
产品发布标准
1、所有产品需求都已完成
2、交互视觉完成了走查
3、遗留bug经过风险评估
4、使用说明文档完备
风险评估
计划本身就需要更新维护,所以需要对测试过程和产品质量可能会发生的问题和风险做好应对准备,避免问题真的发生后出现连锁反应,影响整个测试和剩下的工作。
测试风险一般包含:
测试范围风险
测试遗漏:一开始,测试需求分析不准确、不到位,遗漏了测试点,甚至遗漏了某个测试类型。所以测试需求分析是整个测试工作的基础。
需求变更:加需求、改需求都需要重新进行测试需求分析。需要测试的不能遗漏、不需要测试的就不要浪费人力物力。
测试进度风险
工作量预估不准确
耦合任务延迟:测试依赖开发,开发没有完成或者改bug不及时导致进度延后
测试人员变动
产品质量风险
代码质量
测试人员能力