测试计划（计划）

项目测试计划目的是在一种有组织的方式下，为完成测试打好基础。从管理的角度来看，测试计划是最重要的一份文档，因为它帮助我们管理整个项目。如果全面而谨慎地设计一份测试计划，那么测试的执行和结果分析过程将会非常顺利。（参见E.1节，一个单元测试计划的例子；E.4节，一个系统测试计划的例子；F.24节，用来检验单元测试是否彻底和全面。）

测试计划是一个不断更新的文档，尤其是在螺旋式环境中，因为系统在不断的变化。因此系统改变时，测试计划也要随之改变。一份好的测试计划应该具有下列特点。

l    有机会发现大部分缺陷。

l    为绝大部分代码提供测试覆盖。

l    具有灵活性。

l    可以很容易地执行、能够自动化地执行、具有可重复性。

l    定义要执行的测试种类。

l    清晰地记录期望的测试结果。

l    当发现缺陷时提供缺陷修改时间。

l    清楚地定义测试目标。

l    阐明测试策略。

l    清楚地定义测试结束标准。

l    没有冗余。

l    识别出风险。

l    记录测试需求。

l    定义测试交付物。

我们有很多方法编写测试计划，图12-1为我们展示了一个框架，其中包括了基本的测试计划中要考虑的绝大部分事项。可以把它当做测试相关条目的一个检查表。这些条目中的部分内容明显是必需的，例如定义测试需求和测试团队；而有些条目可能就不一定需要，这取决于项目的特性以及时间约束。

规划测试方法包含以下3个步骤：建立项目测试计划，定义度量标准，评审和批准项目测试计划。这3个步骤可以分解为各自相关的一系列任务，如图12-1所示。

建立 测试计划

计划的评审和批准

定义 度量目标

建立缺陷报告/跟踪规程

确定测试结束标准

定义总体功能需求

获得批准

评审的日程安排/执行

定义度量标准要点

定义度量标准

定义批准规程

建立报告规程

定义项目问题解决规程

定义配置构建规程

建立版本控制规程

建立变更请求规程

选择测试工具

创建测试进度表

确定测试种类

定义依赖关系

搭建测试环境

定义测试交付物

制定回归测试策略

组建测试团队

准备引言部分

（步骤）

（任务）

图12-1  测试规划（步骤/任务）

12.1.1  任务1：准备引言部分

测试计划详细内容的第一部分是对将要在相关机会应用中解决的问题的描述。这部分定义了项目的简要背景，描述了促成系统开发决策的事件或当前状态。同时，在引言部分中还应给出应用程序开发的风险、用途、目的和收益，以及整个团队的评价成功的因素。关键成功因素是一个度量项，对于评价一个主要功能是否达到了预期目标起着决定性的影响。目标是整个团队经过努力达到的一个可测量的最终状态。目标的例子包括下面一些。

l    新的产品机会。

l    效率的提高（内部的和外部的）。

l    组织的形像。

l    成长过程（内部的和外部的）。

l    经济方面（收入、成本收益率）。

l    竞争位置。

l    市场领先。

引言部分中同样需要包含关于管理的概要描述。项目发起人是对整个项目拥有最终决定权的一个角色。这个角色在如下方面对于项目拥有授权：项目资金、项目结果、解决项目冲突问题等，还要对整个项目的成功负责。一个管理概要描述了从管理者角度看到的一个适当的应用程序。应当描述将要解决的问题、应用程序的目标、商业机会等。在目标中应当指出该应用程序是否是对旧系统的替代，同时该应用程序可能在管理、技术等方面对整个团队产生影响，如果有影响也要记录下来。

应当列出所有可能用到的文件都并且描述出状态。举例来说：需求规约、功能规约、项目计划、设计规约、原型、用户手册、业务模型/流图、数据模型、项目风险评估等。项目风险是对于项目开发的潜在不利影响，这里我们还应列出跟测试活动相关的项目风险。举例来说：测试技能的缺乏、测试工作的范围、自动测试工具的缺乏以及其他一些类似的风险。更多详细内容参见E.4节（客户端/服务器架构和因特网螺旋测试）。

12.1.2  任务2：定义总体的功能需求

功能规约由以下各部分组成：功能的层次分解、功能窗口结构、窗口标准以及待开发系统的最低运行需求。窗口标准的一个例子是Windows 95的图形用户界面标准。最低运行需求的例子：Windows 95、奔腾二代的微处理器、24MB内存、3GB硬盘空间、一个调制解调器。开发工作进行到这里，一个完整的功能规约还没有被定义出来。我们还需要关于基本窗口结构的最少业务功能的一个清单。

一个基本的功能列表包含系统的主要功能，每个功能都要以“动宾”结构风格命名和描述。这个列表作为构建功能测试的基础（见图12-2）。

图12-2  总体业务功能

功能窗口结构描述了在窗口环境中如何实现功能。这个时候，完整的功能窗口结构也许还没有，但是一个主要窗口的列表应该已经有了（见图12-3）。

图12-3  功能窗口结构

12.1.3  任务3：确定手动/自动测试的种类

测试种类的设计和执行完全取决于应用程序的目标，也就是整个团队一直努力达到的可测量的最终状态。举例来说，如果是一个金融方面的应用程序，有大量的用户将要使用这个系统，那么我们就需要进行特别的安全性和可用性测试。无论如何，有三种类型的测试是几乎任何应用程序中都需要的：功能测试、用户接口测试和回归测试。功能测试占测试工作的一大半，主要关心功能是否能够正确地执行。这是一个基于黑盒模型的测试，测试者完全不关心应用程序内部的行为和结构。用户接口测试，或者称为图形用户界面测试，检查用户交互功能或者功能窗口结构。它保证对象状态与功能有适当的依赖关系，并且在各功能之间提供了有用的导航。回归测试根据在调试、维护或者新版本发布时所做的更改对应用程序进行测试。

其他需要考虑的测试类型包括系统测试和验收测试。系统测试是对整个系统功能性、性能表现和整体使用性的最高层次的测试和评估。验收测试是一个由用户执行的可选测试，目的在于证明应用程序的能力满足了用户的需求。这个测试是否执行取决于项目的形式。有时系统测试已经足够了。

最后，我们需要定义能够使用测试工具自动执行的测试。自动测试有三点好处：可重复性、杠杆作用、便于增加功能。可重复性保证了测试可以反复执行多次，每次执行都保持一致。杠杆作用来自于先前测试的可重复性以及可以使用工具来安排执行测试的过程，这是自动测试独有的特色。随着应用程序的不断更新，越来越多的功能点被添加进来。使用自动测试，功能点的覆盖通过测试库来维护。

12.1.4  任务4：确定测试结束标准

最困难的也最具有政策性的问题就是决定何时停止测试，因为我们不可能知道何时能够发现所有的缺陷。我们至少有如下4个结束测试的标准。

(1) 计划的测试时间期满——这个标准是很弱的，因为它与验证应用程序的质量无关。这个标准根本没有考虑也许测试用例不够充分或者也许不再有可以轻易发现的缺陷了。

(2) 发现了预先确定的缺陷数量——这个标准的问题在于如何估计能够发现的缺陷数量以及可能会过高地估计缺陷数量。如果缺陷的数量估计得不足，那么测试就会不完整。可能的解决方案包括根据同一支开发团队开发相似应用程序的经验、预测模型以及行业的平均情况等。如果缺陷的数量估计得过高，那么也许测试工作在合理的时间范围内就永远不会完成。一个可能的解决方法是估计完成时间，在图上标示出单位时间发现的缺陷数。如果发现缺陷的速度明显减慢了，这也许就是一个“完结”点，指示出绝大部分的缺陷已经被发现了。

(3) 执行所有的正常测试都不再发现任何缺陷——这个标准的主要问题是，在这种方式下，测试人员不会很主动地去设计破坏性的测试用例，以促使被测程序达到它的设计极限。举例来说，当测试程序不再发现缺陷的时候，测试人员的工作就完成了。测试人员期望不要发现缺陷，而且可能下意识地去设计那些能够表明程序已经没有缺陷的测试用例。当我们有一组严格的、非常全面的、接近百分之百覆盖的测试用例时，这个标准是有效的。这个标准的问题就是确定何时我们拥有一套完整的测试用例。如果觉得这样就可以的话，这时一个好的策略是继续进行随机测试。随机测试通常是黑盒测试技术，测试人员完全放开自己的思维，在头脑中列举尽可能多的测试场景。经验告诉我们这项技术是非常有用的附加性技术。

(4) 以上3项的结合——大部分测试项目都利用了以上3个结束标准的结合。我们建议所有的测试都应该被执行，但是随机测试应该根据项目的进度情况来安排。

12.1.5  任务5：制定回归测试策略

回归测试是根据螺旋开发过程、调试、维护或者新版本发布时所做的变更对应用程序进行的测试。这种测试应该在系统的功能更新或修复已经完成之后进行，以保证我们所做的变更没有产生预计之外的影响。比如对如下错误的更改必须要进行回归测试：逻辑和控制流的错误、计算错误、接口错误等。界面（比如图标）错误一般来讲不会影响其他的功能因而不需要回归测试。

对于每次螺旋过程，测试集合中的所有测试都能重新执行一遍是最理想的，但是由于时间的限制，一般来讲是不能实现的。在螺旋开发过程中，比较好的回归测试策略是每次螺旋过程都执行一些回归测试，这些测试要确保后面的螺旋开发或者错误更正没有影响先前演示的功能。在系统已经稳定和所有功能已经被确认之后的系统测试里，回归测试应该由系统测试的一个子集组成。我们需要一套策略来决定应该包含哪些测试用例（参见E.21节）。

再测试矩阵是一个非常好的工具，如表12-1所示，它将测试用例和功能（程序单元）联系起来。矩阵中的每个检查标记（对勾）都表明当对应的功能（或程序单元）新增或者修改时，标记的对应测试用例应当被重新执行。可以在第一个测试螺旋过程之前建立再测试矩阵，但是我们要在之后的螺旋过程中维护好这个矩阵。随着在一个螺旋开发过程中功能（或程序单元）的改动，应当检查和创建再测试矩阵中现有的和新的测试用例，为下一个螺旋过程做好准备。在后续的螺旋过程中，一些功能（或程序单元）也许很稳定，在一段时间内不会再发生改变。在测试螺旋过程之间，我们应当考虑有选择性的去掉一些相关的检查标记。另外参见E.14节。

表12-1  再测试矩阵

（续）

下面是另外一些关于回归测试的考虑。

l    当在每个螺旋测试中反复执行时，回归测试将成为测试自动化的一个潜在的候选方案。

l    回归测试应当在系统第一次发布之后进行。

l    发现原始缺陷的测试用例应当在该缺陷被修复后重新执行。

l    应当进一步进行测试以保证不仅仅在表面上修正了原始缺陷。

l    应当去除重复进行其他测试的回归测试。

l    应当把发现缺陷相关的功能（或者程序单元）范围内的其他测试用例加入到回归测试集合中。

l    客户报告的缺陷应当有很高的优先级并且需要进行彻底的回归测试。

12.1.6  任务6：定义测试交付物

测试的交付物由测试计划、测试设计、测试开发和缺陷记录产生。从螺旋测试中可选择的交付物如下所述。

l    测试计划：定义目标、范围、策略、测试类型、测试环境、测试规程、结束标准等（参见E.4节）。

l    测试设计：对于应用程序功能、性能和易用性的测试。证明已经满足原始的测试目标。

l    变更请求：对当前软件系统进行变更的文档化的要求，一般由用户提出（参见附录D以获得更多详细内容）。与报告系统异常的缺陷报告有着显著的不同。

l    度量标准：系统的一些可量化的方面的测量指标。举例来说：严重缺陷的数量和发现缺陷的总数可以作为测试人数的函数。

l    测试用例：为一个特定目标而开发的一系列特定的测试数据和相关流程。这提供了一个具体的蓝图，指导单个测试的执行，包括那些特殊的输入数据值和相关期望结果（参见E.8节以获得更多详细内容）。

l    测试日志总结报告：将测试人员的个人测试日志中的测试用例按照正在进行或者已完成分类，为状态报告和度量标准收集做准备（参见E.10节）。

l    测试用例日志：记录在测试过程中执行的测试事件中的测试用例。同时也用来记录执行测试的结果，为测试结果总结提供详细的根据，也为重现测试事件提供基础，如果需要的话（参见E.9节）。

l    中期测试报告：测试螺旋过程之间发布的报告，指示测试工作的当前状态（参见第16章，步骤3）。

l    系统总结报告：在所有的螺旋测试全部结束之后的一个全面的测试报告（参见E.11节）。

l    缺陷报告：记录在螺旋测试过程中发现的缺陷（参见E.12节）。

12.1.7  任务7：组建测试团队

人员部分包括人力资源分配和需要的相关技术。测试团队应该尽量由最高才能的人员组成。一般来讲这些人由于能力强所以非常忙，各个地方都需要他们。因此，能否按照最佳情况将这些人用于测试变得至关重要。测试队伍的领导者和队伍本身都需要恰当的技术和经验，并且愿意从事这个项目的工作。理想情况下，他们应该都是专业的质量保证专家，但也能够扮演如下角色：执行责任人、用户、技术操作、数据库管理、计算机中心、独立第三方等。在任何情况下，他们都不能扮演开发团队的角色，因为他们不可能像一个外部单位一样没有偏见。这并不是意味着开发人员不能做测试。事实上，开发人员在将程序提交给测试团队之前，自己应当做充分的单元测试和功能测试。

在测试中，有两个职责范围：测试应用程序，这是测试团队的责任；管理测试过程，这由测试经理负责。测试经理直接管理一名或多名测试人员，他是质量保证和开发团队之间的接口，管理整个测试的执行过程。其职责包括以下几项。

l    设立测试目标。

l    定义测试资源。

l    建立测试规程。

l    开发并维护测试计划。

l    设计测试用例。

l    设计并执行自动测试工具脚本。

l    测试用例开发。

l    提供测试状态。

l    编写报告。

l    分配队伍成员的角色。

l    管理测试资源。

l    定义标准和流程。

l    保证测试过程的质量。

l    培训队伍成员。

l    维护测试统计和度量标准。

测试团队必须由一组有以下职责的队员组成。

l    根据计划执行测试用例。

l    评价测试结果。

l    报告错误。

l    设计并执行自动测试工具脚本。

l    建议改进应用程序。

l    记录缺陷。

测试团队成员的主要职责是测试应用程序并且将发现的缺陷记录在缺陷跟踪系统中以通知开发团队。一旦开发团队修正了缺陷，测试团队就重新执行发现该缺陷的测试用例。

应当指出，测试经理和测试团队成员的角色并不是互相排斥的。测试经理的一些职责测试团队成员也有，反之亦然。

分配全职测试资源的依据是测试功能的范围和开发的时间限制；举例来说，一个中等的开发项目比一个小型的项目需要更多的资源。如果一个中等复杂度的项目A需要5个人的测试团队，那么两倍规模于它的项目B就需要10个测试人员（假设测试人员的能力相同）。

另外一个单凭经验的方法是测试的开销应该接近总预算的25%。由于总的项目开销是知道的，测试工作量可以进行计算或转化为测试人员的人数。

最好的估算是将项目范围、测试团队技术水平和历史项目的综合考虑。对一个特定项目需要多少测试资源进行评估应该依据很多项目的历史资料。也就是说，和类似的项目比较测试资源的水平和绩效表现。

12.1.8  任务8：建立测试环境

测试环境的目的是为测试活动提供一个必须的物理框架。因此，在执行本任务之前应首先编制并评审测试环境的需求。

测试环境主要组成包括物理测试设备、技术和工具。物理测试设备部分包括物理安装。技术部分包括硬件平台、物理网络和它的所有组件、操作系统软件、其他的一些软件比如工具软件。工具部分包括任何专用的测试软件，比如自动测试工具、测试资料库和一些支持软件。

测试设备和工作场所也是需要分配的。小到个人工作空间的配置，大到正式的测试实验室。无论如何，测试人员在一起工作并且和开发团队保持密切的联系都是非常重要的。这些设备应能互相通信，就像有一个共同的目标。同时，需要的测试工具也应安装。

硬件和软件的技术也需要准备。这包括安装测试所需的硬件和软件，还有供应商、用户和信息技术人员之间的协调合作。我们必须与硬件供应商合作，对硬件进行测试。通讯网络也需要进行安装和测试。

12.1.9  任务9：定义依赖关系

本任务的很好的信息来源是其他项目以前制定的测试计划。如果可以，项目工作计划中的任务顺序应该按照本项目中的活动和任务依赖关系进行分析。

举例来说，测试依赖关系包括以下几种。

l    代码可用性。

l    测试人员可用性（即时方式下）。

l    测试需求（合理定义的）。

l    测试工具可用性。

l    测试组培训。

l    技术支持。

l    即时修复缺陷。

l    充足的测试时间。

l    计算机和其他一些硬件。

l    软件和相关文档。

l    系统文件（如果能得到）。

l    定义的开发方法。

l    测试实验室空间可用性。

l    与开发团队的协议（流程和过程）。

应当定义好相关支持人员并且指派到项目中。这包括开发组成员、技术支持人员、网络支持人员和数据库管理支持人员等。

12.1.10  任务10：创建测试进度表

测试进度表应当包含测试步骤（也可能是任务），目标开始日期和结束日期以及职责等。同时也应该描述出应当如何评审、跟踪和批准该测试。一个简单的测试进度表的格式如表12-2所示，在螺旋方法之后。

同时，像Microsoft Project这样的项目管理工具可以将甘特图排版为突出测试的样式，并且按照测试的步骤将测试活动分组。甘特图由任务信息表格和表示测试进度的柱形统计图表组成。同时也包含了任务持续时间，并描述出了任务之间的依赖关系。为了平衡工作量，人力资源可以同样分配到任务中。参见E.13节，另参见模板文件中的甘特螺旋测试方法模板。

表12-2  测试时间进度表

（续）