漫谈软件回归测试
中国系统分析员协会高级会员，51Testing顾问 张华
俗话说“人靠衣裳马靠鞍”，良好的外观往往能够吸引眼球，激发顾客（用户）的购买欲望，最终达成商业利益的实现。软件的设计亦如此，Window XP 在商业上的巨大成功很大一方面来自于它一改往日呆板，以突出“应用”的灰色界面，从“用户体验”角度来设计界面，使界面具有较大的亲和力。就目前的软件设计的发展趋势来说，良好的人机界面设计越来越受到系统分析、设计人员的重视。但是如何对设计的人机界面（包括帮助等）进行测试，给出客观、公正的评价，却鲜见于报端。本文试从共性分析和个性分析的角度，给出一些测试意见和原则，简单且易于上手。起到一个抛砖引玉的目的、以飨读者。
我们知道：“不立规矩无以成方圆”。在软件界面设计强调张扬个性的同时，我们不能忘记软件界面的设计先要讲求规矩－简洁、一致、易用，这是一切软件界面设计和测试的必循之道，是软件人机界面在突出自我时的群体定位。美观、规整的软件人机界面破除新用户对软件的生疏感，使老用户更易于上手、充分重用已有使用经验，并尽量少犯错误。由此我们在对软件人机界面进行测试时（设计评审阶段和系统测试阶段结合进行），不妨从下列一些角度测试软件的人机界面。（1）一致性测试
一致性使软件人机界面的一个基本要求。目的是使用户在使用时，很快熟悉软件的操作环境，同时避免对相关软件操作发生理解歧义。这要求我们在进行测试时，需要判断软件的人机界面是否可以作为一个整体而存在。下面是进行一致性测试的一些参考意见：
提示的格式是否一致；
菜单的格式是否一致；
帮助的格式是否一致；
提示、菜单、帮助中的术语是否一致；
各个控件之间的对齐方式是否一致；
输入界面和输出界面在外观、布局、交互方式上是否一致；
命令语言的语法是否一致；
功能类似的相关界面是否在在外观、布局、交互方式上是否一致（比如商品代码检索和商品名称检索）；
存在同一产品族的时候，是否与其他产品在外观、布局、交互方式上是否一致（例：Office产品族）；
同一层次的文字在同一种提示场合（一般情况、突显、警告等）在文字大小、字体、颜色、对齐方式方面是否一致；
多个连续界面依次出现的情况下，界面的外观、操作方式是否一致（当然可能会有例外，比如操作结束的界面）。
（2）信息反馈测试
假设系统的使用者是一个初出茅庐的生手，你能指望她（他）在进行操作不出错吗？但这还不是问题的所在，问题的所在在于我们都会犯错误，我们都有自己不了解的东西。如何避免，这要求我们的人机界面有足够的输入检查和错误提示功能。通过信息反馈，用户得到出错提示或是任务完成的赞许之语。但有些不幸的是，我们很多系统都在此方面做的不尽人意。下面是这类测试的一些参考意见：
系统是否接受客户的正确输入并做出提示（例：鼠标焦点跳转）； 系统是否拒绝客户的错误输入并做出提示（例：弹出警告框，声响）；
系统显示用户的错误输入的提示是否正确，浅显易懂（例：“ERR004”这样的提示让人不知所云）；
系统是否在用户输入前给出用户具体输入方式的提示（例：网站注册程序）；
系统提示所用的图标或图形是否具有代表性和警示性；
系统提示用语是否按警告级别和完成程度进行分级（若非某些破坏性操作，请对用户温和一些）；
系统在界面（主要是菜单、工具条）上是否提供突显功能（比如鼠标移动到控件时，控件图标变大或颜色变化至与背景有较大反差，当移动开后恢复原状）；
系统是否在用户完成操作时给出操作成功的提示（很多系统都缺少这一步，使用户毫无成就感）。
（3）界面简洁性测试
你的人机界面像你的脸一样对称、干净吗？我们往往看到的使很多系统在人机界面设计上就像长了天花的病人。因此我们不得不对其进行美容前的检查，下面是一些供检查的建议条款。
用户界面是否存在空白空间（没有空白空间的界面是杂乱无章的，易用性极差）；
各个控件之间的间隔是否一致；
各个控件在垂直和水平方向上是否对齐；
菜单深度是否在三层以内（建议不要超出三层，大家可以参考微软的例子）；
界面控件分布是否按照功能分组（菜单、工具栏、单选框组、复选框组、Frame等）；
界面控件本身是否需要通过滑动条的滑动来显示数据（建议采用分页显示并提供数据排序显示功能）；
实际上，一个处理该类测试的原则性的东西就是：干掉多余的东西，尽可能分组。
（4）界面美观度测试
你的界面美观吗？试想一个服装模特穿一身不得体的衣服其展示效果会如何？我至今还记得在学习美学时老师讲过的一句话：美是对比的产物。在软件界面的美观度测试上，我们不得不注意下面的一些建议。
前景与背景色搭配是否反差过大；
前景与背景色是否采用较为清淡的色调而不是深色（比如用天蓝色而不用深蓝色和墨绿色）；
系统界面是否采用了超过三种的基本色（一般情况下不要超过三种）；
字体大小是否与界面的大小比例协调（一般中文采用宋体9-12，英文采用Arial或Times New Roman，日文采用SimSun或明朝）；
按钮较多的界面是否禁止缩放（一般情况下不宜缩放，最好禁止最大、最小化按钮）；
系统是否提供用户界面风格自定义功能，满足用户个人偏好；
（5）用户动作性测试 “科学是懒人的哲学”，这是我大学专业老师的一个观点。我们的计算机系统也不例外。我们的系统能让用户尽可能地偷懒吗（少动手肘，少记命令等），从这个角度出发，相信你会对用户动作性测试的本质有较深的体会。我相信没有一个测试员愿意做的多而收获的少。此外用户从某种角度上是心怀不测的挑衅者和肇事者。他们很少有太多的耐心来对待他们寄以很大期望的系统。下面是一些判断用户是否能够“偷懒”和“发泄防止”的测试建议。
是否存在用户频繁操作的快捷键；
是否允许动作的可逆性（Undo，Redo）；
界面是否有对用户的记忆要求；
系统的反应速度是否符合用户的期望值；
是否存在更便捷、直观的方式来取代当前的界面的显示方式；（比如用菜单界面代替命令语言界面）
用户在使用时任何时候是否能开启帮助文档（F1）；
系统是否提供模糊查询机制和关键字提示机制减少用户的记忆负担（比如清华紫光输入法的模糊音设定）；
是否对可能造成长时间等待的操作提供操作取消功能；
是否支持对错误操作进行可逆性处理，返回原有状态；
是否采用相关控件（如：日历，计算器等）替代用户手工键盘输入；
选项过多的情况下是否采用下拉列表或者关键字检索的方式共用户选择；
系统出错是是否存在恢复机制使用户返回出错前状态（如：Office XP的文件恢复）；
在用户输入数据之前，用户输入数据后才能执行的操作是否被禁止（如特定的按钮变灰）；
系统是否提供“所见即所得（WYIWG）”或“下一步提示”的功能（比如预览）；
（6）行业标准测试
每个行业都有自己的一套标识体系。请尽可能不要与其“撞车”。这就需要我们的人机界面测试人员对软件行业的符号体系有所了解，否则将很难担此大任。
界面使用的图符、声音是否符合软件所面向领域的行业符号体系标准；
界面说使用的术语是否符合软件所面向领域的行业命名标准；
界面的颜色是否与行业代表色彩较为相近；
界面的背景是否能够反映行业相关主题（比如：反映环保的背景一般采用自然风光作为背景）；
界面的设计是否反映行业最新的理念和大众趋势；
当然、每一个软件也应当具有自己的一些个性，这些个性是体现软件开发商和所面向的用户领域的特定需要的。比如微软的启动界面和苹果的启动界面就完全是两码事。一个不失个性的软件，其本身就是软件制作商的“广告代言人”。既要突出制作商，又不能喧宾夺主。下面我们给出一些常见的软件个性测试原则。
软件的安装界面是否有单位介绍或产品介绍，并拥有自己的图标；
软件的安装界面是否在界面上不同于通用的安装工具生成的界面（比如：金山快译的安装界面就比较有特色）；
主界面的图标是否为制作商的图标；
系统启动需要长时间等待时，是否存在Splash界面，它是否包含或反映制作者信息；
软件是否有版本查看机制，版本说明上是否有制作者或是用户的标识；
软件的界面的色彩、背景、布置是否与同类产品有不同之处，如果有，是否更为简洁、美观；
软件界面操作与同类产品相比，是否能够减少用户输入的频繁度；
软件界面操作与同类产品相比，是否在出错预防机制和提示上更为直观、醒目；
软件界面是否为特殊群体或是特殊的应用提供相应的操作机制（比如Windows的放大镜）；
软件维护活动成本占软件产品总成本的三分之二以上,回归测试[1—3]是软件维护活动一个必要组成部分,它用来确保修改后软件的正确性,提高软件产品质量。回归测试成本是昂贵的,它占软件维护活动成本的二分之一左右。软件产品在软件维护阶段,由于用户需求或者功能发生变化而需要对软件作出修改,要确保修改后软件的正确,进行的测试被称为回归测试。
回归测试需要解决四个基本问题:(1)怎样鉴别那些受到修改影响的部分(修改影响分析);(2)采用什么策略来重测受到影响的部分;(3)重测部分的覆盖标准是什么;(4)怎样选择、重用和更改存在的测试用例库(测试用例库的维护)。
本文研究的是第二个问题。关于面向对象软件的修改影响分析技术,已提出了有通过利用数据流图来分析受影响的软件中定义———使用对和他们相关的子路径。与这种方法不同的另一种技术是建立软件中函数和模块之间相互作用的控制流图,鉴别、修改受影响的函数或者模块。无论第一种还是后一种,它们都是建立在过程级或者模块级上进行分析的,这对于面向对象软件的测试粒度是偏小的。本文是基于一个在软件类层次上进行回归测试的选择测试技术。
类作为面向对象软件[4,5]的一个最小单元,以它来创建软件类关系图(ClassRlatedGraph)进行分析软件修改受到影响是比较全面的,本文在类关系图的基础提供一个有选择策略测试技术[6—10],通过对修改前软件和修改后软件类关系图比较,得到需要测试修改的软件部分和修改受到影响的部分,把他们放到类防火墙内,针对防火墙内的类产生可以重用原有测试用例的测试序列。该技术与其他的选择测试技比较有如下优点:(1)这个回归测试选择技术是安全的,也就是它重用已有的测试用例能尽可能暴露出修改后软件的缺陷部分;(2)它是有效的,即使它所选择测试用例也包含有不能暴露缺陷的用例,但比其他的选择测试要精简。
1类关系图(CRG)
1.1类的关联
无论是用C++语言还是JAVA语言书写的面向对象软件,都是以类为软件的基本单元,那么在软件中,类与类之间存在什么样关系?继承性、组合使用是类与类之间常用关系。
继承性(Inheritance):对象或类继承了另一个类的一组属性。例如在图1中,国内快递公司和国外快递公司都继承了快递公司的特征。因此,类(快递公司)称为超类,类(国内快递公司,国外快递公司)被称为子类。
组合(Aggregation):当一个类是另一个类的组成部分,就称为组合关系。例如小汽车包含引擎、车轮等组件。小汽车是一个类,引擎和车轮也是类,那么类小汽车包含类引擎和类车轮。那么小汽车和引擎、车轮是组合关系。
使用(Use):上面例子中,小汽车是由驾驶员驾驶,那么小汽车类和驾驶员类之间存在是使用关系。使用关系存在于两个或多个类之间,一个类使用另一个类。
1.2 关系图
图2描述:类关系图(CRG)是由节点(V)、标签(L)和边(E)组成。节点是组成软件的类,边是用来描述类与类之间关系,标签指出关系种类(Us-使用、Ag-组合、I-继承)。
2 回归测试的过程
选择回归测试技术通过减少测试用例个数和只测试修改受到影响的部分程序来减少回归测试成本,但全部选择测试是利用全部已有测试用例,重新测试修改后的软件,这样将大大增加了测试成本和测试时间,所以部分选择回归测试技术是目前研究的主要方向,本文提供的方法只需要把修改的类和根据类关系图确定修改受到影响的类放到一个类防火墙内(class fire),对类放火墙内类进行测试,进行测试的测试用例可以选择已存在原有测试用例,如果是新增加的类,就可以创建新的测试用例,这样就形成了回归测试的测试用例集。这种选择策略确保软件质量是有效、经济、安全的。一个典型的部分选择重测技术过程大致如下:
(1)选择T′∈T(原有的所有测试用例),形成修改后软件的测试用例;
(2)用T′测试修改后软件P′;
(3)如果有必要,需构造新的测试用例T’’,修改后的软件增加了新的功能就需要创建新测试用例来验证该功能。
(4)用T″测试修改后软件P′,用T″验证修改后软件P′的正确性;
(5)创建T,从T′,T″,得到一个新的测试用例集合和测试修改后软件P′历史记录。
3 回归测试选择策略
我们首先对面向对象软件构造他们的类关系图,类关系图是在程序类层次上创建的,类作为面向对象软件最基本组成单元,测试是高效的、安全的,并且找出了真正需要测试的类,减少了测试代价又是经济的。针对面向对象软件的继承、多态性和动态绑定及异常抛出这些特征,本文把对面向对象软件回归测试可以分为以下几种类型讨论。
3.1 创建类防火墙
我们定义类与类关系为R,它依靠继承、组合和使用,来描述类与类之间依赖关系,R={〈c2,c1〉|c1,c2∈V∧(l∈L∧〈c1,c2,l〉∈E)}。
下列这些都纳入我们关系R范畴:
a,类c1是类c2的派生类。
b,类c2是类c1的一个组成部分。
c,类c1通过使用类c2的成员变量和成员函数使用类c2。
对类c2的修改将会影响类c1的执行。那么类c1和类c2都将放入类防火墙内。
3.2 类内部成员增加
① 继承关系:类c2增加成员函数或者是成员数据,那么它和它的派生类c1将要放入防火墙内。
② 使用关系:如果类c1使用类c2新增加的成员,c1和c2要放入类放火墙内。
3.3 类内部成员删除
① 继承:类c2删除成员函数或者成员数据,那么它和它的派生类c1将放入防火墙内。
② 使用:如果类c1与类c2是使用关系,并且使用了类c2的删除成员函数或者成员数据,那么类c1和类c2要放入类防火墙内。
3.4 类内部成员修改
① 继承:类c2成员被修改或者重命名,那么它和它的派生类c1将要放入防火墙内。
② 使用:类c2成员变量重定义或者重命名,那么类c2和使用它的类c1要放入防火墙内。成员函数体被修改,调用它的类c1要放入类防火墙。
3.5 类的增加
类的增加可以等价于类的成员增加,可以适用2方法。
3.6 类的删除
类的删除等价与类成员删除,放入防火墙的方法类似3方法
3.7 异常抛出
异常作为类,同样适用于以上方法。
如果类c1是类c2的组成部分,那么对c1进行上述修改,修改的部分与c2有关联,将会影响到类c2,c1和c2都要放入类防火墙。
4 实例应用
我们通过一个实例来说明我们的算法。图3是一个包含四个类A,B,C和D的系统。用我们的算法来分析对类A中 fa1的修改,我们将根据修改影响重新选择测试序列。我们假设用T表示原来的测试用例集。
4.1 类内部检测
类成员变量fa1修改影响到类成员方法ma1()。mal()要放入防火墙内将重新测试。
4.2 类的继承检测
mal()影响到子类A1和A2。A1和A2要放入防火墙内进行重新测试。
4.3 调用关系检测
调用类A的受影响成员方法mal()的有类B的mb1()方法。调用类B的受影响mb1()方法的有类C的成员方法mc1(),mc1()也将影响mc2()。类B和类C将放入防火墙内进行重新测试
4.4 关联关系检测
虽然类B和类D有关联,但没有影响因子。所以类D不需要放入防火墙内。
综上所述,假设新的测试用例集用T‘表示,选择T中类A、类B、类C的测试用例组成T‘。因为没有增加新的成员,所以不需要增加新的测试用例。
5结束语
在本文中,我们提出了一个有选择策略测试技术,通过对修改前软件和修改后软件构造类关系,使用它来选择需要测试修改的软件部分和修改受到影响的部分。选择测试技术对修改后软件测试的可以减少测试周期和测试成本。
我们将来的工作是通过该策略算法建立一个自动的面向对象软件回归测试平台,也将对该方法更进一步研究它的有效性。
参考文献
[1]Wu Ye,Chen Meihwa,Kao HM.Regression testing on object-orien-ted Programs.10th International Symposium on Software Reliability Engineering,1999:270—279
[2] Leung H K N, White L. A firewall concept for both control-flow and data-flow in regression integration testing. Conference on Software Maintenance, 1992: 262—271
[3]Kung D,Gao J,Hsia P,et al.Class firewall,test order,and regres-sion testing of object-oriented programs.Journal of Object-Oriented Programming,1995:51—65
[4] Booch G. Object-oriented design with application, Redwood City, Calif: Benjamin/Cummings, 1991
[5] Rumbaugh J. Object-oriented modeling and design, Prentice-Hall,1991
[6]Rothermel G.Harrold M J.Analyzing regression test selection tech-niques.IEEE Transaction Software Engineering,1996:529—551
[7]Rothermel G,Harrold MJ.A safe,efficient regression test selection technique.ACMTransactions on Software Engineering and Methodol-ogy,1997;6(2):173—210
[8]Rothermel G,Harrold MJ.Selecting regression tests for object-orien-ted software.In:International Conferene on Software Maintenane(IC-SM94),British Columbia(Canada):Vicforia,1994:14—25
[9] Harrold M J. Jones J, Li T, et al. Regression test selection for Java software. Proceedings of the ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2001), 2001:312—326
