在软件工程，要求每个阶段都需要有详细计划。软件开发时需要制订开发计划，同样，软件测试也需要制订测试计划。
百度百科对测试计划定义如下：
测试计划Testing plan，描述了要进行的测试活动的范围、方法、资源和进度的文档；是对整个信息系统应用软件组装测试和确认测试。 它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。
从上面的话看出，测试计划是围绕测试范围、测试方法、测试资源、测试进度展开，另外还包括对测试风险。
测试范围
测试范围描述被测对象和主要测试内容，确定要“测什么”和“不测什么”。当收到测试需求后需要开始分析业务需求，从业务需求分解出功能测试点。在整理测试范围过程，也在明确需求内容并对需求内容进一步核对。
譬如，要测试查询商品信息，功能测试既要考虑web端测试，也要考虑移动端测试。同时也需要考虑安全测试和性能测试等非功能性测试。
测试方法
测试方法是用于描述测试整体是“先测什么后测试什么”，以及采用什么测试类型和测试方法。分配给测试的时间是有限，在有限时间里要求得到最大产出比。那我们可以用优先级进行排序，哪些可以先进行测试，哪些可以后测试。
回顾测试范围提到要测试“查询商品信息”，需要添加商品才有商品信息，所以“添加商品信息”比“查询商品信息”功能的优先级更高些。
在这里测试类型主要讲解功能测试和兼容性测试。不同测试类型会使用不同测试方法。
1.功能测试
在测试范围已经确定需要功能测试点，分析哪些测试点适合采用自动化测试，哪些适合使用手工测试。如果使用自动化测试，使用什么样的框架和技术；而手工测试，则采用什么方法设计测试用例。
主干业务流程是相对稳定，稳定部分可以采用自动化测试。对于常变化的页面，不一定适合自动化测试，页面结构变化后也需要修改自动化程序，这也需要耗一定时间和人员。
2.兼容性测试
对于兼容性测试来说，Web测试需要确定覆盖浏览器类型和版本，移动设备测试需要明确覆盖的设备类型和具体iOS/Android的版本。移动端测试还需要考虑能否兼容之前发布过的版本。
一般来说，兼容性测试是在功能稳定才开始进行，兼容性测试往往测试最常见的业务场景，常见的业务场景可以考虑使用自动化测试来完成。
测试资源
测试资源主要测试人员和测试环境，在有限资源需要合理分配和调度，测试资源环节需要明确“谁来测”以及“测试哪部分”的问题。
测试人员
测试人员关系整个测试项目和成败和效率。影响人员有两个重要因素：
1.人员数量；
2.个人经验和专长。
在确定人员后，明确每位测试工程师负责测试哪部分，把具体任务落实到个人，这样减少出现遗漏测试内容以及推卸责任的情况。
测试环境
测试环境是指本次测试使用什么环境进行测试。使用共享测试环境，或是专门搭建一套测试环境，再或者使用准上线环境呢。
测试进度
测试进度主要描述各类测试的开始时间，所需工作量，预计完成时间。例如，编写测试用例的工作量、冒烟测试的工作量、缺陷修复验证工作量时间、回归测试工作量等等。
测试风险
在实际中，很少出现是完全按照制定好的测试计划来进行。项目是动态变化，会受到需求变更、开发延期、人员变动等因素影响。也可能在早期对估算工作量不够准确都会影响到整个测试计划。
在制订计划时，需要评估整个测试过程有哪些潜在风险，如果发生这些风险要采用什么策略来应对。
总结
测试计划主要包括：测试范围、测试方法、测试资源、测试进度和测试风险评估。虽然计划赶不上变化，但测试计划能明确需要被测软件的需测试哪些功能、选择什么测试类型和方法、确定测试资源。在变化中寻找不变的东西，抓住我们有把握的部分，即使测试计划出现变更也能应对自如。
参考：
茹炳晟《软件测试52讲》-08|以终为始，如何才能做好测试计划
