我理想中的功能测试化工具应该满足以下基本条件：
- 简单。测试本来就够复杂了。测试人员本来就该把精力集中在发现系统错误上面。再让测试人员在测试程序上花费大力气，实在得不偿失。所谓简单，关键在于和浏览器用户的操作同轨。程序代码应该完全屏蔽和用户无关的细节。比如说，如果网页上有个叫“递交”的按钮，那对应点击该按钮的语句应该不比getButton("递交").click()更复杂。简而言之，自动化工具的编程模型能让一个测试员看着用户的操作写出对应的代码。套用现在的流行术语，叫自动测试所用的语言应该是和用户的概念模型(conceptual model)对应的业务领域专属语言(Domain Specific Language)
。更严重的后果是测试人员为了赶进度，不得写出低水平的测试代码，起不到发现系统错误的目的。 - 灵活。需求无止境。我们绝对需要一套能随时扩展，支持复杂编程的自动化工具。也许今天我们只需要搜寻网页上一条简单的字串，所以工具提供的字符串函数足敷使用，但明天我们可能就得遍历网页上所有元素，于是我们需要一套强大的HTML解析器。千万不要告诉我，这套工具不支持HTML解析。不幸的是，很多上万刀的工具，就是不支持随意的HTML解析。再我看来，这已经不是开发人员设计上的过失，更本就是对测试人员水平的挑衅。
- 稳定。本来测试的目的是发现系统的错误，结果因为工具不稳定，测试人员发现大量工具的问题，最后不得不花上大量时间来排除于自家系统无关的错误。结果开发人员和测试人员摩擦加剧，测试人员精疲力尽，花大钱投资的工具束之高阁，项目费时费力。。。
- 功能强大，有大量的库供使用。虽说我们可以开发自己的库，但这种费时费力的工作最好不做。毕竟测试的核心部分不是开发自己的库。还不用说将来的维护费用。
至于自动记录操作，图形化支持什么的，都属于锦上添花的东西，如果基本要求不满足，不要也罢。可惜大多数商业工具，都把测试人员当傻瓜，过分注重自动记录，图形化操作等边角功能。我用过下面的工具做Web应用的功能测试自动化，没一款让我满意的：
- Mercury Interactive的QuickTest Professional。我用的好像是v3和v4。这款工具号称全面支持图形化自动记录测试操作，支持用VBScript编程和定制记录下的测试操作。号称拥有强大的测试类库和图形化的定制工具。遗憾的是，这款工具给我们的团队带来了无穷无尽的烦恼。它生成的代码包含大量底层细节，根本不适合人去修改和维护。它生成的代码文件居然和它的Object Repository（Object Repository用来存储自动记录中生成的所有对象，以便日后回放时和回放结果比较）绑定。一不小心，就可能破坏这种绑定，导致生成的文件失效。我明白Mercury的初衷是利用Object Repository来简化自动化操作，可惜这个方法完全无效。我们还发现Quick Test Professional回放的时候常常和记录的不一样，导致测试虚假失败。另外，由于测试结果和object repository相比较，直接造成测试回放对GUI敏感。哪怕改变一个按键的位置都会引起测试失败。问题是，功能测试里我们实在不关心一个按键在左上角还是右下角。总而言之，QuickTest Professional没有做到基本要求里的1，2，和3，直接使这个安装空间高达1.2G的软件沦落为适合小型GUi测试的工具。
- Segue SilkPerformer。我们用过v5和v6.5。这是款相当不错的性能测试工具。功能强大，性能稳定。为我们部门的性能测试和系统测试立下汗马功劳。可惜这款工具并不适合大规模复杂的WEB功能测试，尽管它支持功能测试。我们为了用这款工具，在它的基础上搭建了巨大的测试库，耗资N个人年，但仍然不能让众多的测试人员满意。首先，SilkPerformer的自动记录仍然暴露大量细节，比如说我们必须知道一个button是对应的一个简单链接，还是一段JavaScript。其次，Silkperformer用一种古怪的语言，叫Benchmarking Definition Language。这个语言是标准Pascal和C的混合体，集成了标准pascal的呆板并放弃了C的灵活。这个语言的灵活性之差，以至于它还提供了对COM和JVM的接口，用来支持功能扩展。BTW，对JVM的支持出奇笨拙，比如只有static方法，比如只有一个类。。。最后，SilkPerfomer的BDL在编程上有很多限制。比如它不支持全面HTML解析（6.5开始支持了，但用了一种相当受限的配置方法），也不支持动态的数据结构（不要告诉了定长的数组是动态数据结构，更不消说不同长度的数组居然是不同的数据类型）。对了，我提到了BDL的regular expression支持简直是个笑话么？
所以说，SilkPerformer不能满足基本条件1, 2, 和4。 - Rational的XDE Tester和Robot。这两款软件也用Object Repository，所以自然继承了Object Repository的各种缺点。尽管Rational采用了一些聪明的算法来让Object Repostory变得灵活而稳定，但要我用它提供的Java框架编程，还是饶了俺吧。
- HTTPUnit。这个是免费的开源功能测试框架，接近我的理想。它基本上就是个用代码控制的浏览器（好的功能测试工具就该这么做），合网页上的操作简单对应，相当方便。可惜当前版本的HTTPUnit仅支持有限的JavaScript，而且对IE支持有限，因为它用的是Mozilla的HTML内核和JavaScript引擎。简而言之，基本条件4没有被满足。
- Samie, Samie的出发点相当不错：用程序控制IE Automation。也就是说，Samie利用Perl来模拟一个浏览器的运行。而模拟的方法是调用IE的Automation接口。这样做好最大的好处就是能相对容易地满足基本条件1。至于后面3个基本条件，Perl加上IE都可以轻易地满足。不过Samie还在开发中，仍然需要添加大量功能。不过这是款相当有希望的软件。这也是基本条件4没有被满足。
今天随意浏览杂志，看到一篇减少Watr的的文章。Watr是Ruby写就的Web测试工具。这款工具好像不错。这款工具同样调用IE Automation的接口。我们可以在Eclipse上调试测试代码，因为eclipse集成了对Ruby的支持。看来是开始看铁撬书的时候了。对了，这本书的第一版在网上免费