【1+X】软件测试计划

想看更多内容请移步专栏

转载：【1+X】软件测试技术 - 软件测试计划 - 蓝桥云课 (lanqiao.cn)

软件测试计划

知识点

• 软件测试需求分析
• 什么是软件测试计划
• 编写测试计划的作用
• 做好软件测试计划的关键
• 软件测试计划的具体内容

简介

中国有句俗语“凡事预则立，不预则废”，这里的“预”就是计划的意思。在软件项目中有项目计划，而软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。如何规划整个项目周期的测试工作，如何将测试工作上升到测试管理的高度都依赖于测试计划的制定，详细的测试计划可以帮助测试组之外的人了解为什么和怎样验证软件产品。

本章重点讲解软件测试需求分析、软件测试计划的概述、以及如何编写软件测试计划的各项内容，如项目背景、术语定义、测试范围、测试策略、测试工具、角色分工、任务分工、进度计划以及测试进入和退出的标准、风险及风险分析等内容。

软件测试需求分析

制定软件测试计划的前提是对软件产品进行需求分析。而作为测试人员一定要了解需求相关工作内容。IT 行业有句话是这么说的“一个优秀的产品人员是半个测试人员，而一个优秀的测试人员是半个产品人员”，也说明了这两个岗位的工作内容有一定的重合度。本书不对需求环节做过多的介绍，只重点说明不同类型的软件需求的获取方式以及测试人员在需求评审的时候应该做什么。

根据需求来源的不同，软件分为产品类软件和项目类软件，每种软件需求获取方式不一样，对人员素质要求也不一样。

• 项目类软件

项目类软件的需求由特定用户以合同等契约形式明确下来。需求是通过和用户交流沟通的方式，比如访谈、交流、一起工作等渠道获取。它要求需求获取人员具有良好的业务背景、很好的交流沟通能力和亲和力，还需要具有很强的分析能力。

• 产品类软件

产品类软件没有特定用户以合同形式明确需求。需求主要由市场分析人员分析潜在客户的潜在需求获得，开发的产品源于公司已有的一些项目、技术专利等。比如 office、Photoshop、微信等软件。产品类软件的需求获取一般通过市场调查、问卷、用户反馈、心理分析研究等方式，需要我们的需求获取人员具有深厚的业务背景、敏锐的洞察力、前瞻的预测能力和创造性思维。

虽然需求的获取通常是需求人员去做，测试人员只需要根据需求规格说明书进行测试需求分析即可，但尴尬的是，通常测试人员并没有足够的需求文档来指导测试，这个时候测试人员学会一些需求获取的方法就会非常有用了。

测试需求的分析是整个测试过程的基础，被确定的测试需求项必须是可核实的，它们必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。这里所说的测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，测试需求的分析还包括与客户的交流以澄清某些混淆，并明确哪些需求是更为重要的。其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。

软件测试需求分析的作用非常重要，这里引用一项调查的结果来说明它的重要性：

一项调查的结果表明：56%的软件缺陷其实是在软件需求阶段被引入的，而这其中的 50%是由于需求文档编写不明确、不清晰、不正确等问题导致的，剩下的 50%则是由于需求的遗漏导致的。

所以经常会发生这样的现象：项目组开发出来的软件，虽然已经通过了严格的测试和质量保证人员的确认，但依然会收到很多用户抱怨，甚至开发者团队自身可能都不喜欢使用。原因就是需求从一开始就是错误的。

为了避免出现“需求从一开始就是错误的”现象，软件测试人员需要对软件的需求规格说明书进行测试，而且要尽早参与需求评审会。

• 什么是评审？

IEEE729-1983 规定：在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。

评审的目的是在软件开发与测试的各个阶段进行相应的检查，有利于软件产品与过程的质量提高。据笔者的工作经验来看，通常会发生测试人员参加需求评审会不知道如何下手的情况。测试人员虽然参加需求评审，但大多数人提不出建设性的问题，或者干脆不提问题，只是去需求评审会上学习而已，这样的评审态度是不正确的。如果在需求评审中不提出和可测试性相关的问题，会给后期的测试带来很大的困难，甚至会设计出错误的测试用例，导致测试质量的下降。

测试工程师应主要是针对“需求是不是可测试”来进行评审，这里列一个需求可测试检查单，见下表所示（软件测试工程师需求评审检查单）。

序号	检查单
1	需求中的每个规格是否都有明确的说明？
2	软件的需求的表述是否清晰？
3	软件的需求是否存在二义性？
4	是否对特定含义的术语给予了定义？
5	需求是否有自相矛盾的情况？
6	需求中有没有遗漏一些异常的约束关系？
7	需求中有没有包含不确定的描述，如：大约、可能、等。
8	环境搭建是否有困难或可能有困难？

软件测试计划概述

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

什么是软件测试计划？

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

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

一般情况下，软件测试计划采用的形式是书面文档，但是不能片面地认为制定软件测试计划就是写一篇文档。实际上，文档只是创建详细计划过程的一个副产品，并非计划过程的根本目的，测试过程的最终目标是交流软件小组的意图、期望、以及对将要执行的测试任务的理解。所以重要的是计划过程，而不是产生的结果文档。

但这并不是说描述和总结计划过程结果的最终测试计划文档就不需要了，相反，仍然需要有一个记录计划过程的结果文档作为参考和归档使用—在一些行业这是法律的要求。

编写测试计划的作用

在项目管理中，决定着项目成败是项目三约束条件 TRQ。T-Time（项目进度）、R-Resource（项目资源配置/成本）、Q-Quantity（项目范围）。如下图所示。

项目管理就是以科学的方法和工具来寻找这三者之间的平衡点。项目三约束中强调了这三者之间的制约平衡关系，比如当功能范围“Q”发生变更的时候，通常会通过增加人力资源“R”或者拉长“T”来平衡；同样当资源“R”发生减少的时候，通常会减小功能范围“Q”或者拉长项目时间“T”来平衡，所以三者达到了互相约束的作用。

但通过实际项目的经验来看，当项目因为某种原因不能按计划完成，而 TRQ 都固定的情况下，项目组成员往往会选择牺牲项目质量，使软件变得粗制滥造。所以可见软件质量在项目管理中也是一个非常重要的约束条件，所以项目三约束中的“Q”应该是指 Quantity+Quality（项目范围+项目质量），从而变成影响项目成败的四个关键约束。而覆盖项目质量的文档就是 QA 计划或软件测试计划，所以软件测试计划是保证项目成功的重要因素之一。

软件测试计划是指导测试过程的纲领性文件，在项目执行中发挥核心作用，设定了测试准备工作和执行测试的必备条件，同时形成了测试过程质量保证的基础。

综上所述，关于编写软件测试计划的好处总结如下：

• 软件测试计划是保证项目成功的重要因素之一；
• 管理者可以根据测试计划做宏观调控，进行相应资源的配置管理；
• 可以增加团队间交流，使测试人员了解整个项目不同阶段所要进行的工作安排；
• 便于其他成员了解测试人员的工作内容，配合有关工作；
• 如果是项目式软件的话，可以通过测试计划交代的内容，比如测试过程、人员技能、资源、使用工具等信息，给客户信心。

但需要记住一个核心的基本点，编写软件测试计划的重要目的就是使测试过程能够发现更多的软件缺陷。

如何做好软件测试计划工作

做好软件的测试计划工作并不是一件容易的事情，需要综合考虑各种影响测试的因素。为了做好软件测试计划，需要注意以下几个原则：

测试计划的制定越早越好

测试计划越早制定越好，通常需求文档评审通过后，测试组就需要开始测试计划工作了，并通过计划过程形成测试计划文档。当然，对于开发过程不是十分清晰和稳定的项目，测试计划也可以在总体设计完成后开始编写。

坚持 5W1H 的基本思路，明确软件测试计划内容的 6 要素

• Why（何因？）：测试的目标。指为什么要做测试？测试的目标必须是明确的、可量化的，而不是模棱两可的宏观描述。
• What（何事？）：测试的范围和内容。要测试什么功能？测试范围必须高度覆盖功能需求，并突出关键部分，确定测试内容的优先级。这需要我们准确理解被测软件的功能特征、应用行业的知识。
• When（何时？）：指测试的开始和结束日期。测试各阶段的时间安排要明确合理，并且要与项目计划和开发计划密切结合。
• Where（何处？）：指测试环境及测试文档的存放位置。比如在哪里进行测试？测试系统的哪个部分？对于测试文档的存放，在《软件测试流程》部分，也有讲到，测试文档通常会使用文档管理工具进行管理，此处不赘述。
• Who（何人？）：测试的人员安排、任务分工。谁来做测试的设计？谁来做测试的执行？人员分工要根据每个测试人员的特点进行安排，“好钢用在刀刃上”。
• How（何法？）测试的方法和工具。如何进行测试？如何组织人员？如何规避项目风险？等。测试方法要切实可行，测试工具要具有较高的实用性，生成的测试结果直观、准确等。

“5W1H”原则是制定测试计划时需要考虑的最重要的 6 个要素。牢记这 6 点，会使制定测试计划的工作变得容易起来。虽然软件测试计划一般是由测试经理去编写，但作为软件测试新手，也要准备着向测试经理为测试计划提供内容。

采用评审和更新机制

测试计划编写完成后，一般要对测试计划的正确性、全面性以及可行性等进行评审，评审人员的组成包括项目经理、软件开发人员、测试人员、测试负责人以及其他有关负责人。如果没有经过评审，直接发送给测试团队，测试计划内容可能不准确或遗漏。因为可能需求发生了变更，而测试计划没有及时更新，也有可能受编写人员自身经验和对软件需求的理解所限而导致内容不完善。

所以一定要对软件测试计划进行评审，而且根据审阅意见和建议进行修正和更新。即便如此，在后续的软件测试执行过程中，仍然会出现“计划赶不上变化”的情况，所以软件测试计划需要不断更新。

软件测试计划要简洁、易读

编写软件测试计划要避免 “大而全”，无所不包，长篇大论，既浪费写作时间，也浪费测试人员的阅读时间。“大而全”的一个常见表现就是测试计划文档包含详细的测试技术指标和测试用例。最好的方法是分开创建测试计划和测试用例以及详细的测试技术指标。

测试计划和测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试用例是完成测试任务的具体战术。

软件测试计划内容

如何编写软件测试计划呢？软件测试计划都包含哪些内容呢？我们先来看一份测试计划的案例模板目录，如下图所示。这个目录是在 IEEE 829 标准的基础上编写的一份比较实用的测试计划目录，以下就这些内容一一来做分析，并以此来带领读者掌握计划的编撰过程。

项目概述

项目背景

项目背景中需要列出测试计划所从属的软件系统的名称。说明没有这个产品的时候所处的“悲惨境地”；还要说明这个产品解决了什么问题，能达到什么样的美好未来，以及促成这个转变所需要的产品功能点。例如：

软件系统的名称：《学生考试系统》

组织学生考试工作是教学管理中的一项重要工作内容，但现在学院对于学生考试的管理还采取人工出题、组卷、纸张打印的方式，效率明显太低，而且成本也相对比较大，也不环保。随着信息时代的发展以及计算机广泛的普及，人们的日常学习办公越来越离不开计算机，而对于学校的教务管理中心和老师来说，若能有一套有效的学生考试系统，无疑会大大的提高效率，方便对学生考试的管理。因此，项目组准备开发一套功能完善的考试系统软件，快速处理出题、组卷、发布试卷、以及参加考试等功能。该系统包含学生端和教师端 2 个部分。学生端的功能主要是：学生信息展示、学生登录功能、学生参与考试及查看考试解析等；而教师端的功能主要是：学生信息录入、试题录入、组卷、发布考试、教师阅卷等。

编写目的

是指编写这个文档要达到的目的。比如：

• 使项目测试工作的所有参与人员（客户方参与人员、测试管理者、测试人员）对本项目测试的目标、范围、策略、方法、组织、资源等有一个清晰的认识；
• 使项目测试工作的所有参与人员理解测试控制过程；
• 从策略角度说明本项目测试的组织和管理，指导测试进展，并作为项目测试工作实施的依据；
• 为测试工作提供了一个整体框架和规范。

计划受众

是指可能会阅读和参考这份文档的人员。预期的读者主要有两类受众：测试管理人员（项目经理、客户指派人员）和测试人员。

• 项目经理可以根据该测试计划制定进一步的计划、安排（工作任务分配、时间进度安排）和控制测试过程；
• 客户指派人员通过该测试计划了解测试过程和相关信息；
• 测试人员根据该测试计划中制定的范围、方法确定测试的需求、设计测试用例、执行测试和报告缺陷。

术语定义

项目小组中的全部成员在高级质量和可靠性目标上达成一致是一件困难的事情，如对于软件缺陷的定义：

• 软件未实现产品说明书要求的功能；
• 软件出现了产品说明书中指明不应该出现的错误；
• 软件实现了产品说明书未提到的功能；
• 软件未实现产品说明书虽未明确提及但应该实现的目标；
• 测试人员认为软件不好用，或者不应该出现的功能。

能确认小组全部成员都知道、理解这个定义吗？更重要的是：开发人员同意这个定义吗？项目经理知道软件测试人员的目标吗？如果不是这样，可以想见争执在所难免。测试计划的过程就是保证他们要理解和同意。

所以，术语定义的第一个作用就是让小组内全体人员说法一致。另外也是为了让非专业人士也能看懂这份测试计划文档，因为非专业人士可能并不懂什么是冒烟测试、什么是流量、吞吐量等，那么看文档的效果就会打折。所以我们要进行术语定义，以减少歧义和沟通成本。在术语定义中需要列出文中出现的专门术语和外文首字母组词的原词组，包括通用词语在本文中的专用解释。例如下表所示：

参考资料

写测试计划，不是凭空写出来的，要有一定的依据。所以需要列出用到的参考资料，参考资料通常包括如下几种：

• 本项目经核准的计划任务书、合同或上级机关的批文；
• 属于本项目的其他已发表的文件；
• 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明这些文件资料的来源。

比如：

• 《计算机软件工程规范国家标准汇编 2003》，中国标准出版社；
• 《GBT 15532-2008 计算机软件测试规范 2008》；
• 《GBT 9386-2008 计算机软件测试文档编制规范 2008》；
• 《某某项目需求规格说明书》V1.5 版，项目小组内部文档；
• 《某某项目开发计划书》V1.2 版，项目小组内部文档；
• 《某某项目产品原型图》V1.7 版，项目小组内部文档；

测试范围

测试范围用于确定哪些内容要测试，哪些不要测试。有时会惊讶的发现软件产品中包含的某些内容不必测试。这些内容可能是以前发布过或者测试过的软件部分。计划过程需要验明软件的每一部分，确定它是否要测试。比如有的项目是把几个项目整合到一个大的系统中去，那么就需要事先确定好，是测试全部的子系统，还是仅仅测试其接口部分。

我们通常根据功能范围整理测试范围，包括各模块所包含的功能和项目负责人特别确定的测试范围。可以采用 WBS 来分解测试任务。也可以采用 Excel 格式列出被测模块的功能大纲，如下表所示。

注意：测试范围中比较容易忽略手册、使用说明等文档和数据库的测试，通过《软件测试概述》的学习，我们知道软件是程序、文档和数据的集合，所以文档及数据的测试也应包含在测试范围中。

测试策略/方法

测试策略是描述测试小组用于测试整体和每个阶段的方法。

面对需要测试的产品，使用黑盒测试技术还是白盒测试技术？如果决定使用这两种技术，那么在软件的什么地方使用白盒测试技术，什么地方使用黑盒测试技术？兼容性测试需要做吗？ 界面测试需要做吗？某些代码用手工测试，而其他代码用工具和自动化测试也许是个不错的想法。如果要使用工具，那么是否需要开发，或者能够买到已有的商用解决方案？如果是，选择哪一种情况？

做决策是一项复杂的工作----需要由经验相当丰富的测试员来做，因为这将决定测试工作的成败。使项目小组全体成员都了解并同意预定计划是极其重要的。

测试策略这一项需要注意以下几点：

• 列出对测试对象进行测试的推荐方法；
• 对于每种测试，都应提供测试说明，并解释其实施的原因；
• 将要使用的测试技术以及完成标准；

我们来看几个测试策略/方法的使用，如下表所示。

测试资源

测试资源包括软硬件资源和人力资源。在项目期间测试可能用到的任何资源都要考虑到。详细列出例如：

• 人员：人员数量、经验和专长？他们是全职、兼职、合同还是学生？承担什么角色？
• 设备：计算机、测试硬件、打印机、工具
• 办公室和实验室空间：在哪里？有多大？如何布局？
• 软件：文字处理程序、数据库程序和自定义工具。要购买哪些东西？要写什么材料？
• 外包测试公司：用他们吗？选择他们有什么原则？他们的费用如何？
• 其他设备：磁盘、电话、参考书、培训资料。在项目期间还需要别的吗？

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

软件资源和硬件资源

以下是展示硬件资源和软件资源的一个案例：

硬件资源：
主体：Thinkpad 笔记本电脑 CPU：第十代智能英特尔酷睿 i7-1065G7 处理器，1.3GHz 睿频至 3.9GHz。 内存：8G 显卡：LED 背光、分辨率 1920x1080、宽屏 16:9、集成显卡，支持双屏显示 硬盘：1 块 SCSI 系统硬盘 512G SSD 机箱：带有配套视频接口背板的机箱

软件资源：
操作系统：Windows 10 操作系统 浏览器：IE10、Firefox33.1.1、Google Chrome81.0.4044.92

测试人员配置

测试团队所涉及到的工作角色，通常有测试项目负责人、测试分析员、测试设计员、测试开发人员、测试员、测试系统管理员以及系统配置管理员。在实际实施测试工作时，配置管理员通常由软件开发项目的配置管理员承担；当独立的测试组织实施软件测试时，应配备测试活动的配置管理员。一个人可以承担多个角色的工作，一个角色也可以由多个人承担。这些工作角色所对应的具体职责如下表所示。

测试工具

测试工具是指本项目中所用到的测试工具。测试过程涵盖单元测试、集成测试、系统测试、回归测试、交付测试等各个阶段，如何有效地组织管理起这些不同阶段的测试尤为重要，这就需要软件测试工具的辅助。比如软件测试管理工具、功能测试工具、性能测试工具等。软件测试管理工具能管理整个测试过程，从测试计划、测试用例、测试执行、测试结果到测试报告，提供一个基于中央数据库的、协同合作的环境，即使测试人员分布在各地，也可以随时随地都能参与整个测试过程。除软件测试管理工具之外，还有功能测试工具、性能测试工具等，这个在《软件测试概述》中有讲解到，此处不再赘述。

测试进度

任务分工

在写测试进度这部分内容时，我们应该先明确任务分工，任务分工就是每个人所负责的测试内容。可以参照下表的案例。

“写字板”程序的人员任务分配

测试员	测试任务分配
张三	测试字符格式：字体、大小、颜色、样式
李四	测试布局：项目符号、段落、制表位、换行
王五	配置和兼容性测试
赵六	用户界面测试：易用性、外观、辅助特性
董皊	压力测试和负载测试

实际责任表会更加详细，确保软件的每一部分都分配有人测试。每一个测试员都会清楚地知道自己负责什么，而且有足够的信息开始设计测试用例。最好征求下组内人员意见，尽可能把能力比较强的人放到核心模块上，可以更好的保证质量和控制风险。

测试里程碑

软件测试时间安排很大程度上依赖于开发的时间表，因此测试时间安排应与开发紧密协调。测试进度在测试计划工作中至关重要，因为通常原以为很容易设计和编码的一些必要特性可能后来证实非常耗时。测试进度安排可以为产品小组和项目经理提供信息，以便更好的安排整个项目的进度，他们甚至会根据测试进度决定是否砍掉产品的一些特性，或者将其推迟到下一个版本中推出。

在测试中，通常有几个里程碑，比如系统培训、制定测试计划、设计测试用例、执行测试用例、测试总结报告。进度计划就是完成每个里程碑的开始时间和结束时间，以及对应的工时。如下表所示。

序号	测试活动	计划开始日期	计划结束日期	所需工时
1	系统培训	2025-08-04	2025-08-08	5 个工作日
2	制定测试计划	2025-08-11	2025-08-15	5 个工作日
3	设计测试用例	2025-08-18	2025-09-30	34 个工作日
4	执行测试用例	2025-10-08	2025-11-07	22 个工作日
5	软件测试报告	2025-11-10	2025-11-13	4 个工作日

一般可以安排 3 轮系统测试，每轮测试周期可以根据测试用例的多少，采用最大关键路径法来评估。而整体的测试时间安排可以采用倒推法。

最大关键路径法： 比如：如果张三负责的 A 模块需要 3 天完成，李四负责的 B 模块需要 5 天完成，王五负责的 C 模块需要 4 天完成，那么这轮测试计划的时间就按照 5 天来算。这个时间计算的前提是这 3 人的工作是并行的。

倒推法: 简单的说，如果一个项目是 3 个月，其中 2 个月是开发时间，那最终的测试时间就只有 1 个月了，测试就只能在这 1 个月之内进行计划和安排。

但是在实际的测试进度中，经常会遇到“进度破坏”（Schedule Crunch）的现象发生。也就是由于项目中某部分提交给测试组的时间推迟了导致测试时间压缩的情况。摆脱进度破坏的一个方式就是避免以固定日期制定测试进度表。上表中开始时间和结束时间均采用的是固定时间，这肯定会使测试小组陷入“进度破坏”的境地。可以采用相对日期的形式来规避这种风险。如下表所示。

序号	测试活动	计划开始日期	所需工时
1	制定测试计划	说明书完成后 7 天	2 个星期
2	设计测试用例	测试计划完成	6 个星期
3	执行第 1 轮测试	代码构建完成	3 个星期
4	执行第 2 轮测试	Beta 版代码构建完成	3 个星期
5	执行第 3 轮测试	发行版构建完成	2 个星期
6	测试总结报告	软件测试到达最佳平衡点	1 个星期

另外，关于测试进度还有一个需要注意的事情，就是测试工作通常不能平均分布在整个产品开发周期内，有些测试以说明书和代码审查、工具开发等形式在早期进行，但是测试任务的数量、人员的数量和测试花费随着项目的进展不断增长，在产品发布时会形成短期的高峰。可以制作一个人员随时间的增加而增加的图或表来说明，如下图所示。

项目经理或者测试经理最终负责进度安排，可以使用进度管理工具进行管理，比如前面讲过的禅道。

测试的准则

在测试过程中，经常会遇到一个情况，系统提交给测试人员的时候，根本无法运行或者页面访问失败；或者测试人员根本不知道他们修改了什么内容，根本原因就是测试组没有就测试准则和项目组成员达成一致意见。

设置测试准则需要注重实用性。测试准则通常包括测试进入、暂停、恢复和退出的准则。

• 测试进入的准则：是指开始执行测试的时机；
• 测试暂停的准则：描述系统在什么情况下暂停全部或部分测试工作；
• 测试恢复的准则：描述系统恢复测试的必要条件；
• 测试退出的准则：描述测试退出的条件，有正常退出，也有非正常或意外的退出。

下面以“系统测试准则”为例，向读者介绍它的具体内容，如下表所示：

测试准则，需要在制定测试计划时和相关人员沟通，且得到项目经理审批通过。

风险及应对方案

测试工作的风险是指对测试工作有影响的地方。以下列出在测试过程中可能遇到的风险，供读者参考：

• 需求风险。需求理解不准确或者需求发生变更而导致测试时间被压缩的风险。
• 测试用例风险。测试用例设计不完整导致测试时间被压缩的风险。
• 缺陷风险。缺陷难以复现或者没有很好的被跟踪的风险。
• 代码风险。代码质量差、修改难度大；或者系统架构设计不足导致扩展性不足的风险。
• 测试环境风险。测试环境数据量不足可能导致测试结果误差；再比如一些功能（如支付功能）无法在测试环境进行实际测试，可能导致实际生产环境出现问题。
• 测试技术风险。测试人员技能局限导致测试结果不准确的风险。
• 回归测试风险。回归测试时，业务流程不通导致修复验证，从而造成进度延后的风险。
• 沟通协调风险。部门之间的沟通协作不畅的风险，比如需求变更没有及时沟通，测试结果的反馈不及时等问题。
• 研发流程风险。研发流程不规范导致的一些临时风险。
• 其他不可预计的风险。比如一些突发状况、不可抗力的因素。

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

对于风险，要尽量避免，同时要做好备份方案和容灾机制，规范流程，明确职责，尽可能将风险降到可以接受的范围。

常见的风险应对方案，如测试时间不够，可以加班或者增加测试力量；测试人员技术不纯熟，可以组织成员培训；如考虑到有人员离职或请假，可以提前设定好后备力量。

测试提交的文档

软件测试计划应规定测试完成后测试人员需要归档的文档。如软件测试计划、软件测试用例、软件缺陷报告、缺陷处理日志、软件测试总结报告等。

小结

本章介绍了软件测试需求分析、软件测试计划概述以及如何编写软件测试计划文档。用最大的篇幅介绍了在需求分析的前提下，如何通过对测试过程的计划，来编写软件测试计划的最终文档。除此之外，读者在以后的工作中可能还会听到“测试方案”一词，要明白二者是有区别的。

这里需要注意的是，软件测试计划的内容和格式不是一成不变的，也有公司和专家推崇“一页纸测试计划”。不管是标准规范的软件测试计划文档，还是“一页纸测试计划”文档，它们都只是软件测试计划的副产品，测试计划的过程才是计划的重点。虽然由软件测试经理填写模板的空白项很容易，几个小时甚至更少时间就可以打印出一份软件测试计划来，但这样显然没抓住重点，等到参与项目的测试人员对软件测试计划中的内容一无所知的时候就看出这样做的弊端了。要想编写出来的软件测试计划文档实用有效，就必须重视计划的过程，否则软件测试计划只能是“废纸一张”，在实际工作中被“束之高阁”。