提到测试计划，是否会首先想到一份庞大、正式的测试计划文档？
在早期传统瀑布模式下，测试计划一般是一份很重的文档。但是现在敏捷模式盛行，很少再去制定传统意义上的测试计划了。但是，并不是说测试计划没意义了，而是形式上变得更轻盈，可以随着项目情况实时调整。
所以说，测试计划依旧存在，只是从原来的一次性集中制定测试计划，变成了以迭代的方式持续制定测试计划。
通常，一份好的测试计划应该具备以下内容：测试范围、测试策略、测试资源、测试进度和测试风险预估。
一、测试范围
测试范围，需要明确：
- 测什么
- 不测什么
比如，对于用户登录模块，功能测试既需要测试浏览器还要测试移动端，同时还考虑登录的安全、并发等非功能性需求的测试等等。
同时，由于不可能进行穷尽测试，而且测试的时间和资源都是有限的，所以必须有所取舍，进行有针对性的测试。
二、测试策略
测试策略，需要明确：
- 先测什么后测什么
- 如何来测
1. 测试顺序
重要的项先测，而不重要的项要后测。
比如，对用户登录模块来讲，“用户无法正常登录”和“用户无法重置密码”这两个潜在问题，显然前者影响更大。所以，应该来先测“用户正常登录”，再测“用户重置密码”。
2. 测试类型或方法
1）功能测试
这个是必备方法，包含了接口测试、GUI测试，无须多说。
另外，主线业务的功能测试经常需要执行回归测试，所以条件允许的话，还可以考虑实施自动化测试（优先实现主干业务流程）。
2）兼容性测试
通常在功能测试的后期，这时候功能基本都稳定，方便开展兼容性测试。
主要针对：不同浏览器和版本、不同移动设备类型和操作系统等，选用覆盖最常用业务场景的测试用例进行测试。
3）性能测试
需要在明确了性能需求（并发用户数、响应时间、事务吞吐量等）的前提下，结合被测系统的特点，设计性能测试场景并确定性能测试框架。
性能测试涉及内容繁多，这里不展开了，后续会单独分享。
三、测试资源
通常包括：测试人员、测试环境。
一、测试人员
确认谁来测。
通常需要你对团队的成员有较全面的了解，把每个人放到合适的位置，做合适的事情。
比如，难度较大的工作，或者一些新工具、新方法的应用，又或者自动化测试开发工作，通常由资深的测试工程师来承担；而那些相对机械性、难度较小的工作，则由初级工程师完成。
强烈建议把具体的任务清晰地落实到每个人的身上，这将有利于清晰责任，避免后续可能发生的扯皮。
二、测试环境
确认在哪里测。
根据不同的项目，可能会使用共享的测试环境，也可能使用专用的测试环境，甚至还会直接使用生产环境。不管是用哪种，确认测试环境的可用，或者谁来搭建交付是必要的。
四、测试进度
测试进度主要描述各类测试的开始时间，所需工作量，预计完成时间，从而进一步推出上线发布时间。
五、测试风险预估
计划赶不上变化，通常很少有整个测试过程是完全按照原本测试计划执行的。可能存在：
- 需求变更：比如增加需求、删减需求、修改需求等，一定要重新进行测试需求分析，确定变更后的测试范围和资源评估，并与项目成员及时沟通因此引起的测试进度变化。
- 测试工作量预估不准：随着测试的开展，你可能会发现前期对于测试工作量的预估不够准确，也可能发现需要增加更多的测试类型，也可能发现因为要修改测试架构的严重缺陷而导致很多的测试需要全回归，还有可能出现开发递交测试版本延期，或者人员变动等各种情况。
所以，在制定测试计划时，就要预估整个测试过程中可能存在的潜在风险，以及当这些风险发生时的应对策略。做到心中不慌，有条不紊地应对这些挑战。
