首先，什么是测试计划，说白了，就是用来指导后续测试工作的规范文档，用来规划测试的进度，详细时间，人员，风险等事项。打个比喻，就象我们玩网游，作为一个团队Leader，你要带领团队推倒某个BOSS就是目标，如何推倒，用什么样的战术，配置什么样的人员，每人需要什么装备底线，需要什么技术的，如果BOSS前有小BOSS，用什么样的路线来走，如果遇到问题，应该怎么办，是当场换战术，还是回去总结然后卷土重来。谁来记录人员出勤，人员贡献度，如何分配战利品。大致推倒这个BOSS需要多少天，每天用多长时间。是否需要与其他团队合作，如果需要谁是联系人，有问题由谁来评定，如何合作等等。其实这就是一个详细的计划。按照计划走，在实际执行过程中会少走路，碰到问题，大多也会很容易就得到解决，或找到合适的解决办法。
测试计划也有很多种类，有整体测试计划，有阶段的测试计划，这要看你所在的组织，实际项目情况来定。总的来说有《项目测试计划》、《系统测试计划》、《集成测试计划》、《单元测试计划》。
计划的编制是建立在丰富的项目经验基础上，才能充分的把控整个项目的走向。指导并引导测试工作朝着正确的方向健康的发展。
很多人都问，测试计划在什么时候开始编写，是在项目计划确定后，还是需求规格基线之后，还是详细设计完成？其实这个问题比较笼统，要说明做什么测试计划？需要先明确的一点是，测试计划都是要以需求做为依据，明确了需要测什么，才能确定怎么测。《项目测试计划》是以《项目计划》为输入，服从于《项目计划》，以《项目计划》为参考标准制定的，《系统测试计划》对应的是《需求规格说明》，《集成测试计划》和《单元测试计划》分别是《概要设计》和《详细设计》。如果就《项目测试计划》而言，可以在需求调研阶段就介入，开始着手编写，在《项目计划》确定、通过评审后正式定制。当然，实际情况中一般来说，我们只编写一份测试计划，这也就是大家泛讲的测试计划。这份计划如果有条件就要从需求调研阶段介入，开始了解项目的需求和目标，在《需求规格说明》基线后，开始制定《测试计划》。
下面来说说测试计划的内容。标题、摘要、范围等通用格式部分就不讲了，直进主题，主要包括：
· 测试范围，描述本次测试哪些要测，哪些不测，包括功能，性能，模块等；
· 测试策略，也就是怎么测，如何测；
· 测试类型，清晰的列出都采取何种测试，如功能测试，GUI测试，易用性的测试等等，每种测试类型中还要说明测试的目标，采用的技术，完成的标准及相关的特殊事项等； · 测试工具，测试需要用到的工具，名称、厂商及版本号；
· 测试资源，包括软硬件资源，人力资源等；
· 异常事项的处理，如遇到争执不下的问题，如何解决，找谁去裁决，部门之间的合作等；
· 测试的挂起与恢复，即在什么情况下测试不再继续执行，什么条件满足了再继续，以减少人员闲置浪费资源；
· 测试风险，需要详细列出可能想到的测试过程中会出现的以及规避的方法，如人员可能不稳定，会被其他项目借走，那么我们的测试工作应该如何应对；
· 测试进度，详细的列出任务、时间、人员及所需工时；
· 测试结束标准，说明满足什么条件本次测试工作才可以算结束；
· 输出，明确测试结束后，需要交付的所有文档。
以上就是基本的测试计划需要包括的内容了，可以根据实际情况添加或删减。
测试计划的几点注意：
· 计划宁可时间多一些，也不要少，避免在测试执行阶段因为时间定的不够而捉襟见肘。但要符合实际情况，不能与实际偏离，否则会导致项目反复的变更，影响项目组的工作，以及测试人员的工作热情。
· 测试计划可以长达几百页，也可以简单的只有一张纸，关键测试计划必须实用，也不必要把大量的人力和物理花费在测试计划上，要根据具体情况来确定。
· 不要为了计划而计划，事后补来的计划对于测试工作没有任何意义。
· 计划不是一成不变的，可以随着工作的开展进行修改，但要控制修改力度、频率，频繁的修改就需要重新考虑计划定的是否合理了。
· 有了计划就要按照计划来执行，前提是计划是合理并合适于本项目的，只制定不执行也就完全地失去了测试计划的作用。
测试计划制定完成后，需要进行评审，审核计划的正确性、全面性、可行性。在项目结束后，还应该对测试计划的执行情况进行分析总结，作为以后项目测试计划的经验，积累下来，以提高测试计划的质量。
