本文中，我们将说明对于GUI而言，大量测试用例的不可用是一个严重的问题。我们将展示一个崭新GUI回归测试技术，首先在GUI结构发生变化时自动判断测试用例是否仍然可用。而后判断那些不可用的测试用例中哪些是可以被修复的并应用到修改后的GUI。最后修复这些可修复的测试用例。我们的技术整合到GUI测试框架中，对于任意一个测试用例，都将自动在GUI执行。我们将通过两个测试案例说明我们的技术是有效的，可以使很多测试用例修复，时间执行效率也是可以接受的。
1 介绍
GUI在当今的软件系统中非常普及，占据了软件代码的半壁江山。一个软件系统的GUI的正确性对于确保整个软件系统的顺利运行至关重要。一个普遍的方法是通过对GUI进行测试来确定GUI的正确性。GUI测试要求测试用例（一系列激活GUI窗口的GUI事件）在GUI中产生并执行。然后，目前对于获取GUI测试用例的可行技术是基于资源，需要大量的人工干预。尽管目前有少量的有关自动产生GUI测试用例的文献资料，但在实际操作中，测试用例仍然是通过手工的使用[抓取/重放]工具得到的。
当使用[抓取/重放]工具时，测试人员需要与被测应用程序（AUT，application under test）有所互动；[抓取]可以在文件中保存这些互动，以便[重放]工具可以将它们重放。经验证明，通过使用[抓取/重放]工具，为50个来自不同的窗口的事件生成一个测试用例打工需要20-30分钟。因为需要花费时间，测试人员对于软件界面只生成较少（100-300）的测试用例，因此每一个测试用例都是很珍贵的。
另外，大多数的GUI都是使用快速原型法设计的，这样软件可以在层叠式地进行更新和测试。GUI结构不断的修改要求测试用例可以在不同版本的软件上都是可用的。因为为不同版本的软件生成新的测试用例是非常昂贵的。
尽管回归测试对于传统软件而言是一项非常重要的软件维护手段，占据了大约1/3的软件开发成本，对于GUI的回归测试仍然是一个巨大的有待开发的领域。对于GUI回归测试的需求不同于传统软件对于回归测试的需求。回归测试的研究过去都集中于发展回归测试中的选择技术，这项技术的作用就是从一系列测试用例中选择一部分，这部分用例表明了正确的输入并认为对于验证修改后的软件是必不可少的。那些不能够在新的软件上使用的测试用例将被忽略并丢弃。不可用用例问题对于GUI而言更为严重，因为GUI结构的改变将导致大量测试用例不可用，需要昂贵的更新成本。
当GUI发生变化时，一个测试集合中的测试用例就可被归纳为两类：可用以及不可用。在可用的范畴中，这些测试用例还是可以在修改后的GUI上使用。而在不可用范畴内的测试用例是不能再重用的。例如，一个测试用例里可能包含点击按钮的操作，但这个按钮很可能在新的结构中被删除或是转移到其他地方了。早期的[抓取/重放]工具是根据GUI窗口的对应像素来表示用户事件的。然而，目前的[抓取/重放]工具不再只依赖于坐标，而且还包含了额外的信息如句柄、类型以及（可能的话）窗体的标签，使得当控件被移走时[重放]工具仍然可以定位到正确的窗口。然而即便是用了这些现代的工具，由于GUI结构的修改，如添加一个新的菜单项，将激活一个对话框的动作从一个菜单换到另一个菜单，或是从一个窗口转移到另一个窗口，因此仍然有大量的测试用例变为不可用。第6部分将说明超过74%测试用例将变为不可用。
本文提出一个崭新的GUI回归测试技术。我们的核心想法是不丢弃那些在修改后的GUI上不可用的测试用例。而是自动地将他们修复以便可以应用到修改后的GUI。我们将注意力集中到产生与原有测试用例有些类似的测试用例上，其原因稍后会加以解释。通过使用这项新的技术，一名测试人员可以（1）重新在修改后的GUI上使用原有的仍然可用的测试用例。（2）修复并试用原先已经不可用的测试用例。（3）产生新的测试用例去测试新的功能。第6部分将说明我们的技术将使超过70%的测试技术被修复。
为了进一步说明GUI的回归测试技术，我们在GUI测试框架中简化了GUI的表示方法。同时我们定义了GUI结构事件的控制模型，使用模型来判断GUI是否改变，判断测试用例是否可用，若不可用是否可以被修复。当有很多种方法可以修复一个测试用例时，所有的方法都将被使用，这样就会生成更多的测试用例。我们已经设计出了自动生成工具、表述工具以及重放已修复测试用例工具。
本文的贡献包括：
1． 首次提出一项回归测试技术，该技术可以从不可用测试用例中自动生成新的测试用例。
2． 测试机将决定测试用例在已修改后的GUI上是可用的还是不可用的，以及不可用的测试用例是否可以被修复。
3． 向修复机输入可修复的测试用例，得到可以在已修改的GUI上使用的测试用例。
4． 实验表明，在现实的应用中，本文提供的方法是有效实用的。
5． 将回归测试技术整合到GUI测试框架中。
在下一部分中，我们将定义一个GUI测试用例，并说明GUI的修改影响GUI测试用例的很多途径。然后，我们将在第3部分定义GUI控制流图和GUI调用图。第4部分中将会介绍一个GUI回归测试的例子。第5部分将详细描述回归测试人员将如何使用本文中的修复技术。在第6部分中，我们将通过在Acrobat Reader和WordPad两个软件上使用回归测试技术说明实验结果。最后，在第7部分中，我们将展示目前的一些相关研究。第8章包括本文的总结和未来的工作。
2 GUI模型和测试案例
在这一部分中，我们首先要介绍在GUI测试框架中GUI的模型。尔后我们将定义一个GUI测试用例并引入不可用以及可用测试模型的定义。
一个GUI被模型化为一组对象或窗口O={o1,o2,…om}（例如，标签、表格、按钮、文本框等）以及一组属性P={p1,p2,…pl}（例如，前景、名称）。每一个GUI都会使用对象的相关属性的某些性质。在任何时刻，GUI的状态都可以通过它所包含的所有对象以及所有属性的值来描述。因此，我们定义GUI的状态为：
定义：GUI的状态是指GUI中包含的所有对象的所有属性的状态集。
GUI的有效初始状态定义如下。
定义：如果GUI在初次被激活时的状态Si∈SI，则状态集SI称作该GUI的有效初始状态。
GUI的状态不是一成不变的，在GUI上运行的事件会改变GUI的状态。这些改变后的状态成为改变态。这些事件将被状态转换器进行定义。
定义：事件E={e1,e2,…,en}是可以使GUI的状态转换到另一个状态的函数。
函数表示Sj = e(Si)用于表示状态Sj是由于执行了事件e由状态Si转换而来的。对于测试人员而言，重要的是符合GUI结构的事件序列。我们将测试中使用到的有效的事件序列定义如下。
定义：GUI的有效事件序列为e1;e2;e3;…;en，其中ei+1将在ei之后立刻执行。
一个事件序列如果不是有效的，将被称作非有效事件序列。例如，在MS Word中，剪切（在编辑菜单下）不能在打开（在文件菜单下）执行后立即被执行，因此事件序列<打开，剪切>就是非有效的（忽略键盘快捷方式）。
最后，还要定义GUI测试用例。
定义：GUI测试用例可以表示为（So,e1;e2;…;en），包括任何S0∈SI，SI为初始状态，e1;e2;…;en为一个有效的事件序列。
如果在测试用例中的初始状态是非有效状态或者它其中的事件是无效的，那么这个测试用例就是不可执行的。
定义：如果GUI的改变造成状态So非有效或是事件序列e1;e2;…;en是无法完成的，则测试用例（So,e1;e2;…;en）是不可用的。
不可用的测试用例是不能在GUI上执行的，通常就会被丢弃。
定义：如果测试用例（So,e1;e2;…;en）是可以在修改后的GUI上执行，则该测试用例是可用的。
因为GUI的测试用例的生成是很昂贵的，因此我们设计了这项新技术来修复不可用的测试用例。首先描述GUI的结构来检测出GUI结构上的变化，然后使用这一信息来修复不可用测试用例。并且，由于目前的GUI都非常的大，例如，它们通常包含大量的事件和窗口，我们的描述将使GUI分割为便于管理的几部分。
文章来源于领测软件测试网 https://www.ltesting.net/