1.2.2 软件测试级别

不同的软件开发生命周期模型，采用的测试级别各有不同。但是典型的V模型（如图1-2所示）中涉及的四种测试级别具有很强的代表性，所以，这里以V模型中的测试级别为例，对各个测试级别进行阐述。典型的V模型有四个测试级别，分别与开发阶段相对应：组件测试、集成测试、系统测试和验收测试。

实际采用的V模型测试级别数目既可能比典型V模型提到的四种多，也可能少，这取决于不同组织、项目和软件产品的特性，例如：有的项目在组件测试之后，可能有集成测试；在系统测试之后，有系统集成测试。在一些专业的软件测试书籍和文章中，也经常会提到维护测试，所以，1.2.2.5节也会对维护测试进行简单的介绍，尽管它不是典型V模型中的一个测试级别。

1.2.2.1 组件测试

1.基本含义

组件测试对在编码阶段实现的软件单元进行测试，目的是为了验证软件单元是否按照单元详细设计规格说明正确执行，发现设计和需求中存在的错误以及编码过程中引入的错误。根据开发人员使用编程语言的不同，软件单元所指的内容也不尽相同，可以是模块、单元、程序或功能。在面向对象编程中，它们被称为类。因此，根据不同的软件单元，这些测试分别被称为模块、单元、程序或类的测试。通常情况下，软件单元或单元统称为组件，所以，针对单个软件单元的测试都可以称为组件测试。

组件测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。组件测试作为最低的测试级别，更多采用的是白盒测试技术，系统内多个模块可以并行地进行测试。在组件测试过程中，经常会使用到桩、驱动器和模拟器等。

● 桩用来模拟被测模块工作过程中所调用的模块，它们一般只进行很少的数据处理，例如：打印信息或返回结果等。

● 驱动器用来模拟被测模块的上级模块，它接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印相应的结果。

组件测试包括功能测试和特定的非功能测试，例如：资源行为测试（如内存泄漏）、健壮性测试、基于结构的测试（如分支覆盖）等。组件测试的设计输入主要是单元详细规格说明、软件设计规格说明或数据模型等。

通常，通过开发环境的支持（例如：组件测试框架或调试工具），组件测试会深入到代码中，而且实际设计代码的开发人员也会参与测试。组件测试过程中一旦发现缺陷，开发人员就可以立即进行修改，而不需要以正式的方式记录和跟踪缺陷。

在写代码之前就准备测试和自动化测试用例是组件测试常用的一种方法，称之为测试驱动的方法或测试驱动开发。这个方法根据测试用例的开发周期进行高度迭代，不断地构建和集成小块的代码，然后执行组件测试，直到它们全部通过。

组件测试的任务包括：模块局部数据结构测试、模块参数边界值测试、模块中所有独立执行路径测试，以及模块的各条错误处理路径测试等。

2.测试环境

当程序代码编制完成并通过评审和编译检查后，便可开始组件测试。作为V模型中级别最低的测试，组件测试处理“直接来自开发人员桌面”的测试对象。很明显，对于这个测试级别，测试是在与开发紧密合作的情况下进行的，通常由开发人员自己来执行组件测试。组件测试主要采用白盒测试方法，通常从程序内部结构出发设计测试用例。

测试单元模块可能并不能形成一个完整的可测试系统，因此，在组件测试过程中，可能需要为测试模块开发驱动器和桩模块。

驱动器和桩是组件测试过程中使用的软件，而不是软件产品的组成部分，但它们需要一定的开发费用。

3.测试目的

组件测试中可以发现各种典型的软件缺陷，包括计算错误、遗漏或程序路径选择错误（例如：一些被遗忘或误解的特殊情况）等。因此，组件测试中需要考虑各个方面的测试内容。

第一，检查单元模块自己的接口相关的参数，这是组件测试的基础。测试组件只有在能正确输入数据和输出结果的前提下，进行其他的测试才有意义。单元接口参数正确与否，应该考虑下列因素：

● 输入的实际参数与形式参数的个数是否相同。

● 输入的实际参数与形式参数的属性是否匹配。

● 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同。

● 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配。

● 调用预定义函数时所用参数的个数、属性和次序是否正确。

● 是否存在与当前入口点无关的参数引用。

● 是否修改了只读型参数。

● 各模块对全局变量的定义是否一致。

● 是否把某些约束作为参数传递。

如果模块内包括外部输入和输出，还应该考虑下列因素：

● 文件属性是否正确。

● 文件的OPEN/CLOSE语句是否正确。

● 格式说明与输入/输出语句是否匹配。

● 缓冲区大小与记录长度是否匹配。

● 文件使用前是否已经打开。

● 是否处理了文件尾。

● 是否处理了输入/输出错误。

● 输出信息中是否有文字错误。

第二，检查局部数据结构，可以用来保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：

● 不合适或不相容的数据类型说明。

● 变量无初值。

● 错误的变量初始化或默认值。

● 不正确的变量名（拼错或不正确地截断）。

● 出现地址异常。

第三，在模块中应对每一条独立执行路径进行测试，组件测试的基本任务是保证模块中每条路径至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括：

● 误解或用错了运算符优先级。

● 混合类型的数据运算。

● 错误的变量初始值。

● 数据精度不够。

● 错误的表达式符号。

第四，比较、判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：

● 不同数据类型的对象之间进行比较。

● 错误地使用逻辑运算符或优先级。

● 因计算机精度表示的局限性，期望理论上相等而实际上不相等的错误。

● 比较运算或变量出错。

● 不可能出现的循环终止条件。

● 迭代发散时不能退出。

● 错误地修改了循环变量。

第五，好的软件设计应能预见各种出错条件，并预设各种出错处理路径，出错处理路径同样需要认真测试，测试应着重检查下列问题：

● 输出的出错信息是否难以理解。

● 记录的错误与实际遇到的错误是否相符。

● 异常处理不当。

● 错误信息中是否能提供足够的定位出错信息。

另外，边界值分析测试也是组件测试中最重要的任务之一。众所周知，软件经常在边界上失效，采用边界值分析技术，针对测试对象的边界值进行测试用例设计，很有可能发现新的错误。

同时，组件测试中也需要关注软件的可维护性。可维护性主要指程序代码中所有的特性是否对修改系统的难易程度或继续开发有影响。这时开发人员对程序及其上下文的理解至关重要。这里的开发人员既包括几个月或几年后又被要求继续开发的程序的原开发人员，也包括负责别人开发的代码的其他程序员。因而，下面的这几点对可维护性测试非常重要：代码结构、模块化、代码注释的质量、标准符合性、可理解性、文档化等。

1.2.2.2 集成测试

1.基本含义

集成测试也叫组装测试、联合测试，它是一种旨在暴露接口以及集成组件/系统间交互时存在的缺陷的测试。它是组件测试的逻辑扩展，其关注点是对组件之间的接口进行测试，以及检查与系统其他部分相互作用的测试，例如：操作系统、文件系统、硬件或系统之间的接口。集成测试最简单的形式是将两个已经测试通过的单元组合成一个新的组件，并且测试它们之间的接口（例如：数据交换）。

集成测试的主要工作是把通过组件测试的各模块逐步集成在一起，检查测试数据是否能够在各模块之间正确传递和调用，以及各模块能否正确地协同工作。

集成测试可以应用在多个级别，也可以根据不同的测试对象规模采用不同的集成测试，例如：

● 组件集成测试对不同的软件组件之间的相互作用进行测试，一般在组件测试之后进行。

● 系统集成测试对不同系统之间的相互作用进行测试，一般在系统测试之后进行。在这种情况下，开发团队只能控制自己开发的这部分接口，所以，变更可能是不稳定的。按照工作流执行的业务操作可能包含了一系列系统，因此，跨平台的问题对于系统集成测试至关重要。

系统集成的范围越大，对缺陷的定位就越困难，从而增加了系统的风险。系统集成的策略可以根据系统的框架（例如：自顶向下或自底向上）、功能任务集和处理过程顺序等制定。为了降低在软件开发生命周期后期发现严重缺陷而产生的风险，集成程度应该逐步增加，而不是一下子将系统集成为“巨无霸”来进行测试。测试特定的非功能特征（例如：性能测试）也可以包含在集成测试中。

在集成测试的每个阶段，测试人员只是把精力集中在集成对象本身，例如：假如系统是由模块A和模块B组成的，则集成测试感兴趣的是两个模块之间的接口，而不是每个模块的功能。黑盒测试和白盒测试的方法都可以应用在集成测试。

在理想情况下，测试人员需要理解系统的架构，从而可以对集成测试计划施加影响。假如集成测试计划是在组件或系统生成之前制定，则可以根据最有效率的测试顺序来进行集成测试。

2.测试对象

集成测试是在组件测试的基础上，将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统，并检验各部分工作是否达到或实现相应技术指标及要求的过程和活动。也就是说，在集成测试之前，组件测试应该已经完成，集成测试中所使用的对象应该是已经经过组件测试的软件单元。这一点很重要，因为如果不经过组件测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。

集成测试是组件测试的逻辑扩展。在现实方案中，集成是指多个单元的聚合，许多单元组合成模块，而这些模块又聚合成程序的更大部分，如分系统或系统。集成测试采用的方法是验证软件单元的组合能否正常工作，以及与其他模块集成之后能否正常工作。最后，还要测试构成系统的所有模块组合能否正常工作。集成测试的主要测试依据是软件的概要设计规格说明，任何不符合该说明的程序模块行为都应该加以记录并以缺陷的形式上报。

事实上，很少有软件系统是全新开发的，通常都是对一个已经存在的系统进行修改、扩展，或者是连接到其他系统。在组件测试中，对已经存在的组件或标准组件基本上不再进行测试。但是在集成测试时必须考虑这些系统组件，并检查它们和其他组件的协作情况。

3.测试目的

集成测试的主要测试内容有功能性、可靠性、易用性、效率、可维护性和可移植性等，具体根据软件需求和设计的要求而选定。集成测试的目的是验证各软件单元集成后形成的模块能否达到概要设计规格说明的设计目标。软件集成测试具体的测试内容包括：

● 程序的功能测试，即检查各个子模块或者单元组合起来以后能否满足设计所要求的功能特征和指标。

● 检查一个程序单元或模块的功能是否会对另一个程序单元或模块的功能产生不利影响。

● 根据计算精度的要求，单个程序模块的误差积累起来是否仍能够达到设计要求的技术指标。

● 程序单元或模块之间的接口测试，即把各个程序单元或模块集成起来时，数据在通过其接口时是否会出现不一致情况，例如：是否会出现数据丢失。

● 全局数据结构的测试，即检查各个程序单元或模块所用到的全局变量是否一致、合理。

● 对程序中可能有的特殊安全保密性要求进行测试。

● 根据软件需求和设计中提出的要求，对软件的容错性、易恢复性、错误处理能力进行测试。

● 根据软件设计中提出的要求，对软件的易理解性、易学性和易操作性进行检查和测试。

● 根据软件需求和设计中提出的要求，进行软件的时间特性和资源特性测试。

● 根据软件需求和设计中提出的要求，对软件的可维护性进行测试。

● 根据软件需求和设计中提出的要求，对软件在不同操作系统环境下使用的正确性进行测试。

集成测试的测试对象主要是被集成模块之间接口协同工作方面的内容，例如：数据交换或单元之间通信。通过静态测试去发现这些问题很困难，这些问题需要通过动态测试来发现。集成测试中发现的缺陷大概可以分为下面几类：

● 单元传送了错误的数据，或没有传送数据，导致接收数据的单元不能操作或崩溃（例如：单元的功能缺陷、接口格式不兼容、协议缺陷等）。

● 通信正常，但是被调用的单元使用不同的方法来解析接收到的数据（例如：单元的功能缺陷、规格说明矛盾或错误的理解）。

● 数据内容传输正确，但是传输的时间错误、传输的延迟（时序问题），或者传输的时间间隔太短（例如：吞吐量、负荷、容量问题）。

4.集成策略

为了尽可能又快又早地执行需要的测试，应该以什么样的顺序对单元模块进行集成？如何获得集成测试的最大效率？效率体现了测试成本（测试人员开销、工具的使用等）和测试收益（发现问题的数量和严重程度）之间的关系。寻找、选择并实施项目的最优集成策略是测试经理的重要任务。

集成策略可概括为非渐增式集成测试模式和渐增式集成测试模式两种，具体包括：自底向上集成、自顶向下集成、核心系统先行集成以及随意集成等集成策略。实际运用中需要根据具体被测对象的逻辑层次特性和物理分布特性综合考虑选择哪种集成策略进行测试。下面是几种常用集成策略的描述。

（1）自底向上集成测试

自底向上的集成（Bottom-Up Integration）方式是最常使用的集成策略，其他集成方法或多或少地继承、吸收了这种集成策略的思想。自底向上集成策略从程序模块结构中最底层的模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块。自底向上集成测试的步骤大致如下：

步骤1：按照概要设计规格说明，明确有哪些被测模块。在熟悉被测模块特征的基础上对被测模块进行分层，在同一层次上的模块可以并行进行测试，然后排出测试活动的先后关系，制定测试执行进度。处于同一层次的测试活动可以同时进行，而不会相互影响。

步骤2：按组件间的层次关系，将软件单元集成为子系统，并测试在集成过程中出现的问题。这里，可能需要测试人员开发一些驱动器来驱动集成活动中形成的被测模块。对于比较大的模块，可以先将其中的某几个软件单元集成为子模块，然后再集成为一个较大的模块。

步骤3：持续将上层组件集成到子系统中，直到集成为完整的系统。

自底向上的集成策略是软件工程实践中最常用的策略，相关技术也较为成熟。它的主要特点如下：

● 优点：不需要桩，底层关键组件可以优先集成。

● 缺点：必须用测试驱动器仿真更高级别的单元。

（2）自顶向下集成测试

自顶向下集成（Top-Down Integration）是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据软件的特性确定。自顶向下集成测试的具体步骤为：

步骤1：以主控模块作为测试驱动器，把对主控模块进行组件测试时引入的桩模块用实际模块替代。

步骤2：依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块。

步骤3：每集成一个模块立即测试一遍。

步骤4：只有每组测试完成后，才着手替换下一个桩模块。

步骤5：为避免引入新错误，必须不断地进行回归测试（即全部或部分地重复已做过的测试）。

从步骤2开始，循环执行上述步骤，直至整个程序结构集成完毕。

自顶向下集成的优点在于能尽早地对程序的主要控制路径和决策机制进行检验，因此，能够较早地发现主要控制路径上的错误。缺点是在测试高层模块时，低层处理采用桩模块替代，不能反映真实的情况，重要数据不能及时回送到上层模块，因此测试并不充分。

● 优点：不需要测试驱动器，或者只需要简单的测试驱动，这是因为经过测试的较高级别单元组成了测试环境的主要部分。

● 缺点：还没有集成的较低级别的单元必须用桩代替，成本很高。

（3）核心系统先行集成测试

核心系统先行集成测试策略的思想是先对软件的核心部件进行集成测试，在测试通过的基础上再按各外围软件组件的重要程度逐个集成到核心系统中。每次加入一个外围软件组件都会产生一个产品基线，直至最后形成稳定的软件产品。核心系统先行集成测试策略对应的集成过程是一个逐渐趋于闭合的螺旋形曲线，代表产品逐步定型的过程。其步骤如下：

步骤1：对核心系统中的每个模块进行单独的、充分的测试，必要时使用驱动器和桩模块。

步骤2：对于核心系统中的所有模块一次性集合到被测系统中，解决集成中出现的各类问题。在核心系统规模相对较大的情况下，也可以按照自底向上的步骤集成核心系统的各组成模块。

步骤3：按照各外围软件组件的重要程度以及模块间的相互制约关系，拟定外围软件组件集成到核心系统中的顺序方案。方案经评审以后，即可进行外围软件组件的集成。

步骤4：在外围软件组件添加到核心系统以前，外围软件组件应先完成内部的模块级组件测试。

步骤5：按顺序不断加入外围软件组件，排除外围软件组件集成中出现的问题，形成最终的用户系统。

该集成测试策略对于快速软件开发很有效果，适合较复杂系统的集成测试，能保证一些重要的功能和服务的实现。缺点是采用此法的系统一般应能明确区分核心软件组件和外围软件组件，核心软件组件应具有较高的耦合度，外围软件组件内部也应具有较高的耦合度，但各外围软件组件之间应具有较低的耦合度。

（4）随意集成测试

按照单元完成的顺序进行集成。

● 优点：节省时间，因为每个单元可以最快地集成到系统中来。

● 缺点：可能同时需要桩和测试驱动器。

以上介绍了几种常见的集成测试策略。一般来讲，在现代复杂软件项目集成测试过程中，通常采用核心系统先行集成测试策略进行，自底向上的集成测试策略在采用传统瀑布式开发模式的软件项目集成过程中较为常见。读者应该结合项目的实际工程环境及各测试策略适用的范围进行合理的选型。

1.2.2.3 系统测试

1.基本含义

系统测试是将已经集成好的软件系统作为计算机系统的一部分，与计算机硬件、某些支持软件、数据和人员等系统元素结合起来，在实际运行环境下对计算机系统进行一系列严格有效的测试。系统测试关注的是项目或产品范围中定义的整个系统或产品的行为。在系统测试中，测试环境应该尽量和最终使用的目标或产品使用的环境一致，从而避免遗漏和环境相关的失效。

系统测试可能包含不同的测试用例：根据风险的、根据需求规格说明的、根据业务过程应用的、基于用例或者用户场景的、根据其他对系统行为的更高级别描述的以及根据操作系统和系统资源等的相互作用等。

系统测试需要对系统功能和非功能需求进行研究。系统需求可以以文本形式或模型方式描述。同时测试人员也需要知道在需求不完全或需求没有文档化的时候如何进行测试。验证功能需求的系统测试可以选择最适合的基于规格说明的测试对系统进行测试。例如：决策表技术可以根据描述的业务准则的逻辑组合来生成测试用例；基于结构的技术可以用来评估系统结构元素的完整性等。系统测试通常由独立的测试团队进行。

2.测试环境

集成测试完成后，软件系统已经完全组合起来了，因此，系统测试可以将系统看成一个整体来进行测试。系统测试应该在尽可能和目标运行环境一致的情况下进行。

在尝试节约成本并减少工作量的时候，经常容易犯一个错误：在客户的运行环境上执行系统测试，而不是在独立的环境中测试，这是无益的，原因如下：

● 系统测试时，很可能发生失效并对客户的运行环境造成破坏。在用户环境中系统发生的系统崩溃和数据丢失的代价是巨大的。

● 测试人员难以甚至无法对运行环境的参数进行设置和配置，因此，无法按照测试要求对整个测试环境进行配置。

● 客户环境的其他系统在系统测试的时候也同时在运行，测试环境在不断变化，所以导致系统测试的执行不能重现，或者很难重现。

因此，不应该低估系统测试的工作量，尤其是在测试环境比较复杂的情况下。

3.测试目的

系统测试的目的是确认整个系统是否满足了系统需求规格说明中的功能和非功能需求，以及满足的程度。系统测试应该发现实现和需求不一致而引起的失效。常见的系统测试包括压力测试、容量测试、性能测试、安全测试、容错测试等。

1.2.2.4 验收测试

1.基本含义

验收测试通常由使用系统的用户来进行，同时系统的其他利益相关者也可能参与其中，用来确认用户/客户是否可以接受一个系统。验收测试是根据用户需求和业务流程进行的正式测试，以确保系统符合所有的验收准则。

验收测试的目的是确保系统功能、系统的某部分或特定的系统非功能特征满足验收准则，发现缺陷不是验收测试的主要目标。另外，验收测试也可以用来评估系统是否可以发布和用户对系统使用的准备情况等。验收测试不一定是最后级别的测试，例如：对于大型的系统，可能会在进行系统验收测试之后，进行系统的集成测试。

验收测试在不同的组织或公司也可能使用不同的术语，例如：在系统正式移交给客户之前或之后进行的现场验收测试。验收测试也是对软件质量评价的一个重要环节。

2.验收测试类型

验收测试范围很广，它取决于应用程序的风险。如果开发的软件是用户定制的且具有高风险，则需要进行一个全面的验收测试；假如开发获得的是一个标准的产品，并且已经在一个类似的环境下运行了很长时间，那么，验收测试还应包括安装系统的测试，同时还可能运行一些有代表性的用例（Use Case）。如果系统要通过一种新的方式和其他系统进行协同工作，那么至少要测试一下互操作性。下面对几种常用的验收测试进行简单的描述。

（1）根据合同的验收测试

如果是客户定制的软件，客户（和卖方合作）将根据合同执行验收测试。客户在验收测试结果的基础上来判断订购的软件系统是否满足验收准则，或者合同中定义的服务是否已经满足。假如定制软件的客户在同一个组织内部，例如：IT 部门为组织开发的应用软件，那么同一组织内部的用户部门和IT部门会存在或多或少的正式的合同。

测试标准是开发合同中定义的验收标准，因此，合同中必须清晰明确地表示这些标准，同时还必须明确所有需要遵守的规章，例如：政府的、法律上的、安全方面的规章。

实际上，软件开发者自己会在系统测试的时候检查这些标准。对于验收测试，重新执行验收相关的测试用例，就能够向客户证明软件已经满足合同中的验收标准。

供应商可能会对验收标准存在误解，因此，由客户来设计或者至少评审验收测试用例是至关重要的。和开发环境中进行的系统测试不同，验收测试的环境应该尽可能地和运行环境一致，但是在运行环境下的测试用例本身应该避免对其他正在运行的软件系统造成破坏。由于测试环境不同，系统测试中能够正确工作的测试用例可能会突然失败。最后的验收测试还必须检查交付和安装过程。

为了确定验收标准和验收测试用例，可以使用前面系统测试时讨论的方法。针对管理信息系统，必须考虑有时间约束的商业事务或周期性的事务（例如：一个账单周期）。

（2）用户验收测试

另外一个和验收相关的测试是作为整个测试的最后一个阶段：用户验收测试。在客户和最终用户不同的时候，尤其需要进行这种测试。

通常，不同的用户群对新系统的期望有所不同。即便只有一个用户群因为系统难以使用而拒绝这个系统，也会给系统的应用带来麻烦。即使系统从技术和功能的角度来看都很好，也可能发生这种情况。因而需要对每一个用户群都组织用户验收测试，通常由用户来组织这些测试，并基于商业过程和典型的用户场景选择测试用例。

为了减少验收测试中发现的问题，建议允许一些用户代表在项目的前期检查系统原型。

（3）运行（验收）测试

运行（验收）测试是为了保证系统管理员对系统的验收而进行的测试。测试可以包括备份/恢复循环测试、灾难恢复、用户管理、维护任务和安全攻击检查等。

（4）现场测试

如果软件会在许多不同的运行环境中运行，软件开发者在系统测试时为每种应用创建一个测试环境的开销将很大，甚至是不可能的。这种情况下，系统测试完成后，软件开发者可以选择执行现场测试。现场测试的目标是识别完全未知的或没有详细说明的用户环境的影响，并在需要的时候消除这些影响。因此，软件开发者将预发布的稳定软件版本交付给预先选定的客户，这些客户能够充分代表软件的目标市场，或者他们的运行环境正好可以覆盖可能的环境。

客户既可以运行特定的测试场景，也可以在真实环境中对产品进行使用。他们将发现的问题、意见和对新产品的印象进行反馈。这种由客户代表执行的预发布版本的测试也称为Alpha测试或Beta测试。其中Alpha测试在开发者的场所执行，而Beta测试在客户那里执行。

现场测试不能代替开发者内部的系统测试。只有当系统测试已经证明软件足够稳定后，才可以将新产品提交给潜在的客户做现场测试。

1.2.2.5 维护测试

维护测试并没有包含在典型的V模型中，这里只对其进行简单的描述。软件系统一旦被市场接受，通常会服务几年甚至几十年。在这期间，经常需要对软件系统和它运行的环境进行修正、改变或扩展，如果要对软件或系统进行修改、移植或系统被淘汰，就需要进行维护测试，维护测试是在一个运行的系统上进行的。

对系统或软件进行修改有各种各样的情形：计划中的功能增强（基于版本发布）、变更修改或突发的变更，甚至是环境的变化，例如：计划中的操作系统或数据库升级、为操作系统打补丁等。

为软件移植（从一个平台到另外一个平台）而进行的维护测试应该包括新环境的运行测试（Operational Testing），以及变更以后的软件测试。为系统退出市场而进行的维护测试应该包括数据移植测试或进行长时间数据保存的存档测试。

除了对软件变更进行测试外，维护测试还包括对系统没有发生变更的其他部分进行大范围的回归测试。维护测试的范围取决于变更后是否有产生新缺陷的风险、系统的规模和变更的大小。维护测试根据变更的情况不同，可以在某一或所有的测试级别和测试类型上进行测试。

确定变更如何影响现有系统的过程称为影响分析，它可以帮助决定实施回归测试的广度和深度。

假如需求规格说明遗失或过时，进行维护测试将是一件困难的事情。然而，这是维护测试经常面临的问题，因为维护测试可能是软件开发很久以后的事情，假如没有完善的项目开发过程、测试过程和文档管理控制过程，维护测试所依赖的测试依据是很难保持更新的。