一种基于更动影响域分析的回归测试方法*

回归测试是指被测单元、部件、配置项和系统因各种原因进行更改(以下称更改前为老版本，更改后为新版本)后的再测试[1]，目的是重新验证一个系统或部件被修改后有没有造成不期望的副作用，是否仍然符合它的需求规格说明[2].

在生命周期的任何一个阶段，软件都可能发生改变.改变原因可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块.当软件发生改变时，就可能存在修改错误或产生副作用，而导致软件未被修改的部分产生新的问题，使本来正常的功能发生错误.因此，每当软件发生变化时，就必须重新测试现有功能，以便确定修改是否达到了预期目的，检查修改是否损害了原有的正常功能；同时，还需要补充新的测试用例来测试新的和被修改了的功能.为了验证软件修改的正确性及对其他功能的影响就需要进行回归测试，该测试在软件开发过程中占有很大的比重.根据第三方测试数据统计，1个提交第三方测试的软件，至少有4个版本的回归，多者可达十几个版本.在渐进和快速迭代开发中，新版本的连续发布使回归测试进行得更加频繁.回归测试在软件生命周期中的维护成本中可占总维护成本的1/2[3].

回归测试在软件生命周期中扮演着重要的角色，大约30%的错误都是通过回归测试发现的[3].因忽视回归测试而造成严重后果的例子不计其数.因此回归测试策略研究和选择对提高回归测试效率和有效性是非常有意义的.

目前，有关回归测试方法的研究已有很多，大多数研究集中在某些特定的领域上，采用专门的方法和工具减少测试用例，从而提高回归测试效率.如Memon[4]提出了基于GUI图形界面的回归测试方法，这种GUI图形界面的回归方法不适用于嵌入式软件；基于程序切片技术的回归测试利用切片技术提取信息组成一个程序片段后设计测试用例[5]，但该方法针对稍有规模的程序切片构造非常困难，难以操作.本文在总结常用的回归测试策略的基础上，对策略的特点进行分析，最后从测试成本和效率角度，提出了一种基于更动影响域分析的回归测试方法，详细说明了更动类型，并针对每种类型提出了对应的确认和影响域分析方法.

1 回归测试策略说明及选择

1.1 策略说明

测试人员实施测试时需要将设计的测试用例保存到测试用例库中，并对其进行维护和管理.当得到一个软件的基线版本后，用于测试基线版本的所有测试用例就形成了基线测试用例库.

回归测试时，需要从基线测试用例库中选取合适的测试用例组成回归测试用例包并运行.

回归测试用例包的选取需要结合测试时间和花费成本进行，通常有如下几种回归测试策略[6-8].

(1)全面的回归测试

选择测试用例库中的全部测试用例组成回归测试用例包并重新运行.该方式测试遗漏风险最低，但测试成本最高，测试效率最低.当回归测试次数不断增加、测试用例不断增多时，相关的成本和进度往往超出项目预算.

(2)基于风险分析的回归测试

基于一定的风险标准从测试用例库中选择回归测试用例包.首先运行最重要和可疑的测试用例，而跳过那些非关键、优先级低的测试用例.该测试策略花费的成本相对低；但是，由于目前没有一个好的风险标准，关键等级较高的测试项目采用该策略时，存在极大的质量隐患.

(3)基于操作剖面的回归测试

如果测试用例是基于软件操作剖面设计的，则测试用例的分布反映了系统的实际使用情况.回归测试时优先选择功能最重要或使用最频繁的测试用例，以降低最高级别的风险发生概率，有助于尽早发现那些对可靠性有重大影响的软件问题.这种方法可以在给定的预算条件下最有效地提高软件可靠性，但在实际用例设计过程中，基于软件操作剖面的用例设计方法很难实施.

(4)基于代码更动的回归测试

通过总结代码的更动情况并分析更动的影响范围，对更动及其受影响的部分进行测试.

1.2 策略选择

基于代码更动的回归测试策略花费的成本相对较低，并且能够提高测试效率，具体实施也相对容易.因此嵌入式星上软件的回归测试通常选择该策略.但是该策略的实施质量依赖于更动影响域分析的充分性，因此为保证回归测试质量，研究和总结代码更动影响域分析方法是必须的.

2 代码更动影响域分析方法

通常，代码更动体现在如下3个方面：

1)控制结构算法/逻辑更动；

2)参数更动；

3)参数和控制结构算法/逻辑算法均更动.

2.1 算法/逻辑更动影响域分析方法

2.1.1 遵循原则

算法/逻辑更动影响域分析需遵循如下原则：

1)如果算法的修改既不要求修改它的输入参数，又不要求改变它的输出参数，那么它的影响仅限于被修改的单元或模块；

2)如果算法的修改对输入参数有了新的要求，则该修改不仅影响本模块，还对该参数的“生产者”模块有影响；

3)如果算法的修改对输出参数的结构或类型进行了修改，则该修改不仅影响本模块，还对该参数的“消费者”模块有影响.

2.1.2 分析方法

实际测试过程中，算法/逻辑的更动属性可分为需求更动、问题纠正、完善设计3类.确定代码更动属性后，相关的影响域分析和确认方法如下：

1)属性为需求更动，表示当前代码更动是依据需求变更进行的，因此该类更动首先分析当前代码是否与变更后的需求说明一致，然后分析代码中所有相关功能是否均进行了对应修改，即确认需求变更是否在代码中进行了全面修改；

2)属性为问题纠正，表示当前代码更动是依据代码执行或测试过程中发生或发现问题进行的，因此该类更动需要确认当前代码是否消除了原有问题并没有引入新问题；

3)属性为完善设计，表示当前更动对软件功能和性能没有不良影响，仅仅是依据某种目的而进行的改进，如提高可读性、改善软件性能、删除多余变量等.完善设计修改的影响仅限于被修改的单元或模块.

针对完善设计，根据改进目的，可以进一步细分为等价修改、设计改进、适应性修改，具体如下：

① 等价修改表示代码更改前后实现功能完全一致，没有特定的改进目的；

② 设计改进表示更动前后实现的功能需求相同，但更改后代码有特定的改进目的；

③ 适应性更动表示由于软件修改而带来的间接修改，如增加代码后导致程序中的org位置更动，软件更改引起的作为参数的版本号变化等.

2.2 参数更动影响域分析方法

相对算法/逻辑更动影响域分析，参数更动的影响域分析和确认在实际测试过程中尚未得到充分重视和应用实施，导致由于参数更动而未对该参数相关的所有代码进行适应性修改，造成相关功能实现错误.以下是在实际的软件回归测试过程中由于参数更动不全面而导致的3个典型遗漏问题实例.

例1.某参数TMS001位定义变化

参数TMS001有D7-D0共8位，其中D7未定义，即没有实际意义，其他各位分别代表不同的意义.由于需求更动引起该参数的位定义发生变化，具体说明如下.

1)变化内容：“A令接收到标记”由参数TMS001的D5 位表示改为该参数的D7位表示；

2)代码更动：针对上述变化，代码更动时只在设置“A令接收到标记”的语句处进行了修改，即由设置D5=1B改为设置D7=1B，但是没有对判断“A令接收到标记”的语句进行相应修改，即没有把语句if((TMS001&0x20)==0x20)改为if((TMS001&0x80)==0x80)，造成代码修改不全面，判断错误，最终导致对应功能无法实现.

例2.某参数STAT定义变化

参数STAT为数组变量.参数STAT的数组大小根据新需求发生变化，具体说明如下.

1)变化内容：STAT为数组变量，数组大小由86改为100；

2)代码更动：代码采用for循环的方式对该数组变量进行访问，该变量对应的直接功能模块中的for语句全部进行了修改，但其他模块中的两处for循环语句却被遗漏，即语句

for(j=0;j<86;j++)

heat_channel_current_status[j][1] &= 0xbf

没有改为

for(j=0;j<100;j++)

heat_channel_current_status[j][1] &= 0xbf

上述修改不全面导致对应的功能实现错误.

例3.新增参数NUM

NUM是依据新需求增加的参数，具体变化如下.

1)变化内容：新增定义，该变量值组织到遥测参数中；

2)代码更动：遥测参数组织过程中增加参数NUM的组织，即根据新需求增加了该变量的定义，并根据数据协议组织该参数到一个数据包中，但代码针对该参数没有任何赋值操作，导致新增需求无法实现.

上述3个实例均是由于未进行充分的参数更动影响域分析而引起的恶劣后果.因此回归测试过程中，参数更动影响域分析是必不可少的.

参数分为全局参数和局部参数.在函数之外定义的变量称为全局参数，函数内定义的变量称为局部参数.

2.2.1 全局参数的更动影响域分析

所有对该全局参数有读/写操作的模块都会受到影响，需要结合参数更动类型进行全面地分析和确认.参数更动类型通常包括新增参数、初始值/固定值更动参数、删除参数、形式更动参数、结构更动参数.

(1) 新增参数影响域分析

新增参数为代码中新增一个变量或数据，对应的影响域分析必须包括如下几个方面.

1)软件对该参数访问时对应的逻辑过程必须与需求规格说明一致.

2)该参数被赋过初始值，否则会出现“未初始化就使用”的基本程序问题.

3)至少保证该参数有一次读/写操作，否则会出现新增变量没有明确的功能意义，存在引入错误的可能.

4)结合该参数定义类型，对所有引用该参数的操作语句进行相关的正确性/合理性分析，具体说明如下：

① 软件对该参数的读取、赋值、保存等操作过程中涉及到的其他参数类型是否与该参数类型匹配；

② 如果该参数参与数学运算，需要结合数据类型分析当前运算过程是否会引入运算错误(如溢出).

(2)初始值/固定值更动参数影响域分析

参数初始值/固定值更动为代码中的参数数值发生变化，往往不涉及逻辑确认，因此一般情况下，影响域分析时只需确认初始值/固定值设置是否满足需求说明，当该参数参与公式计算或运算时，则需要分析数值更动是否会引入运算错误.

(3) 删除参数影响域分析

删除参数为代码中删除了其定义和使用语句.影响域分析必须包括如下几个方面：

1) 该参数不再被任何代码语句引用；

2) 该参数涉及的语句被删除后对应的逻辑过程必须满足新的需求说明.

(4)形式更动参数影响域分析

形式更动参数一般情况包括参数的数据类型更动、数据长度更动和数据元素更动.其中，数据类型更动如字符型变为整型；数据长度更动如一个数组的长度变化；数据元素更动如一个参数的各个位的定义变化、一个数组中的各个单元的定义变化.

形式更动参数的影响域分析必须对所有引用该参数的操作语句进行相关的正确性/合理性分析.针对每种更动参数影响域分析的具体说明如下：

1) 数据类型更动的参数，往往不涉及代码逻辑更动，因此影响域分析时只需按照新增参数中数据类型的分析方法进行，确认代码是否引入新的缺陷；

2)数据长度更动的参数，影响域分析时必须对所有引用该参数的语句进行长度引用分析，确认代码中该参数的数据长度全部进行了对应更动，保证更动的全面性；

3)数据元素更动的参数，影响域分析必须对所有引用该参数的操作语句进行充分分析，确认所有代码中有关该参数的元素定义引用(包括读和写)均符合新的协议规定和说明.该类型更动在实际的测试过程中经常被忽略，导致修改引入新缺陷，因此，本文在此对数据元素更动的参数影响域分析进行重点说明.

数据元素更动的参数，指参数的类型/结构没有发生变化，但其内部的数据元素发生变化，如变量int DATA[4]保存对象由TK1、TK2、TK3、TK4更改为TK4、TK3、TK2、TK1.

该更动的影响域分析必须确认软件针对每个参数元素的所有赋值和读取操作是否满足新的需求要求或仍然满足未更改的原需求，以保证避免如下错误认识或结果：

① 源代码由DATA[0]→BUF改为DATA[3]→BUF时，应该是原需求“保存TK1到缓冲区BUF中”的适应性修改，而不能认为是需求更动；

②源代码由DATA[1]=5改为DATA[2]=5时，应该是原需求“设置TK2为5”的适应性修改，而不能认为是需求更动；

③ 源代码X=Y+DATA[2]如果没有更改时，应该是原需求X=Y+TK3更改为X=Y+TK2.此时如果用户需求没有变化，则代码实现错误；

④ 源代码DATA[3]=100如果没有更改时，应该是原需求TK4=100更改为TK1=100.此时如果用户需求没有变化，则代码实现错误.

(5)结构更动参数影响域分析

一个参数如果定义为结构类型，其更动包括新增元素、删除元素、形式更动元素，更动对应的影响域分析可以参见新增参数、删除参数和形式类型更动参数的对应说明.

(6) 参数更动特征说明

通过以上的分析和说明，参数修改对应的影响域分析相关的特征总结如表1所示.

表1 参数更动对影响域分析的特征说明

2.2.2 局部参数的更动影响域分析

局部参数的更动一般情况下只影响本模块，不需要对其他模块进行分析确认，但是必须遵循如下原则：如果该参数在模块中的操作引入了全局参数的运算操作，或参与了全局参数的运算操作，则更动确认时，需要对运算结果对应的范围及引用该结果进行运算的所有语句进行分析，以确保当前更动不会引起软件的运算错误.

2.3 其他影响域分析原则

在前面逻辑/算法和参数更动影响域分析的基础上，为确保当前修改对软件其他功能没有不良影响，需要综合分析当前更改引起的其他影响域，相关的分析原则如下：

1)针对一项代码更动，必须检查分析受影响模块的相关部分是否做了同步更动；

2)针对一个需求更动，必须分析确认代码中所有相关功能均进行了对应修改，即回归影响域分析要确认代码修改是否全面；

3)影响域分析过程中，必须考虑非功能需求(如性能需求、余量需求)的影响分析，一般情况下，代码修改后需要重新运行相关用例对软件性能进行重新测试，以避免代码更动引入性能失效；

4)必须考虑中断程序模块、其他的进程(线程)、内存驻留程序模块等对当前修改后整体代码的影响.操作过程中，采用中断冲突分析技术进行专项检测，以避免代码更动引入中断资源使用冲突或中断时序错误.

3 结 论

本文说明了一种基于更动影响域分析的回归测试方法.采用该方法，测试人员需要进行回归测试时，就可以很容易地识别软件哪些功能和模块需要重新测试，从而快速地从基线测试用例库中提取、修订合适的测试用例组成新的回归测试用例包，通过运行回归测试用例包来实现回归测试.该方法在嵌入式软件回归测试过程中已经得到实际应用.结果表明该方法在有效降低成本的前提下，可保证测试充分性，从而大大提高测试质量.在该回归方法的基础上，下一步需要进行相关工具的研究以实现测试自动化，进一步提高测试效率.

参 考 文 献

[1]闫宇华，李谊，黄宁，等.军用软件测评实验室测评过程和技术能力要求[S].北京：总装电子信息部,2005:26-28

[2]IEEE.Standard glossary of software engieering terminology[S]. New York: IEEE Std,1990

[3]Rothermel G，Harrold M．Analyzing regression test selection techniques[J].IEEE Transactions on Software Engineering,1996,22(8):529-551

[4]Memon A M,Xie Q.Studying the default-detection effectiveness of GUI test cases for rapidly evolving software[J].IEEE Transactions on Software Engineering,2005,31(10):884-896

[5]陈永郑,李龙封.基于程序切片技术的回归测试方法研究[J].计算机技术与发展,2007,17(12):113-115

Chen Y Z,Li L S.Regression testing based on program slicing[J]. Computer Technology and Development, 2007,17(12):113-115

[6]马军勇，杨胜建.软件回归测试研究[J].电子测试，2009,6(6):56-59

Ma J Y，Yang S J. Software regression testing and it’s practice[J]. Electronic Test，2009,6(6):56-59

[7]王小丽,段永颢.软件回归测试用例选取方法研究[J].空间控制技术与应用,2010,36(3):46-51

Wang X L，Duan Y H. Research and application on regression test suite selection[J].Aerospace Control and Application,2010,36(3):46-51

[8]古乐,史九林.软件测试技术概论[M].北京:清华大学出版社,2007:216-217