软件测试学习笔记（三）软件测试过程

1.软件测试过程概述

软件测试过程与软件工程的开发过程是相对应的，我们可以采用V型图来表示软件开发与软件测试的对应关系，也可以采用螺旋形图来表示这种关系。

  单元测试的目的是保证每个模块单独运行正确，多采用白盒技术，检查模块控制结构的某些特殊路径，期望覆盖尽可能多的出错点。
  经单元测试后的模块，组装为软件包，对软件包进行集成测试，主要测试软件结构问题，因测试建立在模块间的接口上，所以多为黑盒测试，适当辅以白盒测试技术，以便能对主要控制路径进行测试。
  系统测试主要是检验软件是否满足功能、行为和性能方面的要求，这一步完全采用黑盒测试技术。
  验收测试是检验软件产品的最后一道工序，与前面各种测试过程的不同之处主要在于它突出了客户的作用，同时软件开发人员也要参与。

2.单元测试

2.1 单元测试的定义

单元测试是对软件设计的最小单元—模块进行正确性检验的测试工作，主要测试模块在语法、格式和逻辑上的错误。
单元选择的依据：
（1）单元必须是可测的；
（2）单元的行为或输出是可观测的；
（3）有明确的可定义的边界或接口。
确定单元的最基本原则是“高内聚，低耦合”，常见的示例如下(五个)：
（1）在使用过程化编程语言开发设计的软件中，单元可以用一个函数或过程表示，也可以用紧密相关的一组函数或过程表示。
（2）在使用面向对象编程开发工具设计的软件中，单元可以用一个类或者类的一个实例表示，也可以用方法实现的一个功能表示。
（3）在可视化图形环境下或图形用户界面环境下，单元可以是一个窗口，或者是这个窗口中相关元素的集合。
（4）在基于组件的开发环境中，单元可以是一个预先定义的可重用的组件。
（5）对于Web编程的网页，单元可以是页面上的一个子功能。

2.2 单元测试的重要性与原则

2.2.1 单元测试的重要性

从如下几个方面就可以看出单元测试的重要性：
(1) 时间方面
(2) 测试效果方面
(3) 测试成本方面
(4) 产品质量方面
2.2.2 单元测试原则.(7点)
(1) 单元测试越早进行越好;
(2) 单元测试应该依据《软件详细设计规格说明》进行;
(3) 对于修改过的代码应该重做单元测试，以保证对已发现错误的修改没有引入新的错误;
(4) 当测试用例的测试结果与设计规格说明上的预期结果不一致时，测试人员应如实记录实际的测试结果;
(5) 单元测试应注意选择好被测软件单元的大小;
(6) 一个完整的单元测试说明应该包含正面测试和负面的测试;
(7) 注意使用单元测试工具.

2.3单元测试的主要任务

单元测试是针对每个程序模块进行测试，单元测试的主要任务是解决以下5个方面的测试问题。

2.3.1 模块接口测试

对模块接口的测试是检查进出模块单元的数据流是否正确，所以对模块接口的测试必须在任何其他测试之前进行。
针对模块接口测试应进行的检查，主要涉及以下几方面的内容。（11方面）
① 模块接受输入的实际参数个数与模块的形式参数个数是否一致。
② 输入的实际参数与模块的形式参数的类型是否匹配。
③ 输入的实际参数与模块的形式参数所使用单位是否一致。
④ 调用其他模块时，所传送的实际参数个数与被调用模块的形式参数的个数是否相同。
⑤ 调用其他模块时，所传送的实际参数与被调用模块的形式参数的类型是否匹配。
⑥ 调用其他模块时，所传送的实际参数与被调用模块的形式参数的单位是否一致。
⑦ 调用内部函数时，参数的个数、属性和次序是否正确。
⑧ 在模块有多个入口的情况下，是否有引用与当前入口无关的参数。
⑨ 是否会修改了只读型参数。
⑩ 出现全局变量时，这些变量是否在所有引用它们的模块中都有相同的定义。
有没有把某些约束当做参数来传送。

2.3.2 模块局部数据结构测试

模块的局部数据结构是经常发生错误的错误根源，在单元测试工作过程中，必须测试模块内部的数据能否保持完整性、正确性，包括内部数据的内容形式及相互关系不发生错误。
一般注意一下几类错误：
1）不正确的或不一致的类型说明；
2）错误的初始化或默认值；
3）错误的变量名；
4）不相容的数据类型；
5）下溢、上溢或者地址错误。

2.3.3 模块中所有独立执行路径测试

在单元测试中，应对模块中的每一条独立路径进行测试，此时设计的测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。常见的错误如下：
（1）误解的或不正确使用算术优先级；
（2）混合类型的运算；
（3）错误的初始化；
（4）算法错误；
（5）运算精确度不够精确；
（6）表达式的符号表示不正确等。
针对判定和条件覆盖，测试用例还要能够发现如下错误：
（1）不同数据类型的比较；
（2）不正确的逻辑操作或优先级；
（3）应相等的地方由于精确度错误而不能相等；
（4）不正确的判定或不正确的变量；
（5）不正常的或不存在的循环终止；
（6）当遇到分支循环时不能退出；
（7）不适当的修改循环变量。

2.3.4 各种错误处理测试

良好的设计应该预先估计到软件投入运行后可能发生的错误，并给出相应的处理措施，测试错误处理的要点是检验如果模块在工作中发生了错误，其中的出错处理实施是否有效。应主要检查下面的情况：
（1）对运行发生的错误描述得难以理解；
（2）报告的错误与实际遇到的错误不一致；
（3）出错后，在错误处理前就引起了系统干预；
（4）例外条件的处理不正确；
（5）提供的错误信息不足，无法找到出错的原因。

2.3.5 模块边界条件测试

单元测试的最后一步，必须采用边界值分析法来设计测试用例，主要检查以下方面：
（1）处理n维数组的第n个元素时是否出错；
（2）在n次循环的第0次、1次、n次是否有错误；
（3）运算或判断中取最大和最小值是否有错误；
（4）数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误。

2.4 单元测试环境的建立

一般情况下，在完成了程序编写、复查和语法正确性验证后，就应进行单元测试。测试用例设计应与复审工作相结合，根据设计信息选取数据，将增大发现上述各类错误的可能性。在进行单元测试时，需设置若干辅助测试模块。
辅助模块有两种：
一种是驱动模块（Driver），用以模拟被测试模块的上级模块。 驱动模块在单元测试中，接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。
另一种是被调用模拟子模块(sub)，用以模拟被测模块工作过程中所调用的模块。被调用模拟子模块由被测模块调用，它们一般只进行很少的数据处理，以便于检验被测模块与其下级模块的接口。
一般的单元测试环境：

2.5 单元测试主要技术和数据

2.5.1 静态测试

保证算法的逻辑正确性、清晰性、规范性、一致性、算法高效性。能够发现30%-70%的逻辑设计和编码错误，但是还有大量的隐性错误无法通过视觉检查发现，必须通过跟踪、细心分析才能捕捉到。

2.5.2 动态执行测试

可以分别采用白盒测试和黑盒测试。
通过白盒测试证明每种内部操作是否符合设计规格的要求，所有内部成分是否已经经过检查，进行白盒测试时，采用的白盒测试技术主要是逻辑覆盖法和基本路径法。
黑盒测试主要包括功能测试和非功能测试，功能测试可以证明每个实现了的功能是否符合要求。非功能测试是在必要时，对单元的性能（系统响应时间，内存使用的相容性等）进行测试。

2.5.3 状态转换测试

当单元可能处于不同状态转换时，应根据单元可能进入的状态、这些状态之间的转换、引起转换可能导致的状态等进行测试。

2.5.4 单元测试中使用的数据

单元测试中使用的数据，通常不使用真实数据。
当被测试单元的功能不涉及操纵或使用大量数据时，测试中可以使用有代表性的一小部分手工制作的测试数据。在创建测试数据时，应确保数据充分地测试单元的边界条件。
当被测试单元要操纵大量数据，并且有很多单元都有这种需求时，可以考虑使用真实数据的一个较小的有代表性的样本。测试时还要考虑往样本数据中引入一些手工制作的数据，以便测试单元的某个具体特性，例如对错误条件的响应等。
当测试一个单元要从远程数据源接收数据时（例如，从一个客户端/服务器系统中接收数据），有必要在单元测试中使用测试辅助程序，来模拟对这些数据的访问。但在考虑这种选择时，必须首先对开发的测试辅助程序进行测试，以保证模拟的真实性。

2.6 单元测试工具简介

自动化单元测试工具的工作原理是借助于驱动模块与桩模块工作的，运行被测软件单元以检查输入的测试用例是否按软件详细设计规格说明的规定执行相关操作。
目前，单元测试测试工具类型较多，按照测试的范围和功能，可以分为下列几种（八种）。
1. 静态分析工具；
2. 代码规范审核工具；
3. 内存和资源检查工具；
4. 测试数据生成工具；
5. 测试框架工具；
6. 测试结果比较工具；
7. 测试度量工具；
8. 测试文档生成和管理工具
常用的单元测试自动化工具介绍如下：
1. 基于XUnit测试框架的测试工具
2. 常用的C语言单元测试工具
3. Visual Unit单元测试工具
4. 分析覆盖率的工具
5. 静态分析工具

2.7 单元测试人员

单元测试一般由开发设计人员本身完成，并在开发组在组长的监督下进行，由编写该单元的开发设计者设计所需的测试用例和测试数据，来测试该单元并修改缺陷。开发组组长负责保证使用合适的测试技术，在合理的质量控制和监督下执行充分的测试。

3.集成测试

3.1 集成测试的定义

将经过单元测试的模块按设计要求连接起来，组成所规定的软件系统的过程称为“集成”。

3.2 集成测试的主要任务

集成测试是组装软件的系统测试技术之一，按设计要求把通过单元测试的各个模块组装在一起之后，进行集成测试的主要任务是要求软件系统符合实际软件结构，发现与接口有关的各种错误。集成测试的主要任务是解决以下5个方面的测试问题。
① 将各模块连接起来，检查模块相互调用时，数据经过接口是否丢失。
② 将各个子功能组合起来，检查能否达到预期要求的各项功能。
③ 一个模块的功能是否会对另一个模块的功能产生不利的影响。
④ 全局数据结构是否有问题，会不会被异常修改。
⑤ 单个模块的误差积累起来，是否被放大，从而达到不可接受的程度。

3.3 集成测试遵循的原则

集成测试很不好把握，应针对总体设计尽早开始筹划。为了做好集成测试，需要遵循以下原则。（8条）
① 所有公共接口都要被测试到。
② 关键模块必须进行充分的测试。
③ 集成测试应当按一定的层次进行。
④ 集成测试的策略选择应当综合考虑质量、成本和进度之间的关系。
⑤ 集成测试应当尽早开始，并以总体设计为基础。
⑥ 在模块与接口的划分上，测试人员应当和开发人员进行充分的沟通。
⑦ 当接口发生修改时，涉及的相关接口必须进行再测试。
⑧ 测试执行结果应当如实记录。

3.4 集成测试实施方案

集成测试的实施方案有很多种，如：非增式集成测试和增量式集成测试、三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试等。
其中，常用的是非增式集成测试和增量式集成测试两种模式。

3.4.1 非增式测试方法

概括来说，非增式测试方法是采用一步到位的方法来进行测试，即对所有模块进行个别的单元测试后，按程序结构图将各模块连接起来，把连接后的程序当做一个整体进行测试。下图给出的是采用这种非增式的集成测试方法的一个经典例子。

3.4.1 增式测试方法

<1>自顶向下增式测试

自顶向下增式测试表示逐步集成和逐步测试是按结构图自上而下进行的。即模块集成的顺序是首先集成主控模块（主程序），然后按照软件控制层次结构向下进行集成。 可以有深度优先和广度优先两种集成策略。

集成测试的整个过程由下列3个步骤完成。
① 主控模块作为测试驱动器，把对主控模块进行单元测试时引入的被调用模拟子模块用实际模块替代。
② 依照所选用的模块集成策略（深度优先和广度优先），下层的被调用模拟子模块一次一个地被替换为真正的模块。
③ 在每个模块被集成时，都必须立即进行测试一遍。回到第2步重复进行，直到整个系统结构被集成完成。

<2>自底向上增式测试

自底向上增式测试是从最底层的模块开始，按结构图自下而上逐步进行集成和测试。下图表示了采用自底向上增式测试实现同一实例的过程。

3.4.3 其他集成测试实施方案（3种）

<1> 三明治集成测试

将自顶向下测试与自底向上测试两种模式结合起来，才用并行的自顶向下、自底向上集成方式。
它采取持续集成策略，软件开发中的各个模块不是同时完成，根据进度将完成的模块尽可能早地进行集成。
并且，在自底向上集成时，先期完成的模块将是后期模块的被调用程序，而自顶向下集成时，先期完成的模块将是后期模块的驱动程序，从而使后期模块的单元测试和集成测试出现了部分交叉，节省了测试代码的编写，也提高了工作效率。

<2>核心系统先行集成测试

思想是先对核心软件部件进行集成测试，在测试通过的基础上再按各外围部件的重要程度逐个集成到核心系统中。

<3>高频集成测试

是指同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试。该集成方法频繁的将新代码加入到一个已经稳定的基线中，以免集成故障难以发现，同时控制可能出现的基线偏差。

3.4.4 几种集成测试方案的比较

 

非增量式集成测试	增量式集成测试
如果在模块的接口处存在错误，只会在最后的集成测试时一下子暴露出来	将程序一段一段地扩展，测试的范围一步一步的增大，把可能出现的差错分散暴露出来
非增量式集成测试可能发现很多错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置	错误易于定位和纠正，便于找出问题并修改，接口的测试亦可做到完全彻底

自顶向下测试	自底向上测试
自然地做到逐步求精，一开始便能让测试者看到系统的框架；	直到最后一个米快被加入进去之后才能看到整个程序的框架
需要提供被调用模拟子模块，被调用模拟子模块可能不能反映真实情况，因此测试有可能不充分。 在输入输出模块接入系统以前，在被调用模拟子模块中表示测试数据有一定困难。 由于被调用模拟子模块不能模拟数据，如果模块间的数据流不能构成有向的非环状图，一些模块的测试数据便难以生成。	由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，生成测试数据也没有困难

 

三明治集成测试	核心系统先行集成测试	高频集成测试
采用自底向上、自顶向下集成相结合的方式，并采取持续集成的策略，有助于尽早发现缺陷，提高工作效率。	能保证一些重要功能和服务的实现，对于快速软件开发很有效果。但要求能明确区分核心软件部件和外围软件部件。	集成次数频繁，必须借助于自动化工具来实现。

3.5 集成测试技术和测试数据

集成测试主要测试软件的结构问题，因为测试建立在模块的接口上，所以多为黑盒测试，适当辅以白盒测试。
软件集成测试具体内容包括：
(1) 功能性测试
(2) 可靠性测试
(3) 易用性测试
(4) 性能测试
(5) 维护性测试
集成测试一般覆盖的区域包括:
(1) 从其他关联模块调用一个模块；
(2) 在关联模块间正确传输数据；
(3) 关联模块之间的相互影响，即检查引入一个模块会不会对其他模块的功能后性能产生不利的影响；
(4) 模块间接口的可靠性。
执行集成测试应遵循下面的方法。
① 确认组成一个完整系统的模块之间的关系。
② 评审模块之间的交互和通信需求，确认出模块间的接口。
③ 使用上述信息产生一套测试用例。
④ 采用增量式测试，依次将模块加入到系统，并测试新合并后的系统，这个过程以一个逻辑/功能顺序重复进行，直至所有模块被功能集成进来形成完整的系统为止。
此外，在测试过程中尤其要注意关键模块，所谓关键模块一般都具有下述一个或多个特征。
① 对应几条需求。
② 具有高层控制功能。
③ 复杂，易出错。
④ 有特殊的性能要求。
因为集成测试的主要目的是验证组成软件系统的各模块的接口和交互作用，因此集成测试对数据的要求无论从难度和内容来说一般不是很高。
集成测试一般也不使用真实数据，测试人员可以使用手工制作一部分代表性的测试数据。在创建测试数据时，应保证数据充分测试软件系统的边界条件。
在单元测试时，根据需要生成了一些测试数据，在集成测试时可适当地重用这些数据，这样可节省时间和人力。

3.6 集成测试人员

由于集成测试不是在真实环境下进行，而是在开发环境，或是一个独立的测试环境下进行的，所以集成测试所需人员一般从开发组中选出，在开发组长的监督下进行，开发组长负责保证在合理的质量控制和监督下使用合适的测试技术执行充分的集成测试。
在集成测试过程中，测试过程由一个独立测试观察员来监控测试工作。
集成测试过程中应考虑邀请一个用户代表非正式地观看集成测试 。

4.系统测试

4.1 系统测试的定义

系统测试是指经通过集成测试的软件系统，作为计算机系统的一个重要组成部分， 与计算机硬件、外设、某些支撑软件的系统等其他系统元素组合在一起所进行的测试。
目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或矛盾的地方，以验证软件系统的正确性和性能等是否满足需求分析所指定的要求。
系统测试的主要任务：

1）较大工作量集中在软件系统的某些模块与计算机系统中有关设备打交道时的默契配合方面。
2）测试人员要根据原始项目需求对软件产品进行确认，验证软件功能与用户要求的一致性。
3）此外，还必须对文件资料是否完整正确和软件的易移植性、兼容性、出错自动恢复功能、易维护性进行确认。

4.2 系统测试前的准备工作

1）收集软件规格说明书，作为系统测试的依据；
2）收集各种软件说明书，作为系统测试的参考；
3）仔细阅读软件测试计划书，以作为系统测试的根据。如果已有编好的系统测试用例，一并收集。
从上述文档中找出：对系统各种功能的描述；系统要求的数据处理及传输的速率；对系统性能的要求；对备份及修复的要求；对兼容性的描述；对配置的描述；对安全方面的描述等。

4.3 系统测试技术和测试数据

4.3.1 系统测试的主要测试技术

系统测试不需要考虑组件模块的实现细节，而主要是根据需求分析时确定的标准检验软件是否满足功能、行为、性能和系统协调性等方面的要求。
完全采用黑盒测试技术。
系统测试一般要完成以下几种测试。
（1）功能测试
（2）性能测试
（3）系统可靠性、稳定性测试
（4）系统兼容性测试
（5）恢复测试
（6）安全测试
（7）强度测试
（8）面向用户支持方面的测试
用户支持测试 用户界面测试
（9）其他限制条件的测试，如可使用性，可维护性，可移植性、故障处理能力等的测试。

4.3.2 系统测试的测试数据

系统测试所用的数据必须尽可能地像真实数据一样精确和有代表性，也必须和真实数据的大小和复杂性相当。满足上述测试数据需求的一个方法是使用真实数据。
在不使用真实数据的情况下应该考虑使用真实数据的一个拷贝。拷贝数据的质量、精度和数据量必须尽可能地代表真实的数据。当使用真实数据或使用真实数据的拷贝时，仍然有必要引入一些手工数据。在创建手工数据时，测试人员必须采用正规的设计技术，使得提供的数据真正有代表性，确保软件系统能充分地测试。

4.4 系统测试人员

系统测试由独立的测试小组在测试组长的监督下进行，测试组长负责保证在合理的质量控制和监督下使用合适的测试技术执行充分的系统测试。
在系统测试过程中，测试过程由一个独立测试观察员来监控测试工作。
系统测试过程也应考虑邀请一个用户代表非正式地观看测试，同时得到用户反馈意见并在正式验收测试之前尽量满足用户的要求。

5.验收测试

5.1 验收测试的定义

验收测试是软件开发结束后，用户对软件产品投入实际应用前，进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。
验收测试主要是验证软件功能的正确性和需求的符合性。要对软件进行全面的质量检测，还要判断软件是否合格，因此验收测试是一项严格的正式测试活动，是软件工程项目最关键的环节，也是决定软件开发是否成功的关键。

5.2 验收测试的主要内容

验收测试应完成的主要测试工作包括（6个）：
（1）配置复审 配置齐全 分类有序 软件维护细节
（2）合法性检查 开发工具 控件 组件 函数库
（3）软件文档检查 (3种)
a 必须提供检查的文档：项目实施计划，详细技术方案，软件需求规格说明书，概要设计说明书，详细设计说明书，软件测试计划，软件测试报告，用户手册，源程序，项目开发总结，软件质量保证计划；
b 其它可能需要检查的文档：软件配置计划，项目进展报表，阶段评审报表；
c 文档质量的度量准则：
完备性：开发方必须按照计算机软件产品开发文件编制指南的规定编制相应的文档，保证齐全。
正确性：文档描述是否准确，有无歧义，文字表达是否存在错误等。
简明性：文档的语言表达应该清晰，准确，简练，适合各种文档的特定读者。
可追踪性：指软件的设计描述是否按照需求定义进行展开的，应用程序是否与设计文档的描述一致，用户文档是否客观描述应用程序的实际操作，另外，还包括在不同的文档的相关内容之间相互检索的难易程度以及同一文档中某一内容在文档范围中检索的难易程度。
自说明性：指在软件开发各个阶段中，不同文档能够独立表达该软件在其相应阶段的阶段成果能力。
规范性：指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。
（4）软件代码测试
a 源代码一般性检查：仅对系统关键模块的源代码进行抽查，检查模块代码编写的规范性、批注的准确性、是否存在潜在性错误以及代码的可维护性等，包括命名规范检查、注释检查、接口检查、数据类型和限制性检查。
b 软件一致性检查：编译检查，安装/卸载检查，运行模块检查。
（5）软件功能和性能测试
在开发方做完功能演示后，可以进行下列测试：界面测试，可用性测试，功能测试，稳定性测试，性能测试，强壮性测试，逻辑性测试，破坏性测试，安全性测试，性能降级执行方式测试，检查系统的余量要求。
（6）测试结果交付内容
测试结束后，由测试组填写软件测试报告，包括：软件测试计划，软件测试日志，软件文档检查报告，软件代码测试报告，软件系统测试报告，测试总结报告及测试人员签字表。

5.3 验收测试技术和测试数据

验收测试主要是用户代表通过执行其在平常使用系统时的典型任务来测试软件系统，根据业务需求分析，检验软件是否满足功能、行为、性能和系统协调性等方面的要求。
完全采用黑盒测试技术。
只要有可能，在验收测试中就应该使用真实数据。当真实数据中包含机密性或安全性信息，并且这些数据在局部或整个验收测试中可见时，就必须采取以下措施来保证。
① 用户代表被允许使用这些数据；
② 测试组长被允许使用这些数据，或者合理地组织测试使测试组长不必看到这些数据也可进行测试。
③ 测试观察员被允许使用这些数据，或者能够在看不到这些数据的情况下，确认并记录测试用例的成功或失败。
在不使用真实数据的情况下，应该考虑使用真实数据的一个拷贝。拷贝数据的质量、精度和数据量必须尽可能地代表真实的数据。 当使用真实数据或使用真实数据的拷贝时，仍然有必要引入一些手工数据，例如，测试边界条件或错误条件时，可创建一些手工数据。在创建手工数据时，测试人员必须采用正规的设计技术，使得提供的数据真正有代表性，确保软件系统能充分地测试。

5.4 α、β测试

一个软件产品可能拥有众多用户，不可能由每个用户验收，此时多采用α、β测试，以发现那些似乎只有最终用户才能发现的问题。
α测试是在软件开发公司内模拟软件系统的运行环境下的一种验收测试，即软件开发公司组织内部人员，模拟各类用户行为对即将面市的软件产品（称为α版本）进行测试，试图发现并修改错误。
经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况，提出批评意见。然后软件开发公司再对β版本进行改错和完善。
所以，一些软件开发公司把α测试看成是对一个早期的、不稳定的软件版本所进行的验收测试，而把β测试看成是对一个晚期的、更加稳定的软件版本所进行的验收测试。

5.5 验收测试人员

验收测试一般在测试小组的协助下，由用户代表执行。测试组长负责保证在合理的质量控制和监督下使用合适的测试技术执行充分测试。测试人员在验收测试工作中将协助用户代表执行测试，并和测试观察员一起向用户解释测试用例的结果。

6. 回归测试

每当软件增加了新的功能，或者软件中的缺陷被修正，这些变更都有可能影响软件原有的功能和结构。回归测试是为了保证对软件所做的修改没有引入新的错误而重复进行的测试。
回归测试是指软件系统被修改或扩充后重新进行的测试。
在理想的测试环境中，程序每改变一次，测试人员都重新执行回归测试，一方面来验证新增加或修改功能的正确性，另一方面测试人员还要从以前的测试中选取大量的测试以确定是否在实现新功能的过程中引入了缺陷。
因此，严格地说，回归测试不是一个测试阶段，只是一种可以用于单元测试、集成测试、系统测试和验收测试各个测试过程的测试技术。
回归测试和V模型之间的关系：

6.1 回归测试技术和测试数据

回归测试一般采用黑盒测试技术来测试软件的高级需求，而无须考虑软件的实现细节，也可能采用一些非功能测试来检查系统的增强或扩展是否影响了系统的性能特性，以及与其他系统间的互操作性和兼容性问题。
错误猜测在回归测试中是很重要的。错误猜测主要来自于经验，测试者是使用了一系列技术来确定测试所要达到的范围和程度，这些技术主要有：
① 有关软件设计方法和实现技术；
② 有关前期测试阶段结果的知识；
③ 测试类似或相关系统的经验，了解在以前的这些系统中曾在哪些地方出现缺陷；
④ 典型的产生错误的知识，如被零除错误；
⑤ 通用的测试经验规则。
设计和引入回归测试数据的重要原则是，应保证数据中可能影响测试的因素与未经修改扩充的原软件上进行测试时的那些因素尽可能一致。否则要想确定观测到的测试结果是由于数据变化引起的还是很困难的。
例如，如果在回归测试中使用真实数据，理想的方法是首先使用以前软件测试中归档的测试数据来进行回归测试，以便把观测到的与数据无关的软件缺陷分离出来，如果此次测试令人满意的话，可以使用新的真实数据，再重新执行回归测试，以便进一步确认软件的正确性。

6.2 回归测试的范围

在回归测试范围的选择上，一个最简单的方法是每次回归执行所有在前期测试阶段建立的测试，来确认问题修改的正确性，以及没有造成对其他功能的不利影响。
常用的用例选择方法可以分为以下3种。
（1）局限在修改范围内的测试；
（2）在受影响功能范围内回归；
（3）根据一定的覆盖率指标选择回归测试。

6.3 回归测试人员

由于回归测试一般与系统测试和验收测试相关，所以要由测试组长负责，确保选择使用合适的技术和在合理的质量控制中执行充分的回归测试。
测试人员在回归测试工作中将设计并实现测试新的扩展或增强部分所需的新测试用例，并使用正规的设计技术创建或修改已有的测试数据。
在回归测试过程中，测试过程由一个测试观察员来监控测试工作。在回归测试完成时测试组组长负责整理并归档大量的回归测试结果，包括测试结果记录、回归测试日志和简短的回归测试总结报告。

7. 系统排错

系统测试的目的是为了发现尽可能多的错误，系统排错的任务就是根据测试时所发现的错误，找出原因和具体的位置，并进行改正。排错工作主要由程序开发人员进行，也就是说，谁开发的程序由谁来排错。

7.1 排错过程

排错的过程开始于一个测试用例的执行，若测试结果与期望结果有出入，排错过程首先要找出错误原因，然后对错误进行修正。
排错过程有两种可能：
（1）能确定错误原因并进行了纠正，为了保证错误已排除，需要重新执行暴露该错误的原测试用例以及某些回归测试；
（2）未找出错误原因，那么只能对错误原因进行假设，根据假设设计新的测试用例证实这种推测，若推测失败，需进行新的推测，直至找到错误并纠正。

7.2 排错方法和策略

下面简要介绍常用的3种排错方法。
① 原始类排错方法是最常用也是最低效的方法，主要思想是“通过计算机找错”。例如，输出存储器、寄存器的内容或在程序中安排若干输出语句等，凭借大量的现场信息，从中找到出错的线索，耗费大量的时间和精力；
② 回溯法是从错误征兆处开始，人工的沿控制流程往回追踪，直至发现出错根源。但当程序变大时，回溯路线增加，人工回溯不太方便；
③ 归纳和演绎法采用“分治”的概念。首先基于与错误出现有关的所有数据，假想一个错误原因，用这些数据证明或反驳它；或者一次列出所有可能的原因，通过测试一一排除。只要某次测试结果说明某种假设已呈现端倪，则立即精化数据，进一步进行深入的测试。
排错时经常采用的技术：
（1）断点设置：设置断点对源程序实行断点跟踪，对于断点的设置除了根据经验与错误信息外，还应重点考虑几种类型的语句—函数调用语句，判定转移/循环语句，SQL语句，复杂算法段；
（2）可疑变量查看：通过比较变量的当前值与预期值，可以比较轻松的定位程序问题根源。
（3）SQL语句执行检查；
（4）注意群集现象：注意残存的错误数目与该程序中已发现的错误数目成正比。