博客的内容也搬过来帖子正文呗？跳来跳去看起来不方便。

不知道日志监控具体是指啥，是指类似 ELK 的日志统一采集和查找，还是日志错误数达到一定程度自动预警，还是别的。

楼主先明确说下？

比如运维负责环境搭建，然后测开说 ：我也会搭建环境，你 k8s 里的一个参数改成 20，系统性能会更好~，然后留下运维表面佩服内心 mmp
比如拿着代码对开发说：你这么写在高并发下回产生死锁，赶紧给我改，不改好不许下班。。如此种种

没理解，这两个可以提升质量的举措，为啥就变成抢活了？当然不是很认可里面的一些态度做法（这个场景看起来太强势和草率），但我并不觉得给运维、开发提质量保障方面的意见，是在抢活。测开去做测试的活，也应该不只做普通的用例设计、用例执行，还应该深入到技术方案评审、代码 review 等能更深入和高效保障质量的地方，否则这个开发技能就没啥意义了。

另外，你提到的这两种自动化，在我接触的不少团队里，都应该是归到高级业务测试需要掌握的技能了。测开要做的更多应该是其他对开发技能要求更高的地方（如建设测试平台），不应该把主要精力放在这里。

不过有个点确实是要注意的，那就是测试领域内的东西都还没做好的时候，不要过早跨界，先搞好测试的并能让其他角色也用上（比如开发联调用了也可以省事，开始认可），再逐步向外扩展，要不很容易会拉仇恨。

点个赞。很多时候用例评审的场景是最细最全面的，应该起到的作用是能让产品、开发等项目其他角色更完整地了解整个项目的各个场景，起到查漏补缺的作用。

见过太多产品需求没写清晰，开发自己直接脑补不问产品，最后测试发现有问题得返工的场景了。用例评审做得好，这类场景就可以提前被发现和澄清逻辑，这本身就是一种价值。

需要综合这个问题的出现概率（相同操作步骤重复跑 10 次，会出现多少次）、出现后严重程度（有多大影响，是否可以用户自行重试解决）、这个项目的质量要求有多高这些来看吧。没有标准答案。

如果整个测试过程中只出现 1 次且重试多次后都无法复现，一般作为风险报出来就可以，如果觉得还需要更严谨那可以线上加相关监控日志，持续观察。

这个有点伸手了呀，用类似 ios 获取 崩溃日志 的关键字在 bing 里面搜，搜索引擎一搜就有很多靠谱的结果。

挑了一两个看起来靠谱的（没亲测，不排除里面有不靠谱成分）：

ios ：https://zhuanlan.zhihu.com/p/336445798
android ：https://xiaotut.com/54-yy/jisuanji/36626-36626.html

有个去年沙龙活动时组的群，但日常实在太忙没空打理，有兴趣的同学可以进去交流：

第一次见到要通过性能测试估算带宽的，好奇问几个问题：

1、你这里的带宽是指分配给你服务器节点可用的最大带宽么？你用的云厂商有哪几档可以选？

2、你提供的这个信息没有提及通讯内容大小相关信息，比如你资讯是否会带有图片或视频？如果有，是从另外的 CDN 服务获取，还是直接从你服务器回传？这些才是比较影响带宽的，普通的接口纯数据不怎么占用带宽。

成都现在 it 业应该在逐步起来吧，字节在成都也有团队在，社区里也有不少成都的同学（搜索一下就能找到）。

然后这 2 家是你已经精选过觉得最适合自己的 2 家，还是广投简历只有这两家约你？如果是后者，可以耐心点，2 家的情况不能代表整个成都测试圈，多面几家才能更好地认清自己。

另外，项目经验说实话一般 1 年内的经验一般都不大会拉开大的差距，所以你要突出你的学习能力，定计划学习产出作品，以学习作品成果来展示给面试官，同时面试过程中想办法表现出自己这一面。同时也留意下，面试时一定要说清楚自己为啥这 1 年跳了 2 次（一般跳槽太频繁都会问这个，担心你进来后待不住），以及自己未来的规划到底是啥。

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

建议：
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 控件树深度减少或者尽量不获取控件树来解决了。