测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。测试用例主要包含四个内容：用例标题，前置条件，测试步骤和预期结果。用例标题主要描述测试某项功能；前置条件是指用例标题需要满足该条件；测试步骤主要描述用例的操作步骤；预期结果指的是符合预期（开发规格书、需求文档、用户需求等）需求。很多人都以为测试用例包含实际结果，其实是错误的想法。测试用例不包含实际结果，测试用例产生于测试之前，只有测试时，才会有实际结果，所以实际结果是不可能与测试用例同步产生。实际结果存在于BUG文档，BUG文档是根据测试用例测试完后生成的报告文档。

测试用例

测试用例的设计方法主要有黑盒测试法和白盒测试法。

黑盒测试也称功能测试，黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

根据测试用例的测试等级，集成测试应测试的用例，系统测试和回归测试又称测试的用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

⒉规划测试数据的准备

在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其像测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。

除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

⒊编写测试脚本的"设计规格说明书"

为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

⒋评估测试结果的度量基准

完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

⒌分析缺陷的标准

通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等。因为有些因素是客观存在，无法避免的；有些因素则是波动的、不稳定的。例如开发队伍是流动的，有经验的开发人员走了，新人不断补充进来；每个开发人员的工作也会受情绪影响，等等。有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量，从而把人为因素的影响减少。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

因此，测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试必须遵守的准则，更是软件测试质量稳定的根本保障。

确定测试用例之所以很重要，原因有以下几方面。

(1)测试用例构成了设计和制定测试过程的基础。

(2)测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，测试人员对产品质量和测试流程也就越有信心。

(3)判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95%的关键测试用例已得以执行和验证”，远比“我们已完成95%的测试”更有意义。

(4)测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。

(5)测试设计和开发的类型以及所需的资源主要都受控于测试用例。

(6)测试用例通常根据它们所关联的测试类型或测试需求来分类，而且将随类型和需求进行相应的改变。最佳方案是为每个测试需求至少编制两个测试用例：一个测试用例用于证明该需求已经满足，通常称作正面测试用例；另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。

测试用例文档

编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。

软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。

测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：版本号、模块名称、用例编号、用例名称、用例级别、预知条件、验证步骤、期望结果（含判断标准）、测试结果、测试时间、测试人员等。

测试用例的设置

我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。演变为按功能、路径混合模式设置用例。

按功能测试是最简捷的，按用例规约遍历测试每一功能。

对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。

但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。

设计测试用例

测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯 一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。

可以采用软件测试常用的基该方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基该方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

设计原则

测试用例是一个文档，是执行的最小实体。测试用例包括输入、动作、时间和一个期望的结果，其目的是确定应用程序的某个特性是否可正常工作，并且达到程序所设计的结果，以便测试某个程序路径或核实是否满足某个特定需求般在进行测试用例设计前要全面了解被测试产品的功能、明确测试范围(特别是要明确哪些是不需要测试的)、具备基本的测试技术与方法等。测试用例设计一般遵循以下原则:

(1)正确性。输入用户实际数据以验证系统是否满足需求规格说明书的要求;测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。

(2)全面性。覆盖所有的需求功能项;设计的用例除对测试点本身的测试外，还需考虑用户实际使用的情况、与其他部分关联使用的情况、非正常情况(不合理、非法、越界以及极限输入数据)操作和环境设置等。

(3)连贯性。用例组织有条理、主次分明，尤其体现 在业务测试用例上;用例执行粒度尽量保持每个用例都有测点，不能同时覆盖很多功能点，否则执行起来牵连太大，所以每个用例间保持连贯性很重要。

(4)可判定性。测试执行结果的正确性是可判定的，每一个测试用例都有相应的期望结果。

(5)可操作性。测试用例中要写清楚测试的操作步骤，以及与不同的操作步骤相对应的测试结果。

设计方法

1、白盒法

白盒法又称结构化方法(结构测试)或逻辑覆盖法，其基本思想是把程序看作是路径的集合。这样，对程序的测试便转化为对程序中某些路径的测试，要设法让被测程序的“各处”均被执行到，使潜伏在程序每个角落的错误均有机会暴露出来。因此，白盒法实际上是一种选择通过指定路径的输入数据的分析方法。

2、测试覆盖率

采用白盒法可以用测试覆盖率作为测试彻底度的定量衡量标准。常用的覆盖率有:

(1)语句覆盖:要求设计足够的测试数据，使程序的每条语句都至少执行一次。

(2)判定覆盖(分支覆盖):使程序中的每个判定至少出现一次“真值”和一次假值”，即程序中的每个判定(分支)都至少要经过一次。

(3)条件覆盖:使判定中每个条件的所有可能的结果至少出现一次，并且使每条语句至少执行一次。

(4)判定条件覆盖:使判定覆盖和条件覆盖同时得到满足。

(5)多重条件覆盖:又称条件的组合覆盖，是使程序中每个判定中的条件的各种组合都至少取到一次，并且每条语句至少执行一次。

此外，还有诸如路径覆盖(程序中每条路径至少执行一次)、基本路径覆盖(循环次数只考虑小于等于一次所组成的程序路径，每条基本路径至少执行一次)等。为了获取测试覆盖率(不论是哪一种覆盖率)需要有测试工具的帮助，且需要花费人力与机时去做测试工作(设计测试用例、输入测试数据、进行统计计算等)。

3、黑盒法

黑盒法又称为功能测试，是根据软件需求说明书上罗列的各项功能、性能指标，来构造测试用例的输入数据，实际执行被测软件，分析执行过程的行为与执行结果以便检查出被测软件的错误。在黑盒法测试中，测试者可以完全不关心程序的内部结构。可见，白盒法是一种逻辑驱动方法，而黑盒法是一种功能驱动方法。黑盒法是最常用的测试方法。

测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

⒉测试用例的修改更新

测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。

一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。

⒊测试用例的管理软件

运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。

有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。