选择正确的GUI测试自动化工具

　　概要：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测试自动化工具将拥有许多和一个好的开发环境相同的功能。

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

原文转自：http://www.uml.org.cn/Test/200608111.htm