通用系统测试计划模板(附参考模板)

以下以一常用的软件测试计划模板为例 ，介绍了如何制订好一份测试计划。用于软件评测第一阶段，业务系统使用时需根据实际情况来适当增删，以及风险管理应对方案。
这里主要分为以下部分：
文档简介
测试资源与工具
测试策略
测试阶段的开始/结束标准
风险与应对计划
质量目标
测试过程管理
测试范围定义
测试排期（进度、人员安排）
测试交付物
附录-测试关注点

---

文档简介
一般包含测试计划编写目的、限制条件及参考文档
编写目的需要根据文档阅读人群来编写，如果项目属于外包性质的，需要考虑是否会合并在验收文档中。

测试环境
一般包含硬件环境和软件环境，如下图：

测试工具
所有测试过程中使用到的工具，包含用例编写工具、执行测试工具、缺陷管理系统、需求管理系统等等。

测试策略及方法
常见的测试策略如下：
尽量做到在有限的时间里发现尽可能多的缺陷（尤其是严重缺陷）
测试计划与需求阅读同步进行
用例的设计需要高匹配产品需求，在需求的指导下设计出更多更有效的用例
逐步完善测试用例库（测试用例需要根据执行过程中不断修订，动态调整）
保证测试过程受控

常用的用例设计方法：
等价类划分法
是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。

边界值分析法
边界值分析方法是对等价类划分方法的补充。通常输入和输出等价类的边界，就是应侧重测试的边界情况。

错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。错误推测方法的基本思想：列举出程序中所有可能有错误及易发生错误的特殊情况，根据它们来选择Case。

判定表法
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
判定表的优点是可以将复杂问题按照各种可能的情况全部列举出来，避免遗漏。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

场景分析法
对于业务功能测试领域，场景分析法是最普遍也是最主要的设计方法了。首先需要充分了解整体业务。结合分析应用场景，从用户角度出发设计Case，是一种面向用户的测试用例设计方法。

缺陷的严重级别定义
此处不作过多说明，通常按照行业标准定义。但业务为主的产品中，需由产品经理及用户代表来确定缺陷的严重程度，主要根据对用户使用的影响程度来计算。

另外，常见测试类型如下图：

开始/结束标准定义

开始标准与结束标准通常按照公司内部的测试流程来确定，如测试交付产品经理或验收通过，或是达到已经定义好的质量标准。
中断标准
软件开发过程中，难免会出现一些意外导致项目中断，这时测试也应按照提前约定好的暂停，一般存在以下情况时：
软件项目需暂停以进行调整时，测试应随之暂停。
软件项目在开发生命周期内出现重大进度偏差，需暂停或终止时，测试应随之暂停或终止。
若开发任务暂停，则相应测试也暂停。

风险与应对计划
一般包含需求风险、时间风险、资源风险等，需要注意的是，每条风险识别都需要有对应的应对计划措施，至少2条。

质量目标
一般包含产品质量目标与测试质量目标
测试质量目标以下可作为参考：
所有的Case已执行过至少一遍
所有严重级别及以上的Bug已修复且测试人员验证通过
核心功能不允许有中级及以上的Bug
一般功能与终端用户不直接使用的功能不允许有中级以上的Bug
缺陷趋势呈下降并接近为0
在最后的10%时间内没有发现中级以上Bug
 
测试过程管理
通常包含测试文档的过程管理与缺陷处理的流程、汇报会议、进度日报形式等。
文档的过程管理如管理人员、存储、移交、分享等需要定义好形式，缺陷处理流程可以以缺陷管理系统中定义好的工作流来说明。

测试范围定义
测试范围可以按照项目计划书的里程碑来提前拟定，如哪个阶段需要进行底层框架的性能测试、是否需要完成接口测试、功能测试中包含哪些功能点等等。非测试范围一般说明不在本次范围内的功能点或测试类型，有时因项目进度原因可能临时对某些功能点进行删减，需要同步更新。

测试排期（进度、人员安排）
进度排期可参考以下几个节点进行划分，可以根据特定节点来划分不同的阶段。

人员与任务安排可以根据前期已整理好的可用固定资源与临时资源调配来作好相应调动计划。

测试交付物
一般一个项目结束后需要交付的测试产物有：软件测试方案、测试用例、缺陷报告、项目测试报告、用户操作手册（若由测试团队提供时）

附录-测试关注点
附录中依据需要可以增加多个附录，如相关术语、缩略语的解释、测试需特别关注点等 。
测试关注点一般由技术负责人、所属产品经理及用户代表提供，可以在测试方案中提前明确以提醒测试人员的注意事项。
如增删查改功能点、数据导入、导出及特定输入框功能的测试侧重点
1 不能破坏数据库数据的关联和完整
2 检查多次使用back键的情况，在有back的地方，back回到原页面，再back重3 复多次，检查是否出错
4 修改正在使用的数据；
5 多次连续查询正确性
6 导入数据格式要求不应太苛刻，提示明确
7 数据的动态监测是否正确无误
8对于日期时间型数据，检查格式正确性以及时间日期的合理性。比如开始时间不能晚于结束时间等
9 重复数据处理，尤其是键值的重复

测试计划制订完成后，需要与项目中核心负责人确认，待审核通过后便可开始进行下一环节。需要注意的是，测试计划是隶属于项目计划书中的一部分，也是项目计划书的延伸，完成制订后仍需要根据实际情况来动态调整，才能达到最理想的指导目的。

行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群： 320231853，里面有各种软件测试+开发资料和技术可以一起交流学习哦。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！