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

　　5). 抽象层Abstract layers

　　一个“抽象层”使你能够为物理的用户界面元素定义逻辑名称。一些工具称它为“test map” 或“GUI map”，也有些称其为“test frame”。不管它叫什么名称，抽象层的目的就是使维护测试变得更轻松。

　　举个例子，想象一下带有用户名和密码字段的登陆对话框。在程序里，编程人员命名这些字段为“Name”和“Password”。你创建一个抽象层，它也将那些字段识别为“Name”和“Password”，并且在你所有的500个测试中都使用这些标志符 。但是随着所测试软件下一个版本的出现，名称和密码字段的潜在标志符变成了 “username”和“pword”。你只要在一个地方-抽象层中更改UI标志符，而不是在你所有的500个脚本中做变更。

　　几个测试工具都提供了这样的功能，例如窗口录制器，它是特别设计的以支持一个抽象层的创建。这些功能是非常有用的，但是如果你愿意手工的编写抽象层，这也不是绝对需要的。

　　6). 分布式的测试Distributed tests

　　如果你正在测试多用户的软件，你需要能够创建包含多个模拟用户的测试。 例如，你可能想创建一个某台机器上的用户锁住一个文件而另一台机器上的用户又在试图打开同一个文件的测试。你如何自动化这种类型的测试呢?如果你选择的测试工具没有分布式测试的能力的话，那么这将是很困难的。

　　在一个分布式的测试里，自动化测试工具使你能指定执行一个既定指令的机器。这和在一台远程的机器上完成一个测试的能力(这也是一个很好的功能)有些不同。在一台远程机器上开始测试，远程机器从头到尾完整地运行那个测试。但是如果你需要在两个不同的机器上协调这一活动，那么你应该做比只是开始一个测试且让它运行更多的事情。你需要能够创建一个等待一个动作的测试(例如锁住一个文件)，以便在第二台机器开始一个动作之前(例如试图打开文件)在第一台机器上完成操作。

　　7). 文件I/O

　　文件的I/O (输入/输出input/output)意味着工具提供了让你通过编程打开硬盘中的文件，读取文件，写文件和关闭文件(通常是一个ASCII文件)的函数 。

　　文件I/O函数是“数据驱动测试自动化”的核心。在一个数据驱动的自动化测试里，脚本使用文件中的测试数据来驱动测试活动(注意在图2中“测试数据”在测试自动化架构中的角色)。数据驱动测试使自动化大量的测试，却只有少量的测试自动化代码变为可能。

　　如果你正在测试一个Windows的系统，如果工具提供了处理.ini文件的函数，那是特别有用的。例如，如果所测试软件需要知道正在使用哪个服务器，那么在.ini文件中指定服务器的名称是一个很好的方法。于是你只需要在文件中更改测试服务器，而不需要更改自动化脚本。

　　8). 错误处理Error handling

　　在你昨天晚上离开之前，你开始了一个很长的，需要运行250个测试的自动化测试。你来到的第二天早晨，你发现那些测试只运行5分钟，因为在运行第二个测试之前出现了一个意外的对话框。这是个令人沮丧的场景，而且从来不少见。

　　拥有一个优异的错误处理系统的工具使得其他的脚本可以继续运行，甚至于一个脚本失败之后。工具可以停止失败的脚本，然后在开始下一个脚本之前重新设置软件到它初始的状态。

　　如果工具的错误处理能力可以定制的话，那是非常有用的。例如，或许你的产品有已知的的错误条件，它需要一定数量的清除以修复。如果你能够扩展错误处理系统以便它可以识别那些错误并且执行所需的清除，你的自动化测试甚至可以更加得健壮。

　　9). 调试器The debugger

　　没有比“该死，它应该是可以工作的” 的感觉更令人沮丧的事情了，你完成了你的测试并且成功的使它运行在你的机器上了。现在你试图运行测试在其他人的机器上，而它却不能运行。拥有一个好的调试器可以比试验-错误方法使你更快的发现问题。

　　调试器是嵌入在测试脚本开发环境中的，通常调试器使你能够一步步的按行执行脚本，设置“断点”(调试器可以停下执行脚本并且等待下一个指令的地方)，并且检查当前定义的变量和它们的值。如果调试器能够让你在任何可执行行上设置断点那将更好，不管它是在所测试的脚本里还是在支持的代码中(例如，在可重用的库文件)。

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