Appium 大家公司的 UI 都是怎么做的?有没有什么好的产出?

meitian · 2017年08月04日 · 最后由 许伟栋 回复于 2018年04月25日 · 1178 次阅读

现在我们就是比较老的 appium 加 po 模式的做法。维护成本高,而且 UI 没有一个好的运行的时机,也并没有一个好的产出。
想问下大家,有没有什么好的 UI 测试思路,在测试流程中什么时候介入测试?具体的一个应用产出是什么样的?

—— 来自 TesterHome 官方 安卓客户端

共收到 37 条回复 时间 点赞

同问,我的自动化脚本特别不稳定

维护成本高,没有好的运行时机,还没有好的产出
请你告诉我你们做 UI 的意义何在,还不如去搞接口

做 UI 先得考虑你的 app 是否合适,是否已经到了比较稳定的阶段,然后就去考虑应用场景,比如用于主流程回归、冒烟等,其次是用例方面的选择,这些都考虑好了,就要考虑易用性,比如集成到 jenkisn 一键执行,方便其他测试同学使用。
至于所说的维护成本高,我觉得只要是做 UI 就得做好成本高的打算,而且 PO 其实已经使维护成本降到比较低了,如果你说开发三天两头就改个 UI,那我不得不说你们的 app 是真的不适合做 UI,不要为了 UI 而 UI,想楼上所说的接口自动化更适合你们。

敢于发声啊,把接口测试、皮下测试搞起来
现在不都大多前后端分离了么,把 restcontroller 测起来比什么都好,浏览器用少量的 js 单元测试配合 sikuli 玩一玩兼容性就好了

ycwdaaaa 大神总结的恰到好处👍 👍

看评论

我们应该就是传说中 当然遇到那些假敏捷的天天换 UI 的流氓开发,就别搞自动化了。 ----自动化没法搞,只搞了接口

  • 去年刚进公司的时候就是主攻 UI 自动化的,中间一度有段时间比较迷茫(包括技术问题与业务问题),年初借鉴了社区一些文章与开源框架,有了一个 UI 自动化的雏形,所以我觉得首先坚持是最重要的
  • 其次说到 UI 是否有收益,那答案是肯定的,同意@Lihuazhang的说法应该从线上用户使用率高的页面入手进行用例设计
  • 最后希望看到更多好的 UI 自动化思路分享,小白当怀抱好学之心😀
孙高飞 回复

30 多个浏览器都是同一个浏览器吗,有做兼容性的测试吗,不同浏览器的

adonisjph 回复

可以啊,grid 一开始出来的时候,大家都是拿它做兼容性测试的

孙高飞 回复

我的意思是国产浏览器也可以的?

adonisjph 回复

那个我可是没试过😂

孙高飞 回复

所以不担心兼容性的问题吗,我最近被搞死了,国产浏览器的自动化没找到好办法

adonisjph 回复

俺们做 B 端的,不做 C 端。所以你懂的~~~

还不如手工 + 半自动化的工具做。

ui 自动化效率实在低。

你说技术含量的话,自己设计开发半自动化的工具不比 ui 自动化调调别人的工具接口技术含量低。

只不过最早一批人带错方向了,所以你现在搞自动化而不是半自动化。

APP 端的 UI 测试有什么好的方案没?

#1 楼 @Lihuazhang 同意找准业务路径,觉得 case 并不一定越多越好

—— 来自 TesterHome 官方 安卓客户端

我之前搞的 Ui 注册登录和新手引导的,结果用了几次后,大家基本不用了。这个要看时间投入和公司是否支持。

Ui 首先还是要分层,举个例子,如果你最终环境在线上移动的,可以不用在内网模拟器或者其他 build 环境做 UI 层的
介入时间是在前端不改版和稳定后。

应用的产出主要在于回归界面,接口层通无法代表用户按这个前端流程去点击一定会通。有可能某个纯客户端的按钮没了或者点击无法响应就无法进行到下一步了。

没有好的产出的话,可能就不是平台或者架构的问题了,可以从另一方面考虑,自己的产品适合不适合这种 UI 自动化
比如我们的产品在界面交互、功能上都会有比较大的更新迭代,如果全面介入 UI 自动化,就会出现需要一个独立的部门去专门的维护,成本很高,我们都是通过通过测试,内部试用、用户内测的方法就达到产品质量的保证
我们也是从接口测试开始的,毕竟接口更新的速度远远低于功能了,维护成本会相对低很多

我觉得关键还是看形态适合不适合,适合到什么程度,UI 做到什么程度,想达到什么目标,否则的话,可能投入很多,得不到产出

最后一句说出重点

学习了

我们公司,研发的领导很重视这个,觉得 UI 自动化能降低线上 bug。
然并卵,一周改一次版。UI 自动化天天报错,再好的设计模式跟代码都是白搭,自动化天天都要维护,苦不堪言

所以,UI 自动化在我们这很难有产出。如果你们那界面不怎么变的,可以考虑搞一下吧。门槛也低,但是话说回来
不怎么变的系统,是否还需要有专职的测试维护?
所以大部分公司的测试都是为了晋升或者面试,瞎搞一通。

目前 pc 端和手机端的 UI 自动化都在搞,楼主的原理是什么坐标吗还是控件 id

孙高飞 回复

你们公司产品是 PC 端的, 是那种桌面程序软件吗?为啥 UI 测试是用浏览器跑测试用例?求解释。

Sutune 回复

PC 端的浏览器,BS 的,不是 CS

29楼 已删除
孙高飞 回复

并发运行用例会用到多线程或多进程吗?

Sutune 回复

就是多线程,testng 里能配置的

恒温 回复

通过埋点数据归纳出,哪些路径是用户最常用的。把这些整理成自动化用例——这个好赞。天天换 UI 流氓的应该是产品,不是开发吧?哈哈哈

萤烛 回复

。。。开发也喜欢

很多界面本身就是 1 个 URL,还好吧。
自动化还是要用录制的,然后录制后加点检查点和状态机(没有什么不稳定和顺序问题是状态机搞不定的)
https://testerhome.com/topics/5006 推荐下 ATX

孙高飞 回复

关于多浏览器并发跑测试,有个问题请教大神:
举例 300 个 case ,case 和 case 间并发的时候产生的数据冲突 如何避免呢?
例如 A 用例测试产品促销的修改生效,B 用例测试产品税收的价格正确,那么 A 和 B 如果并发执行的时候偶尔选中同一个产品了, B 用例的断言就会被 A 用例给干扰....
也想过几个解决办法, 比如用 Docker 做多套测试环境,或者测试数据通过 SQL 动态查询获取符合条件的 之类的解决办法,但是都有痛点,并不是太能解决...
。。。。。。。。。。。。。。。。。。。
求指教

李晨 回复

你想复杂了, 每个用例用独立的产品就行了。 或者给这种会造成冲突的 case 设置执行顺序。

许伟栋 回复

你好,打扰一下,请问你说的当时借鉴了社区一些文章与开源框架,有了 UI 自动化雏形。请问这个雏形是怎样的?我最近也开始弄 UI 自动化,我目前了解到用 Appium,结合 PO 设计模式,不知道有没有更好的方案?

测试生 回复

我这边是自己小打小闹,pageObject 的形式应该是 UI 自动话比较实用的方案

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