测试计划概述

Test Plan

 

 

 

 

1.       什么是测试计划

1.1.     测试计划的定义

1.2.     为什么要编写测试计划

1.3.     什么时间做测试计划

1.4.     由谁来做测试计划

1.5.     制定原则

1.6.     面对的问题

2.       测试计划的内容

2.1.     测试计划标示符

2.2.     介绍

2.3.     测试项

2.4.   需要测试的功能

2.5.     方法（策略）

2.6.     不需要测试的功能

2.7.     测试项通过/失败的标准

2.8.     测试中断和恢复的规定

2.9.     测试完成所提交的材料

2.10.    测试任务

2.11.    环境需求

2.12.    测试人员的工作职责

2.13.    人员安排与培训需求

2.14.    进度表

2.15.    潜在的问题和风险

2.16.    审批

3.       如何做好测试计划

3.1.     明确测试的目标，增强测试计划的实用性

3.2.     坚持“5W1H”规则

3.3.     采用评审和更新机制，保证测试计划满足实际需求

3.4.     分别创建测试计划与测试详细规格、测试用例

3.5.     测试阶段的划分

3.6.     系统测试阶段日程安排

3.7.     变更控制

 

 

 

这个内容我们准备从四个面来进行介绍。

§          1 What‘s Test plan?

§          2 测试计划的内容

§          3 如何做好测试计划

§          4 注意事项

1.        什么是测试计划

首先我们来看看什么是测试计划，针对这个内容我们又分成以下几个方面来进行介绍：

§          1.1 软件测试计划的定义

§          1.2 为什么要编写测试计划

§          1.3 什么时间开始

§          1.4 由谁编写测试计划

§          1.5 制定原则

§          1.6 面对的问题

 

1.1.      测试计划的定义

软件测试是有计划、有组织和有系统的软件质量保证活动，而不是随意地、松散地、杂乱地实施过程。为了规范软件测试内容、方法和过程，在对软件进行测试之前，必须创建测试计划。

《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

归纳起来定义，测试计划就是描述所有要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织，以及与测试有关的风险等方面

 

1.2.      为什么要编写测试计划

第二，我们来看看为什么要编写测试计划，编写测试计划它能给我们带来什么好处呢？总结起来它有以下几个好处：

1．使软件测试工作进行更顺利。我们一般都说预则立，计划便是我们软件测试工作的预先安排，为我们的整个测试工作指明方向。

2．促进项目参加人员彼此的沟通。测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等。这种形式使测试工作与开发工作紧密的联系起来。

3．使软件测试工作更易于管理。领导能够根据测试计划做宏观调空，进行相应资源配置等；其他人员了解测试人员的工作内容，进行有关配合工作。按照这种方式，资源与变更变成了一个可控制的风险。

1.3.      什么时间做测试计划

确定什么时间开始做测试计划是很重要的，一般来说是测试需求分析前总体测试计划书，测试需求分析后详细测试计划书

1.4.      由谁来做测试计划

编写测试计划是一项系统工作，编写者必须对项目了解，对测试工作所接触到的方方面面都要有系统地把握。因此一般情况下是由具有丰富经验的项目测试负责人 进行编写。

1.5.      制定原则

制定测试计划也是有原则的，主要包含以下几个方面：

§          1．制定测试计划应尽早开始。越早进行测试计划，就可以从最根本的地方去了解我们所要测试的对象及内容，为我们完善测试计划是很有好处的。

§          2．保持测试计划的灵活性。测试计划不是固定的，在测试进行过程中会有一定的变动，测试计划的灵活性为我们持续测试具有很好的支持。

§          3．保持测试计划简洁和易读。测试计划做出来后应该能够让测试人员明了自己的任务和计划。

§          4．尽量争取多渠道评审测试计划。通过不同的人来发现测试计划中的不足及缺陷，可以很好的改进测试计划的质量。

§          5．计算测试计划的投入。投入到测试中的项目经费是一定的，我们制定测试计划时一定要注意测试计划的费用情况。要量力而行。

1.6.      面对的问题

制定测试计划要考虑很多问题，要照顾方方面面可能出现的情况，主要有以下几个问题：

§          1．与开发者意见不一致。这是一种很常见的情况，开发人员往往认为自己的程序是正确的，但是再聪明的程序员也有可能犯错误，特别是对需求理解及把握方面的问题，会造成特别大的分歧。

§           2．缺乏测试工具。软件测试不是只依靠人工就可以完成的，特别是软件规模越来越大，软件测试对工具的依赖也更加的紧密了。甚至是为了发现特定的软件缺陷，需要特殊的工具，但是往往这些工具是需要花费费用的。公司里面不一定是每一种工具都有。

§           3．培训不够。公司一般都忽略了对软件测试人员的培训，测试人员的测试技巧及经验不足。

§          4．管理部门缺乏对测试工作的理解和支持。管理部门经常认为测试工作可有可无，对其支持不是很充分。

§          5．缺乏用户的参与。在测试的过程中，我们不能要求用户参与全过程，我们只能依靠自己对需求的理解及对用户的揣测来进行测试。

§          6．测试时间不足。测试也是很花费时间的，但是项目测试的时间一般都不充分。

§          7．过分依赖测试人员。公司的管理人员往往把对软件的质量问题归咎在测试人员身上，但是很多问题往往是开发人员的疏忽造成的。

§          8．测试人员处于进退两难的状态。测试人员在项目进行过程中，往往由项目经理责罚测试不充分，但是开发人员对测试人员提出的问题又置之不理。

§          9．不得不说“不”。测试就是对软件质量提出质疑。对开发人员认为满意的作品进行批判，这是一个很难作的工作。

2.        测试计划的内容

第二个方面我们来看看测试计划的内容。

制定测试计划时，由于各软件公司的背景不同，测试计划文档也略有差异。实践表明，制定测试计划时，使用正规化文档通常比较好。为了使用方便，在这里给出IEEE软件测试计划文档模板。根据IEEE829－1998软件测试文档编制标准的建议，测试计划包含了16个大纲要项。

§          1．测试计划标识符

§          2．介绍

§          3．测试项

§          4．需要测试的功能

§          5．方法（策略）

§          6．不需要测试的功能

§          7．测试项通过/失败的标准

§          8．测试中断和恢复的规定

§          9．测试完成所提交的材料

§          10．测试任务

§          11．环境需求

§          12．职责

§          13．人员安排与培训需求

§          14．进度表

§          15．潜在的问题和风险

§          16．审批

2.1.      测试计划标示符

 一个测试计划标识符是一个由公司生成的惟一值，它用于标识测试计划的版本、等级，以及与该测试计划相关的软件版本。

2.2.      介绍

在测试计划的介绍部分主要是测试软件基本情况的介绍和测试范围的概括性描述。

2.3.      测试项

测试项部分主要是纲领性描述在测试范围内对哪些具体内容进行测试，确定一个包含所有测试项在内的一览表。具体要点如下。

§          功能的测试

§          设计的测试

§          整体测试

IEEE标准中指出，可以参考下面的文档来完成测试项：

Ÿ         需求规格说明

Ÿ         用户指南

Ÿ         操作指南

Ÿ         安装指南

Ÿ         与测试项相关的事件报告

2.4.      需要测试的功能

测试计划中这一部分列出了待测的功能。

2.5.      方法（策略）

这部分内容是测试计划的核心所在，所以有些软件公司更愿意将其标记为“策略”，而不是“方法”。

测试策略描述测试小组用于测试整体和每个阶段的方法。要描述如何公正、客观地开展测试，要考虑模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响，要尽可能地考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备。测试记录具体说明如下。

Ÿ  公正性声明

Ÿ  测试用例

Ÿ  特殊考虑

Ÿ  经验判断

Ÿ  设想

2.6.      不需要测试的功能

测试计划中这一部分列出了不需要测试的功能。

2.7.      测试项通过/失败的标准

测试计划中这一部分给出了“测试项”中描述的每一个测试项通过/失败的标准。正如每个测试用例都需要一个预期的结果一样，每个测试项同样都需要一个预期的结果。

下面是通过/失败的标准的一些例子：

Ÿ  通过测试用例所占的百分比；

Ÿ  缺陷的数量、严重程度和分布情况；

Ÿ  测试用例覆盖；

Ÿ  用户测试的成功结论；

Ÿ  文档的完整性；

Ÿ  性能标准。

2.8.      测试中断和恢复的规定

测试计划中这一部分给出了测试中断和恢复的标准。常用的测试中断标准如下：

Ÿ  关键路径上的未完成任务

Ÿ  大量的缺陷

Ÿ  严重的缺陷

Ÿ  不完整的测试环境

Ÿ  资源短缺

2.9.      测试完成所提交的材料

 测试完成所提交的材料包含了测试工作开发设计的所有文档、工具等。例如，测试计划、测试设计规格说明、测试用例、测试日志、测试数据、自定义工具、测试缺陷报告和测试总结报告等。

2.10.  测试任务

测试计划中这一部分给出了测试工作所需完成的一系列任务。在这里还列举了所有任务之间的依赖关系和可能需要的特殊技能。

2.11.  环境需求

 环境需求是确定实现测试策略必备条件的过程。

例如：

Ÿ  人员——人数、经验和专长。他们是全职、兼职、业余还是学生？

Ÿ  设备——计算机、测试硬件、打印机、测试工具等。

Ÿ  办公室和实验室空间——在哪里？空间有多大？怎样排列？

Ÿ  软件——字处理程序、数据库程序和自定义工具等。

Ÿ  其他资源——软盘、电话、参考书、培训资料等。

2.12.  测试人员的工作职责

测试人员的工作职责是明确指出了测试任务和测试人员的工作责任。

有时测试需要定义的任务类型不容易分清，不像程序员所编写的程序那样明确。复杂的任务可能有多个执行者，或者由多人共同负责。

2.13.  人员安排与培训需求

前面讨论的测试人员的工作职责是指哪类人员（管理、测试和程序员等）负责哪些任务。人员安排与培训需求是指明确测试人员具体负责软件测试的哪些部分、哪些可测试性能，以及他们需要掌握的技能等。实际责任表会更加详细，确保软件的每一部分都有人进行测试。每一个测试员都会清楚地知道自己应该负责什么，而且有足够的信息开始设计测试用例。

培训需求通常包括学习如何使用某个工具、测试方法、缺陷跟踪系统、配置管理，或者与被测试系统相关的业务基础知识。培训需求各个测试项目会各不相同，它取决于具体项目的情况。

2.14.  进度表

测试进度是围绕着包含在项目计划中的主要事件（如文档、模块的交付日期，接口的可用性等）来构造的。

作为测试计划的一部分，完成测试进度计划安排，可以为项目管理员提供信息，以便更好地安排整个项目的进度。

进度安排会使测试过程容易管理。通常，项目管理员或者测试管理员最终负责进度安排，而测试人员参与安排自己的具体任务。

2.15.  潜在的问题和风险

软件测试人员要明确地指出计划过程中的风险，并与测试管理员和项目管理员交换意见。这些风险应该在测试计划中明确指出，在进度中予以考虑。有些风险是真正存在的，而有些最终证实是无所谓的，重要的是尽早明确指出，以免在项目晚期发现时感到惊慌。

一般而言，大多数测试小组都会发现自己的资源有限，不可能穷尽测试软件所有方面。如果能勾画出风险的轮廓，将有助于测试人员排定待测试项的优先顺序，并且有助于集中精力去关注那些极有可能发生失效的领域。下面是一些潜在的问题和风险的例子：

Ÿ  不现实的交付日期

Ÿ  与其他系统的接口

Ÿ  处理巨额现金的特征

Ÿ  极其复杂的软件

Ÿ  有过缺陷历史的模块

Ÿ  发生过许多或者复杂变更的模块

Ÿ  安全性、性能和可靠性问题

Ÿ  难于变更或测试的特征

 

风险分析是一项十分艰巨的工作，尤其是第一次尝试进行时更是如此，但是以后会好起来，而且也值得这样做。

2.16.  审批

审批人应该是有权宣布已经为转入下一个阶段做好准备的某个人或某几个人。测试计划审批部分一个重要的部件是签名页。审批人除了在适当的位置签署自己的名字和日期外，还应该签署表明他们是否建议通过评审的意见。

 

3.        如何做好测试计划

了解了测试计划的基本内容之后，我们应该想想该如何做好测试计划呢？除了上述讲的制定原则外，我们还应该注意什么呢？

3.1.      明确测试的目标，增强测试计划的实用性

当今任何商业软件都包含了丰富的功能，因此，软件测试的内容千头万绪，如何在纷乱的测试内容之间提炼测试的目标，是制定软件测试计划时首先需要明确的问题。测试目标必须是明确的，可以量化和度量的，而不是模棱两可的宏观描述。另外，测试目标应该相对集中，避免罗列出一系列目标，从而轻重不分或平均用力。根据对用户需求文档和设计规格文档的分析，确定被测软件的质量要求和测试需要达到的目标。

编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确。

3.2.      坚持“5W1H”规则

明确内容与过程  “What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）” 、“Who（谁来做）”、“How（如何做）”

1）why——为什么要进行这些测试；

2) what—测试哪些方面，不同阶段的工作内容；

3) when—测试不同阶段的起止时间；

4) where—相应文档，缺陷的存放位置，测试环境等；

5) who—项目有关人员组成，安排哪些测试人员进行测试；

6) how—如何去做，使用哪些测试工具以及测试方法进行测试。

3.3.      采用评审和更新机制，保证测试计划满足实际需求

测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。

测试计划包含多方面的内容，编写人员可能受自身测试经验和对软件需求的理解所限，而且软件开发是一个渐进的过程，所以最初创建的测试计划可能是不完善的、需要更新的。需要采取相应的评审机制对测试计划的完整性、正确性、可行性进行评估。例如，在创建完测试计划后，提交到由项目经理、开发经理、测试经理、市场经理等组成的评审委员会审阅，根据审阅意见和建议进行修正和更新。

3.4.      分别创建测试计划与测试详细规格、测试用例

编写软件测试计划要避免一种不良倾向是测试计划的“大而全”，无所不包，篇幅冗长，长篇大论，重点不突出，既浪费写作时间，也浪费测试人员的阅读时间。“大而全”的一个常见表现就是测试计划文档包含详细的测试技术指标、测试步骤和测试用例。

最好的方法是把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

3.5.      测试阶段的划分

就通常软件项目而言，基本上采用“瀑布型”开发方式，这种开发方式下，各个项目主要活动比较清晰，易于操作。整个项目生命周期为“需求－设计－编码－测试－发布－实施－维护”。然而，在制定测试计划时候，有些测试经理对测试的阶段划分还不是十分明晰，经常性遇到的问题是把测试单纯理解成系统测试，或者把把各类型测试设计（测试用例的编写和测试数据准备）全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试不足。合理的测试阶段应遵循下面划分方法：

 

 

 

　　照上图所述，相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试和集成测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。

3.6.      系统测试阶段日程安排

划分阶段清楚了，随之而来的问题是测试执行需要多长的时间？标准的工程方法或CMM方式是对工作量进行估算，然后得出具体的估算值。但是这种方法过于复杂，可以另辟专题讨论。一个可操作的简单方法是：根据测试执行上一阶段的活动时间进行换算，换算方法是与上一阶段活动时间1：1.1~1.5左右。举个例子，对测试经理来说，因为开发计划可能包含了单元测试和集成测试，系统测试的时间大概是编码阶段（包含单元测试和集成测试）1到1。5倍。这种方法的优点是简单，依赖于项目计划的日程安排，缺点是水分太多，难于量化。那么，可以采用的另一个简单方法是经验评估。评估方法如下：
　　1． 计算需求文档的页数，得出系统测试用例的页数
　     需求页数：系统测试用例页数 ≈ 1：1
　　2． 由系统测试用例页数计算编写系统测试用例时间
　　 编写系统测试用例时间 ≈ 系统测试用例页数×1小时
　　3． 计算执行系统测试用例时间
　     编写系统用例用时：执行系统测试用时 ≈ 1：2
　　4． 计算回归测试包含的时间
　　 系统测试用时：回归测试用时≈ 2：1
　　注：以上比值是个人工程经验值，需要更正比值的测试经理可以在具体实践中收集数据。
　　基于以上方法优点是需求为已知的，可以利用已知来推算未知，适用于需求是已知且相对稳定的情况下；缺点是处于研发状态的项目，需求不清晰的时候比较难计算。现套用一个例子加于说明：需求文档页数为500，系统测试用例页数推算为500，则编写系统测试用例时间为500小时，执行系统测试用例时间为1000小时，回归测试需要500小时，加起来总共为2000小时，按一天8小时计算，共计250个工作日/人；假如一个月为22个工作日，则共计约11人/月，即投入4个人需要3个月左右时间工作量完成。当然，这是系统测试需要的全部时间。根据测试阶段划分原则，设计用例时间可以和开发同步进行，只需在测试阶段中安排的时间为1500小时即4人2个月工作量。

（测试经理在编写测试计划时候，测试进度中的计划开始/结束时间往往用如20050101-20051201的具体时间划分方式，这样引起的问题是当项目计划进行变更的时候，测试计划时间不得不随时调整，这种变更可能是频繁而琐碎的，可以替代的办法是取消这种方式，采用30工作日/2人或者2人月这种工作量记录方式，这样一来，只需在项目计划中跟踪阶段的具体开始时间即可，不必反复修改测试计划。）

值得注意的是：国内大多数公司的测试时间都是不足的，不可能按照这样的理想比例进行运作，因为测试执行的时间实际上不可能占据整个项目周期的1/2，甚至要短于其中任何一个项目阶段时间。即使是微软的测试结束原则也并不是完成所有必需的测试，而是测试在按计划结束的那一天结束！在测试时间不足的情况下，可参考下面项目计划变更时的做法，因为计划变更也涉及到测试时间不足的情况。

3.7.      变更控制

测试计划改变了已往根据任务进行测试的方式，因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的，本身就是强调按规划的测试战略进行测试，淘汰以往以任务为主的临时性。在这种情况下，测试计划中强调对变更的控制显得尤为重要。

变更来源于以下几个方面

1． 项目计划的变更

2． 需求的变更

3． 测试产品版本的变更

4． 测试资源的变更
　　测试阶段的风险主要是对上述变更所造成的不确定性，有效的应对这些变更就能降低风险发生的几率。要想计划本身不成为空谈和空白无用的纸质文档，对不确定因素的预见和事先防范必须做到心中有数。
　　对于项目计划的变更，除了测试人员及时跟进项目以外，项目经理必须认识到测试组也是项目成员，因此必须把这些变更信息及时通知到项目组，使得整个项目得到顺延。项目计划变更一般涉及都是日程变更，令人遗憾的是，往往为了进度的原因，交付期限是既定的，项目经理不得不减少测试的时间，这样，执行测试的时间就被压缩了。在这种情况下，测试经理常常固执的认为进度缩减的唯一的方法就是向上级通报并主观认为产品质量一定会下降，这种做法和想法不一定是正确的。由于时间不足，不能“完美”的执行所有测试，为了保证质量，第一种办法是调整测试计划中的测试策略和测试范围，实践中测试经理常常忽略测试计划的这个章节。调整的目的是重新检查不重要的测试部分，调换测试的次序和减少测试规模，对测试类型重新组合择优，力求在限定时间内做最重要部分的测试，可以把忽略部分留给确认测试或现场测试。其他应对办法包括减少进入测试的阻力，例如降低测试计划中系统测试准入准则；分步提交测试，例如改成迭代方式增量测试；减少回归测试的要求，例如开发人员实时修改，在测试计划中对缺陷修复响应时间和过程进行约定；和公司QA商量进行简化配置管理，跳过正式发布环节；缺陷进行局部回归而不是重新全部测试等等。
　　第二：项目进行过程中最不可避免的就是需求的变更。那么，测试计划中就不能进行控制和约束的吗？答案是未必。当制定计划时，如果项目需求处于动态变化时，在测试用例章节就要进行说明。许多测试经理在编制测试用例时往往没有把测试用例和测试数据进行区分，因此，造成的问题是当需求变化时辛辛苦苦设计的数据就作废了。在这时，假使面临一个需求动态的项目，必须在计划中对需求变更造成的测试（设计）方式变化进行说明，例如采用用例和数据分离、流程和界面分离、字典项和数据元素分离的设计方式，然后等到最终需求确定后细化测试设计；另一个方面是最好制定一个变更周期的约定――尤其在执行测试阶段发现需求的变更――定义变更的最大频度和重新测试的界限，计划从一定程度上能够降低不可预期需求变化造成的投入损失。值得注意的是：需求发生变更时测试经理额外的工作是记住要在需求跟踪矩阵上做记录。
　　对于测试产品版本的变更，除了部分是由于需求变更造成之外，很有可能是由于修改缺陷引发的问题或配置管理不严格造成。众所周知，测试必须是基于一个稳定的“基线”进行，否则，因反复修改造成测试资源和开发资源的浪费是可观的。合理的测试计划在章节中应增加一个测试更新管理的章节，在此章节明确更新周期和暂停测试的原则。例如，小版本的产品更新不能大于每天三次，一个相对大的版本不能每周大于1次，规定紧急发布产品仅限于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境。测试计划通常制定了准入和准出准则，这是不够的，要考虑测试暂停的时候，产品错误发布或者服务器数据更新就是一个例子，暂停的时候如果测试经理不进行跟踪，可能发生测试组等待测试而没人通知继续测试的情况，所以，增加更新周期和暂停测试原则是很有必要的。
　　最后，测试资源的变更是源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类似。没有测试经理愿意承担资源不足的测试工作，只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小，最终产品质量取决因素不仅仅在于测试经理。为了排除这种风险，除了象时间不足、测试计划变更时那样缩减测试规模等等方法以外，测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源，否则，必须将这个问题作为风险记录。规避风险的办法可能有：
　　一，项目组的需求和实施人员参与系统测试；
　　二，抽调不同模块开发者进行交叉系统测试或借用其他项目开发人员；
　　三，组织客户方进行确认测试或发布β版本。
　　尽管上面尽可能的描述了测试计划如何制定才能“完美”，但是还存在的问题是对测试计划的管理和监控。一份计划投入再多的时间去做也不能保证按照这份计划进行实施。好的测试计划是成功的一半，另一半是对测试计划的执行。对小项目而言，一份更易于操作的测试计划更为实用，对中型乃至大型项目来看，测试经理的测试管理能力就显得格外重要，要确保计划不折不扣的执行下去，测试经理的人际谐调能力，项目测试的操作经验、公司的质量现状都能够对项目测试产生足够的影响。另外，计划也是“动态的”！不必要把所有的因素都可能囊括进去，也不必要针对这种变化额外制定“计划的计划”，测试计划制定不能在项目开始后束之高阁，而是紧追项目的变化，实时进行思考和贯彻，根据现实修改，然后成功实施，这才能实现测试计划的最终目标――保证项目最终产品的质量！