SITAR：GUI测试脚本修复

摘要

本文介绍了ScrIpT repAireR（SITAR），一种自动修复无法使用的低级测试脚本的技术.SITAR使用反向工程技术为每个脚本创建抽象测试，将其映射到带注释的事件流程图（EFG），使用修复转换和人工输入进行修复测试，并合成新的“已修复”测试脚本。在此过程中，SITAR还修复了对检查点中使用的GUI对象的引用，从而生成了最终的测试脚本，该脚本可以自动执行以验证修订后的软件。使用QTP测试脚本进行的实验表明，SITAR是有效的，因为修复了41％到89％的无法使用的测试脚本。修复了20％的测试脚本后，注释显着降低了人工成本。

1. 引言

在本文中，我们介绍了一种ScrIpT repAireR（SITAR），一种修复无法使用的低级测试脚本的技术。SITAR通过将无法使用的测试脚本的抽象级别从脚本语言级别提升到模型级别，应用基于模型的修复转换来获得模型。级别的可用测试用例，然后合成新的低级别的可用脚本。要执行修复，它依赖于GUI的不完善和不准确的EFG模型以及人工输入。

更准确地说，SITAR将具有不完整和不精确的自动反向工程EFGG0的应用测试（AUT）A0，具有不完整和不精确的EFGG1的AUT的修改版本A1以及为A0创建的测试套件TS0（包括图形输出的断言/检查点）作为输入。不能用于A1的测试用例的TS0，因此可以进行维修。SITAR使用修复转换和人工输入（作为批注）来修复可以执行并满足A1断言的测试用例ints0。

我们使用SITAR进行实验的示例系统是QTP，可提供功能化和回归测试自动化。我们的实验涉及370个QTP测试脚本，这些脚本包含总共13043个事件和12个检查点，这些脚本由三个软件应用程序的200多名测试人员获得。我们为每个应用程序使用了两个版本。软件的更改使所有测试脚本都无法在两个应用程序中使用。我们显示，多达89％的剧本已被SITAR修复。一个应用程序脚本的结果行覆盖率从0％上升到68.3％。我们显示，在修复了20％的测试脚本之后，注释可以帮助大大减少人类的参与。

我们的研究还说明了三个重要点：（1）手动创建的测试用例通常比自动逆向工程技术（表10）具有更多的应用范围，（2）SITAR成功地修复测试用例（表11和12）而不会中断-通过将原始测试用例的业务逻辑（表13）和（3）作为模型中的断言来积累人工输入，SITAR在整个维修过程的整个生命周期内实现了更好的自动化（图10和11）。

在设计SITAR中，我们做出了以下研究贡献：使用不完整/不正确的自动逆向工程EFG以及人工输入来修复复杂的测试脚本的机制，同时保留了脚本测试AUT业务逻辑的能力。

在不完全了解GUI及其更改的情况下进行修复的机制。根据现有的EFG近似值，自动向维修人员提供维修建议，然后再选择最适用的维修变换。

· 将人工输入整合并累积到整个过程中的机制，可以加快过程并生成更准确的EFG模型。

· 修复检查点中的对象引用的机制。大多数检查点在已修复的脚本中仍然有效，这表明在修复后，原始测试脚本中编码的业务逻辑仍然存在。

· EFG中有新注释，以方便维修。特别是，我们在边缘上引入了新的占优标记。

· 在代码和模型级别之间进行映射，以实现从代码到模型的转换，反之亦然。

· 输出AUT的带注释的EFG模型，该模型比通过逆向工程自动获得的模型更准确。这些注释采用由测试人员确认/添加的事件/边缘的形式。精确的EFG可以加快维修过程，并具有改善测试生成和对AUT更高版本进行维修的潜力。

2. 相关工作

我们在SITAR上的工作源于先前报道的两项技术，它们为GUI测试修复和脚本维护奠定了基础。测试修复的想法最初是由Memon和Soffa提出的。其中报告的方法会完全自动对可用与不可用的测试用例进行分类。不可用的测试用例会自动进一步分类为可修复或不可修复。开发了修复转换以完全自动化地修复测试用例。由于他们专注于全自动，因此对EFG模型，测试用例和修改做出了许多假设。 EFG被认为是完整而精确的；假设测试用例仅由EFG中的高级事件组成，没有检查点或断言；并假定所有改名都是已知的。这些假设不适用于手动创建的测试脚本。脚本化的测试用例可能包含EFG中不存在的某些事件，这些事件容易发生不完整的情况。测试脚本可用于功能验证的检查点。从GUI到从软件应用程序的一个版本到其下一版本的修改很少能准确地完整记录下来。我们目前的工作SITAR牺牲了完全的自动化，但是通过消除这些假设在更现实的环境中工作。

由于围绕测试修复的困难，Evansand Savoia提出了一种称为差异测试的技术，以缓解测试修复问题并揭示软件演进过程中的行为变化。差异测试会为原始程序和修改后的程序创建测试套件，并将这两个版本与这两个套件进行对比。其他也可能有助于测试修复的研究是对库中API重构的自动检测，它会基于语法分析自动检测两个版本的库之间的重构。同样，修复程序中的缺陷而不是测试用例的工作也很重要。

我们的工作是独一无二的，因为我们还修复了测试用例的预期输出（即测试预言）部分。我们利用我们在测试预言上的早期工作，来构成修复的基础。Xie的工作也与之相关，后者利用回归Oracle检查来增强自动生成的单元测试套件。他们表明，从软件的早期版本开始的测试预言对于在软件升级后检测故障很有用。他们通过在原始软件上执行测试用例来收集对象状态，并将此信息用作针对修改后的软件的增强的单元测试套件的预言。

最后，Pinto等人对围绕测试套件的发展和维护的现实提出了很好的解决方案。他们讨论了各种实际的用例，其中在实践中添加，删除和重构了测试用例。他们还指出，与以前的案例不同，测试修复更加复杂且难以自动化，并且现有的专注于断言的测试修复技术在实践中可能不适用。这促使我们修复真正的测试脚本，该脚本涉及不同类型的更改，并且需要领域知识来修复。我们通过将人类行为存储为模型中的新节点/边/标签来增强半自动修复过程，从而增强了广泛使用的EFG模型。

3. 概述

通过一个名为Project Management System（PMS）的简单本地示例应用程序提供了SITAR的概述，该应用程序用于创建和管理项目；可以添加，编辑和删除项目成员。我们在图1中显示了3个PMS版本1.0的对话框。（最左侧的）主窗口名为PMS，具有两个视图：（1）默认启动屏幕（未显示）和（2）“ Project General Information”屏幕（显示），需要事件序列（文件，打开项目）并从对话框中选择一个项目。在此视图中，用户可以添加新的项目成员或删除现有的成员。单击添加成员将打开（中心）对话框。PMS还包含一个用于启动其他对话框的下拉菜单。例如，“文件”，“创建项目”将打开（最右侧）“创建项目”对话框。

GUI强制执行某些约束。首先，在主窗口中，只有当项目成员（行）选择启用按钮，删除成员。其次，“添加成员”对话框中的“完成成员”按钮将保持禁用状态（图1），直到为“名称”和“电子邮件文本”字段输入有效值为止。

图1 版本1.0中的三个窗口

我们针对1.0版的测试脚本如图2所示。测试脚本TS1创建一个新项目，输入标题和描述的值，然后单击“完成项目”按钮。TS2创建一个新项目成员，输入名称，选择字符并输入电子邮件，最后单击TS3打开一个项目，删除第二个项目成员，然后选择第一个成员以进行进一步的操作。TS4打开一个项目，检查（cp1）它是否有四个成员，删除第一个成员，添加信息一个新成员，但是在单击“完成成员”之前，请检查（cp2）是否显示常任成员； TS5创建一个名为“ new Project”的新项目，并检查（cp1）标题是否正确反映在GUI上，并确认（cp3）四个成员。然后添加一个新成员，检查（cp2）该字符是否正确反映在GUI上，并检查（cp3）成员数是否为1。

4. 模型和算法

图2 SITAR组件的逻辑视图

SITAR组件的逻辑透视图如图8所示。SITAR交易具有三个不同的空间（抽象级别）：( 1）执行，（2）脚本和（3）模型。翻录提高了从执行到模型的级别。映射首先提高了从脚本（对于版本n）到模型的抽象级别，然后在修复了脚本之后，从模型回到脚本（版本n + 1）。现在我们讨论这些组件的设计以及它们用于实现SITAR的模型和算法。

4.1Ripping

翻录旨在将已实现的GUI（版本n + 1）的抽象级别提高到允许修复的抽象模型。在翻录期间，GUI应用程序会自动执行； 该应用程序的窗口以深度优先的方式打开。GUI Ripper从GUI提取所有窗口小部件及其属性。在反向工程过程中，除了窗口小部件属性外，还将恢复每个窗口小部件的其他关键属性（例如，是否启用了窗口小部件，打开了模式/无模式窗口，打开了菜单，关闭了窗口，是按钮 ，它是一个可编辑的文本字段）。 这些属性用于构造EFG。

模态窗口是一个GUI窗口，一旦被调用，它将独占GUI交互，将用户的焦点限制在窗口内特定范围的事件上，直到该窗口被显式或隐式终止。 GUI中其他不限制用户焦点的窗口称为无模式窗口；这些窗口称为非模式窗口。它们只是扩展了用户可用的GUI事件集。我们将术语模态对话框定义为一组由模态窗口X和直接或间接从X调用的无模态窗口组成的窗口。模态对话框将一直保留到X明确终止为止。通过定义，GUI用户不能将一个模态对话框的事件与其他模态对话框的事件进行交错。用户必须明确终止当前活动的模态对话框，或者调用另一个模态对话框以执行不同对话框中的事件。在与GUI交互期间，用户始终会与模式对话框中的事件进行交互。

翻录输出一个EFG模型，该模型表示GUI中所有可能发生的事件交互。建模为有向图，其每个顶点表示一个事件（例如，单击编辑，单击粘贴），每边表示两个事件之间的可能关系。从顶点到顶点y的可能跟随边缘表明，事件y可能在事件x之后立即执行（即y可能跟随x）。

4.2 映射

模型中使用的低级GUI对象/小部件与逻辑事件之间的映射将低级脚本的级别提高到了模型的水平，因此可以将序列映射到EFG路径并随后进行修复。小部件，其容器（例如Dialog和Window）以及用于创建它的类。 QTP还使用这些属性来寻址每个小部件。如前所述，我们显式存储QTP名称和逻辑事件名称之间的映射。我们解析每个脚本语句并提取其对象类型和标题。例如，将对语句JavaWindow（“ PMS”）。JavaButton（“ Add”）。click进行解析以获得两种对象类型：JavaWindow和JavaButton，以及它们相应的标题：PMS和Add。然后从裂土器的映射中搜索这些对象，并使用其逻辑形式表示它们。如果没有找到匹配项，则将创建一个NULL条目。更正式地说，我们的映射是一个两列的查找表：第一列是脚本系统为小部件使用的寻址机制；第二列为脚本系统为小部件使用的寻址机制。第二列是分配给窗口小部件的逻辑模型级字符串标签。要创建映射，我们先从一个空的映射Map开始，然后使用以下算法迭代检查每个脚本，向其中添加条目。输入（1）测试脚本TS，该脚本由在AUTA0原始版本上创建的脚本语句s1; s2; …; sni的序列组成，以及（2）G1，即修改后的AUTA1的EFG。地图。我们的技术的伪代码如图3所示。如第5-8行所示，对于每个脚本语句si，请执行以下操作：

图3修复程序的伪代码

4.3 修理

至此，在获得映射之后，每个脚本语句要么映射到EFG模型中的高级事件，要么映射为NULL。同样，脚本中检查点中引用的每个GUI窗口小部件也都映射到模型级窗口小部件（由于我们将事件和窗口小部件同义地建模，因此相当于一个事件）或NULL。SITAR已准备好开始修复。

修复程序的理想情况是，这些事件在每个事件的映射中都具有一个非NULL条目，并且每个相邻事件对的EFG中都有一条边。这样的序列被认为是有效的，并且该映射用于合成低级脚本。

必须修复至少具有一个NULL（事件/检查点）的映射脚本。而且，即使脚本中没有NULL事件，事件的无效执行流程也仍然值得修复。也就是说，GUI的工作流程需要允许脚本执行的事件顺序。更正式地说，我们将测试修复的问题阐述如下。给定EFGG1和映射的脚本，表示为事件序列e1; e2; …; eni和检查点c1; c2; …; cmi，其中

和

，如果满足以下条件之一，则该脚本需要修复满足条件：

情况1，缺少事件：序列中ei或cj中的至少一个为NULL，其中

和

。

情况2，缺少边：序列中相邻事件中至少有一对

，不是EG1中的有效边沿。

修复的输出是事件e1; e2; …; eni和已修复的检查点c1; c2; …; cmi的序列，其中不包含任何丢失的小部件或丢失的边缘。

5. 实验研究

现在，我们将通过经验研究GUI脚本维护问题并评估SITAR的有效性。4具体来说，我们解决以下研究问题。

RQ1：GUI修改后，原始测试脚本的哪一部分变得不可用？使测试脚本无法使用的GUI修改的本质是什么？

RQ2：GUI的哪一部分会自动撕开？

RQ3：SITAR修复了多少个测试脚本（包括检查点）？修复的测试脚本与原始脚本一样能很好地发现相同比例的代码和事件？

RQ4：维修费用是多少？

RQ5：映射和注释的有效性如何？

RQ6：什么比例的测试脚本无法修复，为什么？

对于上述问题，我们采用了几种指标。对于RQ1，我们计算了无法使用的测试脚本。我们还对GUI修改进行分类并计算每个修改类的受影响测试脚本的数量。对于RR2，我们将开膛手自动获取的事件数量与经过仔细手动检查GUI的事件数量进行比较。对于RQ3，我们计算成功修复的脚本数量，并计算其代码和事件覆盖率。我们手动研究我们无法修复的检查点，并对原因进行分类。对于RQ4，我们衡量维修成本。对于RQ5，我们测量了维修期间人工成本的下降情况。我们计算整个维修过程中的操作率（人工操作次数与已修复测试脚本代码行之间的比率）和每行代码的时间成本（以秒为单位）。对于RQ6，我们对未修复的测试脚本进行计数和分类。

我们确定了三个主要原因。（I）对象参考：已检查的GUI对象已在新版本中更改；该对象的引用应已修复，以便QTP可以访问它；（II）预期的输出：新版本中某些属性（例如，标题，标签）的值已更改；检查点仍然引用旧值。这些只能手动修复。（III）执行伪像：在少数情况下，虽然检查点似乎已正确指定，但它们意外失败。我们将其归因于测试重播的问题，这主要是由于QTP与应用程序之间的时间安排所致。我们稍后再讨论此问题。此问题已解决。

我们根据每次维修所花费的时间来衡量成本；我们区分两种类型的操作：输入（需要修改GUI对象或输入QTP脚本行）和确认（确认），其中包括确认原始脚本行的正确性，选择建议的修复路径测试脚本，并删除脚本行。图10示出了对于大多数应用，与自动输入操作相比，手动输入操作的数量非常少。我们还注意到，手动确认操作的比例随着应用程序的大小和初始EFG的不完整而增加。 OmegaT是最大的应用程序，与第二大应用程序PDFsam相比，其初始EFG模型缺少许多要素，因此它需要最大比例的手动确认操作。对于这三个主题，SITAR所执行的确认操作远比手动执行的要大得多，这是针对RQ4的。我们非正式地注意到，主题的大小，测试脚本的数量，被撕开的模型的完整性，应用程序版本之间的变化影响维修时间。这些因素的更详细的研究是将来工作的主题。

图4.成本效益

为了评估SITAR修复知识积累的有效性，我们在图11中测量了修复的人工成本。x轴以百分比的形式显示了修复过程的进度。 y轴在左图中显示了操作率（手动操作数与已修复测试脚本的代码行之间的比率）；右边的图显示了每行代码的时间成本（以秒为单位）。结果表明：

（1）由于初始模型的不完整和缺乏维修知识，早期阶段的成本要高得多；

（2）人工操作成本迅速下降，并且在维修过程的20％到40％时达到较低水平。

（3）SITAR每条线的维修时间成本少于大部分时间的一半。即使对于前10％的脚本，CS2和PDF2的时间成本也低于1秒。

OT2的时间成本在早期阶段相对较高，但下降得很快，这主要是因为当以后的测试脚本出现相同情况时，先前的手动维修决策会自动重用SITAR。它们如何影响下游维修。

总结结果。在这项研究中，我们从修复的脚本数量，检查点以及代码和事件覆盖率的角度显示了SITAR的优势。我们还根据未修复的脚本和检查点的类别研究了SITAR的弱点。像所有研究一样，其结果也受到有效性的威胁。为了最大程度地减少对内部有效性的威胁，我们依靠可靠的工具（例如QTP和Ripper）来进行此项工作。我们还通过不断地检查我们的数据收集代码和结果（每个应用程序有三到四名参与者）来确保我们的数据正确。为了最大程度地减少对外部有效性的威胁，我们使用开源应用程序作为主题。我们对其代码或演化没有任何影响。但是，我们认识到这些应用程序并不代表各种可能的GUI。对于其他GUI应用程序类型，预期结果会有所不同。我们还雇用了多个测试人员来创建测试脚本并进行维修。但是，他们都是学生。我们意识到，在大学环境中制作的测试脚本可能无法涵盖多种可能的行业功能。

通过共享我们在本研究中使用/生成的数据，我们希望鼓励其他研究人员加强研究，从而帮助进一步减少对有效性的威胁，并为这一备受忽视的测试修复问题做出贡献。

6. 结论与未来研究方向

我们介绍了SITAR，这是一种用于修复由于GUI修改而变得无法使用的低级测试脚本的新技术。我们的工作与众不同之处在于，我们开发了在不完全了解GUI及其更改的情况下进行修复的新机制，在最初不完整的GUI模型中提供了新注释，以方便进行修复，代码之间的映射在模型级实现从代码到模型的转换，反之亦然；以及将人工输入合并而且缓存到整个过程中的机制。我们在三个开源软件主题上的研究结果很有希望。我们能够修复原本完全无法使用的测试套件的重要部分。

来源：慕测科技