showcase 就是给大家当面演示一遍主流程，一般是用来传达核心功能已经准备好

1. 既然他都说是复制粘贴性的迁移逻辑，这么简单的事情为啥还要测试来测问题，他敢不敢直接上线？
2. 【研发主管的说法是 show case 等于帮测试执行了测试用例，测试就不用工作了，因此拒绝 show case】这观点可太强了，没见过这么头铁的，给我整不会了

另外说个笑话，我刚毕业第一年那会，公司内有个工作六七年的开发，还是那种比较爱钻研技术受其他开发敬佩的类型，他当时多次表达过这么一个观点：【技术方案没必要和测试过得太细，不然测试的思维就变得和研发一样，那就测不出问题了】。现在回想，简直放屁。

你这么说倒也是

我自己就接到三次不同前同事的背调电话，当然别人都跟我提前打好招呼了

这种就只能 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~~】

从我的角度看：

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

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

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