让我们来聊一下UI自动化测试

发表于:2016-11-09来源:来自地球的移动测试作者:来自地球的移动测点击数: 标签:UI
我发现了,大家极度关心自动化测试,尤其是UI自动化测试,虽然现在作为专项测试,离开这些越来越远了,但总能遥想以前,我总能想起自己做nokia的WindowsLive的ui自动化,做web的自动化
  我发现了,大家极度关心自动化测试,尤其是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。
 
  3.要用脚本要基于面向对象。脚本不需要编译,调试方便,学习门槛低,像python,能使用的库也丰富。所以自动化测试最佳的使用Python,再配合pydev,用起来还是很舒服的。而说到面向对象,它有个作用,就是通过隔离变化来提升代码的可维护性。说多了,可能你都不明白, 我举个例子来说说, 用了面向对象的UI自动化脚本的样子(python的哈)。

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