全程软件测试（十一）：测试计划的主题——读书笔记

大型软件项目的项目经理和测试负责人一般都在现成的测试计划模板上剪切、复制、查找或替换，最终得到当前项目“专用”的测试计划。但如此创建出的测试计划若没有抓住重点，可能导致其他人不清楚测试人员的意图，使测试项目出现弊端。

如果没有测试计划模板，就需要遵循一系列重要主题的清单，该清单应该在整个项目小组中深入讨论并达成一致。此清单也许并不适用于所有项目，但是它列出了一系列常见的并且与重要测试相关的问题，所以比测试计划模板更实用。计划本质上是一个动态过程，因此若发现列出的问题不适应具体情况，可以自行调整。

测试计划过程的结果是一种文档。软件测试文档标准IEEE 829-1998推荐了一种常用格式。若行业或者公司需要有自己的标准，格式可以预先定义。不论采用何种格式，文档都应该达到能够非常有效地交流工作的目的。

定义

让项目小组中的全部成员在高级期望和可靠性目标这两者上达成一致是一件很困难的事情，而这只是在软件项目中定义用词和术语的开始。

1.软件缺陷的定义

（1）软件未实现产品说明书要求的功能。

（2）软件出现了产品说明书指明不应该出现的错误。

（3）软件实现了产品说明书未提到的功能。

（4）软件未实现产品说明书虽未明确提及但应该实现的目标。

项目小组中最大的问题之一是忽视产品开发中常用术语的含义。程序员、测试员和管理部门对术语都有自己的理解。如果程序员和测试员对软件缺陷定义的基本理解未能达到一致，争论在所难免。测试计划需要对小组成员的用词和使用的术语进行定义，消除理解差异，使全体成员的说法一致。

2.常用术语的定义

以下是一些常用术语和简单的定义，不要将其看作完整或定义明确的清单。术语定义取决于具体项目、开发小组遵循的开发模式，以及所有小组成员的经验。此清单所列术语只是举例说明，帮助学习者理解术语定义的重要性。

（1）构造：程序员将需要测试的代码和内容放在一起。测试计划应该定义构造的频率（每天、每周等）以及期望的质量等级。

（2）测试发布文档：程序员发布的文档。对每一个构造都声明新特性、不同特性、修复问题和准备测试的内容。

（3）α（Alpha）版：适用于对少数主要客户和市场进行数量有限的分发，用于演示目的的早期构造，不适用于实际环境。使用Alpha版的全体人员必须了解其确切内容和质量等级。

（4）β（Beta）版：适用于向潜在客户广泛分发的正式构造。

（5）说明书完成：说明书预计完成并且不再更改的日期。在实际项目中，说明书通常在该日期后还会做修改，但是它确实需要设定，其后只能进行控制范围内的小改动。

（6）特性完成：程序员不再向代码增加新特性，并集中安排修复缺陷的日期。

（7）软件缺陷会议：由测试经理、项目经理、开发经理和产品支持经理组成的团队，每周召开会议，审查软件缺陷，并确定需要修复的缺陷以及修复方法。软件缺陷会议是在测试计划中建立质量和可靠性目标的主要方式之一。

高级期望

高级期望是指测试小组成员一致通过的最高测试要求的目标值。测试过程中的第一个论题是定义测试小组的高级期望。这虽然是项目小组全部成员必须达成一致的基本论题，但却常常被忽视。人们认为它显而易见，并且想当然地假定每个人都了解。但是，优秀的测试人员永远不应该假定任何事。

人、事和地点

测试计划需要明确项目需要的人员、人员的分工以及所有成员的联系方式。整个项目从想法雏形到最终成型都需要各小组成员之间的紧密联系，合理的交流可以提高整个项目的实现效率，因此测试计划应该包括项目中所有主要人员的姓名、职务、地址、电话 码、电子邮件地址和职责范围。

测试计划需明确文档存放的位置、所需软件的下载地址、测试工具的下载地址等。如果在执行测试时硬件不可缺少，则硬件的获取方式和放置地点都需要明确。如果有进行配置测试的外部测试实验室，那么它们的位置和进度的安排也需要明确。

团队之间的责任

一些任务不像测试员、程序员的工作那样边界清晰，复杂的任务可能会涉及多个责任者，某些任务没有责任者，或者由多人共同负责。交流计划和计划这些任务最简单的方法就是使用下表所示的表格。

测试简表

续表

在上表中，“×”表示任务的责任者，“—”表示任务的参加者，空白表示不负责该任务。确定表格第一列中的任务要靠经验，在一般情况下，小组中经验丰富的成员可以先大致浏览一遍清单，然后根据具体项目以及团队之间的关系，补充被忽略的任务。

测试的侧重点

有时软件产品中的某些内容没有必要进行测试，这些内容可能是先前发布过或测试过的软件部分。其他软件公司测试过的内容可以直接接受，外包公司也会提供预先测试过的产品部分。

计划过程就是检查软件的每一部分，确定它是否需要测试。如果不必测试，则需说明理由。如果由于理解上的错误而使部分代码在整个开发周期中都未做过任何测试，就可能导致十分严重的后果。

资源的需求

计划资源需求是确定实现测试策略必备条件的过程。在项目期间需要考虑可能用到的任何资源，列举如下。

（1）人员：人员的数量、经验和专长，工作类型是全职、兼职还是实习。

（2）设备：计算机、测试硬件、打印机、工具。

（3）办公室及实验室空间：位置、面积、格局。

（4）软件：文字处理程序、数据库程序和自定义工具，需要购买的资源和编写的材料。

（5）外包测试公司：是否用到外包测试公司，选择原则和费用。

（6）其他配备：参考书、电话、培训资料以及项目中需要用到的设备。

一些特定的资源需求取决于项目、小组和公司，因此测试计划工作要仔细估算测试软件的要求。在测试开始之前就做好项目预算，可以避免到项目后期获取资源困难，甚至无法获取资源，因此创建完整的清单是非常必要的。

测试的阶段

在计划测试的阶段时，测试小组分析预定的开发模式，从而决定在项目期间是采用一个测试阶段还是多阶段测试。在边写边改的模式中，可能只有一个测试阶段，不断测试直到某个成员宣布测试停止。在瀑布和螺旋模式当中，从检查产品说明书到验收测试可能会有很多阶段，测试计划也属于其中一个阶段。

测试小组在测试的计划过程中应该明确每一个预定的测试阶段，并通知整个项目小组。该过程一般有助于所有小组成员了解全部的开发模式。

注意：

进入和退出规则是与测试阶段相关联的两个重要概念。测试小组不能只依照日期来决定是否进入下一阶段。测试的每一个阶段都必须有客观定义的规则，用来明确地声明本阶段结束，下一阶段开始。例如，真正意义上的 Beta 测试阶段可能从测试员完成验收测试后，从预定的Beta测试结构中没有发现新的软件缺陷时开始。因为有意义的 Beta 测试是更加偏重于用户的测试，一切设计好的测试往往带有局限性，无法体现真实的问题。如果没有明确的进入和退出规则，测试工作就会变得单一，且毫无头绪。

测试的策略

与定义测试阶段相关联的是定义测试策略。测试策略描述测试小组用于测试整体和每个阶段的方法。面对需要测试的产品，需要决定使用黑盒测试，还是白盒测试。如果决定二者综合使用，需要清楚在软件的何时何处运用它们。

某些代码采用手工测试，而有些代码用工具自动化测试效果更好。如果要使用工具，就要看是否需要开发，或者是否能够买到已有的商用解决方案，也许还可以采用更有效的方法，就是把整个测试工作外包到专业的测试公司，只需安排一名测试员监督工作即可。

做决策是一项十分复杂的工作，需要由经验特别丰富的测试员来完成，同时必须使项目小组的全体成员都了解并同意预定计划，因为这关系到测试工作的成败。

测试员的任务分配

只要定义了资源需求、测试阶段和测试策略，创建了产品说明书，就可以为每位测试员分配任务。前面讨论的团队之间的责任，实际上是指每一个功能性团队（管理团队、测试团队和开发团队等）必须负责与其对应的高级任务。计划测试员的任务分配是指明确各测试员负责软件的哪些部分、哪些可测试特性。简化的文档处理程序的测试员任务分配表如下表所示。

文档处理程序的测试员任务分配表

真实的责任表会更加详细，确保软件的每一部分都有测试员进行测试。每一个测试员都会清楚地了解自己所负责的内容，而且有足够的信息用于设计测试用例。

测试进度

计划测试进度需要将以上所述的全部信息映射到整个项目进度中。通常，预估测试进度在测试计划工作中至关重要，因为原以为很容易设计和编码的一些必要特性可能后来测试需要花费大量时间。

例如，某程序在不明显的有限区域之外将不执行打印，没有人注意到打印对测试所产生的影响，从而使该特性保留在软件产品中，结果致使打印机配置测试要花几周时间才能完成。测试进度安排是测试计划的一部分，它可以为产品小组和项目经理提供信息，让他们更好地安排工作。他们甚至可能根据测试进度安排来决定将产品的某些特性去掉，或将其移至下一个版本。

测试工作通常不能平均分布在整个产品的开发周期中，这是关于测试计划的另一个重要问题。有些测试工作以说明书、代码审查以及工具开发等形式在前期进行，但测试任务、参加测试的人员的数量和测试所花费的时间会随着项目的进展而不断增长，在该产品发布之前形成一个短期的高峰。下图所示为典型的测试资源图表。

测试资源图表

由上图可以明显看出，项目中的测试资源随着开发的进度而增长，而持续增长的结果是测试进度受项目中先前事件的影响越来越大。如果项目中某一部分交给测试小组的时间推迟了2周，而按照进度只有3周测试时间，就只能把3周的测试在1周内进行，或者把测试进度推迟2周，这被称为进度破坏（Schedule Crunch）。

可采取避免将任务的启动和停止日期定死的方式来解决进度破坏问题。下表所示的测试进度通常会使小组陷入进度破坏。

固定日期的测试进度

相反，如果测试进度依照测试阶段所定义的进入和退出规则采用相对日期，既指明了测试任务依赖于其他先完成的可交付内容，单个任务所需时间也很明显，如下表所示。

相对日期的测试进度

许多进度安排软件会使这项工作更加轻松，项目经理和测试经理在安排进度时可能会使用此类软件，但同时要求测试员参与安排自己的具体任务。

测试用例

请期待下一期~

软件缺陷 告

请期待下一期~

风险和问题

明确指出项目的潜在问题或者风险区域，这是测试计划中非常实用的部分。

如果有十几个毫无实战经验的测试新手，让他们去测试新建医院的软件，这就是风险。如果某个新软件要用市面上销量前100位的手机进行测试，项目时间却只够用其中70种手机进行测试，这又是一个风险。

软件测试人员需明确指出测试过程中的风险，并与测试经理和项目经理进行讨论，交换意见。这些风险应该在测试计划中列出，在进度中给予一定说明。其中有些是真正的风险，而有些最终被证实无关紧要。为避免在项目晚期造成损失，这些风险必须尽早指出。