关注社区公众号后，底部菜单的 MTSC 大会点击就可以看到最近几届大会视频的入口。

你说的这些，本身就是价值。有一部分也有开源自己的模型出来给大家用的吧。

但现阶段 AI 各个模型还是针对性非常强的，建议可以了解下现在 AI 的一些主流算法和应用领域。对于成熟领域（如车牌号识别、OCR 识别、音转文这类）确实不少成熟的基于 AI 实现的方案可用，甚至也有抽离成了简单的 API 便于集成到任意应用中。但对于新领域（比如楼主提到的在游戏测试领域的引用）并没有这样的直接可用的方案，还处于探索阶段。

不过之前 MTSC 大会游戏专场，网易有分享过一个基于 AI 做得自动按指引做任务的实践，楼主可以看看历年游戏专场的议题了解一下。

经历过的公司，一般基础组件类的（比如一些组件）会对单测有要求，因为你单测覆盖率都给不出来别人不敢用，而且这类无界面的组件不写单测更难测试。

而业务系统的比较少，因为比较难写（大部分业务系统因为历史原因欠债严重，核心逻辑很可能在一个一堆 if else 的上帝类里，写功能都难，单元测试就更难了），而且业务变化太快、有测试人员校验，从质量角度也没有非常强的必要写。

如果你们的敏捷=不写文档和开发完直接上线，这是敏捷的典型反面教材。这玩意不叫敏捷，叫乱来。。。

工作软件胜过全面的文档 != 只要软件不要文档
响应变化胜过遵循计划 != 只要响应不要计划

人家说这句话的场景是当时大部分用的都是最传统的瀑布流，文档要写得差不多有代码那么详细（你找个政府类项目的完整文档看看就知道了，需求说明、概要设计、详细设计，每份文档都是几十页甚至过百页的文档，像写论文一样），计划一排就是排好几周而且中间不能随便变，所以才说这两句呼吁大家不要舍本逐末。你上面说的这个明显就是矫枉过正了。

也可以看看这篇文章，里面提及了几个常见的敏捷理解误区：https://www.scrumcn.com/agile/scrum/4074.html

建议做长期的职业规划的时候，不要过多考虑 领导 这个因素。有好领导是个福分，但他不可能在你持续几十年的职业生涯里一直带着你，关键还是你想下你自己未来想往什么方向走、适合往什么方向走。

对你本身性格等各种情况不熟悉，不好给建议（只看行业动向不看个人能力的职业规划，我自己是比较抗拒的）。建议你可以和你以前的领导以朋友身份吃个饭聊聊，说说你的想法，听听他的建议，这样可能会得到更好意见。

看业务情况，一般 1-2 周一个迭代，最长的不超过 2 周。迭代过程基本也和楼主说的瀑布差不多，不过这个我理解是个软件开发流程都得这么走吧，顺序大部分情况下无法调整，因为相互依赖。

另外，不知道楼主这里提的敏捷，和这里提的传统瀑布有啥差别？
敏捷的具体落地不同公司有很多不同差异的，有的地方小型瀑布（就是需求拆到 1 周内能搞完的粒度）也会认为是敏捷。

不用懵，说明你开始一步一步接触细节和深水区了。这些是成为专家的必经之路，也是差距所在。

selenium 打开的 chrome 用的模式和手动打开有点差异的，有点接近于无痕模式，可以搜索引擎详细查一下。

至于左下角这个，一般是表示焦点所在按钮对应的 url ，js 事件跳转的一般也是会这么显示。你可以对比下看普通模式下如果用 tab 选中登录按钮，左下角的提示是不是也一样是这样？

这个不是议题，是主题，也就是 slogan 哦。我现在改为 slogan 避免大家误解了。

别这样。。。受不起。。。

赞一下考古的态度。人云亦云实在太多了，里面还夹杂着别有用心的引用和传播，有很多东西其实考古一下才能真正理解前因后果。

android 的话，通过打开 https://debugx5.qq.com 应该可以看到调试菜单。

ios 没试过，不清楚。

如果你自己没找到特别需要用到 mac 的地方，不需要买。买了只会觉得没有想象中好用而已。

我自己也是用 mac 主力，windows 打游戏啥的，以前也有做过类似修电脑、重装 windows 等东西，对 windows 命令行也用得比较多。我说说我用 mac 而非 windows 的几个核心原因，你可以看看你是否有类似的需要

1. 支持全屏应用，可以专注写代码不受到各种弹窗干扰（windows 弹窗特别是一闪一闪的，真的特别干扰）
2. 不能装游戏，可以解决自己老是想打游戏的冲动
3. 续航长。不过好久没用 windows 本了，貌似现在也有不少续航很长的 windows 本
4. 基于 unix ，各种习惯更接近 linux ，比如目录结构、命令安装等。当然 windows 装个 cgywin 或者 git bash 也可以用 linux 上的各种命令，但总归有点别扭。
5. ios 开发及自动化支持。当年移动端能跑 ios 的 ui 自动化是很牛逼的一件事，而且没有现在这么完善的逆向工程能做到类似 tidevice 这样在 windows 上也可以跑自动化，加上这方面的自动化工具也优先支持 mac（有一段时间内 appium desktop 这个项目只有 mac 是全功能，windows 版被阉割了不少功能），所以当年买 mac 一大原因就是为了这个。
6. 能装逼。嗯嗯，能买苹果说明你还是有很不错的财力的，当年买了 macbook air 后有段时间开启了到处骑车去咖啡厅用电脑的习惯，后面懒得出去而且低头看电脑久了脖子疼才逐渐放弃。

PS：初入门暂时不建议 m1 ，兼容性坑还是有点大，比如 docker 虽然支持了 m1 ，且内置了 x86_64 指令的虚拟机，可以支持绝大部分镜像才有的 x86_64 指令集，但也有一些不兼容直接 core dump 启动失败。比如有些命令行软件，没法用苹果的自动转译，intel 的直接下载编译好的二进制包就能跑，m1 的还得自己编译而且处理各种编译报错。intel 就基本没这些问题。

额，你百度下怎么采集 android logcat 日志？这个日志收集并不复杂。

从耗时分布看，从发出请求给 WD Proxy 到收到返回值，基本都需要 20 秒左右，占据了绝大部分耗时：

...
2022-01-08 01:35:26:879 - [debug] [WD Proxy] Proxying [GET /element/00000000-0000-1371-ffff-ffff0000014f/attribute/enabled] to [GET http://127.0.0.1:8201/wd/hub/session/74b2d304-3843-4dba-98c2-fc0f9438be52/element/00000000-0000-1371-ffff-ffff0000014f/attribute/enabled] with no body
2022-01-08 01:35:46:924 - [debug] [WD Proxy] Got response with status 200: {"sessionId":"74b2d304-3843-4dba-98c2-fc0f9438be52","value":"true"}
...

这个耗时有点久，可以结合 logcat 日志看看到底这 20 秒在干嘛。

建议先看看你们的直播视频流的架构？

拉流是一对多（对应的是听众），一般生产环境会弄个 CDN 来提升性能和降低系统负荷。这种情况下你压拉流本质上就是压 CDN，意义不大（一般 CDN 都有单 ip 限流策略，你还没压到极限就被限流了）。

搜索 django_apscheduler 相关信息时找到的，可以参考下：https://juejin.cn/post/6844903885400702989。

好久没关注 appium 最新的文档了，没法给很具体的操作建议，只能说下可以参考的排查思路：

1、日志加时间戳，appium server 启动参数里有给日志统一加时间戳的设定的，可以加上。先把时间做下拆分

2、打印 uiautomator 内部日志。之前排查 ios 问题有见到过打印 wda 日志的开关，你可以找找 uiautomator 有没有，有的话把它打开，看 2 分钟内有什么日志，通过日志查看过程中都在干嘛。甚至你打印 logcat 也可以。把 appium 日志里面耗时比较长的 request->response 过程的日志，通过这个地方进一步拆细。

3、查看源码。如果前两步获取的信息都不够充足，无法定位，就去看源码吧，可以重点看 uiautomator driver 部分，

这段日志没有时间戳，看不出每一段的耗时呀，不好给建议。加上时间戳再打印一次？

我理解这个数据论证，想表达的意思是这个至少不是毫无根据天马行空的。数据论证不一定是做实验那种自己采集数据，也包括同行的参照数据（比如阿里的 361）、别的专家的意见等。

我倒是觉得，这个点没啥好纠结的，毕竟这个大部分管理者都很难去推动改变。反倒怎么执行好的同时不至于给团队带来太大的影响，这个才是管理者最需要花精力的。

目前是人肉，人肉审核最靠谱。

对，一切发的东西都要审核。再来一个违规就真的要关站了，宁慢勿错。

简单总结，就是不要在最末尾真的开始搞绩效的时候才来关注绩效，日常各种早会、周会等都要保持好沟通，让员工自己知道自己绩效是好还是不好。

特别是里面提到的 “在主管心里，无论怎样都是有排名的” ，深有感触。刚开始只是带小组感觉不那么明显，当带一个 15 人以上甚至更大团队时，这个会很明显。同时基于这个排名其实也可以定期自己模拟一下给团队的同学做绩效评定，这样更清晰知道自己想培养的人现在有没有培养到位（比如能不能找得到真的比较不错的项目或事迹佐证他拿到好绩效），落后的人是否有及时沟通和给予机会，有没有人自己关注太少没啥印象需要关注下的。

看下整个磁盘的空间？运行过程中需要使用的不仅仅是 docker root 的空间。

也可以参考下这个：https://stackoverflow.com/questions/44634346/failed-to-write-all-bytes-for-bisect-so

就是一眼就能看出来的垃圾信息，比如可以帮开发票这些。

这个其实已经超出测试环节的范畴了。

毕竟准确识别违规内容，这玩意相比普通的测试，更接近于机器学习里面的分类问题了，而且进一步说，因为有商业利益在（SEO 权重高，就会被利用作为推广手段），对方很可能使用到安全攻防相关手段（比如直接木马注入，跳过所有的程序写逻辑防护），这已经不是单单测试可以搞定的了。测试用例防范的是普通用户的不规范操作或者程序可能出现的异常，但很难防范别有用心用户的精心操作。比如 Log4j 这个漏洞，估计 99% 用 log4j 的人都想不到这个使用姿势。

PS：最近学习了一个冷知识 零宽字符 ，有兴趣可以去看看，很可能公司自家的敏感词屏蔽没防护到这个。