对于一个测试者来说，编写文档的能力是基本功。今天主要来聊聊对测试计划的理解。
对于刚入行的人来说，测试计划是不会落在一个测试新手手中来完成的。工作一两年后，就得学会编写测试计划了。我刚入行时，虽然参与了测试计划的编写工作，但仅限于－统计各位测试者的电脑配置，即所说的硬件资源的统计，还有项目组中各成员的联系方式。当然也参与了计划的评审工作。
后来随着工作时间的加 长，经验的累积，自己也开始着手起草测试计划，并主导计划的评审，这是后话，今天我们要谈的是如何编写测试计划及如何评审测试计划？测试计划真的像我们工作中放在某个盘中的那一份长长的文档那么简单吗？测试是一份项目结束后，我们才想起原来这份文档是放在这个盘里的，一直都没有仔细看过。别笑，我经历的公司都出现了这种现象。
《软件测试》这本书里详细介绍了测试计划的目的与目标，测试计划的目标是交流软件测试小组的意图，期望以及对要测试的任务的理解。
从这个定义可以看出，测试计划侧重的是交流，而不是记录。虽然最终是以文档的形式出现，但文档只是一个结果，交流的过程才是这份文档的产生的目的。
现实中的公司很多 都是文档是目的，是结果。是领导想看的，却忽视了交流的过程。这有点本末倒置。只有项目团队中的成员都理解了测试计划工作的安排，最终工作开展才会顺利。
测试计划的模板有很多，百度一下，可以找到很多。但无非都是大同小异，主要包括了：测试成员的工作划分，时间进度安排，软硬件资源需求，风险评估，度量统计，团队之间的责任划分，测试的策略等。
当我新分配到一个新的项目组时，我不会立马写测试计划，也写不出来。而是先弄懂需求，先搞清楚，我要测试的软件到底是啥东东？要求是什么？怎样测试？搞懂了这些，大概需要几天时间，再问清楚，项目的起止时间，进度安排，开发那边的进度安排，等，心里都有谱后，再开始写测试计划，测试计划是一个漫长的过程，不能只是一下午猛击键盘就可以搞出来的。
回到《软件测试》这本书中，作者把测试计划看成了“计划测试的过程”，我觉得很符合测试工作的意图。计划整个测试工作如何安排？如何开展。
编写测试计划是为了让项目小组成员都知道测试员在干什么？为什么那么干？测试计划中会列出一系列的清单，放到小组中讨论，相互沟通，消除歧义，达成一致。并明确在整个项目过程中，各小组间的责任划分。最终以文档的形式记录下来讨论的结果。
知识有限，语言不够精练，没有完全把自己想描述的内容表达出来，或者描述的不够清楚，希望读者能理解。另外，希望广大测试工程师们都看一看《软件测试》这本书。