失控的UI自动化

　　一提到自动化测试，大多数人就会以为是用硬编码(hardcode)的事件和数据来编写脚本，模拟用户和软件之间可能的交互动作，来完成一个预定义的、机器人执行的任务。可能就是因为这个原因， 商业分析师(Business Analysts)或者黑盒测试者得到了太多的工具来帮助他们录制和回放(或者列出相关步骤的关键字)一些人为设想的用户可能会做的操作步骤。确实……看着窗口开关、鼠标魔术般的在桌面上移动是很酷的一件事。但是，对于任何聪明的的人来说， 这种视觉上的惊奇往往只能持续……哦……大约1.7秒……之后就变得麻木无聊了!不幸的是： 自动化常常是很短命的， 它需要大量的维护开销，并且是造成那些失败或谈不上成功的自动化工程的主要原因。

　　总的来说我并不是很热衷于图形界面的自动化测试，这里有很多原因，但是最重要的原因是因为它被滥用了，有一些测试其实找一个人能够执行得更快更好。不过我也理解在某些场合下图形界面自动化测试的确能够提供它的价值。我并不反对图形界面自动化测试，但是绝不主张只是因为能够自动化就用自动化测试，或者只是因为我们有的那些荒诞的想法：认为所有的东西都应该自动化。

　　就拿有一次我和一个测试人员的谈话来举例吧。他的经理希望他去维护一个旧的测试用例，这个用例是用来检测一个操作后箭头的颜色是否正确。如果操作成功，箭头的颜色是绿色，否则就是红色。现在，可以看出我们能很容易通过检测 HRESULT值来自动化一个新的测试，这个测试可以由一个用户在合理的时间内执行完。这部分的代码基本不会被修改，并且没有什么依赖性。但是这个主管坚持要运行这个用户界面测试，尽管图像比较是众所周知存在问题的。(许多图像比较方法都出了名的有问题，产生很多错误的判断，这并不奇怪.)

　　测试人员说这位经理认为这个自动化用例减少测试人员手工操作的重复劳动从而节约时间。真的么?这个测试人员需要每周花几个小时来努力寻找出现错误的地方，调整自动化测试使它在每天的版本上“正确执行”，而只是为了让他的主管高兴。所以，尽管这个功能会被上百个试用每日构建(Daily Build)的人、另外上百个公司内用到内部发行版本的人和上千个使用Beta版本的客户所重复使用，这个主管还是认为不停的调整测试能节约一些测试人员的时间。

　　还有一个例子， 一个测试员询问如何自动化一个测试用例来判断PowerPoint演示中的幻灯片顺序在不同的.ppt文件拷贝中是否相同。当然，这个问题引来了一大堆的回复，比如建议他创建每个幻灯片的图像库，然后用图像比较工具来判断变化。我的回答有点不同。首先，这里有几种方法来编程检测文件的变化，一旦检测到二进制属性的变化，我们可以简单地在幻灯片排序视图中打开PowerPoint演示文件，用几秒钟(取决于幻灯片的数目)直接比较它和原文件的幻灯片顺序。这是比自动化测试慢一点，但是我真的怀疑它会更有效率，尤其是长期来看。我也很好奇在他的项目(不是PowerPoint本身)中这个“测试”究竟实际会被执行几次，是否值得开发一个这样的测试所花的小时数/天数和后期维护的噩梦。

　　这只是滥用UI自动化测试的两个例子，它们显示了下面几个重要的观点:

　　并不是所有的UI自动化测试都节省时间!

　　那些因为常常给出错误结果而需要不断调整的UI自动化测试，浪费了一个测试人员大量的时间在维护上。

　　有时候人工测试是比计算机算法更有效率的办法!

　　确实，任何计算机能做的事情都能在某种程度上被自动化，但是有些测试用人工来做会更加明智和简单。

　　别依赖自动化来模拟你的用户!

　　测试自动化并不能有效的模拟一个用户。确实，在我们内部的测试框架中有很多种方法来减慢模拟的键盘操作(真正的键并没有在键盘上被按下)，或者模拟在一个控件或鼠标上的多次重复点击，和其它试图模拟不同用户行为的技巧。然而，自动化测试在检测行为问题上通常很弱， 例如可用性、易用性或用户实用性的测试。在这种情况下，应该依赖于内部或外部的用户。他们是真正测试和体验你的产品的人。

　　深入内部!

　　我觉得很多测试人员过多的依赖于UI自动化是因为他们觉得这样能够模拟用户行为(虽然大部分的事情，例如填充一个文本框，是通过Windows API来模拟的)，或者可能因为他们不知道怎么深入研究UI背后的实现。不管是哪种情况，考虑一下这个测试的确切的目的是什么。如果检查一个返回值或者调用一个API来改变设置会更简单，那么就深入下去，停止在UI上浪费时间了。(这只会是把测试复杂化，浪费宝贵的机器运转，减少了多种版本间的重用，还常常导致长期的维护代价)。

原文转自：http://www.uml.org.cn/Test/201005055.asp