测试计划的重要性与制定步骤-优快云博客

本文链接：https://blog.youkuaiyun.com/igoone/article/details/7010922

1、为什么要做测试计划

计划：是指导和引向我们达到目标时的准备和策略

测试计划：说明了测试从开始到结束所要思考的步骤

有计划的步骤减少了测试的随意性，避免遗漏和意外

2、计划开始和重要性

软件测试的一个关键原则是，在一个产品的生命周期中，尽可能紧密地将开发过程和测试过程集成在一起。

从开始在需求提取和分析阶段，发现需求中的缺陷，以及通过参与需求过程，尽可能早地收集规格说明，用于测试计划工作。

从项目预算和时间进度安排的角度来看，测试工作量估计和时间的有效性可能影响整个测试工作的成败

3、测试计划活动

确定测试范围和策略
确定测试架构
确定项目管理机制
预估测试工作量
评估风险并准备风险缓解计划
准备并复查测试计划文档

4、计划活动流程

计划开始是确定一个高层次的测试策略，然后加入更多的细节，描述测试的架构，测试的环境和测试用例，直到得到一份完整的测试计划

在测试计划被写成文档并获得批准之后，制定计划的工作仍未停止，因为可能会出现需求变更、时间进度要求的变更或其他变更，这些变更要求测试计划作相应的调整

测试计划应该在整个产品开发过程中进行维护，它是一份有生命周期的文档

它应该保存在一个安全的位置，并进行版本控制。

5、测试范围和策略

第一步：测试范围

建立一个高层次的测试策略：总体的测试范围、用于发现缺陷的测试方法学、控制测试活动的进入/退出标准
把测试活动与开发生命周期进行对照
制定总体策略时，同时考虑静态测试和动态测试
自动化策略作为整体测试策略的一部分
通过评估产品需求文档，确定需要测试哪些东西，来确定测试的范围。

列举每个开发阶段相联系的静态和动态测试方法。

描述测试团队需要得到的每个输入/输出的工件。

确定每个测试阶段的进入和退出标准，以及所有需要测试团队参加的质量检查点。
如果打算采用自动化技术来支持任何一种测试活动，就需要确定一个自动化策略
重要问题：这个产品有多少是可测试的？
测试过度：
测试范围的冗余
花费太多时间来测试产品
项目的时间进度将存在风险
测试不足：
说明测试范围不够大
你的风险将是测试逃逸以及巨大的后续修复支出
取得正确的平衡
与经验有关，也与对测试的成败进行度量有关

第二步：测试策略

根据需求的优先级安排测试活动
高优先级的需求

对用户来说最重要的需求

失效时对用户影响最大的需求

时间进度和资源允许时：测试所有需求

缺少时间或资源时：

充分测试优先级最高的需求

征得用户的同意，把那些只经过部分测试或未测试的需求留到下一个版本再支持
优先测试新功能和修改过的旧功能
经验法则：

如果代码被动过了，就应该测试它

初次发布的产品，所用的东西都是新的，

升级发布或补丁发市，应该对新代码给予特别关注

注意：

对代码的任何改动都可能对那些人们认为“没动过”的代码产生破坏效果

最好是在进行改动时，对程序的所有功能尽可能频繁地运行回归测试
使用各种测试设计技术
使用各种测试设计技术来减少测试工作量

等价类划分

边界值分析

因果图

判定表

场景法

在测试部分程序的输入/输出时，可以通过这些技术来选择输入值的一个子集，达到将测试覆盖范围最大化的目的，并提高测试的效果
减少测试工作量
提高测试效果
测试最有可能出问题的地方
正如软件测试原则里的“错误集中发生现象”

在需求中发现的错误应用到计划中
关注用户常用功能和配置
从需求中理解和分析、寻问客户方代表或者公司项目分析人员，也可以参考以前的系统和以前的文档。

还有另外一种让系统测试变得更为有效的方式，即在代码提交给测试团队之前，让开发团队进行全面的单元测试和集成测试，防止将不能工作的代码提交给测试团队，就会大大节省系统测试的时间。

6、测试方法

确定测试方法从检查开发过程生命周期的每个阶段开始，通过这种检查来确定每个阶段所使用的静态或动态的测试。

采用瀑布式、螺旋式或迭代式发布的生命周期模型都无关紧要，任何生命周期模型的组成阶段都可以进行检查，以确定有效的测试方法

7、确定测试标准

确定测试标准的目的是为控制测试的流程设置一些规则

测试标准应该在测试开始之前确定

测试标准会对其他团队产生影响

由测试团队和所有受影响的团队讨论而得到

系统测试前的四类标准

进入标准

描述了在开始测试之前需要做些什么工作或达到什么要求

确保进入标准得到满足的一种方式是进行系统测试准备复查

退出标准

描述了在怎样的情况下可以结束测试

退出标准看起来应该像这样：“所有计划的测试已被运行，所有被修复的缺陷已经得到验证，所有新发现的缺陷已报告。与计划不一致的地方，例如因为设备问题而未能执行一组测试，已经写入文档。”

测试结束时应按照退出标准进行复查，以确保所有的测试都已完成，并根据测试结果来评估产品是否已准备好发布

暂停／继续标准

描述了在什么样的情况下要暂停测试

以及什么样的情况下再继续测试

通过／失败标准

描述判断测试通过的要求

以及如何算测试是失败的

根据实际情况制定其它的标准

8、确定自动化策略

进行有效的自动化测试

有效的自动化测试基于正确的计划和合理的期望
需要重复进行的活动都是自动化要考虑的候选对象
自动化测试有它自己的完整而独立的生命周期
有效的自动化需要培训，开发，调试和验证

无规划的自动化测试

对资源的浪费
对时间进度产生负面影响（大量时间浪费在调试上）

9、确定测试架构：测试架构（广义）包括

测试的环境（软/硬）
测试环境的组成包括物理测试设施，产品运行的操作系统，产品运行的计算平台等和测试的办公环境等。一些公司拥有专门为测试而建造的实验室，提供一个受控的测试环境，软件系统能够在定义良好的、可重复的条件下接受测试

包括：

硬件要求：各种不同配置的硬件及其数量。

网络要求：测试时所需要的网络环境。

软件要求：测试时所需要的软件产品。

办公场所要求：进行测试时所需要的场地要求

测试的架构

测试架构是指测试用例的组织结构

良好的实践方式：将测试进行合理地组织，让每项测试单独对应软件功能的某个特定部分

基于测试需求的测试可以产生良好的测试组织形式

一组相关的测试被称为一个测试套件（TestPackage / Test Suit）或测试集（Test Set）

级别	定义
测试套件	一组测试，用于验证一组相关的需求或功能
测试	一个或多个测试用例，关注一项需求或功能
测试用例	最小的测试单元，可以从头至尾独立的执行

测试架构的管理：

需要一种版本控制的方式来进行管理，以便随时可以重复得到这些测试。

这种存放机制应该具备如下一些特征：

所有开发和测试执行人员都应该能够访问它

经常性的备份，备份文件应该定期地恢复，已验证备份/恢复的功能可以正常发挥作用。所有测试计划、测试用例和测试结果都需要备份，尽管这一点很明显，但有时却被人们所忽略

应该具有版本控制功能，这样就容易地得到以前的测试

测试的配置
如果被测系统需要在不同的配置环境下运行，则需要指定在该测试项目中要测试的配置列表

制订配置列表时需要将各种不同的配置进行组合搭配，考虑以下原则：

先硬件后软件：先根据硬件和网络配置进行分组，然后再进行软件配置

先系统后应用：进行软件配置时，先根据操作系统分组，然后再根据测试所需要的应用程序分组

10、确定项目管理机制

软件测试项目是一个协同工作的典型，整个项目中有众多的人员和部门参与，包括测试人员、开发人员、项目管理人员、用户等

如何保证整个项目过程中所有人员都能够按照一致的方式工作、处理各自的分工、进行有效的沟通、控制项目的进展等等，都需要所有人在同样的管理机制和指导方针下进行

确定一个共同遵循的项目管理机制就是保证整个项目正常、有序的进行基础

包括但不限于以下各个方面：

管理结构

在软件测试项目中，测试团队需要有自己的管理结构和角色分工

建立合适的测试项目管理结构，有利于项目的管理和实施

报告机制

很多的项目信息仍然需要通过整理、汇总并上报才能有效地传达给项目管理人员和公司管理人员，从而帮助更加有效的管理和控制整个项目的进展。

报告机制主要包括几个部分：

报告类型：测试项目中有多种不同类型的报告，包括测试人员的定期工作报告、测试项目定期报告、项目阶段报告等
报告人员：包括报告的角色和接受报告的角色，要详细定义每种类型报告的报告角色、接收者和抄送者等
报告要求：包括报告内容和格式的要求
报告周期：定义各种报告的报告周期，是日报、周报、月报、阶段还是不定期的

沟通机制

由于测试项目的参与方不同，需要对各方之间的沟通机制进行定义并实施，才能保证各方能够及时、有效地沟通

沟通主要来自于两方面：

内部沟通：测试团队内部会议、交流等的方式。包括发起责任人，参与者，发起周期、主要范畴和产出等

外部沟通：测试团队与开发、用户之间的会议、交流等方式。包括发起者，参与者，协调者，发起周期、主要范畴和产出等

根据项目实际情况的要求，可能需要其他相关的管理方面的要求和机制，可以根据实际情况来制定

11、测试计划的关键的部分

预估测试工作量

1）确定要完成的任务。
2）确定每项任务所需工作量和整个测试生命周期的工作量。第1步中确定的每项工作都有一定的工作量，表明完成该项任务需要多少工作。工作量是人数和时间的乘积，其测量单位是人天或人月等。预估工作量有许多不同的方法，可以根据实际情况选择相应的方法。
3）确定完成每项任务以及整个测试生命周期所需的时间
执行任务所需的时间可以用天、周、月来计算
完成任务所需的时间取决于为工作分派的人数
人数和时间之间的关系不一定是线性的
测试工作所需的总时间将取决于各个独立任务所需的时间，而非简单地相加，因为某些任务可以并行地执行。

4）建立详细的时间进度计划和里程碑表

将前面三步的结果综合起来，得到一份时间进度计划

用甘特图（Gantt chart）来表示

5）评估时间进度风险并准备应对计划

预计在分配的时间内完成关键任务可能会遇到的问题，评估其风险并计划如何处理这些问题

常见风险举例：

在开始测试时，所需的硬件还没有到位

在开始侧试时，要测试的软件还没准备好

在开始测试时，测试用例还没准备好

在开始侧试时，进行测试的人员还没准备好

在测试开发或进行测试的过程中发生了需求变更

在测试开发或进行测试的过程中发生了用户界面的变更