测试管理 我们是否应该开展 UI 自动化测试

Dillon · 2018年06月15日 · 最后由 Dillon 回复于 2018年06月29日 · 23 次阅读

慢慢的,写了 5 篇文章了,从最初的觉得自己既然开始了,就得坚持每周写点东西。给自己总结,若是还能给别人帮助,那么就太好了。到现在突然发现貌似周四周五的深夜,喜欢思考,静下心来想想得失,然后把文章写出来,挺高兴的。

当然我应该是做不到一周一篇文章的,我首先还是把这件事情,当成对自己的总结、提升。其次,确实是非职业再做,更不想写烂文章。

这篇文章,想和大家聊聊,我们是否应该开展 UI 自动化测试。

当然,如果我们广义上认为只要是 UI 层的都算,比如 Monkey 测试、各种专项测试等等,那么答案还是一定要做的,但这次我是想聊狭义上的,只是针对 UI 层的功能自动化,我们是否应该开展。

近 10 年的测试工作,我经历了 3 家公司,都是总公司在北京,分公司在我当地的城市。二线城市,大厂很少。从第二家起,我开始真正涉及到 UI 自动化,并从学习到维护框架到搭建框架。

第三家公司,领导特别重视UI 功能自动化,注意我说的是 UI 的功能自动化,并非其他自动化。反而我在经过了这几年以后,对 UI 自动化已经从最初的热情、激动,变为现在的平静,甚至冷淡了。

我们在第一篇文章说过,UI 自动化是投资最高,收获最低的,详见第一篇文章内容:我们应该如何推进测试体系建设 —— 技术推进篇

自动化层级体系

不知道有多少公司真正把 UI 自动化做好了,假定我指的是覆盖率很高,比如80%以上。那你说,这公司、这产品、这版本,得多稳定啊。

首先,我们既然聊到这了,还是把 UI 自动化的开展思路和大家聊一下吧。

1,通过代码方式实现框架,要么自研,要么直接使用开源

2,使用开源软件进行工具级别投入使用,少量自己开发,基本无代码

下来我们聊聊这 2 个方面

1,代码方式

好处:灵活、定制化高、可锻炼人员能力

问题:需要大家掌握代码,起码达到用例编写级别

2,工具方式
好处:对人员能力要求低,基于成熟工具可达到量产的地步
问题:工具本身可能存在限制,过于依赖工具本身,也可能无法解决某些特殊的问题

补充,所有工具其实都是为了一个目标,即:降低人员要求,提高团队效率

这里我们顺便提下 2 款 UI 自动化测试工具,Robot Framework,Katalon。 太细的不多做阐述了,尤其是Robot Framework,知道的人太多了,这里我们简单聊一下Katalon

最近笔者在进行测试人员的面试时,一个面试者提及的,下来专门看了一下。确实不错,总结以下几点:

1,能和 CI 集成,且很简单(这个是极其重要的)
2,Web、App 均可以
3,无代码,易学习

附 2 张图,图 1 是官方放出的 Katalon Studio vs. Open source frameworks 的直观对比,图 2 是 2018 Top5 的自动化测试工具,通过这 2 张图,你会发现 Katalon 确实是值得学习并且投入使用的

Katalon Studio vs. Open source frameworks

Top5 自动化测试工具

最后,我们还是聊聊到底 UI 自动化该怎么开展。细心的读者到这里已经发现我们说的和标题不一样了。这里我们解读下区别。

1,应该开展 UI 层面的自动化,但不一定是功能的;
2,如果要做功能级别的 UI 自动化,首先应该把 API 层做的比较好了;
3,我们要结合公司当前现状,发版节奏、需求变化、产品生命周期等等综合因素一起确定。

如果你要做,那么我们聊聊应该怎么样让他产生价值:

1,优先挑选稳定少变的模块覆盖;
2,选择重点场景进行覆盖;
3,不要仅按照功能测试用例的步骤实现,而是要按照功能测试用例的一个 suite 为单位进行实现(设想如果一个用例有 10 步,你实现了其中 6 步,你认为覆盖率是 60%,其实是 0%。。。因为你少了 4 步,这个用例还是得需要人工执行);
4,框架设计一定要好,这里面包括几点:
4.1 用例分层
4.2 数据分离
4.3 模块公用
4.4 元素分离
4.5 数据驱动

试想了下最后的效果,应该是这样的,或者不能比这个次。

每天晚上服务器部署后,按照模块 + 场景执行 API 测试 → 按照模块 + 场景执行 UI 测试 → 进行各项专项测试(当然,2 和 3 的顺序不一定一样),然后大家第二天上班,就可以看报告分析结果了。

共收到 10 条回复 时间 点赞

总结的满好的,特别是框架设计的几个要点,深得我心 😄

目前,我的开源框架 Sweetest,也满足这个需求 https://testerhome.com/opensource_projects/sweetest

感觉单元测试是收效最高的,可是写的人又不多

UI 测试维护起来成本太高了,前端改个元素,你就要改好几个用例。。
而且现在各种前端框架生成的页面,元素也不太好查找,写用例很麻烦

赞,喜欢这样的文章

你框架做的再好也没用,如果产品每周迭代,ui 是变化最快的,金字塔模型已经说的很明确了,ui 自动化应该是投入最少的

最近也看到了 katalon,发现也是非常不错,也 google,度娘了很多,发现资料确实少,官方文档也看了,英文不好,楼主能分享下心得,或者一些学习的资料吗??

jierong01 回复

其实我没怎么实践这个,只是学习试用了下,确实还不错,我们之前是公司自己写的框架,只是真觉得 UI 不要太花精力搞,真有技术,搞一些专项测试,然后帮助落地 CICD

Dillon 回复

请教一下,你说的专项测试具体是指哪些呢?性能?API 自动化?

Dillon 回复

9494 做 CI 比较好。

Dillon #10 · 2018年06月29日 Author
donly 回复

比如 APP 性能测试,卡顿测试,内存泄漏,比如 APP 深度 Monkey

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册