● 文档的可读性

　　对于很多项目来讲，文档的目的是要让项目组成员读懂看清——至于目标读者是不是读了看了乃至懂了，那是另外一码事，所以作为文档的作者来讲，应该注意文档的可读性。之前提到的目录，术语和缩略词以及历史信息这些部分都有助于读者理解和使用文档。因此，保证文档结构的完整性是很重要的。另外，如果自己或者对方英语水平不太好，如无特殊要求，使用母语来写文档无疑有助于拉近作者与读者的距离。总之，作为作者应该始终记住：自己一个人看的文档和给所有人看的文档是不一样的。

　　● 标准是可以度量的

　　前面也讲了，标准这一块很重要，但是为什么很多标准成了形式主义呢？有一个很重要的原因就是标准是无法度量的，如果我们的标准定为“开发出一个很受欢迎的产品”，这就有点扯了，先不说你的“很”是怎么衡量的，单说“受欢迎”这个词儿，一千个观众眼里就有一千个哈姆莱特。因此，一个好的测试计划中是应该包含可以衡量的测试停止标准的。

　　Part IV 测试计划文档之外的东西

　　● 测试计划应该持续更新

　　这个观点早在Ron Patton的那本经典书籍《软件测试》中就已经提到过了，但是真正实践起来的却不知道有多少。没有实践的原因自然有很多（人总是喜欢并擅长寻找各种各样千奇百怪的理由来搪塞，而不喜欢花一点点时间和心思在本来就该完成的事情上），譬如没时间，反正没人看等等。支持测试计划应该更新的最主要理由是，测试计划中有些内容需要实时更新。还记得前面提到过的风险分析么？项目的风险随着项目的推进有的被解决，也会有新的风险被发掘出来，而这些都应该通过文档记录下来，以保证任何人在任何时刻查阅都可以看到最新的风险分析信息。

　　● 测试计划之前应该做的事情

　　测试计划不应该是找到一份模板之后随便整整就成了自己的测试计划，那样的测试计划难免会成为案头一堆灰尘嬉戏的天堂。为了完成一份有价值的测试文档，除了上面提到的一些内容之外，我们还应该注意到以下几点：

　　-通读Feature Spec并理解需求

　　-了解开发设计文档

　　-分析风险和未决问题

　　-让Team的人了解你准备怎么做测试

　　-寻找一个测试计划模板 最好是项目组或者公司已有的模板。如果你觉得模板不够好，也可以自己写一个并持续改进，但是我想为了保证测试计划的完整性，模板上的考虑应该还是比没有经验的测试计划设计者要全面的多。当然，我不建议不加筛选地随便在网络上找一个模板草草了事，模板要找但也要选，而且是精选。

　　● 测试计划之后应该做的事情

　　不是测试计划一完成就万事大吉了，除了前面提到的要持续更新之外，还有一些事情需要我们去做。

　　-召集相关人员召开测试计划评审会议

　　-根据评审的结果更新测试计划文档

　　Review貌似是很多公司不存在的一个活动，不要说测试计划review，甚至连code review meeting都是百年难得一遇的奇观。至于为什么我们应该review，乃至为什么要有测试计划，甚至为什么要有测试，这样的问题不是本文的目的，我也不继续浪费大家的时间和自己的口水在这种问题上了。

　　Part V 总结

　　看似简单的测试计划，细细品尝起来还是别有一番风味。这篇文章本来在一开始的时候只是用来发表一下对于最近一个项目的感触和总结一下经验，没想到一下笔就写不完了。从开始写文章到今天落笔，前前后后花了一周的时间，所以衷心希望能给大家有所帮助。在第一部分讲五重境界的时候说了，我说过自己才刚刚上升到第四重，所以文中难免有纰漏，希望兄弟姐妹们可以指出来并允许我添加到文中以方便后来的读者。另外，以上介绍的内容均来自实践经验和个人总结，由于项目千差万别，不同的项目的测试计划应该区别对待，切不可盲目照搬，以上观点仅供参考。

　　PS：对于我的任何观点，所有读者都有权利发表评论。

版权声明：原创作品，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。本文出自UniqueStudioWCD的51Testing软件测试博客：http://www.51testing.com/?146934