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


　　图1测试用例生命周期

　　测试用例通常是针对被测系统的功能模块来进行设计开发的。每个测试用例的设计都会涉及这五个过程。而且，测试用例的这五个阶段是有时间顺序要求的，例如：在设计测试用例之前，需要首先标识测试条件;在实现测试用例以前，需要设计测试用例。测试用例过程既可以是正式化的，比如对每个阶段的输出进行文档化，也可以是非正式化的。具体输出文档的详细程度，可以根据组织和项目的实际情况而定。
　　1测试条件标识
　　测试用例过程的第一步是确定测试什么(测试条件)，并且对测试条件进行优先级的划分。测试条件指的是可以通过测试进行验证的条目或者事件。针对测试系统，会有很多不同的测试条件。根据不同的测试条件，可以进行不同的测试类型分类，例如：功能测试、性能测试、可用性测试等。
　　在测试条件标识过程中，可以采用不同的测试技术，严格而系统的来帮助测试人员获取测试条件，例如：黑盒测试中的等价类划分、边界值分析、因果图分析等，以及白盒测试中的语句覆盖、分支覆盖、条件覆盖等。
　　标识测试条件，是识别需要测试的条目和事件。可以通过不同的方式来对它们进行描述，比如通过简单的句子描述、通过表格的方式或者通过控制流图的方式等描述。测试条件识别活动好和通用的V模型左边的开发活动同时进行。
　　2测试用例设计
　　测试用例设计确定了如何来测试已经识别的测试条件。测试用例指的是针对某个测试目标，而进行的一系列测试步骤。测试用例设计会产生一系列包含特定输入数据、预期结果和其它相关信息的测试用例。
　　测试设计的主要挑战是确定测试预期结果。为了确定测试预期结果，测试人员不仅需要关注测试输出，同时也需要注意测试数据和测试环境的后置条件。
　　假如测试依据可以清楚的定义，测试设计理论上将是比较简单的。但是，测试依据通常情况都是模糊不清的，至少描述是缺少覆盖率的。另外，即使清楚的描述了测试依据，测试输入和测试输出的复杂相互关系也会使得定义测试预期结果非常困难。假如测试用例没有测试的预期结果，则测试用例对于测试结果的对错判断是毫无意义的，也无法提供有效的缺陷报告和增加客户对系统的使用信心。
　　测试预期结果可以是各种各样的，包括需要创建或者输出的结果，也可以是需要更新或者变更的结果，也可以是删除的结果。每个测试用例都应该清楚的描述测试的预期结果。也存在一些特殊情况，在测试用例中没有描述测试的预期结果，为了检查软件是否正确的实现或者工作，必须对实际的输出结果进行仔细的检查和验证。这样，需要测试人员具有被测系统相关的丰富的知识和经验，才可能对软件系统的测试输出作出正确的评估。假如测试输出结果评估认为是正确的，那么可以作为测试用例的期望输出结果。
　　同样，测试用例的设计，以及测试用例预期结果的设置，应该和通用V模型左边相应的开发活动相对应。
　　3测试用例实现
　　测试用例实现的过程包括准备测试脚本、测试输入、测试数据以及预期结果等。测试脚本指的是按照标准的语法组织数据或者指令，测试脚本一般保存在文件中，用于自动化测试。测试输入和测试期望输出也可以作为测试脚本的一部分，也可以保存在其他文件或者数据库中。
　　测试执行之前，首先必须满足测试前置条件。比如一个测试用例需要用到文件中的一些数据，那么这个文件在测试执行时必须已经创建。测试前置条件也包括特定的测试硬件和软件，比如测试一个网络打印机，那么在测试之前，需要建立这样的测试环境，和打印机相关的网络是正常可用。测试预期结果也可以保存在文件中，用于自动化测试。而对于手动测试，可以直接在测试用例中标识。
　　4测试用例执行
　　通过运行测试用例来对被测系统进行测试。对手动测试来说，测试执行主要是测试人员坐到被测系统前面，参考测试用例的步骤来进行测试执行。测试人员输入测试输入、检查测试输出、比较测试预期结果和实际结果、记录在测试过程中发现的问题等等。而对于自动化测试过程，测试执行可能是打开测试工具，运行测试用例脚本和测试脚本等，通过自动化的方式来记录测试结果。
　　必须仔细检查每个测试用例执行的实际输出结果，根据测试预期结果来判断被测系统是否能够正确的工作。有些测试结果的比较可以在测试执行中可以进行，而有的测试结果需要在测试执行完成以后才能进行比较。
　　假如测试实际输出结果和测试预期结果是一样的，那么认为测试用例执行是通过的。假如不一样，那么测试用例执行失败，或者说软件系统存在问题。当然，这是非常简单的比较。更加正确的说法是假如测试结果和测试期望不一致，需要进一步的检查。比如可能是软件存在缺陷，也可能是测试用例本身存在问题，或者是测试用例中的测试预期结果存在问题，甚至是由于测试环境存在问题而引起的。所以，在比较测试结果的时候，需要从不同的方面来确认具体的问题来源。
　　5测试用例管理
　　1)测试用例组织
　　任何一个项目，其测试用例的数目都将是非常庞大的。如何来组织、跟踪和维护测试用例是一件非常重要的事情。在整个测试过程中，可能会涉及不同测试类型的测试用例。如何来组织测试用例，是测试成功与否的一个重要因素，也是提高测试效率的一个重要步骤。
　　测试用例的组织，可以用不同的方法来进行组织或者分类：
　　按照软件功能模块组织：软件系统一般是根据软件的功能模块来进行工作任务分配的。因此，根据软件功能模块进行测试用例设计和执行等是很常用的一种方法。根据模块来组织测试用例，可以保证测试用例能够覆盖每个系统模块，达到较好的模块测试覆盖率。
　　按照测试用例类型组织：将不同测试用例的类型来进行测试用例的分类和组织，也是一种常用的方法。比如可以根据配置测试用例、可用性测试用例、稳定性测试用例、容量测试用例、性能测试用例等来对具体的测试用例进行分类和组织。
　　按照测试用例优先级组织：测试用例是有优先级的。对于任何软件，实现穷尽测试是不现实的。在有限的资源和时间内，首先应该进行优先级高的测试用例，或者用户需要的功能模块或者风险大的功能模块等。
　　在上面的三种测试用例组织方法中，按照功能模块进行划分是常用的。不过，我们可以结合起来使用，比如在按照功能模块划分的基础上，再进行不同优先级的划分，甚至不同测试用例类型来进行划分和组织。
　　测试用例组织好以后，需要进行测试用例的执行，知识测试生命周期中的重要的过程。具体的过程可以如下：
　　根据软件模块，进行具体测试用例的设计，这些测试用例可以保证模块的测试覆盖率。
　　软件的各个模块组成测试单元(单元集成测试)。
　　测试单元和测试环境、测试平台以及测试资源等形成测试计划的重要组成部分，并终形成完整的测试计划。
　　测试计划形成后，需要确定测试执行计划。
　　将测试执行计划划分成多个不同的测试任务。
　　将测试任务分配给测试人员实现测试执行过程。
　　测试人员执行测试得到测试结果和测试相关信息。
　　2)测试用例跟踪
　　在测试执行之前，需要回答这样的一些问题：哪些测试单元是需要测试的?有多少测试用例需要执行?如何来记录测试过程中测试用例的状态?如何通过测试用例的状态，来确定测试的重点或者什么模块是需要进行重点测试的?
　　要回答这些问题，需要对测试过程中测试用例进行跟踪。测试过程中，测试用例的基本状态有三种：通过、未通过和未测试。根据在测试执行过程中测试用例的状态，实现测试用例的跟踪，从而达到测试的有效性。因此，测试用例的跟踪主要是针对测试执行过程中测试用例的状态来进行的，通过测试状态的跟踪和管理，从而实现测试过程和测试有效性的管理和评估。
　　测试用例执行的跟踪：在测试执行的过程中，对测试用例的状态进行跟踪，可以有效的将测试过程量化。比如，执行一轮测试过程中，测试的测试用例数目是多少，每个测试人员每天能够执行的测试用例是多少，测试用例中通过、未通过、未测试的比例各是多少。这些数据可以提供一些信息来判断软件项目执行的质量和执行进度，并对测试进度状态提供明确的数据，有利于测试进度和测试重点的控制。详细的测试用例执行跟踪，可以参考测试用例评估章节。
　　测试用例覆盖率的跟踪：测试用例覆盖率包括了测试需求的覆盖率、测试平台的故概率、测试模块的覆盖率等。
　　测试用例的跟踪方式有各种各样。具体采用的方式需要跟踪组织的测试方针和测试过程、测试成熟度等。具体的方法有：
　　没有任何记录：纯粹通过测试人员的记忆来跟踪测试用例。这种方法并不可取，除非是测试项目是基于个人开发的小的软件系统。
　　电子表格：使用电子表格对测试用例执行过程进行记录和跟踪是一种比较高效的方法。通过电子表格来记录测试用例执行状况，可以直观地看到测试的状态、分析和统计测试用例的状态，以及测试用例和缺陷之间的关联状态，还有测试用例执行的历史记录等等。这种测试用例的信息，可以为测试过程管理和测试过程分析提供有效的量化依据。
　　测试用例工具：好的方法应该是通过测试用例的管理工具，来对测试用例状态、缺陷关联、历史数据等进行管理和分析。工具不仅能够记录和跟
　　测试用例的状态变化，同时也能够生成测试用例相关的结果报表、分析图等，这样可以更叫高效的管理和跟踪整个测试过程。不过，工具的使用需要更高的成本，并且需要专门的人员进行维护。
　　3)测试用例维护
　　测试用例并不是一成不变的，当一个阶段测试过程结束后，会发现一些测试用例编写的不合理，或者下个版本中，部分模块的功能发生了变化，这都需要对当前的一些测试用例进行修改和更新，从而使测试用例具有可复用性。
　　一般在下面的情况下，可能需要修改或者更新测试用例：
　　以前的测试用例设计不全面或者不够准确。随着测试的深入和对产品的熟悉，发现测试用例的步骤描述不够清楚，或者描述的不够正确，甚至原来对系统需求的理解有误差。
　　测试过程中发现的一些问题，并不是通过执行当前的测试用例发现的。这时候，需要增加测试用例来覆盖发现问题的一些步骤。
　　新的版本中有增加的功能或者功能的需求发生了变更。
　　随着版本的升级，有些测试用例需要删除。