可以参考我之前帖子里面应用 Jenkins 多配置的分布式执行方案，但是前提是每个用例是独立的，不能存在依赖关系

弹出微信支付，切换到 Native 就可以用元素定位了

元素

可以的

docker-machine 目前已知唯一方案

感谢各位大佬的回答
1、从实施难易程度与预期落地效果来看，14 楼的方案跟我们团队的目前的流程差不多，在流程管控方面，我们做了测试 coder review、开发交叉 review 环节进行卡点
2、技术层面，增量代码扫描，覆盖率统计，实施起来有一定难度，还需要不断学习

问题是开发提测的时候夹带私货还不同步，你说气人不

夹带私货，不同步。
像代码改动少的情况，通过 codeDiff 很容易看出来，但是需求改动比较多的情况，一次涉及十几个文件，就很难判断了。

感谢解答
我们现在也是靠人工管控的，通过 codeDiff 的方式判断影响范围，但是对于代码基础薄弱的同事不适用

就是字面意思，跟本次需求无关的，都属于。
比如开发之前上线任务遗留的 bug 处理，看到别人写的代码不爽就做了优化等等

p30、p20 都可以定位到，mate20pro 就定位不到

我也遇到过，有些手机能定位到，有些就定位不到，所以果断选择了坐标

底部导航栏可以切换到 NATIVE 去定位，实在定位不到还可以用坐标操作

有条件查询数据库的，还是建议通过查询数据库进行校验
1、有些入库字段查询接口是不会返回的
2、查询接口返回的数据是经过处理的，比如枚举，比如兜底逻辑，这些都是经常出现问题的
所以数据库入库校验非常有必要的，当然没条件，只能通过查询接口了，建议跟开发一起确认好字段入库情况。

不兼容的

是的

看起来像是内嵌 webview
1、如果使用 XPATH，需要切换 context。（APP 内嵌 H5 还要开启 webview 调试）
2、airtest 基于图像识别可以快速搞定这种布局形式，如果都是类似的情况，强烈建议使用 airtest

666

1

建议用 chrome inpsect 试试，或者在代码里打印一下 context，看下 appium 实际获取到的 context

会不会是在 APP 里返回非 webview 页面，webview 实例没有销毁

对于接口回归测试而言，环境对比维护成本更低，而且更准确，前提是有不同环境

疯了，这个勾上就 OK 了，折腾两天了

allure-results 这个是使用的默认地址，但是我报告文件不再这个路径里面，报告的路径是动态的，需要做参数化，之前在 ubuntu 都 OK 的，现在在 windows 上就没效果了

之前在 Ubuntu 上应用的没有问题