“计划赶不上变化”，但如果想要软件测试后期尽可能有序的开展，那么制定一份接地气的测试计划是必须的。
当然，如果你一直是做“敏捷”测试，可能都不知道测试计划为何物，而你常见的仅仅只是一份份任务排期表。
给出一个确切测试计划的目的：
尽早的明确测试工作的内容（范围）、测试工作的方法以及测试工作所需要的各种资源，并把这些信息发布给所有涉及到测试工作的涉众，尽快将下一步测试工作需要考虑的问题和准备的条件落实下来，最终保证软件测试工作有序开展。
测试计划不是某一个人，或者某几个人拍拍脑袋就能凭空想出来的结果。测试计划也不是为了应付一些ISO年审要求所给出的一份必需文档，这样可能写完了就束之高阁，供后面外审人员观赏。
如何制定好一份较实际，能落地的测试计划？
首要任务是熟悉软件需求（可能是用户需求、需求规格说明书，也可能是原型设计）。如果我们都不知道软件需求是什么“东西”，那更别谈怎么获知需求的复杂度、优先级和需求里面包含的测试点等关键信息了。那后续也就无从得知，也无法大致评估设计出的用例大概数目，以及执行测试需要的大概时间了。所以脱离了需求的熟知，很难制定出一份能落地的测试计划。
举个例子：
笔者也经历过，一堆人因为一些原因只能靠几个标题就去制定开发、测试计划的荒唐事，这份计划出生后，自打应付完领导后就从此掩埋在层层文件夹中，大家仅记住了向公司高层保证的“交票”时间。
当需求熟悉后，也不是说可以拍拍脑袋制定测试计划了。这时需要与开发经理、项目（或产品）经理一起来进行计划的拟定。
项目经理参与是必须的，可能也是项目经理主导的，往往公司高层对项目的时间周期已经对项目经理做出了明确的要求，如最长时间、应该在什么时间完成等，而项目经理为了把控项目，内心肯定也有一定的谱了。
而与开发经理共同制定计划，那也是非常有必要的。往往开发经理在制定开发计划时，会说明其中的一些技术难点，这往往也是软件测试的关键点。当开发经理拟出初步的开发时间计划后，我们才能结合需求，以及对下面测试人员的了解给出一个合理的时间计划。
此后，项目经理基于拟出的项目总体计划，以及可能存在的风险，可能会征求开发、测试经理的意见再进行计划调整，这时开发、测试可能需要就实际情况进行据理力争了，或者考虑时间调整后的影响作出应对措施。最终项目总体计划，开发、测试计划才能真正的敲定下来。
接下来是编写测试计划。测试计划每个公司可能模板都不一样，但一些关键点都是相通的。测试计划大概内容包括了以下这些方面：
1、术语、定语和缩略词，即文章中引用的专业术语词汇等，为了让读者明白其义就需要在前面以表格、列表等方式解释清楚。
2、软件测试简介，这里面就包含了本次软件测试的目的，软件测试的背景，以及软件测试的内容范围说明等。
3、软件测试进度安排，即测试的进度计划，如果有集成测试，还应该区分集成测试和系统测试，以及下面迭代测试时间计划、性能测试等类别测试时间计划等。
4、测试资源，这里包括了人员的分配，测试环境的配置及组网图，测试工具等。
5、风险、问题及优先级，为了把控后期的软件测试风险，应该把软件测试中可能存在的风险、问题以等级划分标识出来，并给出对应的应对策略。
6、测试策略，即我们后面开展测试的思路，如怎么开展功能测试、性能测试、安全测试等。（如何制定策略可阅读《小酋测试：你真的了解什么是测试策略么？》）
7、测试标准，包括测试介入标准，退出标准，以及问题严重程度，这些都应该根据公司的实际情况进行划分。如严重程度，既对bug严重级别进行定义，常见的有4级或5级划分。
8、参考文档及测试产出文档，即把制定计划参考所用的文档以及整个软件测试过程需要产出的文档罗列出来。
9、附录，如：项目任务，具体可能包含软件测试过程步骤，以及过程产出等。
（测试计划模板，可以通过在（51ste软件测试部落）公众号输入“计划模板”获取）
测试计划制定好后，需要拉上项目经理、开发经理进行最终的评审。如果有问题，进行适当的修订。最终通过评审后，一份接地气的测试计划就制定完成了。
再来说说决定测试计划好坏的一些关键点：
1、计划最重要的是时间。那怎么评估测试所用时间呢？这个需要根据团队每个成员的能力了解，过往经验基础上进行分析、评估，给出一个切合实际的时间。这里的“时间=开发转测时间+测试所用时长（投入一定测试人员所用时长）”，给出这样的时间才靠谱，毕竟测试紧密依赖开发。