现在我们就是比较老的 appium 加 po 模式的做法。维护成本高，而且 UI 没有一个好的运行的时机，也并没有一个好的产出。
想问下大家，有没有什么好的 UI 测试思路，在测试流程中什么时候介入测试？具体的一个应用产出是什么样的？
—— 来自 TesterHome 官方 安卓客户端
我们也在做这一方面的探索。有的时候也比较迷茫，做 UI 自动化是否是正确的方向。我们天天听到大家说做 UI 自动化，有说做 UI 自动化逼格高，有说做 UI 自动化装逼，投入产出比差，很少有听到人说 UI 自动化效果不错的。我猜这部分效果好的人肯定是偷偷地乐呢。从 qtp 到 webdriver，从 robtium 到 appium，每个时代，UI 自动化都是吸引人的技术，这就说明 UI 自动化是值得投入的，为什么这么说？一，UI 自动化是最接近用户行为的自动化测试，用户不会直接调用接口，也不会把看你的代码，他们就瞎几把乱点。二，自动化看上去比手动有含金量，对于测试工程师而言，会 UI 自动化是不错的加成。三，对于利益相关方，UI 自动化是最好的 acceptance testing。
那么关键就是如何把 ROI 提高了。首先，不仅要对业务熟悉，而且要对用户的行为熟悉。通过业务分析，系统分析，找出哪些容易出错的路径；通过埋点数据归纳出，哪些路径是用户最常用的。把这些整理成自动化用例，然后用你最擅长的语言和工具组织成自动化用例，扔进 CI，产出最简单明了的报告。让所有的自动化用例都是有的放矢，而不是为了自动化而自动化。
然后就是维护了，所有好的架构随着时间的推移，代码的增多，都会变成一坨屎。所以最好的办法就是一口子挖个深井，然后之后就是小维护。那样子会轻松很多。当然遇到那些假敏捷的天天换 UI 的流氓开发，就别搞自动化了。
同问，我的自动化脚本特别不稳定
维护成本高，没有好的运行时机，还没有好的产出
请你告诉我你们做 UI 的意义何在，还不如去搞接口
做 UI 先得考虑你的 app 是否合适，是否已经到了比较稳定的阶段，然后就去考虑应用场景，比如用于主流程回归、冒烟等，其次是用例方面的选择，这些都考虑好了，就要考虑易用性，比如集成到 jenkisn 一键执行，方便其他测试同学使用。
至于所说的维护成本高，我觉得只要是做 UI 就得做好成本高的打算，而且 PO 其实已经使维护成本降到比较低了，如果你说开发三天两头就改个 UI，那我不得不说你们的 app 是真的不适合做 UI，不要为了 UI 而 UI，想楼上所说的接口自动化更适合你们。
敢于发声啊，把接口测试、皮下测试搞起来
现在不都大多前后端分离了么，把 restcontroller 测起来比什么都好，浏览器用少量的 js 单元测试配合 sikuli 玩一玩兼容性就好了
我觉得我们公司的 UI 自动化做的还是不错的， 当然了我们只有 PC 端的，用 docker 把 grid 容器化后扔到 k8s 集群里去跑。 30 个浏览器并发的话 20 分钟就跑完了。目前覆盖了大部分的分支，只有一些不适合做 UI 自动化的和边边角角的功能手动做。稳定性也不错。 一轮下来误报的在 10 个以内，版本验收的时候有好几次是 100% 全通过的。 我们也并没有花大量的时间去维护 UI 自动化的东西，当然我们 TO B 的产品迭代慢，变化不是特别快，业务也相对稳定，前端过于复杂，bug 有一半集中在前端。所以我们的自动化测试以 UI 自动化为主。这也算是一个业务优势。 我说一下做 UI 自动化要注意的几个重点。
- UI 自动化要跟 CI 走，在迭代进入联调时期 (或者是开发自测时期) 的时候监控开发分支 (注意是开发分支)，这时候不是为了找 bug，而是要及时调整脚本，应对 UI 和业务变化。 我们要在提测一开始就输出一份提测质量报告，甚至是提供一份冒烟自动化脚本给开发人员作为提测标准输出。如果在提测之后还要花大量时间修改自动化脚本的话，意义就不是很大了。
- 做 UI 自动化的人要懂设计，懂业务。 UI 自动化不是一个简单的 page object 就完事的。可以说所有自动化测试类型中 UI 自动化是最考验工程师的业务能力和代码设计能力的。根据业务的特点去设计代码结构，抽象共性，封装复用。我们不是写 demo，我们是要支持成百上千的 case，所以设计很重要。这也是为什么我觉得相比 python，java 是更适合的测试语言的原因之一。 这也是为什么我之前写的帖子里就说过设计模式很重要的原因之一。拥有良好的设计才能做到最大程度的代码复用，才不会再需求变化的时候麻爪，才不会花大量时间跑去维护测试脚本。
- 为了维护稳定性，多用自旋等待，异常捕获和重试之类的功能。有的 UI 自动化框架有这些 api，如果没有就自己封装。 不能有太多的误报率，否则又是维护梦魔
ycwdaaaa 大神总结的恰到好处
看评论
我们应该就是传说中 当然遇到那些假敏捷的天天换 UI 的流氓开发，就别搞自动化了。 ----自动化没法搞，只搞了接口
- 去年刚进公司的时候就是主攻 UI 自动化的，中间一度有段时间比较迷茫（包括技术问题与业务问题），年初借鉴了社区一些文章与开源框架，有了一个 UI 自动化的雏形，所以我觉得首先坚持是最重要的
- 其次说到 UI 是否有收益，那答案是肯定的，同意@Lihuazhang的说法应该从线上用户使用率高的页面入手进行用例设计
- 最后希望看到更多好的 UI 自动化思路分享，小白当怀抱好学之心
还不如手工 + 半自动化的工具做。
ui 自动化效率实在低。
你说技术含量的话，自己设计开发半自动化的工具不比 ui 自动化调调别人的工具接口技术含量低。
只不过最早一批人带错方向了，所以你现在搞自动化而不是半自动化。
APP 端的 UI 测试有什么好的方案没？
#1 楼 @Lihuazhang 同意找准业务路径，觉得 case 并不一定越多越好
—— 来自 TesterHome 官方 安卓客户端
我之前搞的 Ui 注册登录和新手引导的，结果用了几次后，大家基本不用了。这个要看时间投入和公司是否支持。
Ui 首先还是要分层，举个例子，如果你最终环境在线上移动的，可以不用在内网模拟器或者其他 build 环境做 UI 层的
介入时间是在前端不改版和稳定后。
应用的产出主要在于回归界面，接口层通无法代表用户按这个前端流程去点击一定会通。有可能某个纯客户端的按钮没了或者点击无法响应就无法进行到下一步了。
没有好的产出的话，可能就不是平台或者架构的问题了，可以从另一方面考虑，自己的产品适合不适合这种 UI 自动化
比如我们的产品在界面交互、功能上都会有比较大的更新迭代，如果全面介入 UI 自动化，就会出现需要一个独立的部门去专门的维护，成本很高，我们都是通过通过测试，内部试用、用户内测的方法就达到产品质量的保证
我们也是从接口测试开始的，毕竟接口更新的速度远远低于功能了，维护成本会相对低很多
我觉得关键还是看形态适合不适合，适合到什么程度，UI 做到什么程度，想达到什么目标，否则的话，可能投入很多，得不到产出
最后一句说出重点
学习了
我们公司，研发的领导很重视这个，觉得 UI 自动化能降低线上 bug。
然并卵，一周改一次版。UI 自动化天天报错，再好的设计模式跟代码都是白搭，自动化天天都要维护，苦不堪言
所以，UI 自动化在我们这很难有产出。如果你们那界面不怎么变的，可以考虑搞一下吧。门槛也低，但是话说回来
不怎么变的系统，是否还需要有专职的测试维护？
所以大部分公司的测试都是为了晋升或者面试，瞎搞一通。
目前 pc 端和手机端的 UI 自动化都在搞，楼主的原理是什么坐标吗还是控件 id
很多界面本身就是 1 个 URL，还好吧。
自动化还是要用录制的，然后录制后加点检查点和状态机（没有什么不稳定和顺序问题是状态机搞不定的）
https://testerhome.com/topics/5006 推荐下 ATX
孙高飞
回复
关于多浏览器并发跑测试，有个问题请教大神:
举例 300 个 case ，case 和 case 间并发的时候产生的数据冲突 如何避免呢？
例如 A 用例测试产品促销的修改生效，B 用例测试产品税收的价格正确，那么 A 和 B 如果并发执行的时候偶尔选中同一个产品了, B 用例的断言就会被 A 用例给干扰....
也想过几个解决办法, 比如用 Docker 做多套测试环境，或者测试数据通过 SQL 动态查询获取符合条件的 之类的解决办法，但是都有痛点，并不是太能解决...
。。。。。。。。。。。。。。。。。。。
求指教
许伟栋
回复
你好，打扰一下，请问你说的当时借鉴了社区一些文章与开源框架，有了 UI 自动化雏形。请问这个雏形是怎样的？我最近也开始弄 UI 自动化，我目前了解到用 Appium，结合 PO 设计模式，不知道有没有更好的方案？
