移动自动化测试落地的典型困惑,你遇到过吗?

移动自动化测试、持续测试已经成为大部分互联网企业对研发团队的必然要求。但理想很丰满,现实却骨感。在实施自动化测试过程中,在技术、业务、人力、管理等维度都会遇到不少难题和挑战。

下面两个真实的问题反馈,你们团队遇到过吗?

@测试K同学

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

1. 面对迭代周期短的应用,自动化的开发维护成本实在太高,那是否还有必要做自动化?

2. UI 自动化测试的产出是很少的,发现不了什么问题,那 UI 测试自动化还有什么价值?

我目前的想法是:前端 UI 和功能的测试全部手工执行,接口的测试实行自动化。

@测试M同学

关于移动自动化测试,我想大家想法都一样:不赚钱的买卖没有必要做!

说说我们的经历吧。公司技术背景是:一个传统软件做 UI 层面的自动化测试,之前没有 CI,手工打包,没有UT,JQuery 4 个版本混用…

开始做自动化测试,前先花了三个月左右(中间还有其他事情)的时间,使用 Jenkins+Ant 实现自动打包,不能算 CI,然后一个月左右开始给大领导和其他利益相关群体做“洗脑”工作。半个月之后,得到结果开始执行,但是必须要有可量化的指标:

1. 自动化测试覆盖率 = 自动化测试覆盖的手工测试用例/手工测试用例总数  

这其中有很大的问题,之前的用例根本就不是良好的用例。没有上下文,没有数据。

2. 自动化测试的价值 = 自动化测试执行的时间/自动化测试代替手工测试的时间

这个还算客观,但是它依赖前一个指标。

好了,终于可以开始做自动化测试,又遇到一连串的挑战:

第一个难题:没有环境

怎么办?折腾以前淘汰的机器定制环境(然后统一升级 Windos 系统)

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

工程是跟 TomCat 耦合在一起的;而且 Linux 部署还不成功!汗!折腾 Autoit,实现 Windows 上的自动更新,自动部署(后台跟 WebQQ 做关联,QQ 上发个消息就能自动部署了,还能查询状态和系统信息)。

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

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

第四个难题:人员能力差

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

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

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

其他难题:简单来说,遇到的技术问题是以上这些。但除此之外,还有很多其他与利益相关体的扯皮等挑战(你懂得,有人的地方就有江湖)。这样一晃接近两年就过去了。

最终我们达到一个什么效果呢,不到 20% 的覆盖率,但是效果很明显。最先实现的那个模块(功能逻辑相对固定),从两年前开始到现在都是bug最少的!

现在虽然换个团队,换个产品,以互联网的方式设计产品,设计架构。但是考虑到成本问题,毅然决然的抛弃了 UI。到目前为止只做接口测试。啰啰嗦嗦写了不少,目的只有一个,别做收益不够的投资!


听听资深测试大咖的看法

@思寒,资深测试架构师,霍格沃兹测试学院校长

以上同学写的很好,都是非常实用的经验。这里简单说一下我的个人意见,仅供参考。

1. 分层自动化

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

2. 充分利用云服务

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

3. 降低自动化的维护成本

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