下载掌阅APP，畅读海量书库
立即打开
软件测试计划是一份描述软件的测试范围、测试环境、测试策略、测试管理、测试风险的文档。软件测试计划是作为软件项目计划的子计划，在项目启动前期是必须去规划制订的。《IEEE软件测试文档标准 829—1998》将测试计划定义为“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”
依据这份测试计划，测试管理人员可以保持测试实施过程的顺畅沟通，跟踪和控制测试进度；测试人员就可以有计划地发现软件产品的缺陷，验证软件的可接受程度。接下来对制定软件测试计划的目的、制定测试计划的原则、如何制定测试计划等方面来详细介绍。
软件测试是有计划、有组织、有系统地对软件质量进行保证的活动，而不是随意的、松散的、杂乱的实施过程。为了规范软件测试内容、方法和过程，在对软件进行测试之前，必须创建软件测试计划。那么制订测试计划的目的主要有以下几点：
在软件测试过程中，常常会遇到一些问题而导致测试工作被延误，事实上有许多问题是预先可以防范的。此外，测试计划中也要考虑测试风险，这些风险包括测试中断、设计规格不断变化、人员不足、人员测试经验不足等。对影响测试过程的问题，都要考虑到计划内容中，也就是说对测试项目的进行要做出最坏的打算，然后针对这些最坏的打算拟订最好的解决办法，尽量避开风险，使软件测试工作进行得更顺利。
测试计划将测试组织结构与测试人员的工作分配纳入其中，测试工作在测试计划中进行了明确的划分，可以避免工作的重复和遗漏，并且测试人员了解每个人所应完成的测试工作内容，并在测试方向、测试策略等方面达成一定的共识，这样使得测试人员之间沟通更加顺利，也可以确保测试人员在沟通上不会产生偏差。
制订测试计划为了使整个软件测试工作系统化，这样可以使软件测试工作更易于管理。管理者能够根据测试计划做宏观调控，进行相应资源配置等。测试负责人可以根据测试计划跟踪测试进度。测试人员能够了解整个项目测试情况，以及项目测试不同阶段所要进行的工作。
测试计划是从测试组织管理的角度对一次测试活动进行的规划。它是对测试活动整个过程的组织、资源、原则等进行规定和约束，对测试过程各个阶段的任务以及时间进度安排，提出对各项任务的评估、风险分析和需求管理。制订软件测试计划可以参考以下几个原则：
测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，它只是测试的一个框架，所以不一定太过详细。测试计划的内容会因项目的级别、项目的大小、测试级别的不同而不同，所以它可以包括项目简介、测试环境、测试策略、风险分析、人员安排、资源分配等内容。测试计划不需要很复杂，要注重测试计划的实用性。事实上，测试计划越简洁易读，它就越有针对性。
测试计划是从技术的角度对一次测试活动进行规划工具的设计、测试用例的设计、测试数据的设计。它是描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。所以，测试计划应该被评审，受控于质量控制。
尽早地开始制订测试计划可以使我们大致了解测试所需的资源，并且在项目的其他方面占用该资源之前进行测试。制订测试计划时应预期到测试过程中的各种不确定因素，要能在测试过程中方便地添加测试用例、测试数据等，测试计划部分内容应该是可变的。这种可变要在制订测试计划时限定在可控范围内。测试计划是指导测试过程的纲领性文件为整个测试阶段的管理工作和技术工作提供指南；确定测试的内容和范围，为评价系统提供依据。
测试计划为整个测试阶段的管理工作和技术工作提供指南；确定测试的内容和范围，为评价系统提供依据。测试计划一般包括测试范围、测试策略、测试资源、测试进度和测试风险预估等部分，并且每部分要给出应对可能出现问题的解决办法，测试计划具体内容可以根据软件项目的规模大小、复杂程度来确定。如图 3.6 所示，左侧是《IEEE 829—1988 软件测试文档编制标准》中软件测试计划文档模板，右侧是某软件项目的测试计划文档目录。
编写软件测试计划要避免一种不良倾向是测试计划篇幅冗长，重点不突出，既浪费写作时间，也浪费测试人员的阅读时间。较好的处理方法是：把详细的测试技术指标包含到独立创建的测试详细规格文档中；把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
图 3.6 测试计划
也可以利用“5W1H”规则创建软件测试计划，可以多问几个问题，借助 5W1H分析法辅助编制测试计划。What（做什么）：测试范围和内容；Why（为什么做）：测试目的；When（何时做）：测试时间；Where（在哪里）：测试地点、文档和软件位置；Who（谁做）：测试人力资源；How（怎么做）：测试方法和工具。它们可以帮助测试团队理解测试的目的，明确测试的范围和内容，确定测试的开始和结束日期，指出测试的方法和工具，做出测试人员分工安排，给出测试文档和软件的存放位置。为了使“5W1H”规则更具体化，需要准确理解被测软件的功能特征、应用行业的知识和软件测试技术，在需要测试的内容里面突出关键部分，可以列出关键及风险内容、属性、场景或者测试技术。对测试过程的阶段划分、文档管理、缺陷管理、进度管理给出软件测试计划切实可行的方法。
测试策略和测试用例是测试计划文档描述的核心所在。
软件测试策略是指在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。
测试用例（Test Case）是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。有时是为某个测试目标而编制的一组包含测试输入（数据以及步骤）、执行条件及预期结果的测试实例。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。
在测试计划编制中，测试策略主要描述测试整个软件和每个阶段的方法，还要描述如何公正、客观地开展测试，要考虑模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素。软件测试可以由手工操作软件去执行测试，也可以借助测试工具自动执行测试。什么时候采用手工测试、什么时候采用自动化测试，都是测试策略需要考虑的。软件测试策略随着软件生命周期变化，可能是因为新的测试需求或发现新的测试风险而不得不采取新的测试策略。
测试用例构成了设计和制定测试过程的基础，测试的“深度”与测试用例的数量成比例。判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施或执行的测试用例的数量为依据的。类似下面这样的说明：“95％的关键测试用例已得以执行和验证”，远比“我们已完成 95％的测试”更有意义。
通常情况下，不论采用什么方法和技术，其测试都不可能是彻底的。因为任何一次完全测试或者穷举测试的工作量都太大，在实践上行不通。因此，任何实际测试都不能够保证被测试程序中不存在遗漏的缺陷。一次完整的软件测试过后，如果程序中遗漏的严重错误过多，则表明测试是不充分的甚至是失败的，而测试不足意味着让用户承担隐藏错误带来的风险。反过来说，如果过度测试，则又会浪费许多宝贵的资源，推高企业的成本。我们需要在这两点上进行权衡，找到一个最佳平衡点。这就是测试策略发挥作用的时候。根据测试执行策略，通常情况需设置预测试用例。预测试用例用于开始实施正式系统测试活动前的“冒烟测试”，通过快速高效的方法，执行优先级相对较高、风险较高的用例，检查被测对象是否符合系统测试实施的标准。当预测试不通过时，测试可能挂起，因此预测试用例的设计是非常重要的。