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个月后。寻找与你现在所需功能，将来需要功能相平衡，以及迎合你预算底线成本的工具，这的确是一个挑战。

　　另一个挑战存在于间接地分开现实和市场。在你评估期间，你要确信花了时间研究手头上工具中比较先进的功能。换句话说，不要依赖功能列表来决定你需要的好工具。应该亲自动手使用产品，并且使它自动化真正的测试。

　　记得在购买新的工具的时候，重要的是不管供应商想使测试自动化看上去怎样得简单，它实际上是编程。相应地选择工具。当你为新的版本更新你的测试包时，你将会知道它是非常的值得，并且将发现你有一个比你曾经想象的更快的完整的测试包。