CN107193739B - 一种黑盒回归测试方法 - Google Patents

Abstract

本发明涉及软件测试技术领域，特别是一种黑盒回归测试方法，包括以下步骤，步骤S101：源代码解析；步骤S102：界面元素分析；步骤S103：交互关系分析；步骤S104：测试执行过程跟踪；步骤S105：用例覆盖分析；步骤S106：测试用例约简；步骤S107：功能差异检测；步骤S108：功能变更影响分析；步骤S109：回归测试用例筛选；步骤S110：影响域覆盖分析。本发明能够有效避免回归测试的重复、冗余和遗漏，大大提高回归测试的充分性、有效性和测试效率。

Description

一种黑盒回归测试方法

技术领域

本发明涉及软件测试技术领域，特别是一种黑盒回归测试方法。

背景技术

软件功能是软件价值的重要体现，软件功能变更是软件开发过程中一项难以避免且经常发生的行为，对于每一次功能变更，都需要通过回归测试验证其正确性。特别是对于GUI类应用软件，这类软件采用人机交互方式，为用户提供了一种快捷、简便的软件操作方式，GUI 类软件在给用户带来直观、简便、快捷的同时，其本身所具有的输入 /输出图形化、事件驱动、事件触发随机性、多任务以及消息传递等特性，使软件功能测试以及回归测试工作面临许多新的挑战。

挑战1：如何获取软件所具有的功能

GUI类软件包含大量的界面，每一个界面中又包含很多菜单和按钮，由此构成不同的软件功能。对于GUI类软件而言，每一个功能路径对应着一个软件功能，在测试过程中，至少要覆盖这些功能路径。然而，由于软件功能路径繁多，仅凭手工方式难以确定被测软件所具有的全部功能，因此也就无法对软件功能进行全面、有效的测试。

挑战2：软件功能变更及其影响域难以确定

目前，大多数GUI类软件是采用快速原型方法开发的，软件版本变更频繁，在软件生存周期内，需要进行多次回归测试，由于GUI类软件功能复杂，难以用人工方式识别软件功能变更以及功能变更对软件其他功能带来的影响，测试人员只能凭借经验对软件进行回归测试，这样，难免造成回归测试的重复、冗余和遗漏，影响回归测试的质量和效率。

挑战3：如何获知测试覆盖情况

GUI类软件采用事件驱动方式执行，用户通过与控件的交互来触发相应的事件进而与内部代码及业务逻辑发生交互，因此，传统测试中的诸如分支覆盖、语句覆盖等经典的覆盖准则很难适用于GUI类软件测试中，无法有效指导测试。另一方面，GUI类软件功能是通过界面体现的，用户通过点击界面元素实现软件功能，因此，如何通过功能覆盖来衡量测试充分性是测试人员面临的另一大难题。

挑战4：如何约简测试用例

在软件测试过程中，测试人员需要设计大量的测试用例，从功能覆盖的角度而言，这些测试用例难免存在重复和冗余，即不同测试用例所覆盖的功能相同，对于这些测试用例，需要进行约简，以减少测试用例执行和维护成本。

挑战5：如何筛选回归测试用例

在前一轮的测试过程中，测试人员设计了大量的测试用例，在回归测试阶段，测试人员需要根据软件功能变更及其影响情况，从已有测试用例集中筛选出回归测试用例，由于缺乏有效的方法，测试人员难以从大量测试用例中筛选出符合要求的回归测试用例。

近年来，软件的功能越来越丰富，复杂度也越来越高。随之，软件***功能测试的测试用例数成倍增长，执行一次全集回归测试的时间大幅度增加，已经成为影响产品快速发布的重要因素之一。尤其在升级维护项目中，需求一般来源于客户，具有需求变化快、时间要求紧、绝大部分代码属于继承等特点，原有的穷举所有测试用例的测试策略存在的周期长、效率低的问题愈加凸显。凭经验选择部分子集进行回归测试，虽然可以大幅度的减少测试时间，但是测试质量无法保证，存在很大的漏测、重复测风险。

回归测试优化技术的重点是如何选择有效的回归测试集来保证测试有效性并提高测试效率。如何平衡成本与风险，业内进行了众多优化技术研究，大部分都集中在对每一个测试需求对应的多个测试用例约简技术上，例如粒子群优化算法、启发式算法、遗传算法、基于数据依赖及控制依赖的用例选择方法等，对测试范围优化技术鲜有涉及。

但上述测试方法及装置存在两点问题：一是，对***测试者的能力要求很高，或者需要掌握用户的使用场景，或者需要对被测软件的设计非常了解，清楚了解每个测试用例在代码中的执行路径，这是大多数***测试人员都无法掌握的。二是，对测试环境和测试资源的要求较高，尤其是嵌入式***，测试资源紧张、测试手段匮乏，很难实施。

中国发明专利申请CN 106354631 A公开了一种快速软件***回归测试的方法，包括：根据代码差异以及使用关系，获得全部变化影响的用户接口全集，确定***回归测试黑盒测试用例范围；根据变化单元的复杂度及用户接口使用变化单元的情况，计算用户接口的优先级，确定黑盒测试用例的执行顺序；依据上述测试范围和优先级顺序实施测试。

目前，在回归测试领域，有代表性的黑盒回归测试工具是Mercury Interactive公司的WinRunner和IBM HP Quick Test Professional (QTP)。这些工具采用捕获/回放技术，通过捕获测试人员的操作，生成测试脚本。在回归测试时，通过回放测试脚本程序，对修改后的软件进行测试。这种方法采用的是重新运行所有测试用例的策略，不能针对软件的修改情况选择回归测试用例，难免执行不必要的测试用例，并且，在回放测试脚本时，由于软件版本的变更，经常导致脚本程序中断，测试人员需要花费大量的时间调试测试脚本，从而，大大降低了测试效率，因此，尽管这些工具有很独特的理念，但实际使用效果不佳。此外，这类工具不具备功能变更标识、功能变更影响分析、测试用例优化以及回归测试用例优选等功能，不能满足回归测试需要。

另外一个在回归测试领域研究较多的是基于代码的回归测试，这类方法主要是通过分析代码，找出受代码改动影响的代码部分，这部分代码是回归测试时需要重新测试的代码。这类方法只适合于白盒测试，由于软件代码与软件功能不存在直接的一一对应关系，因此，这类方法不适合于对软件进行功能回归即黑盒回归测试。

发明内容

本发明需要解决的技术问题是提供一种快速、准确、高效进行黑盒回归测试的方法和***。

为解决上述技术问题，本发明的一种黑盒回归测试方法，包括以下步骤，

步骤S101：源代码解析，通过类型解析和对源代码的词法、语法分析得到代码的语法树和类型***；

步骤S102：界面元素分析，扫描源代码抽象语法树，以窗口类定义为基本单元，分析被测软件的界面构成，形成界面元素树模型；

步骤S103：交互关系分析，扫描源代码抽象语法树，并依据所使用的类型***对调用逻辑、事件流进行分析，形成被测软件界面元素调用关系模型；

步骤S104：测试执行过程跟踪，捕获用例执行过程中所输入的数据以及点击的界面元素，形成用例执行路径数据；

步骤S105：用例覆盖分析，将用例执行数据与界面模型进行匹配，得到每个用例执行后被覆盖的界面元素和路径，并以图形方式显示于界面上；

步骤S106：测试用例约简，分析一组用例所覆盖的界面元素和路径，采用基于调用路径和基于界面元素覆盖数量两种算法剔除其中冗余的测试用例，形成测试用例集；

步骤S107：功能差异检测，通过对两个软件版本的静态分析结果进行分析，找出两个版本间的UI差异和UI变更位置；

步骤S108：功能变更影响分析，依据找到的变更点，采用回溯迭代算法，在界面元素静态结构模型上查找依赖项，形成从变更点出发的变更影响范围即影响域；

步骤S109：回归测试用例筛选：以变更影响域为目标函数，采用覆盖的变更功能优先、关键度优先以及路径长度优先策略，从约简后的测试用例集中查找出能够覆盖变更影响域的最少个数测试用例；

步骤S110：影响域覆盖分析，依据筛选出的回归测试用例所能够覆盖的变更影响域，找出尚未被覆盖的变更影响域。

进一步的，所述步骤S101源代码解析中如果代码为C#语言，将代码的逻辑结构与代码所述的类型***相关联，所述类型***中包含被测软件自定义的类型、引用类库的类型以及框架自身的类型，依据其关联关系识别出语法树的语义信息。

进一步的，所述步骤S104测试执行过程跟踪具体还包括以下步骤，

步骤S141：执行窗口调用树图构建；

步骤S142：界面控件捕获。

更进一步的，所述步骤S142中的界面控件包括按钮、编辑框、菜单项、ListView、标签、工具栏按钮、Tab选项卡、列表框和ComboBox。

进一步的，所述步骤S106测试用例约简具体包括以下步骤，

步骤S161：关键用例处理；

步骤S162：用例筛选；

步骤S163：结果提交。

进一步的，所述步骤S108功能变更影响分析包括基于功能图的变更影响分析和基于调用关系的变更影响分析。

进一步的，所述步骤S109测试用例筛选采用覆盖的变更功能优先、关键度优先、路径长度优先三种原则，从约简后的测试用例集中，挑选出个数最少的测试用例。

采用上述后方法后，本发明有效解决回归测试中的如下问题：

1、软件功能自动获取；

2、软件功能变更标识及变更影响分析；

3、测试覆盖获取；

4、测试用例约简；

5、回归测试用例筛选。

本发明能够有效避免回归测试的重复、冗余和遗漏，大大提高回归测试的充分性、有效性和测试效率。

附图说明

下面结合附图和具体实施方式对本发明作进一步详细的说明。

图1为本发明黑盒回归测试功能结构示意图。

图2为本发明源代码解析工作流程图。

图3为本发明匹配关系示意图。

图4为本发明依赖关系模型图。

图5为本发明按钮种类示意图。

图6为本发明按钮抽象操作流程图。

图7为本发明查找窗口示意图。

图8为本发明文本框抽象操作流程图。

图9为本发明菜单窗口示意图。

图10为本发明菜单抽象操作流程图。

图11为本发明测试用例优化处理流程图。

图12为本发明功能结构变更影响示意图。

图13为本发明调用关系变更影响示意图。

图14为本发明回归测试用例优选处理流程。

图15为本发明学生管理***程序主界面示意图。

图16为本发明界面元素及交互关系分析结果示意图。

图17为本发明“登录***”测试执行跟踪示意图。

图18为本发明测试用例覆盖路径示意图。

图19为本发明测试用例优化结果示意图。

图20为本发明功能差异检测结果示意图。

图21为本发明变更影响分析结果示意图。

具体实施方式

如图1所示，本发明的一种黑盒回归测试方法，包括以下步骤，

步骤S101：源代码解析，通过类型解析和对源代码的词法、语法分析得到代码的语法树和类型***。如图2所示，当代码为C#语言时，由于C#语言是面向对象语言，要对代码进行进一步分析，需要将代码的逻辑结构(AST)与代码所处的类型***相关联，该类型***中包含被测软件自定义的类型、引用类库的类型以及框架自身的类型，依据其关联关系识别出语法树的语义信息。本方案依据程序集依赖关系构建类型***全集，根据语法树节点所定义的元素类型，以全命名查找对应的类型***元素，建立永久关联并进行存储。通过解析方法查询两者关联关系，产生源代码抽象语法树、类型***范围及关联数据库。

步骤S102：界面元素分析，扫描源代码抽象语法树，以窗口类定义为基本单元，分析被测软件的界面构成，形成界面元素树模型。在建立代码逻辑结构和类型***基础上，通过遍历语法树以树结构模板识别方法查找界面元素定义及属性设置。最终形成全集数据模型。

依据AST所表示的语法逻辑和类型***，在代表UI元素的类定义中分析界面元素组织关系，***定义模式库表示要在语法树上识别的特征模板，通过匹配引擎在迭代语法树的过程中抽取界面元素的定义、属性设置和隶属关系信息，形成界面元素集合并建立隶属关系。

模式库中的一条模式规则由一棵节点有序的树形结构表示，依据有序树匹配理论在抽象语法树上进行匹配，规则树是由规则节点与特定规则关联形成的树形结构，规则节点定义语法树节点的属性匹配规则，用于对语法树节点的匹配。如图3所示，节点之间的关系分为三种情形：1.存在于子层：表示AST片段中以某个子节点为根的子树完全与规则匹配；2.存在于左子树：表示AST片段某节点下第一个节点子树中存在与规则匹配的节点，3.存在于子树：表示AST片段某节点下全部子树中存在与规则匹配的节点。

模式库中的一条模式规则由一棵节点有序的树形结构表示，依据有序树匹配理论在抽象语法树上进行匹配，规则树是由规则节点与特定规则关联形成的树形结构，规则节点定义语法树节点的属性匹配规则，用于对语法树节点的匹配。节点之间的关系分为三种情形：1. 存在于子层：表示AST片段中以某个子节点为根的子树完全与规则匹配；2.存在于左子树：表示AST片段某节点下第一个节点子树中存在与规则匹配的节点，3.存在于子树：表示AST片段某节点下全部子树中存在与规则匹配的节点。

步骤S103：交互关系分析，扫描源代码抽象语法树，并依据所使用的类型***对调用逻辑、事件流进行分析，形成被测软件界面元素调用关系模型。在通过语法树迭代遍历语法树获得界面元素定义的同时，识别界面事件的定义-引用关系，在事件和处理函数之间建立连接，分析类型、方法间的调用关系，通过控制流分析方法在界面元素间建立引用关系，形成依赖关系模型。利用有向图建立窗口、窗口元素、元素间交互关系，窗口及元素用有向图中的节点表示，交互及关联关系用有向边来表示，其类图用图4表示。

步骤S104：测试执行过程跟踪，捕获用例执行过程中所输入的数据以及点击的界面元素，形成用例执行路径数据。测试执行跟踪主要用于捕获测试人员所做的操作，例如，点击的菜单、按钮、键盘输入的数据等。通过捕获的这些操作信息，测试人员可以准确掌握测试用例对软件界面元素的覆盖情况。具体包括以下步骤，

步骤S141：执行窗口调用树图构建；为了实现上述目的，本专利中综合采用钩子和API函数，在测试人员执行样本测试用例过程中构建执行窗口调用树图，构建算法如下，执行结束后，W是执行窗口调用树图的结点集合，E是执行窗口调用树图的边的集合。

步骤S142：界面控件捕获，界面控件是软件界面的组成要素，本专利通过对常用界面元素特性分析，给出了以下几种常见控件的抽象操作方法。

1)按钮的抽象操作；

2)编辑框的抽象操作；

3)菜单项的抽象操作；

4)ListView抽象操作；

5)标签的抽象操作；

6)工具栏按钮的抽象操作；

7)Tab选项卡的抽象操作；

8)列表框的抽象操作；

9)ComboBox的抽象操作；

除了这几种常用控件外，工具还对对话框的弹出等GUI软件的状态变化进行抽象操作，下面对部分重要控件的抽象操作进行详细介绍。

1)按钮点击的抽象操作

当判断截获到一条消息并且控件的类名为“BUTTON”时，有可能是一个标准的按钮控件，还有可能是CheckBox或RadioButton，三种控件的区别如图5所示。

对于CheckBox或RadioButton控件，用户可以选择或不选择，将它的值在真与假之间改变。CheckBox和RadioButton控件有一个名为Checked的属性，需要检查Checked属性的值，才能对按钮的状态进行具体描述。

RadioButton和CheckBox有一些不同点，第一、RadioButton控件以组的形式出现，同一组内只能有一个且必须有一个选项选中，选中即控件的Checked属性为真；而CheckBox控件可以以组的形式出现，也可以单独出现，可以多个选项同时选中或均不选中；第二、RadioButton只要被单击，所点击选项的Checked属性就变成真，即使RadioButton的属性已经为真了，单击后它的属性依然为真，而 CheckBox控件属性值在控件被单击后，会从假变为真，或从真变为假。针对按钮控件，其抽象操作流程如图6所示。

判断按钮的类型的处理具体描述为：

利用GetWindowLong(hWnd,nIndex)函数判断按钮的具体类型，函数有两个参数：hWnd：窗口或控件的句柄；nIndex：指定要检索的基于0的偏移量，可以设置为GWL_EXSTYLE代表获得扩展窗口风格、 GWL_STYLE代表获得窗口风格、GWL_HWNDPARENT代表如果父窗口存在，获得父窗口句柄。为了判断具体的控件类型，使用的是GWL_STYLE窗口风格标识，再将获取值同0x0000ffff进行与操作，就可以判定所操作控件是BS_AUTOCHECKBUTTON或BS_AUTORADIOBUTTON，然后再根据控件具体类型进行抽象操作。

2)文本框的抽象操作

由于对编辑框的操作后，收到的消息只是文本框的内容，例如图 7所示记事本程序“查找”窗口，编辑框输入内容“测试”后，如果只是输出记录“在文本框中输入内容‘测试’”，因为没有获取编辑框的标签，无法完整表达所操作的含义，这就需要对编辑框进行一个获取标签信息的特殊处理。对文本框控件的抽象操作处理流程如图8 所示。

如何获取文本框的标签具体描述为：

1、编辑框编辑结束时查找文本框的标签坐标时，首先需要利用 Win32API函数GetWindowRect(int hWnd,ref rt)找到文本框的左侧和底侧的坐标值，其中hWnd代表控件的句柄，rt代表一个结构，结构由四个元素组成，分别是控件的上侧、下侧、左侧、右侧的坐标值。其功能是将句柄为hWnd的控件底侧、左侧、上侧、右侧的坐标拷贝到rt结构中，通过取rt结构的参数值即可。

2、根据经验文本框的标签位置一般在其左侧或者上侧，首先从控件的左侧开始查询，取出所操作文本框控件的左侧和底侧坐标值，按照x坐标递减的顺序，寻找控件类名是“LABEL”的控件，设置递减的长度，如果没有，再取出所操作文本框控件的上侧和左侧坐标值，再按照y坐标值递减的顺序进行查找，同样需要设置递减的长度，直到找到“LABEL”控件，将其标签属性标识文本框控件，对文本框进行抽象操作。

3)菜单项的选择抽象操作

菜单的结构是层次型构造，如图9所示，最上一层“文件”、“编辑”、“格式”的菜单被称为主菜单项，主菜单项在前端的接口中是可见的，下一层的菜单只有单击主菜单之后才会显示，其中“新建”、“打开”等菜单项，都被称为子菜单。子菜单也可以有自己的子菜单，每一个菜单的条目都会有唯一的菜单句柄，用来唯一标识所点击的菜单条目。对菜单控件的抽象操作处理流程如图10所示。

对菜单项抽象操作具体描述为：

1、当点击主菜单时，通过GetMenu(int hWin)函数返回菜单句柄，其中hWnd代表窗口的句柄；

2、再利用MenuItemFromPoint(int hWin,int hMenu,POINT pt) 函数得到所点击主菜单选项在主菜单中的位置索引，其中hWin代表窗口的句柄，hMenu代表菜单的句柄，pt代表当前点击的坐标；

3、调用GetMenuString(int hMenu,int topMenuIndex,int topMenuText,128,MF_BYPOSITION)函数获取主菜单的文本，其中 hPreMenu代表菜单的句柄，topMenuIndex代表点击主菜单项的索引， topMenuText代表得到菜单文本的字符串，MF_BYPOSITION代表获取类型标识；

4、此时子菜单打开，如果用户继续点击子菜单项，调用 GetSubMenu(inthPreMenu,int topMenuIndex)函数获取子菜单项句柄，其中hPreMenu代表菜单的句柄，topMenuIndex代表点击主菜单的索引；MenuItemFromPoint(int hWin,int hSubMenu,Point pt) 函数获取子菜单索引，其中hWin代表主菜单的句柄，hSubMenu代表子菜单的句柄，pt代表鼠标点击的坐标；

5、调用GetMenuString(int hSubMenu,int indexSub,int subMenuText,128,MF_BYCOMMAND)函数获取子菜单文本，其中 hSubMenu代表子菜单的句柄，indexSub代表选择的子菜单项的索引， subMenuText代表的得到子菜单项文本的字符串，进而结合主菜单对菜单项操作进行抽象处理。

步骤S105：用例覆盖分析，将用例执行数据与界面模型进行匹配，得到每个用例执行后被覆盖的界面元素和路径，并以图形方式显示于界面上。

步骤S106：测试用例约简，分析一组用例所覆盖的界面元素和路径，采用基于调用路径和基于界面元素覆盖数量两种算法剔除其中冗余的测试用例，形成测试用例集。

由于测试用例设计的局限性，从功能覆盖的角度而言，难免存在重复或冗余的测试用例，这类测试用例对测试覆盖是没有贡献的，需要将其剔除，以减少回归测试执行和回归测试用例维护工作量。

本发明中提出了基于调用路径和覆盖路径两种测试用例优化策略，采用基于程序路径和功能路径的启发式贪心算法，对测试用例进行约简，有效剔除了重复和冗余的测试用例，大大减少了测试用例的维护和执行费用。

依据测试用例关键度和覆盖UI元素及调用路径的对应关系来完成测试用例集的约简工作，通过及时判断测试用例对UI元素节点的覆盖情况，***在得到每个测试用例所覆盖的界面元素和执行路径后，采用基于调用路径和基于界面元素覆盖数量两种算法剔除其中冗余和重复的测试用例，从而在保留关键测试用例基础上尽可能地收缩测试用例集，完成用例优化。优化分为三个阶段进行，即关键测试用例处理及包含冗余检测阶段、测试用例筛选阶段和测试用例排序阶段，如图11所示。具体包括以下步骤，

步骤S161：关键用例处理；迭代所有的必要测试用例，对所有被必要测试用例覆盖的UI元素节点和调用路径进行标注；迭代所有测试用例，检测测试用例覆盖路径间的包含关系，对包含在关键用例中的冗余用例进行标注。而后更新剩余测试用例集和未被覆盖的UI 节点和调用边形成覆盖需求集。

步骤S162：用例筛选；用例筛选。在现有覆盖需求集和用例集基础上，对所有剩余用例依据调用路径和基于界面元素覆盖数量两种算法进行关键度排序。在调用路径覆盖优先原则下，依据用例覆盖待测有调用关系向边数量进行由高到底排序，在界面元素覆盖数量优先原则下，依据用例覆盖待测UI节点的数量进行由高到底排序，选取关键度最高的用例作为候选用例，更新测试用例集和剩余未被覆盖的 UI节点和调用边，重复上述步骤，直到候选测试用例集为空或所有剩余测试用例关键度为0为止。

步骤S163：结果提交，对所有关键测试用例也依据两种关键度评价方法执行贪心算法进行排序，合并已选测试用例依次排序，顺序设置执行优先级，输出被优化后的测试用例集，综合用例集覆盖范围，提取未能覆盖的功能模型范围。

步骤S107：功能差异检测，通过对两个软件版本的静态分析结果进行分析，找出两个版本间的UI差异和UI变更位置。

通过在UI结构差异和UI交互差异两个方面对新旧两个版本软件进行检测，在全局功能交互模型中标识变化点。

以有向图表示的功能交互模型中抽取界面元素节点。按照包含关系有向边抽取UI元素和其间的连接关系，以树形结构表示***UI构成，建模***功能结构模型；按照调用关系有向边抽取交互模型子图，用来表示UI元素间的功能交互模型。我们通过编辑距离方法比较两种结构之间的差异，通过计算将原版本结构模型映射为新版本结构模型的变更操作序列，揭示两个版本间的功能结构变更和交互变更，并在新旧版本中进行标注形成变更域。

***使用关联关系矩阵存储***UI元素功能结构和交互关系有向图，定义新增、删除、变更三种基本操作，通过计算将原版本功能结构、交互关系有向图转换为新版本有向图的最小代价，将相应的编辑操作映射到新旧版本的结构和交互模型上，标注变更。

***首先以静态分析得到的UI元素节点的全限定名来进行节点对齐和属性比对，生成对应节点间的编辑操作集合；而后对比对比两个版本间的UI元素差异，映射UI元素节点的增加、删除操作；最后对图中的有向边连接关系及其连接属性进行比对，形成连接关系间的增加、删除、修改操作，将上述操作集合并形成操作序列，依据UI 元素差异和属性差异标注功能结构变更、依据有向边差异标注交互关系变更。

步骤S108：功能变更影响分析，依据找到的变更点，采用回溯迭代算法，在界面元素静态结构模型上查找依赖项，形成从变更点出发的变更影响范围即影响域。

***综合基于功能图的变更影响分析和基于调用关系(控制流) 的变更影响分析结果，合并生成变更影响域。

1)基于功能图的变更影响分析。本***采用静态分析技术获得被测软件功能结构，在被测软件交互模型中从窗口元素出发按照UI 元素包含关系可抽取UI结构，结构中的根节点为每一个程序窗口，下级节点构成控件树，在功能结构图中，用元素间节点间的有向边表示包含关联，方向由父节点指向子节点，我们认为子节点属性的变更会影响父节点功能的完成，即，在软件功能图中UI节点属性和子树结构的变更会沿有向边的反方向传递。***首先在结构树中标注变更检测得到的功能结构变更，依据上述传播规律沿有向边上溯到根节点，沿途标注变更影响路径，形成结构变更影响域。

2)基于调用关系的变更影响分析。***在进行基于代码的静态分析时，生成函数调用关系数据结构，我们把依赖关系模型表示为一个有向图，函数作为该有向图的节点，每一个函数调用表达式作为连接两个函数节点的有向边，其方向由调用函数指向被调用函数，整个函数调用有向图描述了被测工程的函数调用关系；通过事件映射模式规则识别出界面元素及事件处理函数间的映射关系，与函数调用合成形成控制依赖有向图。静态分析时抽取了界面元素对象的定义-引用关系，通过综合界面元素定义-引用对(D-U Pair)，在函数调用中识别对界面元素对象的引用，从而在控制流节点(函数)中关联受影响的界面元素，链接形成界面元素间的引用关系，界面元素间的引用关系与控制流方向相同。我们认为界面元素节点的变更，会沿控制流双向传递，***通过函数调用有向边和事件关联有向边，由变更点出发追溯至界面元素节点，沿途标注调用关系影响域。如图12和图13所示，***最终在交互模型中合成两种方式所标注的节点和有向边形成变更影响域，标注受变更影响的所有UI元素。

步骤S109：测试用例筛选：以变更影响域为目标函数，采用覆盖的变更功能优先、关键度优先以及路径长度优先策略，从约简后的测试用例集中查找出能够覆盖变更影响域的最少个数测试用例；

步骤S110：影响域覆盖分析，依据筛选出的回归测试用例所能够覆盖的变更影响域，找出尚未被覆盖的变更影响域。

采用覆盖的变更功能优先、关键度优先、路径长度优先三种原则，从约简后的测试用例集中，挑选出个数最少的测试用例。其工作流程如图14所示。首先，对原有测试用例进行筛选，参照变更域中控制流路径，对因路径变更不能抵达变更点所在UI元素的测试用例进行标注，在候选用例集中排除该用例。而后，利用剩余用例构成候选用例集进行优选：将回归测试用例集置为为空，且其测试覆盖度为0；根据测试人员的选择，依据变更功能优先、关键度优先、路径长度优先的原则计算单个测试用例对变更影响域覆盖的贡献，据此对候选用例进行排序，选取覆盖贡献大于0的测试用例中，贡献最大的测试用例加入回归测试用例集；对变更域节点进行覆盖标注，计算总体覆盖贡献；余下用例重复进行上一步判断，直到余下用例均计算完毕为止；最终提交回归测试用例集，及变更域覆盖数据集，对未能覆盖的变更域节点和路径进行标注，提示进行新用例设计。

上述算法中依据覆盖贡献对候选用例集的排序直接影响了最终测试用例筛选的结果，相关排序指标的计算方式为：

变更功能：整个用例路径上覆盖变更影响域中未覆盖变更点的个数，用来描述单个测试用例对变更影响域覆盖的贡献；

路径关键度：使用在静态分析中的到的UI元素依赖关系有向图中UI节点的扇入数与扇出数的总和，结合测试需求来标注单个元素的关键度，整个用例的关键度是用例所覆盖变更域内尚未覆盖的变更点的关键度的总和，用来描述单个测试用例对变更影响域关键功能点覆盖的贡献。

路径长度：标注测试用例路径的长度，用来度量测试用例执行的大小及用例的综合测试能力，在覆盖度相同的情况下优先选择路径长度大的测试用例。

实施方式一：

下面以VS C#语言开发的学生管理***程序为例，具体说明如何通过本发明实现黑盒回归测试。示例程序输入界面如图15所示。

1、界面元素及交互关系分析

根据本发明步骤S101源代码解析、步骤S102界面元素分析和步骤S103交互关系分析，通过对软件源代码进行分析，可得到界面中的元素，即软件窗口组成、窗口调用关系、控件类型、名称等属性，如图16所示。

2、测试执行跟踪

以“登录***”功能为例，用户界面如图17所示。通过跟踪用户执行步骤，得出用户对“用户名”、“密码”文本框进行了输入操作，对“登录”按钮进行了点击操作，如图17所示。测试操作覆盖了流程涉及“登录”界面，如图18所示。

3、测试用例约简

采用步骤S106测试用例约简中的算法，通过测试用例覆盖路径、界面、控件等的比对，找出冗余测试用例，得出测试用例约简结果，如图19所示。

4、功能差异检测及变更影响分析

采用步骤步骤S107功能差异检测和步骤S108功能变更影响分析中的算法，通过对软件回归版本和基线版本的对比，得出软件功能差异，如图20所示。并且在软件功能调用图中显示变更影响分析，其中黄色标注修改的部分，蓝色标注新增的部分，如图21所示。

虽然以上描述了本发明的具体实施方式，但是本领域熟练技术人员应当理解，这些仅是举例说明，可以对本实施方式作出多种变更或修改，而不背离本发明的原理和实质，本发明的保护范围仅由所附权利要求书限定。

Claims (6)

1.一种黑盒回归测试方法，其特征在于，包括以下步骤，

步骤S101：源代码解析，通过类型解析和对源代码的词法、语法分析得到代码的语法树和类型***；

步骤S102：界面元素分析，扫描源代码抽象语法树，以窗口类定义为基本单元，分析被测软件的界面构成，形成界面元素树模型；

步骤S103：交互关系分析，扫描源代码抽象语法树，并依据所使用的类型***对调用逻辑、事件流进行分析，形成被测软件界面元素调用关系模型；

步骤S104：测试执行过程跟踪，捕获用例执行过程中所输入的数据以及点击的界面元素，形成用例执行路径数据；

步骤S105：用例覆盖分析，将用例执行数据与界面模型进行匹配，得到每个用例执行后被覆盖的界面元素和路径，并以图形方式显示于界面上；

步骤S106：测试用例约简，分析一组用例所覆盖的界面元素和路径，采用基于调用路径和基于界面元素覆盖数量两种算法剔除其中冗余的测试用例，形成测试用例集；

步骤S107：功能差异检测，通过对两个软件版本的静态分析结果进行分析，找出两个版本间的UI差异和UI变更位置；

步骤S108：功能变更影响分析，依据找到的变更点，采用回溯迭代算法，在界面元素静态结构模型上查找依赖项，形成从变更点出发的变更影响范围即影响域；

步骤S109：回归测试用例筛选：以变更影响域为目标函数，采用覆盖的变更功能优先、关键度优先以及路径长度优先策略，从约简后的测试用例集中查找出能够覆盖变更影响域的最少个数测试用例；所述步骤S109回归测试用例筛选采用覆盖的变更功能优先、关键度优先、路径长度优先三种原则，从约简后的测试用例集中，挑选出个数最少的测试用例；

排序指标的计算方式为：

变更功能：整个用例路径上覆盖变更影响域中未覆盖变更点的个数，用来描述单个测试用例对变更影响域覆盖的贡献；

路径关键度：使用在静态分析中的到的UI元素依赖关系有向图中UI节点的扇入数与扇出数的总和，结合测试需求来标注单个元素的关键度，整个用例的关键度是用例所覆盖变更域内尚未覆盖的变更点的关键度的总和，用来描述单个测试用例对变更影响域关键功能点覆盖的贡献；

路径长度：标注测试用例路径的长度，用来度量测试用例执行的大小及用例的综合测试能力，在覆盖度相同的情况下优先选择路径长度大的测试用例；

步骤S110：影响域覆盖分析，依据筛选出的回归测试用例所能够覆盖的变更影响域，找出尚未被覆盖的变更影响域。

2.按照权利要求1所述的一种黑盒回归测试方法，其特征在于：所述步骤S101源代码解析中如果代码为C#语言，将代码的逻辑结构与代码所述的类型***相关联，所述类型***中包含被测软件自定义的类型、引用类库的类型以及框架自身的类型，依据其关联关系识别出语法树的语义信息。

3.按照权利要求1所述的一种黑盒回归测试方法，其特征在于，所述步骤S104测试执行过程跟踪具体还包括以下步骤，

步骤S141：执行窗口调用树图构建；

步骤S142：界面控件捕获。

4.按照权利要求3所述的一种黑盒回归测试方法，其特征在于：所述步骤S142中的界面控件包括按钮、编辑框、菜单项、ListView、标签、Tab选项卡、列表框和ComboBox。

5.按照权利要求1所述的一种黑盒回归测试方法，其特征在于，所述步骤S106测试用例约简具体包括以下步骤，

步骤S161：关键用例处理；

步骤S162：用例筛选；

步骤S163：结果提交。

6.按照权利要求1所述的一种黑盒回归测试方法，其特征在于：所述步骤S108功能变更影响分析包括基于功能图的变更影响分析和基于调用关系的变更影响分析。

Images