5.1 制定测试计划

专业的测试必须以一个好的测试计划作为基础。随着用户对软件产品功能需求的不断增加，软件系统的复杂度也在不断地增长。这就导致人们在测试一个系统时需要做更多更复杂的工作。例如，如果一个系统包含成百上千个模块，成千上万个测试案例，有上百条缺陷必须准确的发现和修改。这些工作需要很多人工作一年或更长的时间才能完成，在测试过程中还会出现很多错误，例如经常错误地估计资源和需求，对风险的估计不充分。事实上很多软件公司的资源是很有限的，而项目组又必须满足很多千变万化的需求，因此必须制定详细的，可以扩充的测试计划。

软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和计划，保证有效地实施软件测试。一方面，编写软件测试计划可以帮助人们收集想法、观点和记忆，人们在日常工作中积累了大量的理论知识和经验教训，编写详细的软件测试计划可以把这些知识和经验直接转化为执行任务的具体方法；另一方面，软件测试计划可以促进团队间关于测试任务和过程的交流；最后软件测试计划可以为组织、安排和管理测试项目提供一个整体框架。

测试计划在测试中处于中心位置，它阐述了测试准备工作和执行测试的必备条件，同时也形成了测试过程质量保证的基础。因此，测试计划必须尽可能早地制定，一般在软件需求阶段开始至软件设计的最后完成，并投入使用，在使用过程中还要对测试计划进行必要的监测，监测的任务包括：测试项目是否按照计划执行、测试计划是否需要调整或修改。

5.1.1 测试计划的内容

测试计划通常包含以下内容，企业可能会根据自身情况进行一定的增删。

0. 测试计划特定信息

通常写在正文和目录之前，用以描述测试计划的特定信息。

0.1 概述

用于识别文档并描述其起源和历史。

0.2 文件唯一标识

唯一标识文档的标识符。此标识符可以包括文件标题、发布日期、版本和/或文件状态（例如草稿、审查、更正、最终版）。

0.3 发布单位

指定负责编制和发布文档的组织，还可能包括作者。

0.4 审批人员

确定负责审查和签署文件（可能是电子文件）的指定人员，还可能包括评审员和相关管理人员。

0.5 更改历史记录

包括文档自创建以来发生的所有更改的日志。可能包括一份清单，其中包括文件的当前版本和任何此文件的先前版本、先前版本相关的文件变更描述、变更原因以及变更人的姓名和角色。变更的原因可能包括审计意见、团队审查和系统变更，做出变更的人可能是文件作者、项目经理和系统所有者。

1. 介绍

提供测试计划上下文和结构的说明信息。

1.1 目的和范围

这里的目的是指测试计划文档要达到的目的，例如：理解系统，测试流程，测试期望等。

确定测试计划主题领域的覆盖范围，并描述任何包含、排除、假设和/或限制。

1.2 引用

列出引用的文档并标识系统、软件和测试信息的存储库。这些引用可以分为从组织外部强加的“外部”引用和从组织内部强加的”内部”引用。

例如：

产品需求说明书
产品概要设计
产品使用说明书

1.3 术语

提供文档中使用的术语、缩写和首字母缩写词（如果有）的词典。

例如：

标准用户：本测试项目中定义的标准用户是指登录到被测网站（网站首页）后，间隔10秒（平均值），向网站提交1次页面（二级页面占30%、三级页面占70%）请求的用户。
事务响应时间：指用户发送页面请求开始到接受服务器正确响应之间的时间间隔（精确到毫秒）。

2. 测试计划背景

2.1 项目/测试子流程

确定正在编写计划的项目或测试子流程以及其他相关上下文信息。

可以包含：

产品规格：产品名称、制造商和产品版本号的说明。
产品信息：产品的用户、开发该产品的背景。
技术结构：介绍产品的主要功能，可以借助图表的格式表述。

2.2 测试项

确定本计划所涵盖测试的测试项目，包括其版本/修订版或可找到此信息的参考。本节可能描述测试项目的任务/业务目的，或可以找到该信息的参考。还可以确定将测试项目从其他环境转移到测试环境的任何程序。

2.3 测试范围

总结要测试的测试项目的特征。还确定了测试项目中明确排除在测试之外的任何特征及其排除的理由。

2.4 假设和约束

描述本计划涵盖的测试工作的任何假设和约束。这些可能包括监管标准、测试政策和组织测试策略中的要求、合同要求、项目时间和成本限制，以及适当技术人员、工具和/或环境的可用性。

例如：

假设：（1）需求比较稳定；（2）项目人员按时到位；（3）项目中遇到的新技术例如远程控制能顺利得到解决；
依赖：人员、设备按时到位且很稳定； 
约束：软件需求文档中描述的需求都能实现，保证项目工期。

2.5 干系人

列出干系人及其与测试的相关性。描述如何与每个干系人进行沟通。

3. 测试沟通

描述测试、其他生命周期活动之间以及组织内部的通信线路。这些信息可以直观地表示，也可以可视化表示，可以包括组织结构图或说明信息和数据流的图。

4. 风险登记

确定本计划涵盖的测试所考虑的风险。这应包括组织测试策略中可能规定的任何相关风险。根据风险的影响和概率，为每个风险计算风险等级水平并提供处理风险的建议。

1) 产品风险

识别与测试相关的产品风险，并提供处理每个风险的建议。与测试相关的产品风险可能包括功能缺陷或性能等非功能方面的缺陷。

2) 项目风险

识别与测试相关的项目风险，并提供处理每个风险的建议。

例如：

其中概率和影响可以设置为1-5，风险等级 = 概率 x 影响。

5. 测试策略

描述指定测试项目或测试子流程的测试方法。确定测试策略要从模块、功能、整体、系统、版本、压力、性能、配置和安装等各个方面来考虑。可参考组织测试策略。

1) 测试子流程

对于项目测试计划，它确定了将要进行的测试的子流程。

2) 测试可交付成果

确定测试活动交付的所有文件或电子记录的等效信息，例如数据库或专用测试工具。测试输入数据和测试输出数据可以确定为可交付成果。作为测试活动的一部分，创建的测试工具也可能包括在内。如果文件已合并或删除，则此列表将相应修改。本小节可能包括文件应交付的时间，以及交付对象（最好是职位，而不是姓名）。

其中需要交付的文档含测试计划中包括的模板以及要求测试团队提交的相关文档：

• 测试用例：提供测试用例模板（确定测试用例编号规则等信息）。
• 测试用例执行情况记录。
• 测试日志：提供测试日志（或工作周报）模板和提交规定。
• 缺陷报告：使用缺陷跟踪系统（产品类型、版本等）还是使用电子文档缺陷报告（包含哪些内容），确定严重程度和优先级别如何划分（有些测试计划中会给出示例）。
• 测试总结：提供缺陷总结模板。

3) 测试设计技术

指定要应用的测试设计技术。

4) 测试完成标准

描述相关测试组织认为测试执行活动已完成的条件。例如，当达到特定的覆盖范围并且未解决的缺陷数量低于规定的限制时，即认为对应的测试活动已经完成。

5) 要收集的指标

描述测试活动期间要收集其值的指标。

6) 测试数据要求

指定项目或测试子流程（视情况而定）的所有相关测试数据要求。需要确定测试数据的来源，并说明特定测试数据的位置，是否出于保密原因必须对数据进行伪装，和/或负责测试数据的角色。

7) 测试环境要求

指定测试环境的必要和所需属性。这可能包括硬件、软件、测试工具、数据库和人员（视情况确定其组织）。包括有关选择、评估、获取和支持每种工具的信息。它可能包括测试准备、测试执行（包括数据捕获）和任何执行后活动的测试环境需求。

8) 重新测试和回归测试

指定将执行重新测试和回归测试的条件。这可能包括对估计试验循环次数的描述。

9) 暂停和恢复标准

指定用于暂停和恢复测试计划中所有或部分测试活动的标准。确定谁负责暂停和恢复测试活动。指定恢复测试时可能必须重复的测试活动。

10) 偏离组织测试策略

记录偏离组织测试策略的任何测试计划内容。确定负责批准偏差的机构（如适用）。

6. 测试活动和估计

根据要使用的测试过程，确定所有必要的测试活动。应考虑重新执行测试活动的迭代策略以及任何依赖项。描述作为测试计划涵盖的测试活动的一部分，将要执行的每个确定测试活动的估计。此外，在适当的情况下，描述分配的测试预算和成本估算。

7. 人员配备

描述本计划涵盖的测试人员配备要求。

1) 角色、活动和职责

概述担任测试相关角色的主要人员（他们是活动负责人）和次要人员（他们不是负责人，但提供支持），以及他们在测试活动中的相应职责和权限。此外，确定负责提供测试项的人员，他们可能是全职或兼职。人员可能包括项目经理、测试经理、开发人员、测试分析师和执行人、运营人员、用户代表、技术支持人员、数据管理人员和质量支持人员。对于每个测试人员，指定需要该人员的时间段。

2) 招聘需求

确定测试项目或测试子流程所需的其他测试人员的具体要求。指定何时需要员工，员工是临时的、全职的还是兼职的，以及所需的技能集。这些可能由合同和业务需求定义。人员配置可通过内部调动、外部招聘、顾问、分包商、业务合作伙伴和/或外包资源完成。

3) 培训需求

按技能级别指定测试培训需求，并确定为所需员工提供必要技能的培训选项。培训可以采取多种形式，包括传统课堂培训、基于计算机的自定进度培训、互联网培训、访问未来用户网站以及由知识丰富的员工指导等选项。

8. 计划表

确定项目进度表和测试策略中定义的测试里程碑。总结测试活动的总体时间表，确定活动结果反馈给开发的位置，组织和支持流程。基于活动估计、可用资源和其他约束，指定每个测试活动和测试里程碑的计划。

计划测试进度和人员安排要考虑：

测试需求范围。
开发进度的变化，需求或设计的变更。
开发组的版本控制。
记录当前项目每项任务实际花费的人员和时间。
测试时间不够，主要是功能冻结后的系统测试的时间可能不够。
测试资源是否能及时到位（设备和人员）。
考虑测试组织的测试成熟度。
商业知识，市场的压力。
测试程序的范围。
测试工作的启动。
软件计划升级的版本个数。
里程碑事件的设置。
风险和问题。

测试人员的任务分配需要考虑：

测试工程师的技术水平。
使用测试工具的熟练程度。
测试人员的培训。

对任务，风险，工期等做评估，常用以下评估技术进行：

直觉或猜测。
早期的指标。
基于公式。
专家共识（Delphi）。
三点法。

任务，工期的评估要客观，达成一致。避免不现实的任务时间表：

5.1.2 正确认识测试计划

测试计划的最终用户

测试计划的最终用户一般是研发团队。

测试计划有时作为产品提交给用户（特殊需求、军方、外包测试用户）。

关于测试计划的格式和内容

用户是研发团队：测试计划的价值取决于它能在多大的程度上帮助管理测试项目和帮助发现错误。千万不要为了写测试计划而写测试计划，测试计划务必能指导测试工作，切实具有可用性。简单的套用模版，没有意义。

用户是特殊用户：按用户要求填写。