我们也是这种情况，主要针对 app 的海外多语言测试，需要关注文案是否正确、各分辨率显示是否正常，之前采用 UI 自动化截图 + 人工查看的方式，但是这种一是得熟悉各 app 的改动内容才能知道截哪些页面，二是改动发版频繁，脚本基本上都是一次性的，有这时间测试早都人工测完了，现在就是很尴尬

可以在前端区分开来，后面有时间改改试下效果怎么样

ok，现在剩下的问题就变成了如何区分用户的点击和滑动操作了，我再想想怎么搞

嗯嗯，这个后续会和开发沟通加上

第一个问题就是主控设备在操作时，在点击时自动 dump 当前页面，然后根据点击的位置从 dump 页面中获取操作所在位置的元素 xpath，然后把 xpath 发送到控制设备执行点击，是这种实现流程吗

感谢大佬指点，想请问一下获取当前操作位置的元素，是每操作一次后 dump 页面元素后，对比操作的位置去 dump 中获取吗，另外目前是基于 scrcpy 实现的云真机，所有的操作都是由 down、up、move 组成的，应该只有点击操作才需要获取元素吧，如何区分点击和滑动呢（像 SoloPi 是先拦截操作，每操作一下需要选择当前的操作类型，使用比较麻烦）

是测自己公司的产品，不过也有很多是没有 id 的 ，如果使用这种方法的话是主控设备每操作一次就自动获取一下当前操作位置的元素，然后再操作其他设备吗，感觉这样也不是很稳定吧，而且滑动这种操作怎么办呢，不同设备显示的内容也可能会有差别

目前有个想法，之前做了一个云真机平台，想增加个一机多控的功能，这样就可以供测试人员同时检查多种语言了，能提高一些效率，但是不太清楚不同分辨率间如何能实现同步操作呢，如果只是根据坐标操作感觉很不靠谱呀，还是只支持同时操作相同分辨率的模拟器呢（只有模拟器能快捷的使用 adb 设置语言，且同步操作更简单一些，真机即使是相同分辨率但尺寸不同的话同步起来还是会有差异），有没有了解相关知识的大佬分享一下这方面的思路呢

这边基本上每次测的 app 都是不一样的，脚本只能用一次，所以每次都得重新写脚本 + 调试，再加上跑的时间，功能已经可以测的差不多了

开发的工作量是不大的，工作量主要是在测试测 ui 显示是否正常这块，我这边也是只能和测试一样等开发出包之后才能开始编写脚本、执行，所以对比测试其实效率也没有提升多少

这种方式也不太现实，目前开发为了测试简单也是把一些简单的功能在 debug 里添加了，但是有些功能还是需要走流程的，没办法全部添加到 debug 里

其实像新上的 app 涉及几十种语言、十几个分辨率的，用自动化截图还是能比人工快一些的，测试的反馈也是不错，但是像日常新增一些页面或者新增几个语言的就没有人工测快了，把我去掉就失业了，公司待遇还是不错的，出去就找不到这样的了

使用 js 点击

如果不是像 appium 基于 uiautomator2 的话，应该可以安装打包生成的 2 个 apk 后使用命令启动

是的，这个命令是手动启动测试的，实际运行 appium 时会自动启动的

不是吧，看网上用的挺多的啊

解决了，是编译的 minitouch 文件有点问题

有什么其他好用的遍历工具推荐一下吗

是 webview 页面吗

已经试过这种方式了，可以切换到 webview，但是切换后获取的页面 Pagesource 和实际的页面不一样

Appium 提供的是有监听功能的，可以在 github 上下载该项目的源码https://github.com/appium/appium-uiautomator2-serverappium\node_modules\appium-uiautomator2-server\apks 目录下的两个 apk 文件；如果是 7.0 以下版本的手机需要修改 bootstap 的源码替换掉 appium\node_modules\appium-android-bootstrap\bootstrap\bin 目录下的 jar 文件，然后自己修改源码添加监听，打包后替换掉