【IT168 技术文章】
购买一个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元素比使用那些不能和任何自动化测试工具一起运行的真正的控件更好。如果你的软件是这种情况的话，在工具评估时把开发人员一起叫来以便他们可以第一时间看到为什么使用标准的控件对于提高软件的可测试性是很重要的。
3). 可重用的库文件Reusable libraries
设想你正在测试一个允许你查询数据库中记录的应用程序。许多产品的功能只可以在有一组可用的查询结果的情况下工作，因此大部分的测试都要包含执行一个查询所需的步骤。现在试想一下轻微地改变一下步骤的顺序：你需要更新每个脚本。
可供选择的方法是创建一个执行查询的函数或子程序。这个函数变成了一个可重用库文件的一部分。每个脚本调用这个函数比重新定义那些步骤更好。如果你在一个地方（函数库中）定义了事件的进展，你将使你所有的脚本更加好维护，这样胜于在需要执行这些操作的每个脚本中定义它们。
为了寻找一个支持可重用库的工具，有两件重要的事情需要做。首先，要确保你用工具创建的脚本能够轻松地调用你放在库文件中的函数。如果工具只允许你调用在当前脚本中创建的子程序那是不足够的。第二，确信函数可以带参数。例如，如果你创建了一个登陆的函数，你想要在每次调用函数的时候指定用户名和密码（而不是在函数中嵌入这些信息）。
4). 外部的库文件Outside libraries
除了创建你自己的库文件之外，你通常会发现访问外部的库文件是非常有用的。在Windows里，这意味着你应该能够调用.dll文件。举个例子，思考一下一个已构建的与关系数据库一起运行的C/S系统。所测试的软件使用了数据库私有的API(Application Program Interface)。如果自动化测试可以使用相同的API，它们可以变得更加强大。他们可以检查不允许访问的用户界面。例如，它们可以检查一个已更改的值是否已经被写到数据库中，而不仅仅只是在屏幕上更改了。即便UI没有给权限给它们记录，它们都可以检查交易是否成功并且完全被记录了。一般说来，这些测试可以比通过验证UI上的值更加准确地判断“成功”或是“失败”。
如果你正在一个Windows系统上测试，你也应该有访问Windows API的权限。Windows API 使你能够获得系统信息，这是非常困难的或者其他方法不可能获得的。例如，在你的自动化脚本中获取或设置注册表的键值的时候是非常有用的。
