这种就只能 case by case 讨论了，一般被裁其实也没多少时间给你留着，基本就是几天内走人，这种情况也没条件做啥事无巨细的交接，肯定是要先保证自己尽快找到下一份工作。不适用我上面说的。

倒不能这么说，我对自己的职场体验还是有要求的，自己也想尽量做好一点，得到更高的评价

我在意自己的职场口碑，也想梳理自己在这家公司做做过的重要事情，我会主动完成沉淀并确保自己对这一次交接满意。

反正每天也是来工位坐着没事干，整一下这些也就顺带的，玩手机反而更无聊。

像上面的案例，如果有背调公司打电话过来了解，你也不能怪别人说不好的话。

才 20w+ 粉丝量就能收入 3w+？那百万粉丝的 up 主一个月得收入多少

整个测试行业也在发展进步，很多测试常见能做的领域已经有了标准答案，最典型的如覆盖率、自动化框架、CICD，天天写总有乏味的一天，再写也写不出什么新的东西，新的问题永远都是在实际的业务和实际的合作团队中出现，这些你要在网络上解释又很费劲没必要，所以技术文章变少是可以理解的。

深入交流更多发生在一对一，或者线下、职场内。

据我了解，外包对于甲方来说是可以随时无成本裁掉，而真正的赔偿是外包公司给你的，和甲方无关。

理论上即使你在甲方那离职了，外包公司应该还要给你支付工资。

【以上仅供参考，可靠性不清楚】

只能说这道理类似【去做才有可能成功，不做一定不成功】

运维成本要考虑电费哦，待机状态和运行状态硬件（或者就直接说显卡吧）的功耗可不一样

这种也很好玩：垃圾佬狂喜！300 块的 CPU+600 块的计算卡？组装能跑 70B 模型的 AI 服务器是种什么体验？(浪潮 SA5212M5 + 3x MI50)

技术管理速成书籍：《知行》
推荐了很多次了，不看就是亏

30+

就连研发的技术面试也得说清楚搞这个技术是服务于什么业务场景，对应到测试，肯定是同一个道理，就是搞的测试能力测试工具要解决什么业务质量问题

一般来说，组织架构调整是伴随着一定的尾部淘汰（裁员），也确实有些研发走了，但是测试都正常，目前没啥影响，就是个人负责的业务方向调动一下。最晚 9 月初，后面还是会接着给大家贡献行业动态的，毕竟我自己也想关注一下，大模型真的太强了，最近帮我解决了很多电脑装机但网上很难查到的问题。

团队组织架构调整了，最近正在变动，所以停更几个星期

为什么没有 “全链路” UI 自动化测试工具？

因为每个业务的 “全链路” 长得都不一样，中间有多少服务接口，经过多少层缓存、消息队列、数据库，服务之间彼此如何通信交流，根本没一个定式。所以从 “模块化” 的思想出发，UI 自动化就是测 UI，接口自动化就是测接口。做 “全链路” 自动化就自己用不同的工具去拼装支持不同的需求。

双周更一次，偶尔休个刊，有时候又忘发

问题范围太大了，编都没法帮你编出来

如果你还有时间和精力系统学习，就会找一些 MIT、CMU 的计算机算法公开课慢慢啃，这种方式尤其适合学生党。

但是对于咱们这种上班族来说时间很碎片化，精力也相对有限，更高效的办法还是多刷，去押题……

其实了解业务逻辑不等价于绑死在某个具体业务上。

了解的过程是业务和技术一起发展的，在理解具体业务场景后，往往对应的技术实现就水到渠成理解了，当看这种东西多了，脑海里就开始构建【什么类型的业务场景 => 什么样的技术构成】这种关系，我管这种叫 “经验”，越是高阶的人脑海里这种关系索引越丰富越具象。

而这些知识，都是可以在不同的业务间迁移的，如业务需要登录、支付、查询、写入等很多共性场景，就都能做知识迁移了。

其实在大厂数据库权限一样很严格，测试也没有数据库权限（线上线下的都没有，想要往往得走好几层 leader 的审批，得跟一堆人解释）。

这时得提前和研发沟通好，要不让研发支持帮忙看数据库数据，要不换其他的验证方式检查数据

这是好事，不是坏事。

内部逻辑才是业务根本，基本的工具都是一用就会其实没所谓，思想掌握就好。

这个表述角度好，很赞同。
【现在大部分考核制度其实就是为了把前 5% 和后 5% 筛出来而已，也就是他们根本不是为了引导你成为公司需要的那种人】
【从这个角度看，只要你和别人不一样，你就会脱颖而出（注意别整到后 5% 了哈哈），而技术上区分度相对好操作点，so~~】

从我的角度看：

• 熟悉业务不等于有竞争力。个人视角，业务 = 了解技术链路 + 熟悉产品形态 + 理解产品规划 + 掌握竞品动态。一句话说，如果给你找个技术很好的打手，你能否从零复制一个产品出来，复制出多少大概等于对产品理解多少。

如果业务技术链路非常简单，没有几个层级的上下游，也没什么历史债务的说法，代码量小场景简单流量低，对应的是业务熟悉门槛低，测试研发替换成本低，熟悉这类业务是竞争力不足的。

• 技术确实是容易突出个体差异，因为业务经验和知识的验证比较依赖一些关键场景彰显（重大需求的测试判断、日常长期的质量保障布局、问题排查现场的思路），这种彰显机会实话说确实不多。技术就很容易在日常工作体现，而且给人的印象是更长远的，比如做了一个测试工具大家会记住很久，但是你线上查出了一个问题不一定会被大家记住。

同意，面试重在务实。

不过如果是换成我，测试用例设计 可以再加多一些细节和花样，
我倾向于让候选人去说某个功能研发大概会怎么实现，需要什么要素、架构，内部之间如何交互通信，最后我想听到的是候选人的用例设计里包含了提及的这些技术实现要素，这就代表候选人真的理解这个功能。
这种测试，我可以认为 ta 只是除了代码技能不如开发熟练，在业务理解上一点都不差，如果还能说的上业务的一些产品指标和产品规划就更加分。

另一方面，我会关注候选人的整体质量保障方案，也就是除了用例设计之外，其他专项测试、灰度、监控等各方面的想法。这可以看出来候选人整体质量保障思维框架是否完整，思路是否广阔。（别说，很多人其实说完了线下测试就没有然后了）

这一套下来，就用能折腾个二十分钟了。

我理解这种问题应该不是临阵磨枪就能答得好，肯定需要思考沉淀过。

1、DNS 劫持，劫持的是运营商，和用不用数据流量没有任何关联
2、切换 WIFI，还是推 —— 这个要看你切换 WIFI 后解析 DNS 是不是还在同一个服务器，还是在的话估计没解决
3、换设备，换 ip，用 pc 打开随机推荐的博文，再看安全中转，还是有广告（不是黄）—— 这些操作应该都没关系，最终还是看你的 DNS 解析是在哪里进行

可能是被 DNS 投毒了吧，曾经的大网站，应该不至于这么干

从目标倒推过程：

1. 用例未来可维护 —— 要保存在云端且有版本管理可复原版本，不能存在本地个人电脑
2. 多人协作成本要足够低 —— 支持共享与多人在线编辑，有权限控制
3. 可追溯上下文分析其他问题 —— 需求 & bug 单关联检索展示
4. 用例呈现结构清晰 —— 使用清晰简单的树状脑图，避免使用冗长的表格
5. 用例可打标可筛选 —— 工具支持自定义标签与检索