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

meitian · August 04, 2017 · Last by 许伟栋 replied at April 25, 2018 · 2888 hits

现在我们就是比较老的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测试有什么好的方案没?

meitian #20 · August 05, 2017 作者

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

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

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

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

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

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

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

最后一句说出重点

学习了

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

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

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

孙高飞 回复

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

Sutune 回复

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

29Floor has been deleted
孙高飞 回复

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

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自动话比较实用的方案

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