MILY: Arial; mso-bidi-font-size: 22.0pt">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分钟，因为在运行第二个测试之前出现了一个意外的对话框。这是个令人沮丧的场景，而且从来不少见。
拥有一个优异的错误处理系统的工具使得其他的脚本可以继续运行，甚至于一个脚本失败之后。工具可以停止失败的脚本，然后在开始下一个脚本之前重新设置软件到它初始的状态。
如果工具的错误处理能力可以定制的话，那是非常有用的。例如，或许你的产品有已知的的错误条件，它需要一定数量的清除以修复。如果你能够扩展错误处理系统以便它可以识别那些错误并且执行所需的清除，你的自动化测试甚至可以更加得健壮。
9). 调试器The debugger
没有比“该死，它应该是可以工作的” 的感觉更令人沮丧的事情了，你完成了你的测试并且成功的使它运行在你的机器上了。现在你试图运行测试在其他人的机器上，而它却不能运行。拥有一个好的调试器可以比试验－错误方法使你更快的发现问题。
调试器是嵌入在测试脚本开发环境中的，通常调试器使你能够一步步的按行执行脚本，设置“断点”（调试器可以停下执行脚本并且等待下一个指令的地方），并且检查当前定义的变量和它们的值。如果调试器能够让你在任何可执行行上设置断点那将更好，不管它是在所测试的脚本里还是在支持的代码中（例如，在可重用的库文件）。
10). 源代码控制Source control
源代码控制是一个任何类型软件开发的基础性工具，因此测试自动化也不例外。一般来说，源代码控制系统允许你从一个主库中check in或check out文件，回滚到先前的版本，找出版本之间的差异，并且同时追踪几个项目。这些功能使得多个人工作在源码文件的多个版本上变为可能。
与其寻找一个包括了源代码控制功能的测试工具，不如使用和软件开发人员所使用的一样的源代码控制系统，实际上这样也会更好些。使用相同的源代码控制系统的实用性好处是你可以利用已经有一个建立了的工作方式的事实。使用相同的系统还有心理上的好处：在你组织的其他人了解到测试自动化是“真正的编程”。
即使你是你团队中唯一的正在做自动化测试的人，你仍然要确信你所构建的测试系统中的所有部分－从测试数据文件和测试脚本到抽象层－可以在源码控制下进行。幸运地是，和源代码控制系统集成是比较简单的：如果测试自动化文件用ASCII存储，你可以使用你源码控制系统中的所有功能。用二进制格式存储自动化测试任何部分的测试工具会妨碍你和你的测试一起使用源码控制的能力。你仍然可以把二进制文件放到源码控制中，但是你将不能把文件的一个版本和另一个版本对比以判断文件做何变更。（如果你不确定的话，你可以通过用好像Windows中的Notpad文字处理器来打开文件以断定它是否是ASCII。如果你只看到文字字符并且有些意思，那么文件就是ASCII的。如果取而代之的是看到笑脸，心形，方块或其他的奇怪的字符，那么文件可能就是二进制的了。）
另外，如果测试工具需要你将所有的文件放在一个集中的地方并且规定文件的结构，你需要试验一下以确定和集中的文件位置一起使用源码控制的最好方法（最好是在评估期间）。
11). 命令行脚本执行Command line script execution
从命令行运行脚本的能力使得设置脚本更加地容易，在机器comes back up之后自动地重启机器和重新开始测试。这也使在每个版本后自动地开始自动化测试成为可能。
12). 用户社区The user community
最后一个要查找的功能在软件盒中是找不到：寻找一个拥有已建立用户社区的工具。讨论组，用户的网站和当地用户团体是所有可以学习你新工具细节的好地方。用户社区的成员常常会共享通用函数的库文件或其他一些有用的源代码－这样为开发你自己的内部可重用的库文件有很大的帮助。
在你购买大量license之前先购买一些
就大多数组织而言，转换工具的成本是非常昂贵的。那不仅仅是购买新软件的事情。它也是关乎是要用新的工具重新创建现有的测试还是继续为现有的工具支付维护费用的事情。购买一个受限的试用版的一个或两个license，可能是在没有太大风险的情况下试验工具的最好办法。如果试用版运行的很好，那么就购买更多的license并且全力的投入。如果试用版运行的不好，至少你没有购买太多的license，潜在地浪费了很多的钱。
这也意味着如果你现在有一个工作的相当好的工具，但是没有本文提及的所有功能，不要马上跑出去买一个新的工具。切换工具可能比你相象中更加地昂贵。
结论
评估自动化测试工具是特别困难的，因为大部分的测试工具供应商在试图做成买卖时，强调易用功能多过编程功能。你不会发现工具不能和你的源代码控制系统一起工作，或是脚本很难维护，直到上路的6个月后。寻找与你现在所需功能，将来需要功能相平衡，以及迎合你预算底线成本的工具，这的确是一个挑战。
文章来源于领测软件测试网 https://www.ltesting.net/
