概要：GUI (图形用户界面graphical user interface)工具自诩其拥有许多的功能。把GUI测试自动化作为一个编程的项目处理，你将需要一个和你项目大小相当的工具。这是一篇对你购买的GUI测试自动化产品中你所需的关键功能的梗概。

　　· 在选择一个GUI测试工具需要考虑的因素

　　· 把GUI测试自动化象一个编程项目一样对待

　　· 必要功能的清单

　　购买一个GUI测试自动化工具是一个令人畏缩的任务。如果你是第一次评估工具的话，很难知道要在工具里查找些什么。即使你以前曾经评估过GUI测试工具，那些可用的工具和你上次察看时的情况可能也已经发生了巨大的变化。你会选择哪一个工具呢?你真的需要每个供应商的市场宣传册中吹捧的所有功能吗?你知道你不应该听从那些圆滑的宣传标语。你不确信从现在开始的6个月里你会需要哪些功能。因此你在购买一个可能远远超出你目的的高端工具和购买一个仅仅可以开始作些事情的低端工具之间痛苦的徘徊。

　　你要做的第一件事情是建立你将在评估工具中使用的决策标准。有一些标准可能是很明显的：你想从一个有信誉的供应商手中购买，你选择的工具需要支持你测试的操作系统，并且容易使用，不管这对你的组织重不重要。这篇文章并不是要告诉你那些你已知的所需功能，而是要说一说在你第一次采购后的几个月里你将发现需要的GUI测试自动化工具中的功能。把它看成是一个对即要发生事情的“预警”(heads up)。

　　在开始时，思考一下自动化测试系统的概要图形。如果你把测试开发看成是创建一些运行于基于GUI的软件应用程序的测试那样一件简单的事情的话，那么你的测试自动化的模型看上去像图1。

　　当你只使用录制和回放时，你的测试将类似于此图。但是这个模型是有局限的。因为测试直接和用户界面一起工作，几乎在UI上的任何变更都意味着每个使用了这部分UI的测试都需要变更。另外，如果有一些大多数测试都必须执行的通用操作(例如，登陆)，那么每个测试都必须包括这些步骤。后，由于在测试中嵌入了所有的测试数据，为了迎合变更，甚至象在登陆表格中的名称这样小的事情，你都不得不编辑测试代码。

　　结果，做日常维护是非常的困难，并且为本地化或UI检查而做的重大变更更是一个恶梦。象这样的测试系统在一个单独的版本里彻底崩溃可不是罕见的。换句话说，在1.0版本中可以运行的测试，但在2.0中你可能需要再创建它们了。

　　为了说明每个缺点，让我们增加一些更多的元素。在后面将会详细的解释每个元素。首先，在所测试的软件和测试脚本中增加一个抽象层。抽象层把UI元素映射为测试将使用的逻辑名称。接下来，增加一个可重用的函数库以封装常用的操作。后，增加测试数据文件以保存否则可能被硬编码在脚本中的数据。现在这个模型看起来象图2。

　　即使你没有计划使用在这个图中的所有元素，你都要寻找一个可以支持所有这些元素的工具。你会在比你想象中更早的时间里需要这些功能。

　　为什么呢?当你创建一些快速的，低劣的并且为任意使用而设计的测试时，你的自动化测试工作量是不太可能得到回报的，除非你的测试大部分是：

　　·可维护的：从一个版本到另一个版本都是可用的，只是为了新的功能或新的UI而做少量的更新

　　·可靠的：提供准确的结果，它对于识别所测试软件中问题是直接了当的

　　·健壮的：能够处理异常的错误条件，使测试可以在没有人工干涉的情况下运行。

　　只有当你将测试自动化象软件开发一样认真的对待，你才能达到那个目标。测试自动化实际上是编程。因此一个好的GUI测试自动化工具将拥有许多和一个好的开发环境相同的功能。

　　“噢，当然”你可能会想。“我将在我的大量的空闲时间里开始编写我的测试。”你或许刚刚好有足够的时间完成你现在的任务。自动化被假设为可以使你的生活更加轻松，而不是增加一个全新的编程任务。不幸的是，如果你不将测试自动化看待为一个编程任务，你将无止尽的重做，重做，重做。更糟的是，如果在项目的末尾时，后一分钟的变更破坏了测试，那么已自动化的测试将不能够运行-刚好在你需要它们的时候。即使你认为你没有时间在多数的测试中遵循的开发实践，也应该购买一个支持它们的工具。把它看成是一个保险措施。

　　因此你可以怎样确信你已经识别了一个将使你能够构建一个系统并利用的编程实践实现它的工具呢?让我们来看看在任何的工具中都很重要的12个功能。

　　功能检查表

　　1). 脚本语言

　　本文中描述的其他所有功能的一个先决条件是工具必须有一种包含了常见编程构想的脚本语言。至少，它应该：

　　·使你能够编辑已录制的脚本

　　·支持变量和数据类型

　　·支持矩阵，列表，结构，或其他复合的数据类型

　　·支持条件式的逻辑(IF和CASE语句)

　　·支持循环 (FOR， WHILE)

　　·使你可以创建和调用函数

　　如果工具使用的是象VB或C一样的常用语言，你会获得一个附加的好处：很容易找到这些语言的书籍或培训课程，并且在你组织中的大多人可能已经知道它们。

　　语言越强大，你潜在拥有的控制越多。成熟的脚本语言使你能够创建更加成熟的脚本。当然，拥有一个复杂语言也使创建比所测软件更复杂的自动化测试变为可能。因此寻找一门可以带给你所需的力量和灵活性的语言，并且为使用这一先进的功能明智地设计你的测试。

　　2). UI元素识别器 element identifiers

　　为了编写真正的可以测试一些东西的测试脚本，你应该确信测试工具能够把UI上的元素识别为对象，而不是试图通过坐标指向它们。

　　如果你正在测试一个Windows的应用程序，并且开发人员正在使用MFC (Microsoft Foundation Class library) 控件的话，那么大多数可用的测试工具都没有什么问题。然而，如果你的应用程序是使用Java Swing控件(a.k.a. JFC，或 Java Foundation Class library)编写的话，有些工具会比其它的工具工作地更好。在评估期间，确信工具可以识别多种典型窗口中的UI元素。

　　有些UI元素根本不是真正的控件，这是真的，它们只是一些当你点击它们时可以作些事情的位图。使用位图UI元素比使用那些不能和任何自动化测试工具一起运行的真正的控件更好。如果你的软件是这种情况的话，在工具评估时把开发人员一起叫来以便他们可以第一时间看到为什么使用标准的控件对于提高软件的可测试性是很重要的。