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