公司产品有 IOS、Android 、H5、小程序、公众号，如果做 UI 自动化，尽可能的少写代码，比如一套用例代码，可以用于多端测试，还要考虑后续的维护成本，可以封装成 PO 模式，目前在尝试用 appium 和 airtest 分别进行尝试， 想请教一下大家，有没有类似的解决方案，尽可能少写代码，覆盖多端。
RF
如果你有 H5 的话，建议你整 airtest，安卓/IOS 的内嵌 H5，airtest 可以把页面转化为原生方便你定位元素。
如果多端页面逻辑和 UI 一样，可以一套用例多端共享，只需要把初始化过程和定位元素参数化出来就可以，我们就是这样做的，我们用的 Appium，主要是因为我们是 3 年前开始搞的，那时候 Airetest 没有 Appium 合适，现在可以俩对比着调研，看看哪个更合适自己的项目
在明确选择这么做之前，想先问问业务多端的 ui 本来就是完全一致的吗？我猜肯定是不一致的，不然为什么不直接上类似 flutter 等跨端语言，而是要每个端都专人写
如果业务本身多端就不一致，这个选择就是巨坑，坑的还是自己
爱摸鱼的小狐狸
回复
好的，大体可以理解：命令行传参区分环境，然后页面里元素定位应该是维护了多套吧，但是用例是一套，用例根据环境，选择 diver 和元素定位执行，对吧
王稀饭
回复
你说的很有道理，我们客户端用的 flutter 加原生，IOS 和安卓是一个开发，所以我觉得，页面应该是统一的，可以做成一套；H5 和小程序，是其他开发，估计还要做一套
xpcs
回复
各种实操经验，但凡是不一样的人来开发就必然会引入差异，所以可能最后变成：
- Android 和 iOS 部分自动化可以复用，但还是不少地方要分开维护
- H5 和 小程序就各做各的
我觉得可以这么去考虑：
- 是不是一定要做 UI 自动化才能解决现在的质量或效率问题？
- Android、iOS、H5、小程序，在明确了不存在一套代码全部覆盖的前提下，还是想要全部都做，精力应该不允许，故哪个端综合考虑流量大、风险高、历史问题多的，就应该先做哪个端
- UI 自动化无法做很重，UI 频繁变更决定了其维护成本高，哪个公司哪个业务都一样，所以有些质量问题得考虑结合其他手段解决，这些手段可能是什么？
，这样双端都通用了，UI 自动化也发现不了什么问题的，随便搞搞就行了
小黑子-祖国人
回复
妥当，只是考虑 C 端产品多，可以考虑介入，我们本身有接口自动化，但我想的接口暴露不出 UI 的问题，比如接口通，前台点击没有调用到接口等等。
王稀饭
回复
妥当，的确要考虑成本和效率问题，我们本身有接口自动化，但是产品都是 C 端，所以我考虑通过 UI，能暴露一些 UI 方面的问题，多谢，我继续调研一下发版频次和线上问题，看看做哪个端合适
xpcs
回复
是的，如果从收益角度看，站得住脚的逻辑可能是：
- 先分析哪个端的 ui 问题多，并且这些 ui 问题能用 ui 自动化解决（这部分就是预期收益）
- 再来说我要在这个端做 ui 自动化，并且还能使用有 ui bug 的版本，来验证新做的 ui 自动化的确能发现过往的 ui 问题（这部分会比较难，事实上往往做的 ui 自动化还真不一定能把历史出现过的问题都拦截住，就看老板认不认吧）