相信大多数的软件测试工程师都听说过或者简单了解过测试计划，但是你真的知道什么是测试计划么？你真的知道如何编写测试计划么？大多数人应该是一脸茫然。百度的结果五花八门，有没有相对规范的标准呢？答案是没有，至少我没有找到。那么今天我就结合经验和对一些国内技术前沿的公司跟大家聊一聊什么是测试计划以及如何编写测试计划。
  计划的必要性：
  在我们日常的工作和生活中，经常需要做计划。古人云：凡事预则立，不预则废（《礼记.中庸》），也就是强调预先计划的重要性和必要性。
  我们做项目，项目需要定项目计划；测试作为项目中的一部分，当然也需要制定测试计划。

• 测试计划就像是我们写论文一样，首先做好提纲，才能一步一步的完善填充，有了测试计划就掌握了整个项目的进度和方向，在工作中可以有个指导的作用，不至于偏离工作方向；
• 测试计划规定预期的目标，以什么样的程度完成和在预期多久内完成，这样的规定能够使工作人员做好心理准备，合理的期限和目标能够使工作人员不松懈，有效率的完成一个项目；
• 计划作为对未来工作的规划，肯定会受到突发的或者不稳定的因素影响而导致整个项目出现延期甚至无法进行的结果。因此计划中对于风险评估的必要性就在于罗列出影响整个项目进行的因素，并制定相应紧急方案，将损失降至最小化；
• 人员的安排呈现合理化。任何一个项目内的工作都有难易繁简的划分，因而才需要有专长的工程师进行对应的测试。难度较大的由资深测试人员安排，难度小的由新进实习生来进行，整个项目的进行就会显得合理化层次化条理化。同时将职责清晰地具体划分到个人身上，也有利于日后的纠错，及时发现哪个环节出现问题；
• 测试计划的制作是在需求分析完成之后所进行，所以测试计划的执行在一定程度上也是对需求分析的进一步的检验，若在制定过程中，发现有不合理的因素存在，还能及时反馈，进行调整，不至于使众多的人力做了无用功；
• 测试计划的安排也是一个项目中多个部门间合作的工作指导，一环扣一环，工作的交接在时间上做好详细的备注，才能让部门的合作显得默契。

  一个测试计划制定者的素养：

• 有多年从事测试工作的经验，能够条例清晰的罗列出测试中的流程和应当留心的步骤，以及不可缺少的风险规避的意识
• 对于部门的员工能力要有一定程度的了解，才能合理的安排工作内容
• 高压下的冷静处理能力，一旦项目出现突发的严重问题，能够冷静找出出错环节。
• 人际沟通的能力，一个测试计划也是有与其他部门之间的合作关系，需要与其保持及时有效的沟通，了解到他们的需求

  那么我们什么时候来做测试计划呢？
  一般来说，在产品需求确认，做过测试需求分析之后我们就要开始编写测试计划。当然测试计划编写的工作要根据工作实际来决定，也就是具体情况具体分析（政治课学的哈~）
  其实，要想做好测试计划必须有一定的测试经验。那么下面我就结合工作实际，跟大家聊一聊测试计划的内容。
  测试计划的内容：

• 测试范围 明确测什么？比如：产品的具体业务需求有哪些？产品是web端的还是移动端的，还是两者都有？

• 测试策略 明确怎么测？对不同业务需求，具体要有哪些测试类型、测试场景、测试方法。

• 资源安排 包括测试人员的安排，测试环境是怎样的，测试工具的选择等。

• 进度安排 在明确测试范围、方法和人员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接。

• 发布标准 发布标准是测试完成和产品上线需要满足的条件，以便项目内所有角色都有一致认可的目标。怎样才算是测完了？达到怎样的标准才可以上线？

• 风险预防 最后，我们需要对整个测试过程中可能存在的风险，以及当这些风险发生时的应对措施提前进行一些考虑和准备，并在测试计划中体现出来。

  我们把这些内容模板化，形成测试计划的模板。无论是在实际的工作中还是大家学习编写测试计划，都可以用这样的模板来使用。

在此模板的基础上，我们一点点来剖析如何编写测试计划。

这里的参考资料可以有：（可行性分析报告、软件需求定义、软件系统分析、软件概要设计、软件详细设计、软件测试需求、硬件可行性分析报告、硬件需求分析、硬件概要设计、硬件原理图设计、硬件结构设计、硬件测试需求、模块开发手册、测试时间表及人员安排、测试计划、测试方案、测试报告、测试分析报告、用户操作手册、安装指南等）
2 测试范围
测试范围的确定来自于需求文档，依据是项目的交互稿和需求分析结果
2.1功能测试范围的分析
功能点的拆分、接口测试、UI测试
2.2系统测试范围的分析
（1）容错处理
（2）兼容性要求
（3）配置要求
（4）性能要求
（5）安全性要求
（6）可靠性、日志文件

3.测试策略
为了更好确定软件测试策略，可以问如下一些问题：
(1).回归测试的范围如何确定？
(2).如何利用可重复性的测试？
(3).测试缺乏可预见性，如何收集衡量测试结果的指标？
(4).如何建立稳定的、模拟系统实际运行的测试环境？
(5).如何从无穷的输入数据中选择合理的、有效的测试数据集？
(6).如何衡量这份测试策略的有效性？
1、基于测试技术的测试策略
(1).任何情况下都要使用边界值分析方法
(2).等价类划分法是对边界值分析方法的有效补充
(3).如果功能的输入数据/条件存在多种组合情况，则使用因果图
(4).错误推测法
(5).对照程序逻辑来审查已有测试用例的逻辑覆盖程度
(6).白盒测试
2、分阶段的测试策略
(1).严格执行代码审查
(2).单元测试和集成测试，准备自动化测试
(3).系统测试中，以每次发布用户基线为结束标志
(4).不能忽略安全性测试、可用性测试、配置测试和数据完整性测试
(5).在功能测试、安全性测试、配置测试中进行探索性测试
3、基于测试方案的综合测试策略
(1).测试优先级，优先级越高，越早测试，测试力度越大
(2).使用尽可能少的测试用例，发现尽可能多的程序错误
(3).测试策略尽量简单、清晰
(4).基于缺陷分析的测试策略

4、测试资源
测试人力资源包含两个维度：
1、测试人员数量
2、测试人员经验、能力。
环境资源一般包括：
1、测试服务器环境（尽量与线上环境保持一致）
2、终端环境（PC配置，手机型号）
3、测试工具（bug管理工具，用例管理工具，性能测试工具等）
在我们的测试计划中，测试人员分配、测试环境资源、网络资源、工具使用都要明确写出来。

5、进度安排
测试工作的进度安排依赖于开发工作的节点和提交测试进度的时间，并且直接影响预期的上线时间。所以我们需要根据产品业务的复杂度、所需要进行的不同的测试类型的复杂度、产品上线的质量要求的高低、测试人员的数量、能力和经验这些因素，来评估不同阶段、不同类型的测试工作的工作量。
可以用工作分解结构表方法评估工作量：
1、列出本项目需要完成的各项任务
2、细化每个任务，尤其是测试阶段，需要对模块进行拆分，拆分到可衡量和细化的维度
3、预先设计测试点，按照测试点来估算
4、给每个维度估算时间，需要优化和重复操作的部分
5、在已估算结果上浮动10%-15%

6、发布标准
测试完成的标准，也就是说做到什么样算是测试工作做完了。主要包括：
1、测试计划里所有测试类型都已经完成了
2、功能上、兼容性上没有影响用户使用的Bug
3、允许遗留小部分影响不是很大的Bug，但这个数量应该小于一个值
4、性能上符合设计目标和上线要求 这些标准都是针对测试工作本身的要求。
在满足了测试本身的前提下，产品要发布还需要满足要求：
1、产品需求都已完成
2、交互视觉走查都已完成
3、一流的小部分Bug项目组完成了风险评估，都认可且问题不大
4、产品使用说明或用户手册或更新log都已完备等等。

7、风险说明
测试风险分类：
1、测试范围的风险，测试遗漏、需求变更；比如说一开始测试需求分析不准确、不到位漏了测试点，甚至某个测试类型遗漏了，这样问题就比较大了，所以测试需求分析是整个测试工作的基础，还有就是产品需求变更的风险，加需求、减需求、改需求都需要重新进行测试需求分析，需要测得一定要测到，不需要测的就不要浪费人力物力和工作量；
2、测试进度的风险，工作量预估不准确、耦合任务延迟、测试人员变动；比如说做计划时工作量估计的不准，测试做着做着发现时间不够导致项目延期，还有测试依赖开发，可能开发工作没有按时完成或改bug不及时导致进度延后，还有可能测试人员因为别的项目更重要抽调走了或者请假、离职等原因造成人员变动；
3、产品质量的风险，代码质量、测试人员能力；比如开发的代码质量比较低或者测试人员是新人对业务不熟悉，能力和经验有所欠缺等等。
测试风险的控制方法：
1、根据风险发生的概率和带来的影响确定风险的优先级，然后才去措施避免那些可以避免的风险；
2、风险转移，比如去掉新功能，转移风险；
3、不可避免的风险，就设法降低风险，如提高测试用例的覆盖率；
4、事先做好风险管理计划，喜欢里程碑和验收管理；
5、有一套应急、有效的处理方法，比如全员了解，注意日常观察，及时发现风险出现的征兆；
6、做计划时，要留有余地
7、制定文档标准。

  到这里我们就完成了一份测试计划。有的人可能依旧存在疑问：做计划真的有那么重要么？我们实际工作中有很多项目根本就没有计划依旧可以完成的啊！我们来看一下不做计划可能会有哪些问题~
 首先，如果没有计划我们无法预估工作量和需要的测试人员数量。一个项目的工作量和需要的人员数量都没有依据，在公司里怎么来协调和安排呢？
 其次，测试人员的分工明确，会导致工作重复和遗漏。出了问题大家可能都觉得不是自己的问题，导致工作混乱效率低下。
再就是测试进度失控。到底什么时候做完没有一个预期，其他的团队怎么安排工作呢？进度有没有失控也没有判断依据，临到预计的上线时间才发现还有很多没有测到、没测完，直接影响整个项目的进行。
还有就是应对需求变更困难，对可能出现的风险没有准备。一旦出现问题，大家一片混乱，很容易导致测试遗漏和项目延期。
 最后就是没有统一发布标准，上线意见不一致。测试团队认为Bug太多不能上线，开发团队认为都是小Bug不要紧，先上线再说，导致争执不下的局面。、
 当然根据项目不同还可能存在其他一些列问题…
 总而言之，测试计划的作用非常重要。

• 指导测试过程
• 协调项目安排
• 提高测试效率
• 提高测试质量
  做测试计划对测试人员的能力和要求是非常高的，从另一个角度来说，测试计划可以体现一个测试人员的自我修养。一个测试人员需要很好的经验沉淀、有很多好的全局意识才能做好一个项目的测试计划。
  希望大家都能够很好的胜任编写测试计划这项工作。

一、概括

软件测试工作流程主要包括：

①　测试需求分析阶段；
②　测试计划阶段；
③　测试设计阶段；
④　测试执行阶段；
⑤　测试评估阶段。

具体而言：

①　测试需求分析阶段：阅读需求，理解需求，主要是对业务的学习，分析需求点，参与需求评审会议。
②　测试计划阶段：主要任务是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，整体测试策略的制定。风险评估与规避措施有一个制定。
③　测试设计阶段：主要是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。
④　测试执行阶段：搭建环境，执行冒烟测试（预测试），然后进入正式测试，bug管理直到测试结束。
⑤　测试评估阶段：出测试报告，确认是否可以上线。

二、测试需求分析的目的

1.把用户需求转化为功能需求：

1）对测试范围进行度量；
2）对处理分支进行度量；
3）对需求业务的场景进行度量；
4）明确其功能对应的输入、处理和输出；
5）把隐式需求转变为明确。

2.明确测试活动的五个要素：

1）测试需求是什么：测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。
2）决定怎么测试；
3）明确测试时间；
4）确定测试人员；
5）确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。

三、测试需求分析

1.确认功能

1）业务功能：与用户实际业务直接相关的功能或者细节；
2）辅助功能：辅助完成业务功能的一些功能或者细节，例如：设置过滤条件；
3）数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围，数据之间的关系等；
4）易用性需求：功能的细节，产品中必须提供，便于功能操作使用的一些细节，例如：快捷键等；
5）编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束条件，例如：只能输入数字等；
6）参数需求：功能的细节，在功能执行时，需要根据参数设置不同，进行不同处理的细节；
7）权限需求：功能的细节，在功能执行的过程，根据不同的权限进行不同的处理，不包括直接限制某个功能的权限；
8）性能约束：功能的细节，执行功能时，必须满足的性能需求。

2.场景分析

1）考虑场景的调用者：考虑每一个场景提供的服务是供哪些外部模块或者系统调用的，找出所有调用者。调用前提，约束都要考虑。每一个调用都可以考虑成一个大的业务流程（一般和外部有交互的业务出错率比较大，需要重点关注）；
2）考虑系统内部各个场景之间的：形成内部业务流程，需要分析每个场景之间的约束关系，执行条件，组织出各种业务流程图。

3.挖掘隐性需求（需要测试工程师的经验积累）

1）常用的或者规定的业务流程
2）各个业务流程分支的遍历
3）明确规定不可使用的业务流程
4）没有明确规定但是应该不可使用的业务流程
5）其他异常或者不符合规定的操作

以上是粗略的讲解了如何进行测试需求分析，在需求分析过程中通过参考需求规格说明书来编写整个测试计划，这个阶段一般情况下是测试主管编写的。包括测试人员，测试时间，测试工具，以及测试方法等。

四、测试用例设计

测试用例是测试工作的最核心的模块，在执行任何测试之前，首先必须完成测试用例的编写。测试用例是指导你执行测试，帮助证明软件功能或发现软件缺陷的一种说明。用例设计好后进行审核。这个地方该讲的东西就多了，如何设计测试用例，设计测试用的方法，怎么进行测试用例的审核等等。

1.如何进行测试用例的设计

编写测试用例之前我们需要对项目的需求有清晰的了解，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数，作为测试用例的编写者不仅了解要有常见的测试用例编写方法，同时需要了解被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构。

2.步骤：

1)测试需求分析：

从项目部拿到软件的需求规格说明书后，开始对项目的需求进行分析，通过自己的分析、理解，整理成为测试需求， 清楚分析出被测试对象具有哪些功能。 明确测试用例中的测试集用例与需求的关系，即一个或多个测试用例集对应一个测试需求。

2)业务流程分析：

分析完需求后，明确每一个功能的业务处理流程，不同的功能点作业务的组合，以及项目的隐式需求。如遇复杂的测试用例设计前，先画出软件的业务流程。从业务流程上，应得到以下信息：
①　主流程是什么?
②　条件备选流程是什么?
③　数据流向是什么?
④　关键的判断条件是什么?

3.测试用例设计

完成以上两步则可进行测试用例设计，功能测试用例，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。
设计测试用例的常见方法：
1）等价类
2）边界值
3）因果图
4）判定表
5）状态迁移
6）正交实验
7）场景法
8）错误推断
注意：编写测试用例时，我们尽可能取的不应该是有效等价类而应该是无效等价类

4.编写完成后自我检查以及部门内部评审：

1）测试用例本身的描述是否清晰，语言准确；是否存在二义性；
2）测试用例内容是否完整，是否清晰的包含输入和预期输出的结果；测试步骤是否清晰；
3）测试用例中使用的测试数据是否恰当，准确；
4）测试用例是否具有指导性，是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷，而不是限制他们的思维；
5）是否考虑到测试用例执行的效率。对于不断重复执行的步骤，是否保证了验证点相同；或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下；
6）画出软件需求跟踪矩阵，验证测试用例是否完全覆盖了需求，验证测试用例的覆盖性；
7）测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间/成本的关系，应该视具体情况而定。

注：具体详细内容可参考《如何有效的进行测试用例评审》

5.测试用例更新完善

测试用例编写完成之后需要不断完善，如遇需求更改或功能新增时，测试用例必须配套修改更新，同时在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。
五、测试用例执行过程
首先搭建测试环境，准备好测试数据，进行预测，预测通过之后，按照测试用例进入正式测试，有效的测试执行可以将测试用例发挥最大的价值。因此，测试用例规范执行有助于更好的发现代码中存在的缺陷。

根据个人测试工作经验，好的测试执行应该包含如下内容：

1.测试执行中评估测试执行时间不足，需及时上报风险。满足质量优先，进度其次原则。
2.测试用例按优先级顺序执行，通常是基本、详细和异常顺序执行。
3.未执行用例、标志为删除或者无效的用例，需注明原因。
4.执行过程中有疑问的测试用例（场景、操作步骤、检查点等）需找测试设计人员澄清。
5.测试执行需对用例描述的检查点逐一检查，避免遗漏。
6.重视不易重现的缺陷场景，可能是一个bug。
7.执行过程中发现有前期设计遗漏用例需补充到用例文档并执行验证。
8.建议测试人员交叉执行重复测试用例，用例执行对相同测试人员有免疫性。避免可能的缺陷一直遗漏到现网。
9.如有需要，建议保留测试结果，结果可视。也便于不同版本间的测试结果对比。
10.已确认问题需及时按照问题单提单要求（规范和缺陷定级）提单。
11.跟踪问题单修复情况并回归验证问题单。
12.测试结束，将最终测试用例文档上传到归档目录，实现用例重用。

在测试用例执行过程中，包含了：功能测试阶段、缺陷跟踪阶段（bug tracking）、回归测试阶段、系统测试阶段、验收测试阶段等（系统已满足测试条件（开发完成），按照已经评审过的测试用例依次执行，执行过程中及时记录问题，将问题及时提交到禅道上，要跟踪缺陷。等开发修复后进行回归测试，确认修复后关闭缺陷。

六、测试报告

最后已达到准出要求的根据测试情况写测试报告，对整个测试过程和版本的质量做一个评估。
测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。

测试的内容可以总结为以下目录（根据实际情况进行具体调整）：

①　首页
②　引言（目的、背景、缩略语、参考文献）
③　测试概要(测试方法、范围、测试环境、工具)
④　测试结果与缺陷分析（功能、性能）
⑤　测试结论与建议（项目概况、测试时间 测试情况、结论性能汇总）
⑥　附录（缺陷统计）

至此并不算最后的完结工作，软件测试还包含了线上功能检查、当前版本问题反馈以及改进建议 等。这样才算是软件测试最终结束，软件测试是贯穿于整个软件生命周期的。

附录

测试工作流程图解（网图）

注：所有的内容均整理自各路大神，帮助喜欢测试的朋友，谢谢！

如何写好软件测试计划书

软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。

详细的测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。它非常有用但是测试项目组之外的人却很少去读它。

什么样的测试计划书符合要求

软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中，这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

案例：一份看似“不错的”软件测试计划书

下面是某项的测试计划书

提纲挈领，透过这份测试计划书的目录，如何对这份测试计划书进行评价？
在回答这个问题之前，我们先看看测试过程中的一个重要的活动或者阶段——测试计划阶段都需要做什么？这个阶段的产出物是什么？

测试计划阶段的任务

测试计划可以在项目计划或主测试计划中文档化，也可以在不同的测试级别（如系统测试和验收测试）的测试计划中文档化。测试计划文档的大纲可以参考“软件测试文档标准”（IEEE Std 829-1998）。

测试计划受到很多因素的影响：组织的测试方针、测试范围、测试目标、风险、约束、关键程度、可测试性和资源的可用性等。随着项目和测试计划的不断推进，将有更多的信息和具体细节包含在计划中。

测试计划是个持续的活动，需要在整个生命周期过程和活动中进行。从测试中得到的反馈信息可以识别变化的风险，从而对计划作相应的调整。

测试计划阶段需要做的事情

对整个系统或部分系统可能的测试计划活动包括：

• 确定测试的范围和风险，明确测试的目标；
• 决定总体测试方法，包括测试级别、入口和出口准则的界定；
• 把测试活动整合和协调到整个软件生命周期活动中去（采购、供应、开发和运维）；
• 决定测试什么？测试由什么角色来执行？如何进行测试？如何评估测试结果？
• 为测试分析和设计活动安排时间进度；
• 为测试实现、执行和评估安排时间进度；
• 为已定义的不同测试活动分配资源；
• 定义测试文档的数量、详细程度、结构和模板；
• 为监控测试准备和执行、缺陷解决和风险问题选择度量项；

明确了测试计划阶段需要完成工作，就很容易思考一份高质量的测试计划书中应该包括什么内容了。

软件测试计划的文档化（产出物）——软件测试计划书

下面是根据IEEE 829标准编写的一份测试计划的目录：

这份测试计划中：

• 在第2部分明确了被测软件系统（产品）待测的特性和不测试的特性。
• 在第3部分明确了测试目标
• 在第4部分明确定义了准入/准出规则；通过和失败的标准；暂停标准和测试恢复需求

这些内容都是很重要的内容。

最后还描述了：

• 测试提交产出物

对比以上两份软件测试计划书的目录，可以看出第二份软件测试计划书的内容更加合理一些。

如何写好软件测试计划书的内容？

这个问题其实是“仁者见仁，智者见智”。不同的软件测试项目经理或者测试负责人、Test Leader等都有自己的看法。什么内容该写进去？写道什么程度？是否真的用心去写好每一个章节的内容？

现实中，大多数软件测试项目经理或者测试负责人、Test Leader其实内心都是恐惧写文档的。很多时候不是不会写，而是不重视或者只是为了应付工作。原因其实很简单，无外乎有以下几种：

• “文档无用论”，写文档还不如多用一些时间在解决项目问题上；
• 写了软件测试计划其实也没有几个人看；
• 文档其实不被重视；
• 仅仅是为了应付公司品质部门、QAO的检查或者CMMI评估；
• 在工作中测试管理的具体实践活动，依赖的是经验，而不是一份写在纸上的测试计划书；
• 敏捷过程是“轻文档”化的；
• 其它种种原因……

软件测试计划真的仅仅只是一份文档吗？
软件测试计划真的没有用吗？
敏捷过程就真的不需要测试计划了吗？

这些显然是一些借口或者错误的认识。

为什么我们需要测试计划？

无论做什么工作，都是计划先行，然后按照所制定的计划去执行、跟踪和控制。软件测试也一样，先要制定测试计划，是做好整个测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的、有效的测试计划。软件测试计划的目标是提供一个测试框架，不断收集产品特性信息，对测试的不确定性（测试范围、测试风险等）进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得我们对测试的范围、用例数量、工作量、资源和时间等进行合理的估算，从而对测试策略、方法、人力、日程等做出决定或安排。

在编写测试计划之前，可以考虑下面几个问题：

• 为什么要编写测试计划？
  （1）Test Manager/测试主管等能够根据测试计划做宏观调控，进行相应资源配置等；
  （2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；
  （3）便于其他人员了解测试人员的工作内容，进行有关配合工作
• 什么时间开始编写测试计划？
  （测试需求分析前总体测试计划书/测试需求分析后详细测试计划书）
• 由谁来编写测试计划？
  具有丰富经验的测试负责人Test Leader
• 测试计划编写的基本思路（5W1H）
  （1）why——为什么要进行这些测试；
  （2）what—测试哪些方面，不同阶段的工作内容；
  （3）when—测试不同阶段的起止时间；
  （4）where—相应文档，缺陷的存放位置，测试环境等；
  （5）who—项目有关人员组成，安排哪些测试人员进行测试
  （6）how—如何去做，使用哪些测试工具以及测试方法进行测试。

测试计划的要点

测试规划与软件开发活动同步进行，在需求分析时，就开始测试策划，确定测试需求、目标、资源等。测试计划可以按不同的测试阶段（集成测试、系统测试等）来组织，也可以为每个测试任务或目标(安全性、性能、可靠性等测试)进行考虑。

测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等，其关键是制定有效的测试策略，界定清楚地测试范围，识别出测试中所存在的各种风险并找出风险回避、监控和管理的方法，针对不同的测试目标或阶段确定测试方法，对测试工作量及所需的资源、时间进行合理的估算。所有这些，都是为了两个根本目的：测试的质量和效率。

测试计划中需要明确测试范围

测试主要依据“产品设计规格说明书”、代码所发生的变化及其影响的区域，来确定哪些功能和特性要测试，哪些功能和特性不需要测试。在确定测试范围时，主要考虑的因素有：

• 优先级最高的需求功能
• 新增加的功能和编码改动较大的已有功能
• 容易出现问题的部分功能
• 过去测试不够充分的地方
• 经常被用户使用的功能和配置（占20%）
• 哪些不需要测试的功能和特性（排除出测试范围）

在实际的测试实施中，有时候存在测试执行到一定阶段，由于某种原因（例如：环境不具备、测试账号的问题、测试数据的问题、公司安全策略的限制等等导致测试条件不满足，从而一些之前计划在测试范围内的功能，需要排除出测试范围）测试范围需要发生变更。那么这就需要遵守变更流程，并且更新测试计划文档，以及更新后的测试计划获得审批。

这个环节其实常常被Test Leader和Test Manager或忽视。

我遇到过很多类似的情况，没有遵守变更流程，并且更新测试计划获得审批，这最终导致的结果是测试功能混乱；经历2-3个版本迭代之后，被测需求难以追溯。一旦存在产品发布之后出现功能上的问题，用户抱怨不断。其实这就反映出测试计划不合理而导致的问题。

测试估算：所需资源和日程安排

为了合理、准确地安排日程，对测试工作量要进行正确的估计。除了对工作量的估计之外，还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及到不同的项目、不同的测试人员、不同的前期介入方式，要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难，但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理，并适当增加10%-20%的余量，估算结果就比较准确了。
　　
在估算的基础上，进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的，所以人力资源的计划要有一定的灵活性和动态性，形成有机的动态平衡，保证测试的进度和资源的使用的效率。

需要精心编写准备测试计划

要做好测试计划，测试设计人员要仔细阅读有关资料，包括用户需求规格说明书、设计文档等，全面熟悉系统，并建议注意以下方面：

• 让所有合适的相关人员参与测试项目的计划制定，特别是在测试计划早期；
• 测试所需的时间、人力及其它资源的预估，尽量做到客观、准确、留有余地；
• 测试项目的输入、输出和质量标准，应与各方达成一致；

测试计划的主要内容

测试计划的主要内容包括以下要点：

1. 测试计划标识
2. 版本修订记录
3. 简介（目的）
4. 主要阅读者
5. 测试项（交付测试的一切内容）
6. 需要测试的功能
7. 不需要测试的功能
8. 测试项通过/失败的准则
9. 测试准则（入口准则、出口准则、暂停和恢复准则）
10. 测试交付物/产出物
11. 测试任务
12. 进度计划（可以与10.测试任务合并做出一个进度和任务的矩阵，关键里程碑点的描述）
13. 环境需求
14. 工具
15. 职责矩阵
16. 人员和培训的需求
17. 风险和缓解风险/预防风险的对策
18. 批准（测试计划需要进行评审和审批）

有一些时候对上述内容可以进行裁剪。还有一些测试团队/组织会将测试计划与测试策略合并成为一个文档。
我在测试管理中，允许一些小的测试项目或者临时性的测试项目将测试计划（Test Plan）和测试策略（Test Strategy）进行合并。事实上，很多Test Leader，Test Manager是不愿意花费太多的精力去写文档、维护文档的。即便如此，2-3页纸的测试计划还是需要的。此时，测试策略（Test Strategy）就尤为重要了。

测试计划需要评审

测试计划不可能一气呵成，而是要经过计划初期、起草、讨论、审查等不同阶段，才能将测试计划制定好。测试计划的评审是完成测试计划关键的一个环节，包括测试组织内部的自我评审、讨论和修改，然后交到评审会进行正式的评审，直至测试计划得到审批。

测试计划的正式评审，项目中的每个人（产品经理、项目经理、开发工程师等）都应当参与。计划的审查是必不可少的，每一个参与者都可能根据其经验及专长提出问题或建议，弥补在测试范围、工作量、风险等各方面的不足，进一步完善测试计划。

（更新完）