测试计划描述了如何完成测试，有效的测试计划会驱动测试工作的完成，使测试执行、测试分析以及测试报告的工作开展更加顺利。

一、测试计划的重要性和目的

1、 测试计划的重要性

测试计划是在软件测试中最重要的步骤之一，它在软件开发的前期对软件测试做出清晰，完整的计划，不光对整个测试起到关键性的作用，而且对开发人员的开发工作，整个项目的规划，项目经理的审查都有辅助性作用。

2、 测试计划的目的

测试计划描述所要完成的测试，包括测试背景、测试目的、风险分析、所需资源、任务安排和进度等：

（1）将需求和总体设计分解成可测试，应该测试，推迟测试和无法测试的范围

（2）对每个范围制订测试的策略和方法

（3）制订release和停止测试的标准

（4）准备测试所需要的环境

（5）确定测试风险

（6）确定软件测试目标

（7）确定测试所需要的资源其其他相关信息

（8）制订测试进度和任务安排

二、测试计划编写基本策略

1、测试计划编写依据：项目计划、项目计划的评估状态以及业务的理解

2、测试计划编写时间：尽早开始。原则上应该在需求定义完成之后开始编写测试计划，对于开发过程不是十分清晰和稳定的项目，测试计划也可以在总体设计完成后开始编写。

3、测试计划的编写与实施：测试计划应该由测试小组组长或最有经验的测试人员来进行编写，测试计划由测试人员来实施，测试人员可以对测试计划进行相关人员确认后进行调整。

4、测试计划的变更：测试计划是一个发展变化的文档，会随着项目的进展、人员或环境的变动而变化，确保测试计划是最新的而且依据测试计划执行测试工作。

5、测试计划的优先级别：没有谁可以保证通过测试后的产品没有缺陷，也没有公司会允许无休止的测试。好的测试是一个有代表性、简单和有效的测试，在测试计划中，必须制定测试的优先级和重点。

6、测试计划的评审：测试计划需要由高级测试人员或测试组长制订，在经验不足或条件限制的软件测试计划的制订时，需要多名测试人员共同制订和修正.

（1）软件项目经理负责评审测试计划的方向正确性和软件开发按照总体设计方案实施(如有改动，需通知测试人员修改计划)，并保证软件具有可测试性

（2）QA人员评审测试过程的正确性和能够按照计划要求的正确实施

（3）高级经理评审测试计划的导言和范围的正确性

7、测试计划的管理

测试计划将按照项目编码或软件名称和版本进行管理，所有文档放置于CVS。

8、测试计划制定过程：

（1） 评估项目计划和状态

（2） 组建测试小组

（3） 了解项目风险

（4） 制定测试计划

（5） 审查测试计划

9、测试计划的原则

（1） 尽早开始

（2） 灵活变更

（3） 合理评审

（4） 简洁易读

三、测试计划的主要内容

测试计划的内容会因不同的项目以及项目的大小而有所不同，一般而言在测试计划中应该清晰描述以下内容：

1、 测试目标：对测试目标进行简要的描述。

2、 测试概要：摘要说明所需测试的软件、名词解释、以

及提及所参考的相关文档。

3、 测试范围：测试计划所包含的测试软件需测试的范围

和优先级，哪些需要重点测试、哪些无需测试或无法

测试或推迟测试。

4、 重点事项：列出需要测试的软件的所有的主要功能和

测试重点，这部分应该能和测试案例设计相对应和互

相检查。

5、 质量目标：制定测试软件的产品质量目标和软件测试

目标。

6、 资源需求：进行测试所需要的软硬件、测试工具、必

要的技术资源、培训、文档等。

7、 人员组织：需要多少人进行测试，各自的角色和责任，

他们是否需要进行相关的学习和培训，什么时候他们

需要开始，并将持续多长时间。

8、 测试策略：制定测试整体策略、所使用的测试技术和

方法。

9、 发布提交：在按照测试计划进行测试发布后需要交付

的软件产品、测试案例、测试数据及相关文档。

10、 测试进度和任务人员安排：将测试的计划合理的

分配到不同的测试人员，并注意先后顺序.如果开发的Release不确定，可以给出测试的时间段.对于长期大型的测试计划，可以使用里程碑来表示进度的变化。 11、 测试开始/完成/延迟/继续的标准：制定测试开始

和完成的标准；某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续。 12、 风险分析：需要考虑测试计划中可能的风险和解

决方法。

四、软件测试计划模板

请参考《软件测试计划模板》，在模板中详细讲述了如何编写测试计划。

 

第二篇：测试计划编写指南

由安博测试空间技术中心/提供

测试计划编写指南

文档目的和结构

测试计划编写指南说明测试计划编写的各个方面。文档按照大纲的形式组织。大纲的每个标题下有详细的说明：1. 说明该主题的重要性。 2. 提示和技巧。

一、介绍

A. 文档目的

B. 文档摘要

C. 文档历史和变更

二、背景

A. 系统视图和目标

B. 联系方式

C. 相关信息保存的位置

三、质量目标

四、测试策略

A. 整体策略

B. 测试范围

五、测试方法

A. 里程碑技术

B. 测试文档（测试用例）

C. 测试实施过程

1. 测试系统接受条件

2. 测试时间表

D. 稳定阶段测试

1. 稳定阶段摘要

2. 测试遍数

3. 项目结束

E. 自动测试策略

F. 集成测试策略

G. 内容测试

H. 性能测试和压力测试

I 兼容性测试

六、测试组织

A. 测试团队结构

B. 功能划分

七、资源需求

A. 培训需求

B. 硬件需求

C. 软件需求

D. 办公空间需求

八、时间进度安排

九、缺陷处理

A. 数据库管理

B. 缺陷处理过程

十、测试过程控制

A. 缺陷数据分析

B. 测试工作周报

十一、风险分析

十二、 系统发布

一、介绍

测试计划编写指南有两类潜在的受众。首先，测试负责人使用它作为指导方针编写测试计划。测试计划编写完成后，将作为整个团队（包括开发人员和测试人员）沟通的基础。

测试项目开始时，应该完成测试计划的大部分内容。项目开始后，由于测试情况有变化，可能导致测试计划文档变化。如果文档有明显的变化，必须在文档中添加变更历史来记载这些变化。

A. 文档目的

测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。

B. 文档摘要

这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员（比如经理或开发项目的负责人）。

提示和技巧：

l 在写这一节时，考虑一下你的计划在那些地方可能会引起反对。这个计划跟以前的计划相比，有什么不同的地方。测试项目与系统开发计划的关系等。

l 使用列表的格式，可以将问题按重要程度罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在。

C. 文档历史和变更

[作者] – [日期] – [文档的当前状态，上版本以来所作的主要变化]

二、背景

A. 系统视图和目标

系统视图对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。系统目标是帮助实现系统视图的重要指标。系统视图和目标对实现整个项目计划来说是至关重要的。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。

通常情况下视图和项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。

提示和技巧：

l 为什么视图对客户是重要的？

l 你如何向客户表达这种视图？

l 你将做什么来保证你是在向实现视图的方向前进?

l 在你回答这些问题之后，你就可以将视图转换成测试导向的目标？

B. 联系方式

列出项目参与人员的联系方式包括 E-mail 和电话。

C. 相关信息保存的位置

l 测试服务器的相关信息

l 测试文档保存的位置

l 测试工具保存的位置

三、质量目标

围绕软件质量，有几种不同的说法。第一个是质量是一种绝对的标准，对所有的系统必须等同处理。事实上，质量是相对的而且是和产品相关的概念。例如，多媒体产品的质量目标倾向于精美的表示和适当的内容，而应用系统可能倾向于易用性、健壮性和适用于不同的任务。质量目标可能是动态的。在项目进行过程中，会由于市场压力、新的机会和功能改变而重新设定质量目标。

另一种有关软件质量的说法是，定义和衡量系统质量是测试部门一个部门的事。实际上，建立质量标准是所有职能部门共同努力的结果。测试、开发、系统使用部门、用户教育、系统支撑必须为建立和维护系统的质量标准做出自己的贡献。每个部门必须对自己最了解的部分做出相应的质量定义。例如，测试和开发部门对系统质量的衡量标准主要是健壮性和正确性。

用户部门可能对易用性方面比较熟悉。

最后，质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具，应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如，系统是否能够正式发行？在代码完成后，应该修复那些缺陷？在系统完成后那种类型的测试是最合适的。

四、测试策略

A. 整体策略

本节的目的是说明计划中使用的基本的测试过程。

提示和技巧：

l 是否使用里程碑技术和在测试过程中验证每个模块？或者是什么都不做，只是普通的测试而已。 l 测试人员是否在项目开发初期就开始工作？或者测试人员只在系统开发完后，才开始测试。

B. 测试范围

测试部门可能对应该做什么测试觉得很迷惑。本节试图对这些问题做一些规定。通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。

提示和技巧：

l 需要特别测试那些部分？

l 那些部分不需要测试，为什么？

l 测试人员是否需要测试内容以及相关部分？

l 是否要验证每个模块的稳定性？

五、测试方法

下面几节将说明测试计划的核心部分。如果将项目比做游戏，这些内容将是攻关秘籍。它们提供在整个测试过程中，每一个步骤的详细说明。每一节会就测试的不同方面做详细的说明。这一部分的主要读者是测试人员，因为计划主要是为了规定如何进行测试。

A. 里程碑技术

里程碑技术将项目的运行分成不同的阶段，在项目过程中提供检查工作进展状态的方法。即使只有一个里程碑，也要在这里说明。在说明中，要列出通过和继续往下走的标准。

1. 计划阶段

2. 开发阶段

3. 稳定阶段

B. 测试文档（测试用例）

测试用例需要列出彻底测试一个功能模块所需的详细步骤。使用测试用例的主要目的是避免完成了所需的测试内容而不仅仅是走过场。

提示和技巧：

l 通常可以定义测试用例模板，这样每个测试用例都有同样的格式。就像测试用例的格式一样，可以用不同的办法来编写测试用例。这些方法的主要区别是用例的详细程度。在极端的情况下，用例的每一步都详细列出，这样的话，能保证运行测试用例的人员在做同样的事情，而且容易实现自动执行。但对于用例编写人员来说，意味着庞大的工作量，他必须考虑每一个步骤。当功能发生变化时，维护这样的测试用例是非常困难的。

l 另一种极端的情况是非常概要的测试用例。这些用例是非常宽泛的，只提供简洁的描述说明需要做什么。让测试人员决定如何实现，以及使用那些数据来测试。大多数的专业测试人员赞同于一个折中的方案，并倾向于提供较为详细的步骤。

C. 测试实施过程

本节的目的说明在测试过程中测试部门在接受测试系统时应执行什么检查。这一节有助于其他部门（开发部门、用户教育部门）了解在发布测试系统时应做些什么。保持测试系统相对稳定是非常重要的。

1. 测试系统接受条件

本节的目的说明在测试过程中测试部门在接受测试系统时应执行什么检查。

提示和技巧：

谁负责建立测试系统，如何保持测试系统和开发系统之间的同步。

在开发人员提交新程序时，如何检查代码的质量。

开发部门是否需要运行简单的用例，验证系统是否正常，如果验证失败，需要采取什么行动。 需要做什么测试验证测试系统是稳定的。

同步的间隔时间。

当项目进展到不同阶段时，是否需要更新这些规则。

2. 测试时间表

在系统的不同阶段，需要计划在什么时候应得到什么样的测试系统。

提示和技巧：

l 测试系统多长时间更新一次（每日，每周一次或多次，在什么时间，准备好代码）？

l 当项目进展到不同阶段时，是否需要更新这些规则。

D. 稳定阶段测试

1. 稳定阶段摘要

在代码完成到系统最后发行之前为系统稳定阶段。在系统稳定阶段需要对系统的各个部分进行最后的检查。可以建立一个检查重点列表，挨项进行检查。

2. 测试遍数

在稳定化测试阶段至少要运行一遍完整的测试和一个简短的测试。前者用于发现错误，后者用于验证发行版本。

3. 项目结束

在系统投入使用的时候，最后应作的测试安排。

E. 自动测试策略

在测试过程中，可以适当考虑使用自动测试策略。自动测试不是保证产品质量的万能药，不能保证发现软件的缺陷。自动测试有它的长处和短处，要充分考虑系统特性、时间安排、测试人员的编程经验和可以使用的自动化工具。

使用自动化技术主要目的是发现系统缺陷，提高测试用例的运行效率和对系统进行快速检测。测试自动化跟系统本身的特性相关，如果系统主要是数值运算，可以对结果进行简单判断，使用自动化技术的效率就高，否则系统主要是跟内容相关，自动化测试的效率就比较低。

提示和技巧：

l 自动化的目标是什么。

l 你如何衡量这些目标。

l 在测试中，是否实行代码覆盖，分支覆盖和功能覆盖。

l 哪些部分可以自动化？自动化程度有多高。

l 使用什么自动化工具？是否开发新的自动化工具？

F. 集成测试策略

集成测试有两个范围。一个是系统内部各个功能模块的交互作用，各种可能的组合是非常多的，表现为系统有丰富多彩的表现。另外一种集成是测试系统与相关系统的集成。

提示和技巧：

l 用户帮助内容在何时如何与系统功能交互作用？怎样测试？

l 典型的用户情景是什么？

l 有哪些可能的逻辑组合？

l 类似功能的逻辑是否一致？

l 是否有相同的界面？

l 菜单命令是否一致？

G. 内容测试

对于系统来说，总有些内容部分需要测试，例如帮助等。对于网站来说，文字说明也是相当重要的。内容测试的第一步就是将内容部分标识出来，再确定谁来实施测试。

提示和技巧

l 如果内容只是一些帮助文件，用户教育部门会编写和验证这些内容。如果系统是以内容为主的，拥有上百万的文字、千个链接以及不计其数的图片，在这种情况下需要使用由编辑、校对和测试人员组成的小组来负责内容测试。

l 与内容提供者确定“什么是内容的缺陷”。避免出现模糊的问题，比如“读起来有点问题”或者“太文绉绉”。

l 哪些内容需要测试。

l 如何将内容测试与其他工作分开。

l 是否使用自动测试（比如超链接测试）。

l 如果使用自动测试，区分那些内容无法使用自动测试，哪些部分可以保证能自动测试。 H. 性能测试和压力测试

在性能测试中，执行不同的测试，并进行记时，然后将这些数据与以前的数据进行对比。现在的系统多是 C/S 架构或 B/S 架构，需要测试系统对多个用户的并发响应能力，一般情况下可以使用软件在一台机器上模拟几千个客户端进行压力测试来衡量这些指标。

提示和要点：

l 系统和竞争对手的系统相比有多快。这可能是一个质量指标，比如“比竞争对手 X 快”。 l 与以前的系统进行相比。比如“在增添新功能后是否跟以前一样快甚至更快些。”

l 如果没有可比性，可以使用合理速度来进行衡量，但这种数据必须经确认。

l 需要衡量哪些性能，可以在测试计划中，指定重点领域，在实际测试过程中，在进行具体确定。 l 是否有行业标准可在测试中使用。

l 在什么时候执行性能测试？如果需要进行代码优化，需要尽早进行性能测试，这样代码修改带来的负面影响比较小。

l 性能测试是否跟硬件平台相关。需要确定在何种硬件平台下进行性能测试。

l 在性能测试中，有几个指标需要注意，如 CPU 使用率内存使用率以及磁盘吞吐率等，这样能确定系统的瓶颈在哪。是否能进行优化。

I 兼容性测试

对于 C/S 架构的系统来说，需要考虑客户端支持的系统平台。对于 B/S 架构的系统来说需要考虑用户端浏览器的版本。

提示和技巧：

l 确定主流的客户端浏览器版本。

l 决定支持哪些版本的浏览器。

l 在什么平台上做开发和测试，在那些平台上进行兼容性测试。

六、测试组织

A. 测试团队结构

这一节说明测试团队的结构和项目测试人员的数量。

提示和技巧

l 查看开发计划确定那些功能需要最多资源。

l 确定需要多少测试人员。

l 多少人做自动测试，是哪些人。

B. 功能划分

这一节说明系统可以分成那些模块，分别由谁负责。

提示和技巧：

l 系统的那些常用功能需要测试。

l 是不是需要测试系统的所有功能。

l 是不是需要与开发部门在功能方面对应一致。

七、资源需求

A. 培训需求

本节说明项目测试人员需要哪些培训。

提示和技巧：

l 对于新手需要先介绍测试系统，如果测试人员比较熟悉该系统，则需要说明新系统的功能。 l 是否进行自动测试。

l 测试人员要不要培训以编写自动化脚本。

B. 硬件需求

本节说明测试人员需要的各种类型的硬件以及这个测试团队需要的硬件。

C. 软件需求

本节说明测试人员需要使用的软件。

D. 办公空间需求

本节说明需要多少办公空间。

八、时间进度安排

包括主要时间点的安排

日期

代码完成时间

第一遍测试

第X遍测试

系统发行时间

九、缺陷处理

测试过程中可衡量的是发现的缺陷的状况。因此缺陷的报告和管理必须写成书面文档。

A. 数据库管理

提示和技巧：

l 谁负责创建数据库？

l 谁有权限增加数据库的帐号？

l 谁有权使用哪类帐号？

l 数据库使用过程中出了问题和谁联系？

l 谁负责数据库备份？

l 多长时间备份一次？

l 由谁使用数据库？

l 缺陷管理应该与开发部门的负责人一起讨论。

B. 缺陷处理过程

提示和技巧：

l 解释缺陷报告和分配过程。

l 缺陷标题、测试环境应如何填写

l 解释如何输入，解决，重新打开，关闭和重新即或一个缺陷。

l 让测试人员清楚一个缺陷从击活到解决的全过程。

l 缺陷必须指定由谁负责解决。

l 定义优先级、严重级别等。

l 在项目结束时，如何解决这些缺陷。

十、测试过程控制

在测试过程中，通过对缺陷数据库进行分析可以确定测试的状态。另外，通过让测试人员填写测试工作周报，可以对项目进展状况进行反馈。

A. 缺陷数据分析

提示和技巧：

l 在开发过程和稳定阶段是否有过多的未处理缺陷，这可能说明开发的资源不够，或者有其它问题。 l 如何确定项目中是否有过多的缺陷。

l 测试人员是否积极发现缺陷，或者过分积极。

l 在每个时间点上，系统是否稳定。

l 系统哪些部分的缺陷最集中。

l 在系统发行时修复了多少缺陷。

l 哪些类型的缺陷最普遍。

B. 测试工作周报

提示和技巧：

l 周报中应包括哪些信息。

l 如何填写工作周报。

l 谁负责查看工作周报。

十一、风险分析

在系统开发和测试过程中，会有各种可能导致系统发布延迟，在计划中需要预先估计这些风险，并且提出相应的对付办法。

十二、 系统发布

确定系统在什么情况下可以发布，由谁决定。

制定成功的测试计划

《世界商业评论》ICXO.COM ( 日期：2004-07-28 11:04)

工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。 产品基本情况调研：

这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。

具体的要点有：

目的：重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置， 粗略的估计测试大致需要的周期和最终测试报告递交的时间。

变更：说明有可能会导致测试计划变更的事件。包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。

技术结构：可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。

产品规格：就是制造商和产品版本号的说明。

测试范围：简单的描述如何搭建测试平台以及测试的潜在的风险。

项目信息：说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。

测试需求说明：

这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试

的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。具体要点有：

功能的测试：理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一

个浩大的工程，但是有利于测试的完整性。

设计的测试：对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。

整体考虑：这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的

过程中的正确性。

测试的策略和记录：

这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、

整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能的考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录重要包括的部分

具体说明如下：

公正性声明：要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。

测试案例：描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的回归测试留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。

特殊考虑：有的时候，针对一些外界环境的影响，要对软件进行一些特殊方面的测试。

经验判断：对以往的测试中，经常出现的问题加以考虑。

设想：采取一些发散性的思维，往往能帮助你找的测试的新途径。

测试资源配置：

项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。

计划表：

测试的计划表可以做成一个多个项目通用的形式，根据大致的时间估计来制作，操作流程

要以软件测试的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。

问题跟踪报告：

在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的

性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境。

问题描述尽可能是定量的，分门别类的列举，问题有几种：

1、严重问题：严重问题意味着功能不可用，或者是权限限制方面的失误等等，也可能是某个地方的改变造成了

别的地方的问题。

2、一般问题：功能没有按设计要求实现或者是一些界面交互的实现不正确。

3、建议问题：功能运行得不象要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面先是错误，格式不对，含义模糊混淆的提示信息等等。

测试计划的评审：

又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测

试部门人员的认同，包括部门的负责人的同意和签字。

结果：

计划并不是到这里就结束了，在最后测试结果的评审中，必须要严格验证计划和实际的执

行是不是有偏差，体现在最终报告的内容是否和测试的计划保持一致，然后，就可以开始着手制作下一个测试计划了。

作者Blog：/zyqlc/