年底不会有 HC 了，肯定是财年后再决定要不要扩招的，你要休息也别在这个时间点。一拖可能就是半年。当然后面真的去找也应该有机会毕竟是年轻劳动力

图像识别 + 文字识别，如果你需要验证 UI 那这 2 个方案其实也作用不大。

不是哪个钱多选哪个嘛？25 年选 offer 的逻辑改了吗？

整体到手有 40% 提升就果断去，后续跳槽这就是你的基准线了，看远一点兄弟

有需求才有价值

全链路主要是针对容量评估，接口间资源竞争有比较好的测验。像我呆的小厂，一般流量没那么大加上现在都上了动态扩容等拓展方案，在容量评估上其实没那么大的要求了，资源竞争的话也是针对可能会引起行锁，表锁的接口进行验证。所以没充足资源去做全链路把核心接口做一下问题也不大，实际情况下来也确实是这样不会出什么问题，更多是没测引起的问题。

全量回归吧，这种迁移一个方法的数据结构类型转化有点差异都是一堆问题，而且目前这种迁移大部分是用 AI 做的

挺好的

无所屌谓拉，过程中没让你产出要交接了你也产出不了啥的

我也是月底跑路，在做离职交接，内容比较多，但是你不可能在最后一个月产出这么多的文档的，日常还是要接正常的需求，所以在管理的时候你就应该有意识的产出核心业务，技术内容的文档。交接主要还是把工作心得，执行手段，这些交接出去。最后在去写文档可能这个人本身都已经忘了很久以前为什么这么做了。

第一点，所谓的走不通我感觉还是懒吧，我们现在就是全量测试用例跑，由于业态原因某个业务线的 2700 多条测试用例一次跑完要 10 分钟。已经符合部门要求，如果想更快就是加机器加并发数，拆数据维度。所以你所谓的选取类似精准测试我觉得不是万级别甚至 10 万级别的测试用例，无所屌谓就是全量就是去研究什么写法能跑的更快。

第二点，测试分工一定会导致最终维护不下去，除非这个测试人员有前进的动力。针对低代码平台我知道的大多数是没有前进的动力的，因为除了自动化用例设计（可能他们也没意识到），技术无任何提升。这就导致了恶性循环，你让他们怎么有激情有动力去做这件事情，它没有收益只有成本，这就是人性。第二点只有制度改变或者像大厂以利诱惑强制要求你这么做。不然解决不了的，自发性自驱型的人永远是少数。

已最终生产质量，和提交 bug 质量为依据，这应该是测试开发一体去看待。就像有些测试 c1 他只测业务，很少关注技术实现，性能，安全等内容。如果出个事故就会出现高风险事故。c2 测试他的测试内容和用例设计都会考虑到性能和技术实现的优缺点能够提供更大范围的优化建议。你自己就知道哪个是好的，有效的，收敛的。所以单纯看数量没啥意义。

针对 jd 做针对性的包装和学习，你工作年限少就算背调也没那么严格

哎，登录态，用户影响回归，纯 web 端，配置复杂一下就麻烦，关键 mcp 也是通过指令去驱动想想就不想搞就只能当玩具

工资太低了换一个正经的吧

我们有非代码错误，100% 成功率的要求，其实你统计出来的问题最终，还是得归纳到用你的这个平台，如何写出高可维护性的测试用例。这个目标去前进

攒好资本，到 35,40 的时候你可以有躺平的本钱，学习拓展人脉和个人能力，不仅仅是测试这个门类的。

类似接口文档，元素是一个接口可以服用给所有测试用例，测试用例只要入参就行，同时也支持模块化，提取入参，那么对应的用例调用模块时只要入参就行了，拓展和维护性就会高很多 l

先把原来的事情干好再说

哎，说了一堆没说做的效果怎么样，落地后数据怎么样，效果比传统的快了多少，稳定了多少，用例量级在多少。总之都在说工具没说业务和效果，让人看了都是在吹很虚

到最后其实更看重，你看到了什么问题，做了什么工具，给团队带来什么提升。另外纯测开出了中大厂，总有到头的时候，那到头了之后你怎么来证明你的价值，不断优化能够凑合用的工具吗？想明白这一点很重要。

现实中基本是赛马的玩法

测开只有中大厂有需求，去小厂价格贵不说，效果还真不如纯功能测试。毕竟是体力活呀

所以兜底就是人工呀，这东西我们只能调整提示词。

闭环了，因为做不了测试开发，所以就找不到测试开发的工作。30 了没累积出来确实就很难