我发现了，大家极度关心自动化测试，尤其是UI自动化测试，虽然现在作为专项测试，离开这些越来越远了，但总能遥想以前，我总能想起自己做nokia的WindowsLive的ui自动化，做web的自动化测试，后面加入腾讯，写过pc的自动化，作为早期的终端测试，做android的自动化，然后mac的，然后ios。 先不说有多少成功经验，但是确实有一些感悟，现在分享给大家，希望能帮助大家思考，少走弯路。

*UI自动化测试的真实价值

 

测试生命中三大幻觉:

今天能发布

明天能发布

UI自动化实现了，测试就可以不用测了

正正是第三点赋予了ui自动化测试错误的价值。让UI自动化测试验证UI, 利用图片比较去做自动验证，甚至利用截图定位按钮。真是找死的节奏呀。 现在我带大家认识下它的真正价值。

1. 验证逻辑而非UI

UI的验证会引入大量的不稳定因素。换句话说，像当年的测试大牛段念说的，你跑过了UI自动化，你就相信没问题了吗？不会相信，原因是啥？因为聪明的你会发现，你验证的东西越多，例如界面的每个按钮，颜色，排布，互联网应用变化最大的就是UI, 你的用例就越不稳定，所以你最终肯定不会验证全部UI。那结果就是"然并卵"了, 你根本不会相信这个用例真的通过了。因此给大家定个UI自动化能做的，验证逻辑（另外一种说法，说这种叫功能自动化）。什么叫验证逻辑？例如验证qq是否登录成功，验证到了好友列表，就是登录成功，甚至有登录成功的日志都可以，怎么稳定怎么行。

2.代替大量的UI重复操作

简单来说就是UI自动化你要投入5元，只是执行4次，每次赚5毛的话，那你还亏3元的问题。什么时候会大量呢？像手Q, 编译百个市场的包，每个包要验证核心功能。或者像性能ui自动化监控，同一个用例为了多次采样，也会执行多次。还有每日构建，集成，都可以。关键点就是用次数来增加价值，UI自动化能帮你确保不出死人的问题，如登录不了，登录了又卡死，或者是监控UI之外的其他，如性能。这些都有机会让其价值高于成本的。

*最大难点，维护

 

无间道: 出来混，迟早要还的。 这句话，最好用来说明，为什么自动化测试构造得越快越随便，未来的维护成本也就越大。更甚者，脚本依赖录制得来的，也是找死的节奏。 无数的故事告诉我，很多UI自动化都是死在一开始就写或者录一堆脚本，结果每天都要花大量时间排查错误，错误有脚本错误，有功能的变更，有bug，甚至问题是随机出现的，但是无论你的问题或者是功能的问题，反正你排查错误的时间是花进去了，哪怕你不用改脚本。所以这里看来，

要解决维护的难点，终极招数就是不要碰UI自动化。其实很多大牛都是说不要做ui自动化的，或者这个事情不是最高优先级，但是现实是，大家都做了，优先级还不低。所以我当然不说不做了，要做就只能要狠狠地干一场，要成功，不要失败。下面给大家有两点建议，一是策略，二是技术。

策略上，维护成本的控制，脚本要慢慢上，先做核心的BVT，人均维护的脚本1~2个，定目标，如稳定运营1个月，后面增加的脚本要在测试环境稳定跑上一周，才能切换到正式环境。 组织培训，知识分享，分享写自动化遇到的坑，沉淀最佳的实践，让大家知道写UI自动化也是在自我提升，而不是简单的工作任务。

技术上，降低维护成本的方法，

1.脚本里不要有坐标，图像识别这些，想都别想，想都别想，想都别想！这些都是不稳定的因素。

2.脚本里不要有sleep。sleep就是UI自动化的稳定性的克星，绝对不能有。一方面，如果帮助建立或者直接使用UI自动化测试等待界面稳定的阻塞方法，例如waitForIdle，等待控件出现和消失的方法，如waitForInvisiable之类的。另外一种，就是封装一个timeout的类，里面包含重试和sleep的策略，让脚本直接使用。反正，不要看到sleep。

原文转自：http://www.jianshu.com/p/84f2a5d86334