CN102831057A

CN102831057A - 一种用功能图分析软件功能变更及其影响的方法

Info

Publication number: CN102831057A
Application number: CN2012102868486A
Authority: CN
Inventors: 于秀山; 王建伟; 许峰; 宋炎淼; 于长钺; 杨豹; 董昕; 刘然; 刘怡静; 黄忠见; 迟芳
Original assignee: 于秀山
Current assignee: China Software Evaluation Center
Priority date: 2012-08-13
Filing date: 2012-08-13
Publication date: 2012-12-19
Anticipated expiration: 2032-08-13
Also published as: CN102831057B

Abstract

本发明公开了一种用功能图分析软件功能变更及其影响的方法，包括：通过对被测软件进行分析，构建软件功能图；分析控件变更和代码变更影响；控件与代码映射，通过分析源程序代码，采用代码与界面控件映射方法，找出变更代码所对应的软件功能，将代码变更转化为功能变更；根据功能变更和代码变更所影响到的软件功能情况，分析功能变更影响域，找出经过功能变更点的所有功能。本发明采用方法依赖图描述代码依赖关系，能够准确反映代码变更对软件带来的影响；充分考虑了代码变更和控件变更对软件功能带来的影响，影响分析全面；根据控件和代码之间关联关系将代码变更转换为功能变更，变更影响分析结果直观。

Description

一种用功能图分析软件功能变更及其影响的方法

技术领域

本发明涉及一种软件测试方法，具体涉及一种用功能图分析软件功能变更及其影响的方法。

背景技术

软件变更是软件生存周期中不可避免且十分频繁的一种行为，软件变更后原有软件将受到不同程度的影响，其中有些影响是显而易见的，称为显性影响，有些影响是潜在的，难以从表面识别，称为隐性影响。软件变更影响分析是确定这些变更对软件所造成的显性特别是隐性影响，为软件测试、维护等提供技术支持。

20世纪80年代以来，GUI（图形用户界面）技术得到了广泛应用，GUI软件在给用户带来直观、简便的同时，其本身所具有的输入/输出图形化、事件驱动、事件触发随机性、多任务以及消息传递等特性，使软件功能变得越来越复杂。此外，目前大多数GUI软件都是采用快速原型方法开发的，软件版本变更频繁。软件功能的复杂性导致软件功能的每一处变更，都将对与此功能相关的其他功能带来显性和隐性影响，隐性影响难以直接、直观地识别出来，因此，在回归测试时，只能凭经验设计测试用例，难免造成测试用例的遗漏、重复和冗余，严重影响回归测试的充分性和测试效率。

在变更影响域分析领域，有代表性的研究如下：

1.面向过程分析方法

传统的变更影响分析技术是针对面向过程程序而提出的，这些方法采用程序依赖图对程序进行分析，运用控制依赖和数据依赖来表现程序节点间的依赖关系。控制依赖是从程序控制结构中提取出来的软件运行时序逻辑关系；而数据依赖则是从数据声明中提取出来的数据定义-引用关系。

使用这种程序依赖图可以很好地描述面向过程程序中的程序逻辑，但对于面向对象软件中以对象为基础的程序逻辑，这些方法不能很好处理因面向对象中的多态性而产生的间接依赖关系。

2.基于类依赖图方法

近年来，针对面向对象程序特点，有些学者将变更影响分析技术运用于面向对象软件中，提出了通过类依赖图分析变更影响的方法。这种方法粒度过粗，导致分析结果准确度不高。

上述两种方法都是以源代码为分析对象，根据源代码变更情况，找出受源代码变更影响的其他源代码。采用这些方法，能够找出代码变更影响域，但由于软件代码与功能不是简单的对应关系，因此，即使知道了受变更影响的代码，也无法得知受影响的功能。为了覆盖受变更影响的源代码，测试人员还需要花费一定的精力阅读代码，才能设计出覆盖变更影响域的回归测试用例，从而影响回归测试的效率。

软件功能是软件的精髓，用户通过软件所提供的功能完成指定的任务，相对于代码而言，软件功能更加直观，因此，从功能层面分析软件变更影响域将更加直观和简便，而已有的方法难以有效解决这个问题。

发明内容

本发明所解决的技术问题是提供一种用功能图分析软件功能变更及其影响的方法，主要解决如何从软件功能层面分析软件变更影响域，从而提高变更影响域分析的直观性、充分性和效率。

技术方案包括：

一种用功能图分析软件功能变更及其影响的方法，包括：

构建软件功能图；通过对被测软件进行分析，找出软件所有的功能以及功能之间的关系；

分析控件变更影响；通过比较新旧版本软件功能图，找出新旧版本功能差异及差异影响；

分析代码变更影响；通过比较新旧版本软件源程序代码，找出代码变更部分，根据代码变更情况，采用方法依赖图找出受代码变更影响的代码；

控件与代码映射；通过分析源程序代码，采用代码与界面控件映射方法，找出变更代码所对应的软件功能，将代码变更转化为功能变更；

分析功能变更影响域；根据功能变更和代码变更所影响到的软件功能情况，采用深度搜索算法，找出经过功能变更点的所有功能。

进一步，软件功能图构建具体包括：

词法和语法分析；采用类编译原理技术，对被测软件源代码进行词法和语法分析，通过分析得到抽象语法树和符号表；

图形用户界面GUI控件辨识；采用深度优先搜索技术，遍历抽象语法树和符号表，得到源代码中所有的GUI控件；

软件功能图生成；根据GUI控件之间的相互关系，通过对GUI控件分析，生成完整的软件功能图。

进一步：在控件变更影响分析中，针对新旧版本两个软件，首先生成软件功能图G1和软件功能图G2，而后通过比较这两个软件功能图，标识出发生变化的控件，最后根据标识出的控件找出受变更影响的其他控件。

进一步，代码变更影响分析的步骤包括：

构建方法依赖图和方法变更影响传递图，将方法依赖转换为方法变更影响传递；

方法变更影响和属性变更影响分析。根据方法变更和属性变更类型分析代码变更影响。

进一步，通过控件与代码映射建立源代码与控件之间的映射关系，从而将代码变更转化为功能变更。利用代码变更影响分析结果，根据其中受到影响的方法集合和属性集合找出与其对应的控件，并在软件功能比较结果图中予以标识。

进一步，功能变更影响域分析是根据软件功能变更标识结果，找出经过变更点的所有功能路径，所述功能路径是受功能变更影响的部分，也是回归测试时必须覆盖的最小功能集。

与现有技术相比较，本发明的有益效果是：

本发明针对GUI软件特点，从软件功能出发，提出了基于控件变更和代码变更的软件功能变更影响域分析方法。与已有方法相比，有以下优点：

（1）克服了面向过程方法不适用于面向对象软件的缺点，能够处理面向对象软件中的多态、继承等，适用于面向对象软件；

（2）与基于类划分的代码依赖图相比，本发明中采用方法依赖图描述代码依赖关系，代码分析粒度适中，能够准确反映代码变更对软件功能带来的影响；

（3）与单纯的功能变更影响分析相比，本发明充分考虑了代码变更和控件变更对软件功能带来的影响，影响分析全面，没有遗漏；

（4）与单纯的代码变更影响分析相比，本发明根据控件和代码之间的关联关系，将代码变更转换为功能变更，变更影响分析结果直观，便于使用。

附图说明

图1是本发明的主工作流程图；

图2是本发明中软件功能图生成的工作流程图；

图3是本发明中词法和语法分析流程图；

图4是本发明中GUI控件辨识的工作流程图；

图5是本发明中控件与代码映射表生成流程图；

图6是本发明中控件变更影响分析流程图；

图7是本发明中程序模块划分示意图；

图8是本发明中类变更对控件影响示意图；

图9是本发明中代码变更影响分析的流程图；

图10是本发明中的方法依赖图；

图11是本发明中依赖关系方向和变更传递方向示意图；

图12是本发明中方法依赖图和方法变更传递图；

图13是本发明中变更前后的学生管理系统界面图；

图14是本发明中V1.0版软件功能图；

图15是本发明中V2.0版软件功能图；

图16本发明中方法变更及函数调用关系图。

具体实施方式

本发明针对已有方法存在的问题，从软件功能的角度分析软件功能变更影响域，主要解决如何找出软件中受代码变更影响的软件功能，从而提高变更影响域分析的直观性、充分性和效率。

对于GUI软件而言，软件功能变更来自于两个方面，一是界面控件变更，二是底层代码变更。界面控件变更将显性影响软件已有的功能，底层代码变更将隐性影响软件已有功能。本发明针对这两种变更，对功能变更影响域进行分析。

下面参考附图和优选实施例，对本发明技术方案作详细说明。

如图1所示，是本发明的主工作流程图。一种用功能图分析软件功能变更及其影响的执行过程如下。

步骤1：软件功能图构建。通过对被测软件进行分析，找出软件所有的功能以及功能之间的关系；

步骤2：控件变更影响分析。通过比较新旧版本软件功能图，找出新旧版本功能差异及差异影响；

步骤3：代码变更影响分析。通过比较新旧版本软件源程序代码，找出代码变更部分，根据代码变更情况，采用方法依赖图找出受代码变更影响的代码；

步骤4：控件与代码映射。通过分析源程序代码，采用代码与界面控件映射方法，找出变更代码所对应的软件功能，将代码变更转化为功能变更；

步骤5：功能变更影响域分析。根据功能变更和代码变更所影响到的软件功能，采用深度搜索算法，找出经过功能变更点的所有功能，这些功能就是受软件变更影响的功能。

下面对上述5个步骤作详细说明。

如图2所示，是本发明中软件功能图生成的工作流程图。

软件功能图用来描述软件所具有的功能，是本发明的基础，这部分功能主要通过分析源程序代码，构建语法树和符号表，在此基础上，找出源程序与软件界面的对应关系，并生成软件功能图。

步骤1中的软件功能图生成包括如下步骤：

步骤11：词法和语法分析。采用类编译原理技术，对被测软件源代码进行词法和语法分析，通过分析，得到抽象语法树和符号表；

步骤12：GUI控件辨识。采用深度优先搜索技术，遍历抽象语法树和符号表，得到源代码中所有的GUI控件（如：窗口、按钮等）；

步骤13：软件功能图生成。根据GUI控件之间的相互关系（如：父子关系、调用关系等），通过对GUI控件分析，生成完整的软件功能图。

该方案可以使用算法1描述。

算法1.GetGUIRelationGraph(P)

输入P：源代码

输出G：P中GUI软件控件关系图

1.(AST,SymTable)<-Lexical_Syntax_Analyze(P)

2.GUIEmtList<-GEL_AST_SymTable(AST,SymTable)

3.(G,T)<-GRG_AST_GEL(AST,GUIEmtList)

4.Return(G,T)

算法1的第1步以P（被测软件的源代码）为参数调用函数Lexical_Syntactax_Analyze，得到P的抽象语法树AST和符号表SymTable；第2步以AST和SymTable为参数调用函数GEL_AST_SymTable，得到P的GUI控件列表GUIEmtList；第3步以AST和GUIEmtList为参数调用函数GRG_AST_GEL，得到GUI软件功能图。

步骤11中，词法和语法分析的主要目的是得到被测软件源代码的抽象语法树和符号表。

定义1：抽象语法树是一棵树T=<V,E>，其中：

V是树的节点，由源代码中的各种语法结构组成；

E是树的边，负责连接各种语法结构。

定义2：符号表是一个表形数据结构，词法分析过程中产生的标识符作为符号表的入口，后续分析得到的信息，如：标识符的类型、使用方式、存储空间等都可以根据需要加入到表中。

如图3所示，是本发明中词法和语法分析流程图。词法和语法分析是生成软件功能图的基础。本发明采用通用的方法对被测软件的源代码进行词法和语法分析。由算法2描述。

算法2.Lexical_Syntax_Analyze(P)

输入P：源代码

输出(AST,SymTable)：P的抽象语法树和符号表

1.TokenStream<-Lexical_Analyze(P)

2.(AST,SymTable)<-Syntax_Analyze(TokenStream)

3.Return(AST,SymTable)

源代码在经过词法和语法分析后，将得到其抽象语法树和符号表。算法2的第1步对源代码P进行词法分析，得到P的标记流TokenStream；第2步以标记流为基础进行语法分析，得到P的抽象语法树AST和符号表SymTable；第3步将AST和SymTable返回。

步骤12中GUI控件辨识的目的是找出程序中所设计的所有GUI控件，即：通过对抽象语法树和符号表的分析，辨识出所有的GUI控件。这一步主要通过对抽象语法树的遍历和对符号表的查找来完成。主要方法是：以深度优先方法遍历抽象语法树，如果某个叶子节点是变量，这时通过查找符号表，可以得到该变量的类型；如果该类型是GUI控件类型，则说明该变量所描述的是一个GUI控件。

程序编译和本方案中的GUI控件辨识都使用了抽象语法树和符号表，但两者的目的不同，前者的目的是生成并优化目标代码，而后者的目的是找出源代码中所有的GUI控件。

1.GUI控件类型

编程语言不同，其所包含的控件类型也不同，以Java Swing为例，其所包含的控件可以分为如下几类：

（1）窗口和窗框类：JWindow，JColorChooser,JComponent,JDesktopPane,JDialog,JEditorPane,JFileChooser,JFrame,JInternalFrame,JLayeredPane,JOptionPane,JRootPane,JScrollPane,JSplitPane,JTabbedPane；

（2）按钮类：JButton,JToggleButton,JCheckBox,JCheckBoxMenuItem,JComboBox,JRadioButton,JRadioButtonMenuItem；

（3）菜单类：JMenu,JMenuBar,JMenuItem,JPopupMenu；

（4）文本输入类：JTextArea,JTextComponent,JTextField,JPasswordField；

（5）其它：JTree,JViewPort,JScrollBar,JSeparator,JSlider,JSpinner,JTable,JTableHeader,JToolBar,JToolTip,JLabel,JList,JProgressBar。

虽然这些控件有各自的使用方法，但是，将某个变量定义为某种控件的方式是由语言本身的规范确定的，因此，可以根据这些规范，采用统一的方法辨识这些控件。

2.变量定义方式

对控件变量的定义方式主要有2种：

（1）变量声明

在程序设计语言中，变量声明负责指出某变量的存在以及其相关的性质，但并不对其进行初始化。

例如：private javax.swing.JButton computeButton;该语句定义了类型为javax.swing.JButton的变量computeButton。

（2）变量定义

在程序设计语言中，变量定义不仅负责指出某变量的存在以及其相关的性质，还需要对其进行初始化。

例如：javax.swing.JMenu fileMenu=new javax.swing.JMenu();

该语句定义了类型为javax.swing.JMenu的变量fileMenu并使用new语句对其进行了初始化。

3.控件辨别方法

如图4所示，是本发明中GUI控件辨识的工作流程图。通过在抽象语法树中对上述两种定义方式进行搜索，同时结合符号表中的内容，就可以辨识出源代码中所有的控件及其变量。

通过遍历抽象语法树和查找符号表，可以生成GUI控件列表。算法3.GEL_AST_SymTable(AST,SymTable)描述了GUI控件辨别算法。

算法3.GEL_AST_SymTable(AST,SymTable)

输入AST：源代码的抽象语法树

输入SymTable：源代码的符号表

输出GEL：源代码中的GUI控件列表

1.GEL<-[];

2.遍历AST的所有叶子节点Node

3.if(LookUpType(SymTable,Node)=GUI控件类型)

4.GEL<-Node::GEL

5.Return GEL

算法3的第1步初始化返回值GEL为空列表；第2步至第4步开始遍历抽象语法树AST；其中第3步调用函数LookUpType(SymTable,Node)判断叶子节点Node是否为GUI控件类型，如果是，则在第4步将该节点加入返回值GEL列表；抽象语法树AST遍历完成后，第5步将GUI控件列表GEL返回。

如图5所示，是本发明中控件与代码映射表生成流程图。步骤13中，要生成软件功能图，除了获取程序中的控件外，还需要知道这些控件之间的关系。GUI控件之间具有多种关系，主要包括：父子关系、兄弟关系和调用关系。

定义3：父子关系。父子关系是指在定义过程中产生的控件之间的某种与层次相关的定义关系。编程语言不同，其表征方式也不相同。在Java Swing中，父子关系的定义主要通过父控件的.add()函数（控件类型不同，该函数也有所区别）来完成。

例如，在下面的代码中

popFrame是一个JFrame类型的控件，testButton是一个JButton类型的控件。上述语句表达的含义是：将testButton加入到popFrame中，据此可知，testButton是popFrame的子控件，popFrame是testButton的父控件。

定义4：兄弟关系。具有相同父亲的GUI控件之间的关系称为兄弟关系。

例如，在下面的代码中

Button1和Button2都是popFrame的子控件，因此，Button1和Button2之间是兄弟关系。

定义5：调用关系。调用关系是指在程序执行过程中，对某控件执行某种操作（如：点击），导致某种事件被发出，从而引起其它控件的执行。例如：点击按钮A后，弹出窗口B，那么就称A和B之间具有调用关系。

以Java Swing为例，其控件通过对事件的监听完成对事件的处理。Java Swing对事件进行监听的方法包括：ActionListener,AdjustmentListener,ComponentListener,ContainerListener,FocusListener,HierarchyBoundsListener,HierarchyListener,InputMethodListener,ItemListener,KeyListener,MouseListener,MouseMotionListener,MouseWheelListener,TextListener,WindowFocusListener,WindowListener,WindowStateListener。

以常用的JButton类型的按钮控件为例，当按钮被按下时，通常会执行某个用户定义的函数。用户通过向按钮的addActionListener函数传递一个 ActionLisener函数来完成上述的功能。在ActionListener函数中，用户需要实现actionPerformed函数，该函数就是按钮被按下时执行的动作，如果用户希望执行自己定义的某个函数，则可以将该函数加入到actionPerformed函数中。

例如，在下面的代码中

openButton是一个JButton类型的按钮，通过将openButtonActionPerformed函数加入到ActionListener函数中的actionPerformed函数体中，可以实现当openButton按钮被按下时调用openButtonActionPerformed函数。

综上所述，生成控件与代码映射表的主要工作流程如图5所示，该过程由算法4描述。

算法4.GRG_AST_GEL(AST,GUIEmtList)

输入AST：源代码的抽象语法树

输入GUIEmtList：源代码中的GUI控件列表

输出T：GUI控件代码映射表

1.(G,T)<-(Null,Null)

2.遍历GUIEmtList中的所有GUI控件GEmt1

3.遍历AST

4.if(GEmt1与GUIEmtList中的某元素GEmt2是父子关系)

5.G<-G+FatherChild(GEmt1,GEmt2)

6.if(GEmt1与GUIEmtList中的某元素GEmt2是兄弟关系)

7.G<-G+Brother(GEmt1,GEmt2)

8.if(GEmt1与GUIEmtList中的某元素GEmt2是调用关系)

9.G<-G+Invoke(GEmt1,GEmt2)

10.GCode<-AST中与GEmt1对应的代码段

11.T<-T::[GEmt1,GCode]

12.Return(G,T)

算法4的工作过程是：第1步将返回值G和T初始化为空；第2步至第9步遍历GUIEmtList中的所有GUI控件GEmt1，寻找与GEmt1有关系的其它控件；第3步遍历抽象语法树AST；第4、5步寻找父子关系；第6、7步寻找兄弟关系；第8、9步寻找调用关系；第10步找到GEmt1控件对应的源代码段；第11步将GEmt1和GCode的映射加入到T中；第12步将结果返回。

如图6所示，是本发明中控件变更影响分析流程图。步骤2的控件变更影响分析主要从功能层面识别新旧版本软件功能上的差异以及差异对软件其他功能的影响。

针对新旧版本两个软件，首先生成软件功能图G1和软件功能图G2，而后通过比较这两个软件功能图，标识出发生变化的控件，最后根据标识出的控件，找出受变更影响的其他控件。

1.控件变更标识

GUI界面由分层次结构的组件组成，组件又包含各种不同类型的控件，组件本身也是一个控件，GUI界面的变更体现为控件的变更。

对于两个软件功能图G1，G2，其差别可能出现在节点集合上，也可能出现在边集合上，也可能二者皆有差别。对两个软件功能图进行比较时，需要对节点集合和边集合都进行比较。算法5描述了对2个软件功能图进行比较的方法。

算法5.SFG_Compare(G1,G2)

输入G1：软件功能图1

输入G2：软件功能图2

输出NS：G1和G2中不相同的节点集合

输出ES:G1和G2中不相同的边集合

1.NS,ES<-{},{}；

2.(NS1,ES1)<-(G1的节点集合,G1的边集合)；

3.(NS2,ES2)<-(G2的节点集合,G2的边集合)；

4.NS<-(NS1-NS2)+(NS2–NS1)；

5.ES<-(ES1-ES2)+(ES2–ES1)；

6.Return(NS,ES)

算法5的工作过程如下：第1步初始化返回值；第2步得到软件功能图G1的节点集合NS1和边集合ES1；第3步得到软件功能图G2的节点集合NS2和边集合ES2；第4步计算NS1与NS2的差以及NS2与NS1的差，它们的并是G1和G2不同节点集合NS；第5步得到G1和G2不同的边集合ES；第6步将NS和ES返回。

2.控件变更影响分析

通过控件变更标识，找出了新旧版本软件功能图之间的功能变更情况，对于这些变更，可以分为两种情况：控件本身属性的变更和新增/删除控件产生的变更。控件属性变更是图形用户界面中与显示相关属性的变更，如控件的大小、位置、颜色的变化。这种变更不涉及软件功能性的改变；而新增/删除控件的变更不仅使软件功能或特性发生了改变，而且描述GUI界面关系的软件功能图也会发生改变。

GUI界面控件变更包括三种情况：新增控件、删除控件和控件自身各种属性的修改。这三类变更的影响各不相同，下面分别对这三类变更影响进行分析。

（1）新增控件

当GUI软件中增加了新控件时，新增加的控件和其它控件之间有事件交互，表现在软件功能图上，新增GUI控件顶点有和其它控件顶点交互的边。

对于新增控件，在软件功能比较结果图中保留新增控件节点以及新增节点和其它节点之间的交互边。

（2）删除控件

当GUI控件被删除时，在软件功能比较结果图中该节点以及和其有事件交互关系节点之间的边都要删除。

（3）修改控件

GUI控件的修改主要是指控件属性如颜色、位置坐标、大小等变化，这些变化对GUI软件功能不产生影响，因此，不需要修改软件功能比较结果图。

步骤3中，代码变更影响分析对GUI软件来说，控件通过调用底层处理代码处理用户输入事件，最终实现软件各项功能，故代码变更是引起软件功能变更的根本原因。

如图7所示，是本发明中程序模块划分示意图。根据面向对象软件特点，按照代码模块划分的粗细粒度，可以将程序模块划分为以下六个层次：功能模块级(Function module Level)、类簇级(Class Cluster/Inter-class Level)、类级(Class Level)，方法级(Method Level)、程序块级(Program module Level)和程序语句级(Program Statement Level)。从图7中不难看出，从功能模块级到程序语句级，其划分粒度不断细化。

目前，国内外在面向对象软件变更影响研究领域，主要采用的是基于类划分的依赖图模型。采用这种方法，当生成GUI软件回归测试用例时，其粒度过粗，表现为当类发生改变时，与该类相关联的所有GUI控件均被认为发生了变更，需要对其重新测试，而发生变更的代码不一定对与该类关联的所有GUI控件产生影响，故依据类划分的依赖图产生的测试用例存在大量冗余。

如图8所示，是本发明中类变更对控件影响示意图。名为“设置员工年龄”和“设置员工性别”控件分别调用类Staff中的方法Setage( )和方法Setsex( )对各自事件进行处理，故“设置员工年龄”和“设置员工性别”控件和Staff类相关联。当Staff类中方法Setage( )发生变更时，显然类Staff 发生了变更，在回归测试时需要对包括上述列举的两控件在内的所有和Staff类相关联的控件进行测试。但是对“设置员工性别”控件而言，它调用的Setsex( )方法虽然和发生变更的方法Setage( )同在Staff类中，但是这两个方法并无语义链接，不存在依赖关系，Setage( )的变更不会影响到Setsex()方法，故对“设置员工性别”控件的测试是多余的。

造成上述问题的原因在于采用类划分方法粒度过粗，针对这个问题，本发明根据代码和控件的关联关系，结合变更影响分析需要，提出了一种基于方法依赖图的变更影响分析模型。方法依赖图其粒度比类依赖图细，有利于提高变更影响分析精度。这种方法虽然比语句和程序块级划分的粒度粗，但对GUI软件而言，软件所有的功能通过控件调用与之相关的事件处理方法来实现，而且控件与程序语句和程序块之间并无直接关联关系，因此，语句或程序块级的划分，不仅变更影响分析开销巨大，而且对GUI软件测试也没有实际意义。

在变更影响分析中，常常将能产生变更影响传递的源代码模块的变更称为原子变更。原子变更是为了追踪源代码的变更而定义的一组便于分析的、相互独立的、不可再分解的变更，原子变更是代码变更影响分析基本单元。由于在代码中方法对方法，方法对属性均存在直接调用关系，故方法除了对方法产生依赖外，也会对属性产生依赖。因此，本发明中考虑来自于方法和属性两个方面的变更，方法变更和属性变更在程序代码中具体表现形式如见表1所示。

表1方法变更和属性变更种类

如图9所示，是本发明中代码变更影响分析的流程图。代码变更影响分析的流程包括如下步骤：

步骤31：方法依赖图构建

方法依赖图是面向对象软件中方法依赖关系信息的抽象，其本质是一个多边有向图。

如图10所示，是本发明中的方法依赖图，顶点代表源代码中的方法，其内容包含了方法的定义信息、数据成员，方法所包含的代码及和方法关联的控件等信息。

方法依赖图中的边表示顶点之间的依赖关系，方法之间的依赖关系体现为方法对方法的调用关系上：若方法m调用了方法f，则有从m出发到f的有向边，并且方法m依赖于f，即m∈IMS(f)。

定义6：方法依赖图是一个三元组：

G_dep=<V,D,E>(<Vertex,Dependency,Edge>)

其中，V代表图中顶点的集合，其成员称为节点或顶点，在方法依赖图中顶点集合即方法集合；关联映射D：

称为边与顶点的关联映射，这里(V,V)称为集合V的偶对集，其成员偶对出现，形如(u,v)，u和v是顶点，但它们未必不同，D(e)＝(u,v)时称边e关联顶点u、v，边e是一条有向边，即边e的起点为u，终点为v；E是所有边的集合。

由依赖关系定义可知，在方法依赖图中，依赖关系具有如下性质：

（1）自反性：依赖图中任何一个顶点都依赖于其自身，即

总是成立，其中D是方法依赖图中的关联映射。

在方法依赖图中，方法发生变更必然会影响到方法本身，故自反性显然成立，如图10中方法C自身递归调用，递归调用是方法依赖关系中自反特性的一个特例。由于自反性总是存在于方法依赖图的各个顶点中，自反性除了保持语义完整性的说明意义外，几乎没有其它任何意义，至少对代码变更影响分析没有什么实际的意义，因此，不单独进行分析。

（2）传递性：若方法a依赖于方法b，而且方法b依赖于方法c，那么方法a依赖于方法c，即

根据方法依赖传递特性，可以将方法之间的依赖关系分为直接依赖和间接依赖。方法之间的直接依赖表现为方法调用方法，直接依赖也称为显性依赖；而通过传递导致的变更影响的依赖称为间接依赖，两个间接依赖方法中间至少通过一个以上的方法传递依赖关系，间接依赖也称为隐性依赖。不难看出，方法依赖图中依赖关系的传递性正是导致变更产生影响的根本原因。

（3）有向性：若方法a依赖于方法b，该声明仅定义了一种单向依赖关系，并不保证方法b依赖于方法a，即

不一定成立。

步骤32：方法变更影响传递图构建

方法变更影响传递图G_tran也可以表示为三元组：G_tran=<V,D,E>，V代表图中的方法节点集合，D是关联映射，E是所有变更影响传递边集合。

当一个方法发生变更时，由方法依赖关系性质可知，变更影响将会传递到所有直接或间接依赖于它的方法中。在方法依赖关系模型图中，依赖关系D(Dependecy)是一组二元关系，如果方法methoda依赖于方法methodb，有methoda D methodb，当methodb发生变更时，由于methoda依赖于methodb，所以methoda也应会发生相应变更。

如图11所示，是本发明中依赖关系方向和变更传递方向示意图。变更传递方向正好与依赖关系方向相反。

如图12所示，是本发明中方法依赖图和方法变更传递图。由上述分析可知，将方法依赖图中边的方向反向变换后的图即为方法变更影响传递图。显然变更传递关系同样具有自反性、传递性和有向性。方法依赖图中的逆邻接表即为方法变更影响传递图的邻接表，反之同样成立。

步骤33：方法变更影响传递和属性变更影响传递

1.方法变更影响传递

为了便于表达，引入表2所示的符号。

表2符号列表

由表可知，方法变更有三类，根据这三类变更特性，给出各自在方法变更影响传递图中的变更影响传递规则。

（1）增加方法

规则1（新增方法和原有方法无调用关系）：如果方法newmethod和其它方法之间不存在依赖关系，则有：

受到影响的方法集合IMS(newmethod)＝{newmethod}

方法新增的依赖集合NMDS(newmethod)＝{newmethod}

方法变更影响传递图G_tran的顶点集合V＝{newmethod}∪V。

新增方法所带来的变更影响不会传递到其它方法中，其影响仅限于该方法本身，故变更影响传递到此结束。

规则2（新增方法被原有方法调用）：如果新增方法被其它原有方法调用，那么其它方法将对新增的方法产生依赖。如果方法newmethod是一个新增被调用方法，则有：

受到影响的方法集合

IMS(newmethod)={callm|callm＜newmethod∧callm∈V}∪{newmethod}

方法新增的依赖集合NMDS(newmethod)＝{newmethod}

方法变更影响传递图G_tran的边集合

E=E∪{(newmethod,callm)|callm＜newmethod∧callm∈V}

方法变更影响传递图G_tran的顶点集合V＝{newmethod}∪V。

规则3（新增方法调用了原有方法）：如果新增方法调用了已存在的方法，那么新增的方法对其所调用的方法将产生依赖。如果方法newmethod是一个新增的调用其它方法的方法，则有：

受到影响的方法集合IMS(newmethod)＝{newmethod}

方法新增的依赖集合

NMDS(newmethod)={calledm|newmethod＜calledm∧calledm∈V}∪{newmethod}

方法变更影响传递图G_tran的边集合

E=E∪{(calledm,newmethod)|newmethod＜calledm∧calledm∈V}

方法变更影响传递图G_tran的顶点集合V＝{newmethod}∪V。

（2）删除方法

规则4（方法的删除）：如果方法dmethod是一个被删除的方法，则有：

受到影响的方法集合IMS(dmethod)={callm|callm＜dmethod∧callm∈V}

被删除方法的依赖集合

方法变更影响传递图G_tran的边集合

E=E-({(dmethod,v)|v＜dmethod∨v∈V}∪{(c,dmethod)|c＜dmethod∨c∈V})

方法变更影响传递图G_tran的顶点集合V＝V-{dmethod}。

（3）修改方法

修改方法是指对方法所包含代码的修改，由于修改方法代码时，可能增加或者删除该方法的调用方法，也有可能修改除调用方法外的其它代码，如修改方法中循环控制条件代码，故需要根据不同修改情况，制定不同变更处理规则。

规则5（修改的方法中新增加了调用方法）：当方法mmethod新增加了调用方法时，则有：

受到影响的方法集合

IMS(mmethod)={callm|callm＜mmethod∧callm∈V}

方法新增的依赖集合

NMDS(mmethod)={calledm|mmethod＜calledm∧calledm∈V}

方法变更影响传递图G_tran的边集合

E=E∪{(calledm,mmethod)|mmethod＜calledm∧calledm∈NMDS(mmethod)}规则6（修改的方法对其调用方法删除）：当方法mmethod删除对其调用方法时，Vd表示被删除的调用方法集合，则有：

受到影响的方法集合IMS(mmethod)={callm|callm＜mmethod∧callm∈V}

方法减少的依赖集合

DMDS(mmethod)={calledm|(mmethod＜calledm∧calledm∈Vd}

方法变更影响传递图G_tran的边集合

E=E-{(dm,mmethod)|mmethod＜dm∧dm∈DMDS(dm)}。

2.属性变更影响传递

除了方法对方法的调用可以使方法之间产生语义连接外，方法还对属性产生调用。将属性独立于方法变更之外进行变更影响分析，是因为在对程序代码划分时，各种模块之间不完全是包含与被包含之间的关系。从图7中可以看出，基于方法划分的模块并不完全包含基于程序代码划分的模块，所以当属性发生变更时，包含这些变更属性的语句可能不属于任何方法，如代码中的全局变量属性值变更、类属性值变更，这就需要对这些属性变更影响进行单独的分析。

属性变更对属性影响和方法变更对方法影响分析类似，也是首先建立属性之间的变更影响传递图，然后通过属性变更传递图搜索受变更影响的属性集合IMF(v)（v是发生变更的属性）。由于属性的变更只通过属性之间赋值产生依赖，属性依赖关系相对简单。

属性变更对方法产生的影响分析步骤是：首先找出调用了IMF集合中属性的方法，并标识这些方法，然后分析这些方法的变更影响，并标识受变更影响的方法，最后被标识的方法就是受属性变更影响的方法。属性变更影响传递按照规则7进行处理。

规则7（全局变量属性或类属性成员变更）：如果属性v是全局变量属性或类属性成员，当v发生变更时，则有：

受到影响的方法的集合

由于属性变更并不对方法变更影响传递图产生影响，故方法变更影响传递图不发生改变。

步骤34：代码变更影响分析。

根据上述分析，代码变更影响分析主要包括两个算法：MethodImpactSet和FieldImpactSet，分别从方法变更和属性变更两个方面分析受变更影响的方法集合，程序中受变更影响的方法集合是所有受方法变更影响的方法集合和受属性变更影响的方法集合之和。

1.MethodImpactSet算法（方法变更影响传递算法）

首先分析原子变更方法对方法变更传递图结构的影响，然后对方法变更影响传递图结构进行修改，最后以变更的方法为源节点在变更影响传递图中搜索出从该节点出发的可达节点集合，这个集合便是受该方法变更影响的方法集合，该算法结束后返回受变更影响的方法集合IMS。具体算法如算法6所示。

算法6：方法变更影响传递算法

输入：发生变更的方法（method）

输出：受方法变更影响的方法集合（IMS）

步骤a：获取方法各种集合；通过对发生变更method方法分析，分别获取调用方法的集合CMS(method)、方法依赖集MDS(method)、method方法新增加的方法组成的新增依赖集合NMDS(method)和在方法中被删除了的方法组成的方法依赖集DMDS(method)；

步骤b：新增方法；当新增一个方法时，根据变更影响传递规则中新增加方法的相应规则修改方法传递图，如果新增加的方法是一个孤立的方法，将该方法加入IMS(method)，算法结束；

步骤c：删除方法；当删除一个方法时，根据传递规则4修改方法传递图，并将method方法节点从图中删除；

步骤d：修改方法；当修改只涉及方法本身时，根据传递规则5和6修改方法传递图；

步骤e：发生变更的方法在变更传递图中传递；

（1）设置受变更影响的方法队列Im_list，first和last分别是队列的首尾指针，将发生变更的方法method加入到队列Im_list中，并对已经加入队列的method做入队标记；

（2）如果队列不为空：队列Im_list中的第一个方法v出队，并将该方法加入到受变更影响的集合IMS(method)中，首指针first向右移动一位，指向队列中下一个方法，搜寻调用了方法v的方法集合MDS(v)；若队列为空，则转到步骤f；

（3）依次从方法v的依赖集合MDS(v)中取出方法p直到集合为空：如果方法p还未加入队列Im_list中，则将方法p加入到队列Im_list尾部，并将队列尾指针last向右移动一位，指向最后加入队列的方法p，同时标记方法p；如果集合MDS(v)为空，则执行（4）；

（4）如果队列Im_list还有未出队的方法，则返回（2）；

步骤f：返回受变更影响的集合IMS(method)。

2.FieldImpactSet算法（属性变更影响传递算法）

该算法主要首先将变更的属性作为变更源，在属性变更传递图中寻找出受原子属性变更影响的属性集合IFS，然后分析受到IFS中属性变更直接影响的方法集合FMS，最后以FMS集合中的方法作为原子变更，在方法变更影响传递图中求出所有受到FMS中方法变更影响的方法集合IMS。具体算法如算法7所示。

算法7：属性变更影响传递算法

输入：发生变更的属性（field）

输出：受属性变更影响的方法集合（IMS）

步骤a：受变更影响的属性集合；将发生变更的属性field作为变更源，通过调用Get_ifs(field)方法获取在属性变更传递图中受变更影响的属性集合IFS(field)。

步骤b：受属性变更直接影响方法集合；

（1）依次从IFS(field)中取出受变更影响的属性f，若方法m使用了属性f，将方法m加入到FMS(field)中；

（2）若IFS(field)中还有未被移除的方法，返回（1），否则，进入步骤c。

步骤c：获取受变更影响的方法集合；

（1）依次从FMS(field)取出受属性变更影响的方法m，以方法m为变更源输入，调用变更传递方法MethodImpactSet(m)，从方法变更影响传递图中获取受方法m变更影响的方法集合IMS(m)；

（2）将受方法m变更影响的方法集合IMS(m)加入到受属性field变更影响的集合IMS(field)中；

（3）若集合FMS(field)中还有受变更影响的方法，则返回（1）；否则进入步骤d。当删除一个方法时，根据传递规则4修改方法传递图，并将method方法节点从图中删除；

步骤d：返回受属性变更影响的集合IMS(field)，结束。

步骤4中，控件与代码映射主要建立源代码与控件之间的映射关系，从而将代码变更转化为功能变更。控件与代码的映射关系由本发明中的算法4给出，其工作流程如图5所示。在此基础上，利用步骤3中的代码变更影响分析结果，根据其中受到影响的方法集合IMS(method)和属性集合 IMS(field)，找出与其对应的控件，并在软件功能比较结果图中予以标识。

至此，因软件控件变更和代码变更所引起的软件功能变更均在软件功能比较结果图中予以标识，为后续软件功能变更影响分析打下了基础。步骤5中，功能变更影响域分析主要根据软件功能变更标识结果，找出经过变更点的所有功能路径，这些路径就是受功能变更影响的部分，也是回归测试时必须覆盖的最小功能集。

经过变更点的所有功能路径可以使用算法8产生。

算法8：Path_Gen(G,NS,ES)

输入G：软件功能图

输入NS：G中新增功能路径节点集合

输入ES：G中新增功能路径边集合

输出PS：G中受变更影响的功能路径集合

1.PS<-{}；

2.以深度优先方法遍历G

3.将当前的节点和边按顺序压入栈Stack

4.如果当前节点n属于NS，或当前边e属于ES，则令PS<-PS+{Stack中的节点和边构成的路径}

5.将回溯时访问过的当前节点与当前边弹出栈Stack

6.Return PS

算法8的工作过程如下：第1步将返回值PS初始化为空集合；第2步开始至第5步以深度优先方法遍历G；第3步将当前节点和边压入一个栈Stack；第4步判断：如果当前节点或当前边属于NS或ES，则这是新的节点或边，于是将当前栈中的路径存入PS；第5步是在回溯时将不需要的节点和边弹出栈；第6步将结果PS返回。

经过算法8后，可以得到需要测试的新的功能路径集合PS。根据该集合可以很方便地设计出新的测试用例。

下面以“学生管理系统”为例，对本发明技术方案予以说明。

1.软件功能图

如图13所示，是本发明中变更前后的学生管理系统界面图。在图13中，左面的图是V1.0版软件界面，右面的图是V2.0版软件界面。

如图14所示，是本发明中V1.0版软件功能图，如图15所示，是本发明中V2.0版软件功能图。

2.功能变更标识

通过比较图14和图15，可以找出V1.0版和V2.0版软件功能之间的差异，即V2.0版软件中增加了与“课程管理”相关的三个功能：课程增加、课程修改、课程删除（图15中右边斜体字部分）

3.代码变更影响分析

（1）代码变更标识

两个版本软件部分源代码如下：

学生管理系统1.0版

Figure 2012102868486100002DEST_PATH_IMAGE002

学生管理系统2.0版

Figure 2012102868486100002DEST_PATH_IMAGE003

Figure 2012102868486100002DEST_PATH_IMAGE004

Figure 2012102868486100002DEST_PATH_IMAGE005

通过比较V1.0和V2.0版本软件，可以找出发生变更的代码（在源代码中用红色标记）。

（2）代码变更影响分析

如图16所示，本发明中方法变更及函数调用关系图。针对上述代码变更，图16中红色标记的是发生变更的函数，通过该函数调用关系图，可以找出受变更影响的函数。在本例中，由于根路径中的函数StuMain.javaactionPerformed()发生了变更，因此，所有的函数均受到影响。

4、控件与代码映射

针对上述发生变更的函数，其对应的界面控件如表3所示。

表3变更函数与界面控件映射关系

从表3中可以清楚看出受代码变更影响的界面控件。结合功能变更分析结果，可以得出本次软件变更对软件功能产生的影响，这些受影响的控件是回归测试时必须覆盖的控件。