包含：被测对象，主要的测试内容
确定测试范围一般在测试需求分析完成后进行，所以确定测试范围的过程在一定程度上也是对测试需求分析的进一步检验，有助于在早起阶段发现潜在的测试遗漏；
由于测试时间和成本有限，必须进行针对性的测试，因此测试范围中要明确 测什么 和 不测什么 。
测试策略就是要明确 先测什么后测什么 和 如何来测 ，明确测试的重点，以及各项测试的先后顺序；
比如：对 用户登录模块 来讲，“用户无法正常登录”和“用户无法重置密码”这两个潜在问题重要性并不高，所以应该按优先级来先测“用户正常登录”
测试策略还要说明，采用什么样的 测试类型 和 测试方法 ，不仅要给出为什么要选用这个测试类型，还要详细说明具体的实施方法。
前期，明确性能需求（ 并发用户数 、 响应时间 、 事务吞吐量 ），结合被测系统的特点，设计性能测试场景并确定性能测试框架
比如：
如果性能是背景数据敏感的场景，还需要确定背景数据量级与分布，并决定产生背景数据的技术方案，比如是通过 API 并发调用来产生测试数据，还是直接在数据库上做批量 insert 和 update 操作，或者是两种方式的结合。
最后，无论采用哪种方式，都需要明确待开发的单用户脚本的数量，以便后续能够顺利组装压测测试场景。
关于性能测试的实施，首先，需要根据你想要解决的问题，确定性能测试的类型，然后，根据具体的性能测下类型开展测试。
还有很多测试类型
比如：接口测试、集成测试、安全测试、容量验证、安装测试、故障恢复测试
包含：测试人员和测试环境
测试资源需要明确 谁来测 和 在哪里测
主要描述：各类测试的开始时间，所需工作量，预计完成时间，并以此为依据来建议最终产品的上线发布时间
在传统瀑布模型中，测试进度完全依赖于开发完成并递交测试版本的时间。如果开发提交测试版本发生了延误，那么在不裁剪测试需求的情况下，产品整体的上线时间就同样会延期。
然而在敏捷模式下，测试活动贯穿于整个开发过程，很多测试工作会和开发工作同步进行，比如采用行为驱动开发（Behavior-Driven Development）模式，这样测试进度就不会完全依赖于开发递交可测试版本的时间。
行为驱动开发，就是平时我们经常说的 BDD，指的是可以通过自然语言书写非程序员可读的测试用例
对于需求变更，如增加需求、删减需求、修改需求，一定要重新进行测试需求分析，确定变更后的测试范围和资源评估，并与项目经理和产品经理及时沟通因此引起的测试进度变化
测试过程中，可能会发生以下情况
所以，在制定测试计划时，就要预估整个测试过程中可能存在的潜在风险，以及风险发生时的应对策略。
原文：https://www.cnblogs.com/poloyy/p/12198900.html