测试用例生命周期

　　完整的测试用例生命周期过程，它通常有测试条件标识、测试用例设计、测试用例实现、测试用例的执行，以及测试用例管理等几个阶段组成。由于不同的公司的质量方针和测试策略的不同，采用的测试用例过程可能会有所不同，或者侧重点不同。下图是测试用例生命周期的瀑布结构。

　　图1 测试用例生命周期

　　测试用例通常是针对被测系统的功能模块来进行设计开发的。每个测试用例的设计都会涉及这五个过程。而且，测试用例的这五个阶段是有时间顺序要求的，例如：在设计测试用例之前，需要首先标识测试条件;在实现测试用例以前，需要设计测试用例。测试用例过程既可以是正式化的，比如对每个阶段的输出进行文档化，也可以是非正式化的。具体输出文档的详细程度，可以根据组织和项目的实际情况而定。

　　1 测试条件标识

　　测试用例过程的第一步是确定测试什么(测试条件)，并且对测试条件进行优先级的划分。测试条件指的是可以通过测试进行验证的条目或者事件。针对测试系统，会有很多不同的测试条件。根据不同的测试条件，可以进行不同的测试类型分类，例如：功能测试、性能测试、可用性测试等。

　　在测试条件标识过程中，可以采用不同的测试技术，严格而系统的来帮助测试人员获取测试条件，例如：黑盒测试中的等价类划分、边界值分析、因果图分析等，以及白盒测试中的语句覆盖、分支覆盖、条件覆盖等。

　　标识测试条件，就是识别需要测试的条目和事件。可以通过不同的方式来对它们进行描述，比如通过简单的句子描述、通过表格的方式或者通过控制流图的方式等描述。测试条件识别活动最好和通用的V模型左边的开发活动同时进行。

　　2 测试用例设计

　　测试用例设计确定了如何来测试已经识别的测试条件。测试用例指的是针对某个测试目标，而进行的一系列测试步骤。测试用例设计会产生一系列包含特定输入数据、预期结果和其它相关信息的测试用例。

　　测试设计的主要挑战是确定测试预期结果。为了确定测试预期结果，测试人员不仅需要关注测试输出，同时也需要注意测试数据和测试环境的后置条件。

　　假如测试依据可以清楚的定义，测试设计理论上将是比较简单的。但是，测试依据通常情况都是模糊不清的，至少描述是缺少覆盖率的。另外，即使清楚的描述了测试依据，测试输入和测试输出的复杂相互关系也会使得定义测试预期结果非常困难。假如测试用例没有测试的预期结果，则测试用例对于测试结果的对错判断是毫无意义的，也无法提供有效的缺陷报告和增加客户对系统的使用信心。

　　测试预期结果可以是各种各样的，包括需要创建或者输出的结果，也可以是需要更新或者变更的结果，也可以是删除的结果。每个测试用例都应该清楚的描述测试的预期结果。也存在一些特殊情况，在测试用例中没有描述测试的预期结果，为了检查软件是否正确的实现或者工作，必须对实际的输出结果进行仔细的检查和验证。这样，就需要测试人员具有被测系统相关的丰富的知识和经验，才可能对软件系统的测试输出作出正确的评估。假如测试输出结果评估认为是正确的，那么就可以作为测试用例的期望输出结果。

　　同样，测试用例的设计，以及测试用例预期结果的设置，应该和通用V模型左边相应的开发活动相对应。

　　3 测试用例实现

　　测试用例实现的过程包括准备测试脚本、测试输入、测试数据以及预期结果等。测试脚本指的是按照标准的语法组织数据或者指令，测试脚本一般保存在文件中，用于自动化测试。测试输入和测试期望输出也可以作为测试脚本的一部分，也可以保存在其他文件或者数据库中。

　　测试执行之前，首先必须满足测试前置条件。比如一个测试用例需要用到文件中的一些数据，那么这个文件在测试执行时必须已经创建。测试前置条件也包括特定的测试硬件和软件，比如测试一个网络打印机，那么在测试之前，需要建立这样的测试环境，和打印机相关的网络是正常可用。测试预期结果也可以保存在文件中，用于自动化测试。而对于手动测试，可以直接在测试用例中标识。

　　4 测试用例执行

原文转自：http://www.uml.org.cn/Test/201011165.asp