我没写过 appium espresso 脚本，但我感觉这应该不是，讲道理应该会调用 java-client 的 api 才对

应该是 appium push apk 到手机的时候失败了，你往前追一下 appium 日志看看

谷歌没有这样的工具，只能自己撸。主要是大家对 appium 的使用基本停留在 UIAutomator 上，对 espresso 的开发和了解不多

因为 espresso 是侵入式的测试方案，获取到的信息是真实的控件信息，而不是由系统解释了一层（UIAutomator 就是这样的），所以兼容性好啊

再给你推荐一个方案，用你原来的方式找控件，找到后，拿到这个控件的区域，然后用 monkey 去点

是的，使用 espresso 的话，整个控件树的信息跟 uiautomatorviewer 完全不一样了

那跟普通的非视频类的 app 没啥区别吧，只是点击下详情页里面的东西，啥 ui 自动化都可以做，比如 appium

开发也一样啊。

名言：

1. 代码写得好，bug 少，看起来像一个闲人
2. 注释多，解耦好，代码清晰，任何人都可以替代。
3. 代码写的烂，每天风风火火改 bug，各种救火，解决线上各种大问题，于是顺利成章成为公司不可替代的人才。
4. 代码乱只有自己看得懂，是公司不可替代的人才

关键是你想测试什么功能点，ui 自动化就那些

看到这个 unauthorized，我第一反应是设备未授权，设备连上 pc 后会弹个授权框，没点吗？

据我所知 appium 官方 api 不支持这种操作的。

如果对 appium 改造下，是可以的。
主要改造 appium-espresso-driver 里面的 espresso server，可以对 webview 做类似 page speed 的专项检测。

看这错误是 app 启动超时了，你确定模拟器上安装 app 成功了吗？手动打开能打开吗

tap 其实就是 click，看源码：

register(postHandler, new Click("/wd/hub/session/:sessionId/appium/tap"));

public class Click extends SafeRequestHandler {

    public Click(String mappedUri) {
        super(mappedUri);
    }

    @Override
    protected AppiumResponse safeHandle(IHttpRequest request) throws JSONException,
            UiObjectNotFoundException {
        JSONObject payload = getPayload(request);
        if (payload.has(ELEMENT_ID_KEY_NAME)) {
            Logger.info("Click element command");
            String id = payload.getString(ELEMENT_ID_KEY_NAME);
            Session session = AppiumUIA2Driver.getInstance().getSessionOrThrow();
            AndroidElement element = session.getKnownElements().getElementFromCache(id);
            if (element == null) {
                return new AppiumResponse(getSessionId(request), WDStatus.NO_SUCH_ELEMENT);
            }
            element.click();
        } else {
            Logger.info("tap command");
            Point coords = new Point(Double.parseDouble(payload.get("x").toString()),
                    Double.parseDouble(payload.get("y").toString()));
            coords = PositionHelper.getDeviceAbsPos(coords);
            final boolean res = getUiDevice().click(coords.x.intValue(), coords.y.intValue());
            return new AppiumResponse(getSessionId(request), res);
        }
        Device.waitForIdle();
        return new AppiumResponse(getSessionId(request), true);
    }
}

是的，appium 使用 UIAutomator 的时候其实还是调用 UIDevice 来做 click 的，它会参考 clickable 这个值去，如果是 false，那就失败了。可以改 appium-android-driver 中 bootstrap 的代码，click 都基于坐标去点击，就是复杂点

是的，类似 UIAutomatorviewer，因为 espresso 获取到的控件信息和 UIAutomator 的不一样了

UIAutomator 只是 appium 中的一种技术方案，espresso 和 UIAutomator 是同一层次的东西，你可以去了解下

最佳的方式当然是改造 appium 啦，就跟监控权限框一样，参考我 testerhome 专栏，但这个方案应该不适合你，比较复杂。我推荐是写在脚本中，开一个线程去做这件事。

不定时出现的弹框写个监控去做，全流程测试过程中每隔几秒检测一次（异步）

方案 1：如果是用 espresso 来做的话，这个叉叉是可以准确识别的，没有识别不到的情况
方案 2：native 识别 + 图像识别互相补充去识别这个叉叉，兼容性取决于图像识别的能力，难度较高
方案 3：相对识别，先找到上面的大控件，再往下找这个叉叉

查找算法是算法，但 native 控件的话，你只能基于 UIAutomator，你们或许用了辅助功能，利用 accessbilityService 来做，但兼容性跟 UIAutomator 是一样的，UIAutomator 背后的原理也是它。非侵入式的控件定位，绕不过 accessbilityService，那就绕不过兼容性

对于 solopi，我的疑问有几点：

1. 识别控件的兼容性怎样？
   native 控件定位采用的是 UIAutomator1 或者 2 来识别，兼容性是很差的，尤其对 h5 页面特别差，而基于 chrome dev tools protols 可以弥补，因为它其实本质是类似 webui 的测试，是 js 取控件的，所以会比较准，但要使用这个技术，要么这个 webview 是 x5 内核（手动开启调试），要么就是自己应用开启 debug 调试模式，才能去做。至于基于图像来识别，看了相关的视频，感觉还不错，我之前在 testin 做过一段时间，简单的还是比较好识别的，但图像不具备特色就比较难识别，并且在不同手机上，图片颜色可能都不太一样，对上百台设备乃至上千台设备，识别控件的准确度会怎样？不知道有没有实际测试过验证过。图像识别在我看来只是一个补充。

2. 一机多控稳定性怎样？
   看着是通过 socket 连不同的手机，有主从之分，这个 socket 会不会被系统干掉导致连接断开

3. 能否支持持续集成？
   这个很重要，有没有一个方式提测让设备随时能够执行任务，能否配合 Jenkins 做定时任务呢？

虽然有很多疑问，但我还是觉得 solopi 是一个很不错的工具，在无线自动化上的探索已经做的很好了（虽然我不认为无线自动化是一种很好的方式）

你们原来用的是 UIAutomator 或者 UIAutomator2 的吧，RN 是基于 webview 的，你用 espresso 来做，可以把它想象成 webui 测试，另外你们需要编写一个获取当前界面信息的工具

我就是技术远远大于业务能力，但我认为技术都是为业务服务的，最终肯定是业务结果大于技术结果，因为最终业务做的好才是真的好啊。
但如果技术做的好，可以大大减少业务负担，提高做业务的能力，提高公司测试效能，也是一个重要的考核。

业务结果是考虑的现在的结果，而技术考虑的是未来的结果，技术是可以成倍增长的。

我们应该把现在的业务做好，在技术上不断精进，不断探索，不至于以后可能拖了公司后腿。

不是写的很清楚吗错误，io.appium.settings 已存在，INSTALL_FAILED_ALREADY_EXISTS