移动测试基础 移动应用自动化测试的困惑

KevinXu · November 17, 2014 · Last by mic replied at November 19, 2014 · 1879 hits

在我实施移动应用自动化测试的过程当中,我思考最多的倒不是技术实现上面的问题,而是:

  1. 面对迭代周期短的应用,自动化的开发维护成本实在太高,那是否有必要做自动化?
  2. UI的自动化的产出是很少的,发现不了什么问题,是否有必要自动化? 我始终在思考UI自动化的意义,UI自动化产生的价值有多少? 我目前的想法是前端UI和功能的测试全部手工执行,接口的测试实行自动化 对于上面的2个问题,期望移动应用测试大神来释疑,谢谢!
共收到 16 条回复 时间 点赞

增加ut环节,其次稳定模块可以加入ui

#1楼 @kasi 谢谢!ut指的是unit testing?如果是,目前这个环节开发在覆盖,稳定模块加入UI自动化是个可行的方案,多谢指导!

分层自动化

把接口测试做好, 这个可以很好的保证后端质量. 而且最不易变. 自动化价值高
UT单测交给研发. 监督他们搞好. 保证一定的覆盖率,
UI测试小部分业务要自动化, 保证质量还是有用的, 大部分是易变的, 手工测试即可. 我不看好UI自动化

充分利用云服务

兼容性测试(Testin MTC)
众测服务(花钱也不多, 值得尝试, 发众测任务, 比如把游戏打通N关, 注册N个帐号之类的, 发动少量群众可以发现更多问题)
安全测试(类似乌云. 可能稍贵. 测试行业暂时还没有这种服务)
性能测试(云服务目前还不太好用, 还得靠自己)

降低自动化的维护成本

比如录制回放技术, 不过这个录制回放工具的好坏很大程度决定了效率和成本
和研发约定规则 自动生成自动化测试用例
改善自动化的架构, 比如使用关键词驱动框架来维护. 这样贴近业务. 而且业务是基本不变的
成本太大的话不走自动化也是一条路.

#3楼 @seveniruby 释然,顿时就有了执行步骤了,非常感谢!

很多时候我们想了很多我们自动化的意义。有多少含金量。 领导说: 这个是项目指标, 需要一份数据。需要的只是一个报告数据。 这也是自动化的作用。。 自动化对于主要功能的回归质量保证还是很有用处的。保证基本功能,快速的发现主要功能存在的问题。

成本太大的话不走自动化也是一条路

大家想法都是一样的,不赚钱的买卖都是没有必要的~ *

说说我们的经历吧。
三年前
背景:一个传统软件做UI层面的自动化测试
没有CI,手工打包,没有UT,jquery4个版本混用....
开始做自动化测试,前先花了三个月左右(中间还有其他事情)的时间,使用jenkins+ant实现自动打包,不能算CI
然后一个月左右开始给大领导和其他利益相关群体做“洗脑”工作。半个月之后,得到结果开始执行,但是必须要有可量化的指标:

  1. 自动化测试覆盖率= 自动化测试覆盖的手工测试用例/手工测试用例总数 这其中有很大的问题,之前的用例根本就不是良好的用例。没有上下文,没有数据,
  2. 自动化测试的价值=自动化测试执行的时间/自动化测试代替手工测试的时间 这个还算客观,但是它依赖前一个指标

好了开始做了,

第一个问题:没有环境

怎么办?折腾以前淘汰的机器定制环境(先是xp,后来统一升级到win7)

第二个问题:环境不能自动部署

工程是跟tomcat耦合在一起的;而且linux部署还不成功!!
折腾autoit,实现windows上的自动更新,自动部署(后台跟webqq做关联,qq上发个消息就能自动部署了,还能查询状态和系统信息)

第三个问题:没有测试用例,也没有可使用的数据,这是一个大坑

又话费了接近三个月的时间,才梳理出来一个关键模块的测试用例(基于BDD的)跟它的数据。中间还返工了一次,因为版本更新,用例重构了。
然后陆陆续续花费了接近两个月的时间才准备好了相关数据。制定了以后数据准备的方案

第四个问题:人员能力差

这个问题从开始就很明显!没办法,招人,一边独自做,一边招人,来来回回折腾了5个人,最后一个人稳定了两年多。中间做了不下十次培训,文档写了至少三遍

第五个问题:版本也在更新,前台重构,对应的底层控件经常出妖怪问题

这些问题,有产品自身的可测性问题;也有webdriver的妖怪问题。
导致我们架构重构了两次,并分别做了针对不同版本的适配(主要是前台控件的操作适配)

简单来说是这些,还有很多与其他利益相关体的扯皮的因素(你懂得,有人的地方就有江湖)。这样一晃接近两年的过去了。
最终我们达到一个什么效果,不到20%的覆盖率,但是效果很明显。最先实现的那个模块(功能逻辑相对固定),从两年前开始到现在都是bug最少的!

现在


虽然换个团队,换个产品,以互联网的方式设计产品,设计架构。但是考虑到成本问题,毅然决然的抛弃了UI。到目前为止只做接口测试。

啰啰嗦嗦写了不少,目的只有一个,别做收益不够的投资!

#6楼 @mic 写的很好. 是实用的经验.

#6楼 @mic very helpful,经验是最宝贵的,非常感谢分享!

#6楼 @mic 我其实很想了解别人在实现ui自动化的经验,你的回答就是我要的答案,谢谢!

#9楼 @kevin_xu_v
其实最到最后,基本上除了真实的开发业务逻辑之外,整个架构从硬件到软件,从与boss谈判到动手搬机房,从人员招聘到团队稳定建设,真真的统统摸索了一遍。在国内来说,团队不够成熟的话,ui自动化测试没有半年以上的迭代周期,可以先别碰了。

#10楼 @mic 好的,谢谢你的建议!

@mic, 赞有人的地方就有江湖。

赞同:自动化一定要证明有其存在的价值。

从我的个人实践上来说: UI自动化一定要从最简单的做起,不一定是一定要cover一个主流程。常常见到一些测试经理说,自动化cover了几个主流程(外行话)。如果主流程太长(10多个子模块交互),我想基本上一个主流程就搞死你。

我推荐的做法是:分拆,分拆成一个个颗粒度很细的小测试。
在这方面投点资还是可以的。

看到大家的讨论受益匪浅,自动化还是很有价值的,但是我这边的测试现在是分层来测试的,基本的套路是底层的单元测试,然后是接口的自动化测试和一点点ui的自动化测试以及最上层的验证测试。移动互联网迭代太快了,刚开始做比较费劲,也比较难推进一些思想的实现,不过还是坚持下来。做出了一些成果。

很多时候做ui自动化不是为了测试ui,而是为了endtoend的模拟用户行为,以此曝露用户路径会发生的问题。

#6楼 @mic 感谢分享。 UI确实是比较难搞的一块。

#6楼 @mic 移动测试的抛弃UI自动化?

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up