模板
教程
环境
性能
功能
管理
GUI回归测试
本文中，我们将说明对于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． 实验表明，在现实的应用中，本文提供的方法是有效实用的。
