我理想中的功能测试化工具应该满足以下基本条件:
- 简单。测试本来就够复杂了。测试人员本来就该把精力集中在发现系统错误上面。再让测试人员在测试程序上花费大力气,实在得不偿失。所谓简单,关键在于和浏览器用户的操作同轨。程序代码应该完全屏蔽和用户无关的细节。比如说,如果网页上有个叫“递交”的按钮,那对应点击该按钮的语句应该不比getButton("递交").click()更复杂。简而言之,自动化工具的编程模型能让一个测试员看着用户的操作写出对应的代码。套用现在的流行术语,叫自动测试所用的语言应该是和用户的概念模型(conceptual model)对应的业务领域专属语言(Domain Specific Language) 。更严重的后果是测试人员为了赶进度,不得写出低水平的测试代码,起不到发现系统错误的目的。
- 灵活。需求无止境。我们绝对需要一套能随时扩展,支持复杂编程的自动化工具。也许今天我们只需要搜寻网页上一条简单的字串,所以工具提供的字符串函数足敷使用,但明天我们可能就得遍历网页上所有元素,于是我们需要一套强大的HTML解析器。千万不要告诉我,这套工具不支持HTML解析。不幸的是,很多上万刀的工具,就是不支持随意的HTML解析。再我看来,这已经不是开发人员设计上的过失,更本就是对测试人员水平的挑衅。
- 稳定。本来测试的目的是发现系统的错误,结果因为工具不稳定,测试人员发现大量工具的问题,最后不得不花上大量时间来排除于自家系统无关的错误。结果开发人员和测试人员摩擦加剧,测试人员精疲力尽,花大钱投