3). 可重用的库文件Reusable libraries

　　设想你正在测试一个允许你查询数据库中记录的应用程序。许多产品的功能只可以在有一组可用的查询结果的情况下工作，因此大部分的测试都要包含执行一个查询所需的步骤。现在试想一下轻微地改变一下步骤的顺序：你需要更新每个脚本。

　　可供选择的方法是创建一个执行查询的函数或子程序。这个函数变成了一个可重用库文件的一部分。每个脚本调用这个函数比重新定义那些步骤更好。如果你在一个地方(函数库中)定义了事件的进展，你将使你所有的脚本更加好维护，这样胜于在需要执行这些操作的每个脚本中定义它们。

　　为了寻找一个支持可重用库的工具，有两件重要的事情需要做。首先，要确保你用工具创建的脚本能够轻松地调用你放在库文件中的函数。如果工具只允许你调用在当前脚本中创建的子程序那是不足够的。第二，确信函数可以带参数。例如，如果你创建了一个登陆的函数，你想要在每次调用函数的时候指定用户名和密码(而不是在函数中嵌入这些信息)。

　　4). 外部的库文件Outside libraries

　　除了创建你自己的库文件之外，你通常会发现访问外部的库文件是非常有用的。在Windows里，这意味着你应该能够调用.dll文件。举个例子，思考一下一个已构建的与关系数据库一起运行的C/S系统。所测试的软件使用了数据库私有的API(Application Program Interface)。如果自动化测试可以使用相同的API，它们可以变得更加强大。他们可以检查不允许访问的用户界面。例如，它们可以检查一个已更改的值是否已经被写到数据库中，而不仅仅只是在屏幕上更改了。即便UI没有给权限给它们记录，它们都可以检查交易是否成功并且完全被记录了。一般说来，这些测试可以比通过验证UI上的值更加准确地判断“成功”或是“失败”。

　　如果你正在一个Windows系统上测试，你也应该有访问Windows API的权限。Windows API 使你能够获得系统信息，这是非常困难的或者其他方法不可能获得的。例如，在你的自动化脚本中获取或设置注册表的键值的时候是非常有用的。

　　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分钟，因为在运行第二个测试之前出现了一个意外的对话框。这是个令人沮丧的场景，而且从来不少见。

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

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