如何编写一个好的测试计划
http://www.51testing.com/html/68/n-108068.html
目前，OSSP已经有比较规范的测试计划模版。编写测试计划时，可以以模版为基础进行编写。测试计划中各部分如何编写可以参加模版的详细说明。根据测试项目的规模与测试任务的复杂程度，可以对测试计划的编写项进行添加或裁剪。这里对测试计划制定中的几个部分作详细说明：
1.明确测试目标，确定测试需求。根据当前测试工作目标不同，测试需求的确定方式有所不同。如当前为新项目的测试工作，则测试需求可能为该项目能按时上线并按用户需求的功能正常使用等；而对于产品的阶段性测试，测试需求可以以列表形式展现，列表可以列出本次测试工作所需要测试的更新及影响的测试点等。
2.制定测试策略的时候，需要考虑：
根据测试项目特点，确定本次测试需要经历的测试阶段。确定测试阶段后，确考虑每个测试阶段的目标、进入条件及退出条件（完成标准）。
根据确定的测试阶段，分析每个测试阶段需要包含的各种测试类型，如是否需要性能测试、安装测试等。确定测试类型后，确定每种测试的测试目标、测试方法、完成标准及特殊事项考虑。
确定测试阶段、测试类型后，针对需要，确定测试方式及测试工具。
特别的：在考虑测试策略时，还应结合系统的特点及系统功能的优先级及难易程度，分析各项测试的重点及难点。另外，根据测试时间的长短不同，测试策略也需要有相应体现。
3.确定测试资源：测试资源的确定，需要充分调研，基本确定系统规模、功能复杂度、系统运行环境等，结合测试策略，考虑所需要的测试资源。确定测试资源，主要包括：
明确测试过程中角色分配。这点在测试计划阶段必须明确到人的是测试负责人这个角色。其他角色，如测试参与人员，可以不明确到具体的人员姓名。
明确测试人力资源及测试环境：考虑人力资源时，需要考虑所需人力资源的数量、各人力的知识或技能程度等。在测试计划阶段，测试负责人就可以开始协调测试资源，需要在该阶段就确定测试资源，包括人员资源及环境资源。有些项目可能测试资源比较紧张，测试计划制定者在制定计划时应该考虑最少测试资源与充足测试资源这两种条件下的测试策略调整。
4.测试里程碑设计：一般测试里程碑在模版上已经列示出来，测试计划制定者按照之前分析的测试需求、确定的测试策略及明确的测试资源，作相应的风险分析，从而确定测试里程碑及里程碑的起始时间。在制定里程碑起始时间时，可能出现项目留给测试的时间在当前实际下不足，则应及时与项目经理沟通或者重新考虑测试策略或者重新调配资源。
5.测试管理及任务的制定：这部分内容的计划，对顺利完成测试任务，保证计划执行有着重要意义。这部分内容，主要包括接收测试条件、测试时间（测试轮次）的设计、测试人员任务的分配、测试过程管理策略、测试完成标准确定及测试过程评审机制。这里，主要对测试时间、测试人员任务、测试过程管理作特别说明：
（1）测试时间设计和测试人员任务分配可以作为一体考虑。测试计划制定者需要有运筹的思想，根据当前测试资源的状况结合测试策略，确定测试需要经历多少轮次，各人员分别承担什么样的测试任务。测试计划制定者应该始终明确，成功的测试工作是用尽可能少的时间发现最多的缺陷。对于测试时间的评估，可以根据编写的文档页数、测试用例条数、执行测试用例数量及回归测试大约用时来衡量。但是目前工作中，除了上述标准，还应按项目实际情况和计划制定者的经验综合考虑。
测试轮次设计：设计测试轮次时，一般必须有回归测试环节。回归测试之前往往会经历多轮测试。但是建议不要设计太多轮次测试，以避免资源耗用过于频繁。每一轮测试都应有各自明确的目标与测试策略。如第一轮保证功能正确，第二轮保证流程顺畅，性能稳定等。最终应该设计回归测试环节，保证之前缺陷被正确修改，在该阶段还可以配合进行安装测试。如果系统庞大或测试工作复杂，对每一轮次测试，可以单独做小的测试计划，保证更好的测试效果。在测试时间控制上，应该略微预留一点时间，以控制突发事件。
在测试任务设计上，需要统筹分析考虑，合理安排人力资源。每个人测试什么任务，和谁一起承担，都应有特别的考虑；测试任务分配要均衡，避免出现一些任务特别紧张，一些任务很快完成的情况。
（2）测试过程管理设计中，需要考虑BUG管理流程，项目测试进度控制。
BUG管理中，需要考虑： BUG管理的工具是什么，BUG管理系统中各角色人员的权限是什么（测试准备一部分），研发人员解决BUG花费的时间限制，研发人员反馈BUG修改的规范、测试人员确认BUG的时间限制。总之，需要制定一个BUG管理流程，从一个BUG产生到BUG关闭这个流程中，所经历的过程规范。
测试过程管理规范的约定：如是否采用周报制度，对于项目较紧时是否采用日报的形式。对项目组成员可以要求进行日志形式提交测试情况等。
(一)——万事开头难
测试计划应该是整个测试流程中第一份测试文档了，但是一般情况下去不是测试人员学习的第一站。或许是因为万事开头难的缘故，测试计划确实挺让人纠结了。
很多有了一定的经验的测试人员在教新人的时候第一步都不是按照测试流程先从测试计划开始，而是让从测试用例的执行开始——这虽是无奈之举，但是对于测试新手来讲，还是可以学习很多东西的。闲话扯得有点远，回到我要介绍的正题上面来，计划测试。
对，是计划测试，不是测试计划。尽管我们刚才讨论了一些关于测试计划的内容。但是我们需要关心的的确是计划测试，而不是测试计划。永远要记住，我们是在做测试，而不是在完成文档，尽管我们经常需要诸如测试计划测试用例测试报告之类的各种各样的文档，但是那些都不是测试的本质。
既然是计划测试，那么我们首先要搞明白测试到底要干什么。笔者将它抽象概括为：特定的人在特定的时间在特定的地方做了特定的事情以实现特定的目标。其实任何一项工作都可以抽象成前面这句话，所以我们还需要将这句话与我们所从事的测试工作联系起来。
所谓人，当然是指测试人员了，而“特定的人”则坚持的是“按能力分工”各司其职的原则。测试用例设计人员做测试设计，测试用例执行人员做执行用例等等。
所谓“特定的时间”，是指我们的测试过程是分成各种阶段的，各种阶段所侧重的测试要点是不一样的。
所谓“特定的地方”则是指测试环境，这是指我们必须在计划我们的测试工作的时候就要考虑到某些特殊类型的测试是需要特殊的环境的，这个环境包括了硬件设施(如手机测试你总得拿个手机来试试吧，总不能一直纸上谈兵来着)环境，计算机硬件环境和软件环境。
所谓“特定的事情”即是指我们测试技术本身了，也就是诸如测试用例设计，测试用例执行，写测试代码，部署测试环境等等。
所谓“特定的目标”即是指我们测试的目的。测试是需要成本的，人力物力都是需要的，既然我们对测试有投入那么我们是期望获得一些东西的。测试最常喊的口号是改善质量水平，也有一些还在喊保证质量的，这就是我们所谓“目标”。不过，可惜的是这些口号并没有多大的用处，因为在实际的软件项目中我们更加看重的则是可度量的测试工作，也就是说我们要由一个可度量的“目标”——亦即“特定的目标”——可能是发现了多少bug可能是测试覆盖率达到了多少等等。
我们在计划测试的时候，需要考虑的不仅仅是测试本身，从上面的分析可以看出，我们要关注“人、时、地、事、责”，也就是古代中华所讲究的“天时地利人和”之类的东西。需要指出的是，在我们计划测试的过程中，最常被人忽略的就是我们测试应该达到什么目标这个问题了。在计划测试的时候，切记要约定好测试的目标，这一目标反映在测试计划文档中即“测试结束标准”。
关于计划测试的内容有很多，在接下来的文章中，笔者将逐一展开与大家分享。
(二)——测试计划
在前一篇文章中，我们提到了计划测试要考虑到人、事、时等诸多问题，也提到了计划测试重在计划这个过程而不在测试计划这个文档。
这篇文章却要专门讨论一些测试计划相关的话题。网络上现在已经泛滥了关于测试计划的模板——用泛滥只是表示很多，并没有贬损的意思，笔者才疏一时想不到好的词语——这些模板对于制作一份测试计划文档来讲非常有用，但是生搬硬套这些文档却并不能帮助我们很好的计划我们的测试工作，但是这些测试计划中的主题却可以很好地帮助我们计划我们的测试工作并有效避免疏漏。
我并不会给出一份我所常用的测试计划模板，因为这些模板实在已经太多，已经够用了。笔者在测试工作中，曾经写出两种测试计划，一种类似于当前网络上流传的版本，另外一种则是在笔者的某篇blog文章中提到的所谓“实用主义测试计划”——事实上是更接近测试设计书的一个文档，但是确实有些公司把它称之为测试计划，而在本系列文章中笔者将不再讨论这种测试计划，也不会考虑细到“怎样设计某个功能的测试用例”的程度的计划工作。
