SITAR: GUI 测试脚本修复

SITAR: GUI 测试脚本修复

论文：Zebao Gao,Zhenyu Chen, Atif Memon, Yunxiao Zou. SITAR: GUI test script repair. IEEE Transactions on Software Engineering, 2016, vol. 42, pp. 170-186https://www.computer.org/10.1109/TSE.2015.2454510论文摘要：GUI应用程序的系统测试需要测试案例（由一系列的用户操作/事件组成），执行测试用例后对软件的输出进行验证。为了确保实现自动重新执行测试，这些测试用例越来越多地被编码为低水平的测试脚本，通过测试工具实现自动重放。每当GUI发生改变（组件被移动，窗口合并），一些测试脚本就会变得不可用，因为其编码的输入序列不再有效。此外，由于软件的输出可能已经改变，它们编码在测试脚本中的测试预言（断言和检查点）可能就不能再正确检测到相应的GUI对象。我们提出了ScrIpT repAireR (SITAR)，一种可以自动修复不可用的低水平的测试脚本的技术。SITAR使用了逆向工程工具为每一个测试用例创建一个抽象的测试，并将其映射到一个有注解的事件流图（event-flow graph，EFG），使用脚本修复转换和人工输入来修复该脚本，并合成一个"已修复"测试脚本。在这个过程中，SITAR同时修复了测试脚本检查点中对于GUI对象的引用，产生了一个最终的测试脚本，可以被自动执行来验证改进后的软件。SITAR通过在EFG中以注解的形式不断累积人类知识来分期偿还人在多个脚本上的干预。使用QTP测试脚本的实验表明，SITAR的有效之处在于修复了41-89％不可用的测试脚本。在修复20％的测试脚本后，注释显着降低了人力成本。

技术介绍：

对使用图形用户界面（GUI）的软件应用程序进行自动化测试的会遇到一个重要问题，每当软件发生更改，大量测试用例都可能失效。因为修改后的GUI不再允许它们编码的事件序列，或者它们的检查点（断言）不再能正确检查预期的GUI对象。但是GUI测试是必须的，因为它们通常基于精心设计的用例和功能要求。测试人员投入宝贵的时间将他们的领域知识和经验转换成测试脚本和检查点，以全面涵盖业务逻辑，使这些脚本变得复杂和有价值。当大量测试变得无法使用并且每次修改GUI时需要重新编码或重新记录时，高维护成本会使其价值相形见绌。

GUI脚本修复一直以来受到非常高的关注。丹尼尔等人提出一种白盒方法，其中记录GUI更改，特别是GUI重构，稍后用于修复测试用例。他们设想使用智能IDE，IDE会精确记录这些更改，并将使用它们更改GUI代码和修复测试用例。Fu等人提出了一种GUI测试脚本的类型推断工具TIGOR，它可以作为测试人员的助手，通过静态分析确定GUI脚本的类型错误。

图1：SITAR组件的逻辑关系组件主要分为三个部分：执行、脚本和模型。Ripping将级别从执行提高到了模型，Mapping将脚本（对于版本n）的抽象级别提升到模型，一旦修复了脚本，就从模型回到脚本级别（版本n + 1）。

图2：GUI Ripping过程自动生成事件流图，它的顶点代表事件，边代表事件发生的顺序，由nx到ny表示ny表示的事件可以紧跟在一些执行路径上由nx表示的事件之后。

在Ripping期间，我们的工具会执行应用程序；打开其主窗口，提取所有事件的列表并存储在队列中；事件由该队列中的Ripper一个接一个地执行。点击按钮，选择单选按钮等，从而模仿用户行为。如果遇到文本字段，则输入手动预设值；如果没有提供，则随机生成一个。当事件执行时，它们会打开新窗口。这会导致当前窗口发生变化。先前的队列被压入堆栈，稍后在新的当前窗口关闭时使用。

表1：GUI Ripping的第二个输出是每个GUI组件的签名，即一种标识和访问每个GUI组件的方式。基于这些签名，SITAR可以将测试脚本语句映射到EFG中的逻辑时间名称，并最终将测试脚本映射到逻辑事件序列。

在Ripping期间，我们知道每个GUI组件的位置，其容器（例如，对话框和窗口）以及用于创建它的类。我们解析每个脚本语句并提取其对象类型和标题，然后在Ripper的映射中搜索它们，并使用它们的逻辑形式表示。如果未找到匹配，则创建NULL条目。

修复从四个输入开始：一组逻辑事件序列，每个序列对应一个测试脚本；EFG模型，其中所有边被标记为may-follow；初始映射；每对事件之间的被允许的路径的空表。修复过程存在两种情况：（1）序列中存在NULL事件，导致这种情况的原因有很多，可能该事件已经不在该应用中，就需要剔除该事件在前后事件之间添加follow关系。也可能事件仍然存在但是在创建EFG时忽略了，这种情况需要人工添加遗漏的事件。也可能该事件对应的元素属性发生改变，使得签名无法与之匹配，该信息也需要被添加到映射表中。（2）序列中的两个连续事件x和y没有EFG中对应的边，就需要多个机制来修复该序列。首先扫描已经修复过的路径中是否存在这样一个序列a，使得<x,y>能被<x,a,y>取代。其次可以通过最短路径算法来寻找x到y的可能路径。所有的修复都以建议的方式提供给测试人员，经由测试人员授权再执行。

1）我们使用自动逆向工程获得的不完整/不准确的EFG与人工输入一起修复复杂测试脚本的机制，同时保留脚本测试AUT业务逻辑的能力。

2）我们基于现有近似准确的EFG，自动提供修复建议给测试人员，然后由测试人员选择最合适的修复变换。将人类输入纳入并累积到整个过程中的机制，这加速了整个过程并有助于产生更准确的EFG模型。

3）我们在代码和模型级别之间进行映射，以实现从代码到模型的转换。

4）我们输出AUT的包含注释的EFG模型，该模型比通过逆向工程自动获得的模型更准确。这些注释采用由测试人员确认/添加的事件/边的形式。准确的EFG加速了修复过程，并且有改进AUT的后续版本的测试生成和修复的潜力。