任何活动都是计划先行，制定了周密计划，活动效果就有了一定的保证。如果没有计划，结果往往难以预料。软件测试也不例外，通常都会有详细的项目计划。
软件测试作为整个项目中的重要一环，也要执行详细的测试计划。正所谓运筹帷幄之中，决胜千里之外，强调的就是预先计划的重要性和必要性。

如果没有测试计划，会带来哪些问题呢？

1、很难确切地知道具体的测试范围，以及应该采取的具体测试策略；

2、很难预估具体的工作量和所需要的测试工程师数量，同时还会造成各个测试工程师的分工不明确，引发某些测试工作被重复执行而有些测试则被遗漏的问题；

3、测试的整体进度完全不可控，甚至很难确切知道目前测试的完成情况，对于测试完成时间就更难预估准确的时间节点了；

4、整个项目对潜在风险的抵抗能力很弱，很难应对需求的变更以及其他突发事件。

概述

制定测试计划，是为了确定测试目标、测试范围和任务，所需的各种资源和投入，遇见可能出现的问题和风险，采取正确的测试策略以指导测试的执行，最终按时按量地完成测试任务，达到测试目标。

在制定计划前，测试负责人需要掌握项目的足够信息，比如需要仔细阅读有关资料，包括用户需求规格说明书、设计文档等，全面熟悉系统。

测试计划：描述了要进行的测试活动的范围、方法、资源和进度的文档；确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。

以我司的模板为例，其主要内容如下图：

测试计划目录.png

1、引言

包括文档的目的、适用范围、项目背景以及参考资料。

1.1.文档目的
XXXX.....，本文档将对现有某某业务进行优化的项目测试任务转化为具体的测试计划和说明，是项目在各种测试阶段任务、人员分配和时间安排的工作规范。

1.2.适用范围
本文档介绍了XXX管理优化的测试计划，文档供XXX模块相关的需求人员、开发人员和测试人员使用。

1.3.项目背景
由于业务发展，现有系统功能已经不能有效满足用户需求，需要做一个全新的XXX管理模块，针对新模块的需求说明以及老模块需要沿用的逻辑进行测试。

1.4.参考资料
XXX项目需求规格说明书.docx
http://XX.XX.XX.XX（备注：Demo地址）
XXX开发时间及人员安排

2、测试目标及范围

本次测试内容为新需求文档的说明和XXX管理模块中需要沿用的逻辑以及老数据的兼容，描述被测对象以及主要的测试内容
（需要明确“测什么”和“不测什么”）

比如，用户登录模块，功能测试既需要测试浏览器端又需要测试移动端，同时还考虑登录的安全和并发性能相关的非功能性需求的测试等。

测试范围的确定通常是在测试需求分析完成后进行，所以确定测试范围的过程在一定程度上也是对测试需求分析的进一步检验，这将有助于在早期阶段就发现潜在的测试遗漏。

3、测试策略

明确“测试的重点”，以及“各项测试的先后顺序”（先测什么后测什么）和“如何来测”（采用什么样的测试类型和测试方法）

重要的项先测，而不重要的项要后测。

依旧以“登录”模块为例
“用户无法正常登录”和“用户无法重置密码”这两个潜在问题，对业务的影响孰轻孰重一目了然，所以，应该按照优先级来先测“用户正常登录”，再测“用户重置密码”。

补充说明：测试策略设计能力是指，对于各种不同的被测软件，能够快速准确地理解需求，并在有限的时间和资源下，明确测试重点以及最适合的测试方法的能力，一定是需要在大量实践的基础上潜移默化形成的，是功能测试工程师最核心的竞争力，也是最难培养的。

3.1.功能测试策略
根据测试需求分析的思维导图，采用等价类、边界值、错误推测法等方式来设计测试用例，以及如何准备相关的测试数据

3.2. 兼容性测试策略
XXX项目兼容性测试需要做以下方面：

1. Firefox下进行完整测试；
2. IE和Chrome下主要进行XXX 几种流程、报表查看和导出等测试

测试机操作系统：WIN8，WIN10

补充：对于兼容性测试来说，Web 测试需要确定覆盖的浏览器类型和版本，移动设备测试需要确定覆盖的设备类型和具体 iOS/Android 的版本等。

至于如何确定，可以找产品定，如果产品也定不了的，那么也可以参考市场上的主流使用情况

兼容性测试的实施，往往是在功能测试的后期，也就是说需要等功能基本都稳定了，才会开始兼容性测试。

当然也有特例，比如，对于前端引入了新的前端框架或者组件库，往往就会先在前期做兼容性评估，以确保不会引入后期无法解决的兼容性问题。

兼容性测试用例的选取，往往来自于已经实现的自动化测试用例。道理很简单，因为兼容性测试往往要覆盖最常用的业务场景，而这些最常用的业务场景通常也是首批实现自动化测试的目标。

补充：如需性能测试就可以补上
对于性能测试，需要在明确了性能需求（并发用户数、响应时间、事务吞吐量等）的前提下，结合被测系统的特点，设计性能测试场景并确定性能测试框架。

比如，是直接在 API 级别发起压力测试，还是必须模拟终端用户行为进行基于协议的压力测试。再比如，是基于模块进行压力测试，还是发起全链路压测。

如果性能是背景数据敏感的场景，还需要确定背景数据量级与分布，并决定产生背景数据的技术方案，比如是通过 API 并发调用来产生测试数据，还是直接在数据库上做批量 insert 和 update 操作，或者是两种方式的结合。

最后，无论采用哪种方式，都需要明确待开发的单用户脚本的数量，以便后续能够顺利组装压测测试场景。

性能测试的实施，往往先要根据业务场景来决定需要开发哪些单用户脚本，脚本的开发会涉及到很多性能测试脚本特有的概念，比如思考时间、集合点、动态关联等等。

脚本开发完成后，你还要以脚本为单位组织测试场景（Scenario），场景定义简单来说就是百分之多少的用户在做登录、百分之多少的用户在做查询、每个用户的操作步骤之间需要等待多少时间、并发用户的增速是 5 秒一个，还是 5 秒 2 个等等。

最后，才是具体的测试场景执行。和自动化功能测试不同，性能测试执行完成后性能测试报告的解读，是整个测试过程中最关键的点。

另外也还有很多别的测试类型，比如接口测试、集成测试、安全测试、容量验证、安装测试、故障恢复测试等）

4、测试资源

各个测试阶段的资源分配，软、硬件资源和人力资源的组织和建设，包括测试人员的角色、责任和测试任务。（需要明确“谁来测”和“在哪里测”）

测试人员是最重要的，直接关系到整个测试项目的成败和效率。测试人员的资源通常有两个维度：一是，测试工程师的数量；二是，测试工程师的个人经验和能力。

4.1.服务器环境
不同的项目，可能会使用共享的测试环境，也可能使用专用的测试环境，甚至还会直接使用生产环境。
另外，对于目前一些已经实现容器化部署与发布的项目，测试环境就会变得更简单与轻量级

测试服务器 ： IP地址
集成服务器 ： IP地址
线上服务器 ： IP地址

4.2.网络环境
公司办公网络环境

4.3.测试工具
Bug管理工具： TFS （注：微软源代码管理工具）

5、进度安排

合理的阶段划分，并定义每个测试阶段进入要求和完成的标准。确定各个测试阶段的结束日期和最后测试报告提交日期，制定详细的时间表。
（需要明确各类测试的开始时间，所需工作量和预计完成时间）

5.1.测试进度及人员安排

5.2.具体模块测试用例人员安排
功能点 开始时间 结束时间 测试人员 备注

5.3.输出文档

• 软件测试计划
• 测试用例
• 中间可发布阶段性报告 （项目周期比较长）
• 发布前测试报告

6、发布标准

6.1.测试结束标准
1）测试用例100%执行
2）没有 critical 级别的 bug，没有影响用户正常使用的 bug；
3）完成包含需求内容的功能测试、系统兼容性测试；
4）未修改的bug经过需求确认可以延期修改

6.2.产品发布标准
1）已按照需求文档完全的实现需求；
2）符合交互稿的交互设计规范、符合视觉要求，已经通过设计评审；
3）允许遗留可能会对用户正常使用造成一定影响的 normal 级缺陷，但应在发布前告知项目组，并经风险评估一致同意发布后方可发布

7、风险及约束

潜在的测试风险分析、识别，以及风险回避、监控和管理。
（需要明确如何有效应对各种潜在的变化）

1）上述工作量预估中对需求变更进行了一定的风险覆盖，但如果需求变更超出目前预计，则可能导致编写测试用例和执行测试相关工作量增加、 测试进度延迟
2）开发提交测试版本比该计划延迟的风险，发生此种情况时，执行测试的时间应该合理顺延
3）提交测试版本质量较低的风险，或者开发理解可能导致比该计划更多轮次的回归测试
4）代码版本管理执行不力的风险，发生版本管理混乱的情况时，将只选取 一个稳定版本进行测试，不考虑中间版本的反复测试。一轮测试完成后， 再进行下一稳定版本的回归测试
5）需求不确定，目前还有一些需求还需跟用户确认，需求说明书可能还有没说明到的地方。在测试用例编写期间花费更多精力，尽量将功能细节描述模糊的地方都提出来，并及早确认，否则会对开发和测试进度影响较大

8、测试停止及恢复

1）测试停止准则：开发提交的版本出现导致系统无法测试的BUG，或出现一个严重问题造成50%以上功能都不能进行测试的BUG，即冒烟测试失败；其他项目停止的事件；
2）测试恢复准则：不存在导致系统无法测试的BUG，冒烟测试通过

问题：项目延期，测试计划要不要修改？

如果一般性的延期，可以不修改，如果项目有大改动，有新需求什么的，可以更新，也可以再制定阶段性的计划，总而言之，测试计划要跟项目计划一致

最后补充下测试目标和测试策略

测试目标

为了制定正确的测试目标，需要充分理解用户的需求，将用户的需求转化为测试需求
比如用户要求一个官网在使用时能快速响应，不能出错，转化为测试需求，即为性能测试，接下来再确定具体的目标：多少人同时在线时，响应时间应小于几秒等。
在确定测试目标时，往往需要对软件产品所涉及的业务功能和业务流程进行分析，从而进一步细化测试目标，设计出对应的测试用例来验证各项具体的测试目标是否实现。

测试目标可能会根据预算或时间限制进行调整，如功能测试的不同层次：

• 最低目标：正常的输入+正常的处理过程，有一个正确的输出
• 基本目标：对异常的输入有错误的捕获，并进行相应提示
• 较高目标：对隐藏需求进行测试确定哪些功能特性需要测试、哪些不需要测试，包括功能特性分解、具体测试任务的确定，如功能测试、用户界面测试、性能测试、安全性测试等。

测试策略

根据测试需求和范围、测试风险、测试工作量和测试资源限制等来决定测试策略，是测试计划的关键内容。

一般情况下，不管采用什么方法和技术，测试都是不彻底的，不能够保证被测试程序中不存在遗漏的缺陷。
一轮系统测试过后，如果程序中遗漏的严重错误过多，说明测试是不充分的甚至是失败的，让用户承担隐藏错误带来的风险。相反，如果过度测试，又会浪费很多资源，加大测试成本。
因此，有必要找到一个平衡点，依据软件项目类型、规模以及应用背景的不同，选择不同的测试方案，以最少的软、硬件以及人力获得最佳的测试效果。

在制定策略时，需要综合考虑影响因素，如Tester本身所具有的能力、掌握的测试方法和技术、时间约束等。

如何制定测试策略？
在制定过程中，需要考虑用户特点、系统功能之间的关系、资源配置、上个版本的测试质量、已有的测试经验等因素的影响，找到问题的解决办法，包括采取哪些测试方法、采用什么样的测试工具，需要尽可能地考虑细节。