从楼主现状看，要靠个人突破很难。不过能找得到社区，说明学习自驱能力还是不错的。

建议：
1、换工作，找个相对没那么闲、有挑战性一些的工作。年轻时躺平，后面的路很难走

2、基于 1，重点去准备自己的作品。现在的环境给你的项目经验基本很难有竞争力，所以你要靠你的学习能力来体现你的竞争优势，把你学习笔记、学习作品整理好，展示给面试官，如果觉得不错的甚至可以分享过来社区，说不定有伯乐看到后会赏识你。

3、交流很重要。想办法加一些同城的同行圈子（微信群啥的都行），帮下别人解决你现在学习方向上的疑难杂症。这些虽然很难成为你的项目经验，但可以作为你学习能力的有力体现，在问到你遇到的疑难杂症时至少能有一些有深度的回答，同时也帮你逐步积累圈子内的人脉和打造自己影响力，说不定别人通过你对这些疑难杂症的解决觉得你不错，可以帮你内推甚至直接招你入职呢。

flutter 打包出来的 android app ，也有包名的吧？

不错的新思路扩展，加个精便于更多人看到。

楼主先发下自己思路，抛砖引玉？要不有点伸手了。

这里的信息都只能看到朦胧的现状，看不到未来（上升通道、公司未来业务发展预期）呀。

只看现状来做选择，公司一更养老，但也很容易踩坑（比如管理岗加班少，我是不大相信的，比较高级别的管理岗基本都是弹性上班，7*24 小时 oncall ；空降一般坑更大，承受上级压力同时还得想办法打好下级关系）。

公司二看起来规模大，但那是总人数，看不出技术团队规模和技术上的沉淀情况。

如果你之前真的没怎么接触过这块，而且有意愿后续要深入这块，推荐你买本相关的书看看，帮助你快速建立一些初步的体系知识。比如艾辉老师出的《机器学习测试入门与实践》、《大数据测试技术与实践》

如果只是偶尔一两个需求涉及，那就先人工抽样检查吧。

新词还会越来越多的，这个背后有点人性使然，和互联网大厂黑话原理有点类似。你和老板沟通多了，你会发现有时候这些新词还是老板们相互沟通的常用词，你不用这个词老板反而听不懂或者觉得 low 。。。

所以，与其抗拒，不如吸收，理解清楚背后含义，然后对不同的人用不同的描述方式就好。

你这个业务其实和普通用户业务还有点区别，特征是：没有办法给出明确的预期结果。

1.检查抓取到的资讯，通过算法，打上的标签是否正确

这种地方用到的算法，有可能是通过机器学习训练得到的算法模型。这类模型是否准确，专业点说叫 “会不会存在过拟合” ，即会不会对训练的数据吻合度很高，但对新数据吻合度很低。这类算法要测试是否准确，个人理解的标准姿势应该是不断扩充更新训练集、测试集、验证集三个数据集合，保障训练出来的模型在后两个集合下一直保持好的表现。

当然简单点，也可以抽样检查下算法模型得出的标签，和你理解的（或者更好是找提这个标签需求的产品来看）是否一致，如果不一致比较多，可以反馈，要求进行优化。

如果像你说的，只是检测关键字是否匹配，匹配就打标签，那就做个单测甚至直接 review 代码，看关键字和标签的映射关系对不对就可以了。

2.根据推荐策略，测试给用户推荐资讯的准确度

这个和前者类似，准确度这玩意没有标准的衡量方式。一般最简单也最容易让人信服的，就是点击率、转化率这些相比没有推荐有没有提升（可以做 AB 测试，这样最明显）。而这块其实测试没什么能做的，最多就是自己做个小的接口测试，每次策略有更新时验证下对于接口测试里提供的咨询数据，推荐策略得出的结论是否基本一致。准确率要提升，背后更多是产品和算法工程师根据用户转化率情况，持续沟通优化。

你的想法在测试同行来看是对的，测试对质量负主要责任，但不是全部责任，这个应该大部分同行是认可的。

但怎么改变开发、产品乃至老板的看法，这才是关键。

我觉得对于兄弟团队来说，核心是怎么让他们能把控好自己这块的质量同时，不至于太加大他们负担（毕竟这不是他们岗位的核心工作职责，这个一定要认清），所以我们才常说 “质量赋能”；

至于老板，他的核心是你要保障不能出大问题造成非常大的损失，否则你就没啥存在意义了。所以你得说清楚保障质量是系统工程，而你要做好这个系统工程，目前还存在什么阻碍（比如开发甩手掌柜或者不给测试前期介入开发阶段），这些阻碍曾经造成了什么后果，进而让老板帮助你清理阻碍，来更好地帮助你保障不出问题。

赞，期待~

没怎么用过这个报告组件，我看 github 官网有留作者联系方式，建议你直接问作者？

https://github.com/TesterlifeRaymond/BeautifulReport

如果是用在单接口测试，可以直接造出前 19 个接口会产生的数据，手工/程序插入到数据库或者相关中间件里面，这样就可以直接测第 20 个接口。当然前提是你要梳理清楚前 19 个接口在干嘛，并且在他们对数据操作产生变动时，也跟着变。

如果是用在多接口测试或者流程测试，前 19 个接口就老老实实调用就好。一般这么长流程的业务，造数据成本会非常高，日常维护一些主流程的接口用于按需造数据，才能提高效率。

PS：之前在信贷业务，就是类似这样的场景，要跑还款流程就得造前面的提交资料、审批、借款三个流程才行。所以整个团队会花不少时间精力去维护整个主流程的接口测试用例，并且通过加一些参数的方式 + 包一个平台的方式，将它变为造数据的工具。

感谢分享，sonic 衍生的开源工具越来越多啦~

想问下， sib 目前有计划后续支持类似 adb connect 这样的远程连接 ios 设备功能么？

试着搜了下，搜索引擎直接就能找到有不少结果：

https://cn.bing.com/search?q=beautifulreport+%E7%94%A8%E4%BE%8B%E6%8F%8F%E8%BF%B0&form=QBLH&sp=-1&pq=beautifulreport+%E7%94%A8%E4%BE%8B%E6%8F%8F%E8%BF%B0&sc=0-20&qs=n&sk=&cvid=5139D6727F7C46BFB27685D9CA91DCC8

这些结果可以满足楼主需要么？如果不满足，请提供更多您的场景细节信息（比如你的用例是怎么写的，为啥网上的方案不适用）？

很经典的一篇文章，也是持续集成这个理念的根基所在。

参考以前圣翔写过的 wda 提速文章 WebDriverAgent tap 接口速度优化（分析篇）， wda 上耗时比较长甚至引起卡死的操作，一般是获取控件树，所以你可以减少获取控件树的频率或深度。

个人亲测在远程真机控制场景，控件树深度设置为 0，可以非常有效提升各种触控事件的响应速度，从默认深度 50 时的 2-3 秒甚至卡死，变为 1 秒内。

而且由于底层 XCUITest 获取控件树是带有推断逻辑的（个人猜测是为了应对各种 scroll view 场景下的元素查找），所以 scroll view 或者 table view 内置的元素数量比较多，也容易卡死。业务上遇到过一个登录页滚动背景，开发为了保障无限滚动，实现方式是 table view 中每个 cell 就是一个自动滚动长图，然后弄了 9999 个 cell 保障基本不可能滚动到末尾，导致 wda 获取时直接卡死。后面尝试调整为 99 个 cell ，获取速度立马提升到秒级。但这个从 ios 开发角度，table view 的 cell 是自带复用机制的，实际行数不管多少，实际渲染用的 cell 对象数量只会界面可见的最大行数 +1 这么多，所以按开发的认知，是不会觉得性能会出问题的（实际上只要不用 XCUITest dump 控件树，性能压根不会有任何问题）。

考虑到楼主不大可能让开发改源码适配，那以我个人认知，只能让 wda 控件树深度减少或者尽量不获取控件树来解决了。

再看了下正文，发现我说歪了。。。忽略我。。。

一楼是正解。不过我更建议你们 sonar 不要配置成每次构建都跑（代码量大了之后很可能增加的时间更长，研发意见会比较大，而且 sonar 质量阈不通过是不是要阻断部署，这个要和研发达成共识，要不很容易背上影响工作效率的锅），而是独立一个 job 另外做，联动 gitlab push event 自动扫就可以，不要影响研发的正常构建部署。

1、只对增量代码扫描，可以用楼上说的这个方式，但粒度只能到文件粒度，没法到行级别

2、你框里的这个不是指增量代码扫描得出的内容，而是指从某个特定时刻开始，新增的问题。这个是 sonar 内部的一个过滤器，过滤掉这个时刻前的所有问题，只记录这个时刻后的新问题，在 sonar 概念里称为 “新增代码” 。由于 sonar 的理念是只要保障新增代码质量，久而久之整个项目的质量就会上升（老代码只要被重构或者优化就会当做新代码），所以把这个过滤器放到了一个比较显眼的位置。

默认配置这个 “新增代码” 的范围，是以版本号作为起点的，比如版本号 1.0.0 第一次扫描为基线，第二次扫描开始直到版本号变更前的所有扫描，产生的代码变化都会被认为 “新增代码” ，这部分代码产生的问题会被认为是 “新增问题”。

每个项目都可以配置自己的这个 “新增代码” 范围，我们一般配置为从此项目确认开始要求 sonar 代码质量那一天开始，这天前的旧代码问题不追究，这天后新增的都要求符合统一的质量阈要求（比如不能新增阻塞级别的问题等），不符合的就要修。

个人理解：

1、获取这个比例数据，主要是给性能场景设计提供一个相对有效的参考，相对比拍脑袋或者直接都二八原则靠谱。

2、至于说每个小时都不一样这种，实际绝大部分情况下不可能真的每个小时的场景都测试，需要做取舍。你这里列举了 30 天就有 720 个场景，这只是最低效的穷举。一般情况下，业务表现一周是一个周期，工作日和周末会有较大差异，然后性能测试一般只选取高峰期的场景，假设每天都有 2 次高峰期，且周末和工作日高峰期情况差异较大算，那只需要 工作日 2 次高峰期 + 周末 2 次 ，一共 4 个场景就可以了。怎么想办法把穷举的多场景，聪明地通过尽可能少的样本来完成测试，这个本身应该是测试的基本技能，是要最花功夫去思考研究的地方。

3、最后说的线上已经有比例，为何不直接看线上表现作为性能测试结果，主要原因是性能测试场景大部分情况下是为了测试出系统的瓶颈点，线上虽然比例可以参照，但流量绝大部分情况下是不会达到瓶颈点的，所以要测试出系统瓶颈点，就必须要线下做压测才行。当然你做好压测数据隔离后，凌晨直接搞个压测直接压线上也可以，全链路压测由于环境太复杂，基本也都是这么弄的。

最后总结：

楼主的思维有点朝着 1:1 模拟线上情况这个极端走了，场景要穷举全，线上有的都要测试，那自然工作量大且看起来不可能。如楼上所说，多思考，先想清楚你的目标是什么，再去针对性重点解决。应该没有老板给的性能测试目标是穷举线上所有场景的，一般都是挑重点，只要压力最大且出问题损失最大的场景性能能抗住不崩溃，就没问题。

客气了

PS：不要叫我大佬，还没达到大佬水平。

我们兼容性测试做筛选时，基于的不是整体市场份额，而是线上埋点分析得来的用户机型分布。

市场份额看起来很通用，实际和业务匹配度不一定高，比如 3A 游戏和休闲游戏的用户，使用手机的倾向会有比较大的差异。线上机型分布相对靠谱。

想确认下，发版本都得清缓存才能用，"才能用" 指的是才能用新版本，还是才能正常使用？

如果是前者，前面已经提到了，webpack 会给打包出来的资源文件加个 hash 值，浏览器缓存一般是用文件名作为 key 的，文件名变了就不会用缓存而是去服务端拉取。至于 index 则通过加一个告知浏览器不进行缓存的 header 来完成。
网上用 前端 缓存 关键字，搜索到一篇对这个说得比较详细的文章，可以看看：浏览器缓存带来的前端项目更新问题及解决方法

如果是后者，这个就是向下兼容问题了，可以具体说下情况。

开发懒的把代码写的特别规范其实也能提升效率

如果现阶段整个团队是这样的共识，那引入意义不大。静态分析工具原理是词法分析，类似于 idea 常见的各种波浪线提示，过程中也许会发现一些写法不规范引起的、藏得比较深的异常路径 bug（比如最常见的检查做得不够引起空指针），但如果大家觉得只要测试是通过的，这些问题不处理也关系不大的话，那还不到引入的时机。在业务稳定且确认要长期发展，对质量要求更高了也愿意投入更多时间精力去处理一些短期够用长期是大坑的技术债，才适合引入。

另外，引入的时候要注意做下规则筛选，有些 “政治正确” 但实际不会引发问题的规则（比如创建的变量没用）可以先去掉，只保留会引起 bug（如没有有效判空、异常被捕获导致事务回滚无效）的规则。扫描结果逐步得到开发认可后，就可以配合 sonar 提供的质量阈，做到提测前要求扫描并且质量阈结果必须通过。

我看了你各种回复他人评论后，我的总体感受是 “你的这个方案不适合我” ，带有一点否定的感觉。所以我会觉得你想做的是寻求适合自己的解决方案，而不是纯粹听大家说自己的方案。一般看到想了解大家对于某个类型的问题都是怎么解决的，对大家评论的回复主要是表达感谢，然后再是探讨方案其优缺点等细节，甚至整理到正文里进行汇总沉淀，方便更多人了解。

所以基于我的这个理解，给出上面这个把你的被测软件情况说的更详细具体的建议。如果有理解不对的地方，可以回复说明下。

目前看到的首个支持远程音频传输的开源云真机平台，加个精。