被标题吸引进来了，思路确实是挺特别的，基于 app 内部提供的 router 组件统一跳转机制，达到跳转到任意页面的能力。以前我们公司内的 app 架构师也有分享这个，通过 router 来把各个页面组件进行解耦，提高复用性。

有几个疑问点，想交流下：

1、这种 router 提供的能力，主要是 app 部分的，但进入页面后请求服务端数据，还是需要依赖服务端。一般服务端数据也会可能因为有其他人操作导致变化，会引起无法正常回放，这块是怎么处理的？
2、从楼主分享来看，自动回放/遍历方面主要关注 crash/anr ，而这种跳过所有前置步骤直接进入目标页面的方式，会不会导致一些长时间运行才会出现的问题或者组合页面才会出现的问题（比如对一些公共层数据的操作），无法出现？
3、不知道楼主在标题特意强调的 "AI" ，指的是哪部分？微信的文章也看完了，没太看到在哪里运用了 AI 。

这个工具以前所在公司别的团队调研分享有看过，当时有小范围使用，但后面也没有深度用，不知道有没有什么暗坑。

而且这个工具不开源，且比较商业化，大部分公司还是更喜欢免费开源的工具。

get，已记录 issue

你可以去一些沙龙大会看看，大部分用的是 mac 。我说下我选择 mac 的几个核心原因：

1、稳定。我的 mac 几乎天天都用，但一年也就只会因为磁盘空间不足或者要升级系统关几次机，其他大部分时间都只是合盖休眠。这样能确保我每次不用再逐个打开各个软件（日常工作一般都是好几个 idea + 浏览器 + 聊天工具开着），节省时间，思维也比较容易恢复。
2、续航强。windows 本续航能跟上 mac 的，价格基本都比 mac 贵。
3、触控板超好用。我现在日常都用触控板，鼠标基本都不怎么用了。借助触控板 + 全屏应用，能让我更专注在当前工作，不会频繁被消息打断。

看你预算，预算够 16G 内存更好，预算不够可以 8GB，或者直接看官方翻新版，一般同配置官方翻新版可以便宜 20% 左右，而且也可以免息分期。

佩服可以面 30+，手握 10 个以上 offer 的。我毕业到现在累计面试过的估计都没 30 个公司。

开源工具平台的系列文章，默认只加精第一个哈。你可以在第一个头部加上其他后续文章的链接成为一个合集。
后面有干货更足的解析文章，再加精。

感觉有点标题党。我理解的 “轻松搞起来” ，应该是某种机器学习通用套路的介绍，让大家对机器学习的认识能大道至简，快速上手？文中的介绍，感觉对学习机器学习没太大的实际指导作用吧？下面推荐的几本书，都属于专业书，不确定大家入门是否适合。西瓜书以前有看过，对于一个高数已经还给老师的我，前三章都迈不过。

也这个地方分享大家一门我看到过觉得比较不错的机器学习的教程，google 出品的机器学习速成课程，有视频、有文章、有在线练习，学起来比看书要容易记忆。据说本身设计就是用来给内部非机器学习的技术人员快速用上机器学习的，不过内容其实也蛮多的，每天 1 小时，得坚持快 1 个月左右才能完全看完第一遍。

你们这个问题，在于在团队在性能方面专业度不足、无法达成团队共识的情况下，对于性能测试相关决策，没有明确可以拍板的人。产品明显不具备能力，开发和测试意见又相左，甚至开发内部都有两种不同的意见。

解决也不难，看按照你们公司现在的情况，线上性能出严重问题要背锅，是谁来背，然后这个背锅的人/角色来拍板就可以了。拍板的人觉得现在大家都不专业，性能测试做了也没啥意义（对于你目前这个团队情况，我觉得性能测试做完，线上仍然有性能问题这个可能性确实是有的），干脆一刀切全部不做，通过线上监控 + 云服务的灵活伸缩来处理，也是可以的。

当然，从完善的质量保障角度，性能测试肯定不能全部不做，所以可以后面多给开发产品普及下性能出问题影响业务的案例，以及在后面真出事故后，复盘里增加对故障涉及接口的性能测试，这样来逐步推进。

这个问题如果是正面回答，就是自动化两个语言都可以用。至于哪个更广泛，如果单纯按从业人员数量，python 更容易上手，数量应该更多。

但我觉得哪个广泛实际并没有意义，个人理解你的关注点不是统计意义上的 “哪个更多人用”，而是和你切身利益相关的 “哪个更能让你找到好工作” 。所以，建议你要关注的是你的目标公司用的是什么语言。实际上更多人的选择是 主力深入一门，然后另一门也会写或者可以随时快速上手。语言这东西，很多思想其实是相通的，测试用到的大部分场景其实不涉及语言特性（如 java 语言特有的的字节码增强技术），所以深入掌握一门后，要上手另一门主要是语法做一些切换，比从零学习一门语言会快很多。写前后端分离的平台，前端还得用 js 呢，不也一样得学到够用为止？

也从我个人角度，分析下实际用 python 或者 java ，背后的逻辑，仅供参考：

python：上手快，语法相对简单。但因为公司内部自研的开发框架或者平台很少用（互联网大部分开发用的是 java ），所以对接开发框架时会比较麻烦，遇到问题开发也比较难协助。属于短期收益高，长期收益比 java 低一些。

java：上手慢，语法相比 python 要复杂一些。但和开发语言相同，对接开发框架非常便利，而且遇到技术难题也非常便于寻找开发协助，甚至写脚本学会 java 后，还能增进阅读开发代码的水平，产生比做自动化更大的收益。所以属于短期收益低，但长期收益高。

这可能也是为什么大部分测试技术做的比较深，和开发框架平台对接比较多的公司，选 java 的比例会高一些的原因吧。

可以发下你收到通知的截图？有可能是你关注的人有上来回复了，也会收到通知。

我意思是，我不确定你现在一直去纠结 “怎么把第三方 app 的控件 id 做到多设备一致” 这个，是否是你现在真正想达到目的的最佳方案。

android 并非所有控件都一定有 resourceId ，采用 resourceId 也无法唯一指定界面的唯一元素。resourceId 的设计用途不是给 UI 自动化用的，而是给开发人员快速标识某个特定 view 控件，便于在程序中引用和操控的。从这个用途出发，不见得所有 view 都要加 resourceId（程序不引用就没必要加了），也不见得一定唯一（比如多个控件样子一致，也可能直接用一样的 resourceId ）。详细介绍可以看看这篇文章：https://sharrychoo.github.io/blog/android-source/resources-find-and-open

现在可以确定的是，“把第三方 app 的控件 id 做到多设备一致” 是一个技术成本不低的方案，毕竟第三方 app 对你而言是一个不可控的东西，只有你适配他，不可能他适配你。从更低成本解决问题角度考虑，此时应该就要再回去重新想清楚最终目的是什么，是否必须要用基于控件的 UI 自动化这个方案来解决，接口爬虫、直接录制回放型的自动化工具是否可以考虑。但你一直没说明你的最终目的是要做什么，所以也没法给你更有效的建议了。

挺中肯的文章，受教了。

搜索引擎搜了下，你看看这篇对你定位有没有帮助？
https://www.cnblogs.com/king2/p/13867816.html

也附上搜索姿势，如果上面的不合适可以继续找
https://cn.bing.com/search?q=gitlab+webhook+jenkins+expired&form=QBLH&sp=-1&pq=gitlab+webhook+jenkins+expire&sc=0-29&qs=n&sk=&cvid=06D4FD1C188840AC875826F4E8AA8048

我看日志，应该后面重试后成功了，现在这日志也看不出错误原因，建议再持续执行多几次，采集更多数据再分析定位吧。

加精了，期望后面更详细的分享。

error: more than one device/emulator

这个报错一般出现在连接了多于一台 android 设备上，运行 adb 命令时未明确设定设备的 udid 时。你看下你自动化脚本是不是没有指定 udid 给 appium ？

熟练这个定义确实比较虚，个人理解一般是能把变成思路直接转化成对应的代码，并且里面用什么函数之类的都清楚，不用各种搜索引擎辅助为佳。

放到面试考察这个场景：
如果是为了面试回答问题，可以去看看常见 python 面试题，把答案都弄懂。
如果是为了笔试，leetcode 选几个难度为低的，用 python 手写代码（不用 idea 辅助，也不搜索引擎查函数用法）试试，能做到手写出没 bug 能运行的代码应该也算。

http://testerhome.com/opensource_projects/sonic
这个我这边收到的你提交项目的地址，你看下是否有权限可以改？

默认审核未通过前，是不会出现在列表中的。

1、你看下评论框右下角的 排版说明 ，你的 markdown 排版格式不对，所以内容展示不了。
2、请按照 下拉框非下拉截图、下拉框非下拉状态的 xml 控件树、下拉框下拉截图、下拉框下拉状态的 xml 控件树 四个顺序来发吧，现在只有一个 xml 片段，一头雾水。

1、匿名专区，所有发帖人 + 评论人，都是用的匿名账户，非真实账户。只是为了便于区分，避免大家误以为是同一个人在自问自答，所以从以前统一都显示为 匿名用户 ，改为了系统自动生成随机用户名。
2、如果想要非匿名，也可以勾选评论框的 “显示名字” ，这样系统就不会进行匿名处理。比如我这个评论，就是非匿名状态。

还是没懂你这个场景。如果是做爬虫或者机器人点赞评论这类路径比较固定的自动化，完全可以走接口，没必要走 app？就算由于接口加密或者自研传输协议导致你无法走接口，那是否可以考虑按键精灵之类的直接录制脚本？分辨率不同布局不同，那就不同分辨率分别录一遍就可以了，安卓主流分辨率也就那几个，没多少成本。

UI 自动化的所有优化设计，都是围绕着 “控件操作” 来的，之所以要围绕这个，原因是为了降低多操作路径情况下的长期维护成本，提高控件的复用性。如果你本身操作路径就不多，直接录制回放投入产出比更高。

然后关于第三方 app 控件在不同设备上 id 不一样的，你确定用 resourceId 无法满足么？前面已经提了，你的 nid 本身不靠谱是根本原因，不要基于这个现象下 “同一个 app 在不同设备控件定位方式不通用” 这个结论。

只有你一个测试，意味着你对测试的认知很多都是来自于非测试的同学，这个会有点危险，会导致你容易存在 “你以为需要这个经验/技能，因此花大量时间准备学习，但实际大家需要的并不是这个” 这种思想误区，导致努力方向错误。

建议你不用等明年，现在立马就可以开始投简历面试下，能不能面到另说，但至少让你清晰你离自己心仪的工作还缺什么，方便自己做针对性提升，确保方向正确。

PS：如果能拿到 offer，建议去至少 30 人以上的测试团队，这样规模的团队一般都有人才梯队建设，对没经验的应届生更友好。不过对应的这类团队的招聘标准也比较高，面之前要好好做好准备。

麻烦发下完整的 appium log 内容？你截图里的报错是 session 长时间没有收到新命令后，appium 服务自动关闭 session 时的报错，对应的并不是你第一个截图里的脚本操作，所以这个错和你那个脚本对应的执行内容没有关系。

测试人员应该有自己的判断，但这个判断是否可以变成团队决策进行执行，取决于整个团队的沟通结果。至于哪些做哪些不做，核心就是看出性能问题的风险和测试成本对比，同样是测试先判断，项目团队沟通决策后执行。

你这个例子里，你做出了你的判断，这个是好事。但只是一个开发人员说不用，你就放弃了，没有把你的判断推动到整个项目团队决策（产品 + 开发 + 测试），所以你这个放弃有点太轻易了。