滥用的UI自动化测试

前几天读了一篇文章《UI Automation Out of Control》，作者是微软的测试专家，结合自己多年的经验，讲述了自己对UI自动化测试的感悟。读完全文，如醍醐灌顶啊，因为最近两个月一直也在使用内部的一套颇为强大和复杂的自动化系统工作，但是自动化的同时，心里始终有个结憋着，或者心底始终对自动化尤其是UI自动化打着问号。看了这篇文章，看到问题根结了。

T/M'S~e[v`6} TI0　　很多QE/QA都认为他们的自动化测试工具盒系统能完好地模拟用户的实际操作以及与产品的交互，他们认为这样的UI自动化测试系统是很理想很完美的测试工具，所以很多软件公司、互联网公司都花费很大代价开发或者外包开发各式各样的UI自动化系统用于测试自己的产品，不仅如此，这套系统后续的维护和使用仍旧耗费着大量人力。

D ykCt*z-yWu051Testing软件测试网kA_4YwU_$D&S

　　以我所负责的产品为例吧。我们的自动化测试系统十分庞大，至少从六年前就已经开始工作了，这些年来这个系统一直在随着产品的更新而更新。产品最初只有Windows版本，最近两年陆续支持Mac OS，Linux， 以及各种如日中天的Mobile系统，如iOS，Android， QNX等等。所以测试系统也越来越细化，维护测试系统的工作人员也不得不增多。初步估计，目前所有case的复杂度综合应该不次于Windows NT级别的OS了。这当然表现出了公司对于产品质量控制的高标准要求，这是好事。那么再说说过度使用自动化测试尤其是UI自动化的负面因素。

n4P(C0}v)w0

"{&MvT`%O7P3Z(t0　　为了提高自动化比率，需要将一些合适的手动的测试用例修改成能自动化的用例，这花费了我大概15个工作日；为了让UI自动化系统将这些case自动化地运行起来，一般还需要底层脚本的驱动，编写和测试这些脚本又花费了大概15个工作日。这还不是全部，自动化系统嘛，现在流行分布式、跨平台、以及xx as service，所以我们还需要再为自己的团队建设一套UI系统。运气好的话可以直接在旧的平台的基础上搭建，运气不好，需求分析、系统设计、实现等等等等又是一套产品出来了，这就可能需要两三个月甚至半年的时间了。最后，我们拥有了另一个强大的，分布式的，无间断的，健壮的自动化测试系统。

(vK0y DK WO051Testing软件测试网;m ^t B1ONd

　　终于开始测试了，我使用这套UI自动化系统先创建了一套基准截图，为后续测试做准备，这也就是点一个按钮的功夫。自动化是不是很好啊，先不用高兴。第一次的测试任务终于来了，我们的强大系统派上用场了，可是测试过程中突然发现怎么错误率（与基准的不匹配率）这么高呢，没事，用新的结果覆盖基准，更新基准就行了，第一次看来基准有点问题，没能够发现重大bug；第二次测试任务开始了，发现由于随着产品更新，基准又有点不准确了，还得更新；………就这样，UI自动化测试的过程演变成了测试系统不断更新的过程。但是，这套系统是绝对不能丢弃的，因为它代表了我们的测试工作的自动化程度，有了它就可以自豪地宣称我们的自动化比率已经达到了多么高的高度，已经如何足够智能。所以它就一直这么存在着了。51Testing软件测试网YJIhzk![1O i

*^(W6Ys!m8J7P0　　其实，真正的测试是不应该用机器来模仿用户操作的，但是我们不肯能雇十万名员工过来整天只是装作普通用户来使用产品，所以自动化在一定程度上能帮助公司削减开支的同时保证产品质量。但是过度依赖自动化测试，就会适得其反。简而言之，就是不能为了自动化而自动化。51Testing软件测试网0c8X+bm"ry)h

lofs9^.v0　　以上评论并非针对特定公司。如果恰巧有大型软件公司的读者，应该也会有类似感悟吧。51Testing软件测试网 ln7D)U%ys2~B)k