其实嘛，测试计划就是把和测试有关的一些比较不太细节的事情都说清楚。
测试计划模板网上有很多，但总结比较之后就会发现，无论格式怎么变，都逃不出6W（what,why,who,when,where,how)。
将6w解释清楚，就不失为一个好的测试计划。
比如说，你说这个项目不做硬件的兼容性测试。那就要写到测试计划里面。写清楚，我们不测，原因是一二三四。大家认可了，PM也认可了，testers也认可了，以后就变成共识了。以后再有人来问你，“你们为什么不测硬件兼容性啊？”你就让他自己去看测试计划。
又比如说，产品怎么样才算能发布啊？这个事情已开始就要在测试计划写清楚。比如说，必须达到“连续48小时新bug数量少于3个，才能进入准备发布和收尾阶段”，等等。到时候大家就有依据了。到时候如果PM来找你，责问你“你们测试部门凭什么说产品还不能发布”，那时候你就可以八测试计划翻出来给他看。
还比如说，整个测试部门谁负责产品安全性测试的，也要在测试计划里面规定。到时候，一旦大家相互推诿，“安全性不是我负责的”。那时候就可以疤测试计划翻出来，白纸黑字，谁也别想赖。
再比如说，整个团队要有文件服务器，要有代码服务器，要有bug服务器，谁负责维护，机器down了找谁，也要在test plan里面写好。到时候，一旦什么东西down了，tester就不用到处问了。翻开测试计划一看，哦，原来bug server是Alice负责的，直接找他就可以乐。
这些东西和在一起，就是测试计划了。写的时候，尽量从将来看的人的角度出发，把他们想了解的事情、可能产生混淆的事情都写好了、规定好了，就是一份好的测试计划。
具体的方面包括：
- 启动条件
- 测试通过/失败标准
- 暂停测试的原因和恢复的要求
- 测试依据的文档
- 环境要求
- 任务分配
- 所需人员和分配
- 进度安排
- 风险和费用
- 测试的监控
- 评审
- 测试结束的条件
- 可交付成果
时间： 2024-10-21 08:58:51