无解，就不搞了，换个思路做好现网发布的老功能自动化、日常拨测、性能监控

有怼必回，不代表强势或不容易被拿捏。次次解释等于不解释。
不认可我的观点没关系，认为自己做事方式没问题就坚持这么干，我只负责给发帖的兄弟建议，看到的人认不认可跟我没关系，哈哈

至于评论区说的叼开发，怼项目经理之类的，都是口嗨气话，怼一个人或许过瘾，但一天怼 5 个人以上（遇到不符合自己预期的同事领导就怼），累不累呢

流程上看，你确实 “没测”，然后把问题回到本质上看，要是不以流程上的数据为准，难道信声音大的那个人吗？不单单是留痕，而是在你们项目规定的流程上留痕，如果没有流程，那就按你自己理解的可追溯去留痕（最 low 也得有个聊天截图啥的）

作为一个快 10 年的老油条，友情啰嗦一句，工作上最忌讳的是 “望文生义，自以为是”，这个自以为是不是说自己骄傲目中无人，而是所有做事都基于 “我以为，我理解，我觉得的” 前提。

要是在重庆，不知道多抢手

扎心了，老铁

用技术手段去弥补管理流程规范与企业文化的漏洞，有点吃力且效果不佳呀。个人觉得还是主推流程规范吧，没人愿意梳理那就不梳理，暴雷了该分锅分锅，问题大到一定程度才会有领导关注并授权 + 给予资源支持

我算是见识了啥叫纸上谈兵

那些前置处理脚本放在 case 层吗？比如鉴权、加密、各个项目不同规范的 header 组装等。

我们现在就是这么做的，几十个微服务模块日志查询还是比较方便，以前一个一个微服务登录上去看日志相对比较麻烦，尤其是遇到复杂问题时

我以为是用 易 语言写了段代码，结果。。。。你欺骗了我

挺好的分享

毕竟 90% 的公司，要求是表面功能用起来 OK 就行，对应到研发总监头上也不会去规范这些事情。

这个是真的赞，我们单元测试还是归于研发做，虽然他们基本不怎么做。这个工具应该能解决研发不太想做单测的痛点，已经转给他们了

我个人觉得，把测试当成餐馆的服务员或航母上的黄马甲来看待比较合适。一个技术支撑型岗位，始终为一个非量化的业务质量服务。
就像一个餐馆，服务员不会因为今天多端了几个盘子（测试多产出几个用例或多发现几个 bug），老板就觉得服务员的价值变大了，但提升整个餐馆的服务体验，光靠服务员是不行的。
也像一艘航母，不会因为黄马甲多引导了几次舰载机起飞降落，整个航母的战斗力就变强了，但不能少了黄马甲要做的事情。

拔出来的 40 米 **，被活生生地摁了回去。。。

如果是反感功能测试，去转后端研发，我不建议你急着转。即使坚持尝试，也建议做能力侧或中台类后端研发，跟构建自动化或性能测试平台这类公共类工具系统比较相通。
纯业务后端研发，我个人是不太建议你转的。测开自己做一个自动化平台 跟 研发写一个业务功能 完全是两码事，该面对的功能还得面对，只不过是从测试找问题的变成了研发写问题和改问题。好比你不喜欢汽车流水线，从检测出厂车辆变成组装汽车某个部件，你还是会被汽车流水线或上面领导的业务压力恶心到。

隆哥的一步梭哈到位，是我未来十多年改善置换的终极目标。

停的这段时间，总感觉碎片时间里少了什么，恭喜恢复

不是测试环节如何避免，而是流程机制上如何避免，涉及算法和人工审核流程的分类粒度。比如，国内主流的新闻类应用，在发布或转发很严肃的内容时，至少是算法一遍，人工两遍，但社区这类开源技术类论坛明显不可能投那么大成本。所以，只能维护的大佬们在实践中求一个相对平衡点。哎，我知道我说了一大堆废话，但个人觉得现实就是这么回事。

看来 “从质量管理出发，慢慢构建项目管理意识” 想法的人不止我一个呀，刚好今年把 pmp 过了，也不是要转项目管理，给自己留一手可能性，顺带向上游扩展视野。
现在慢慢也会去咨询或闲聊上游的业务走向与需求规划。
如果自己能用最少的人天，保证最合适的质量产出（平衡点），就算是保值属性的打工人，老板应该是乐意用的。

7 年了，有的夫妻都结了离，离了结，我还依然矗立在测试岗位上

这次特地看了是 “小道消息”，建议收集下 35~40 没有上岸的测试老兵做个分享吧，相信这个社区大部分人，几年后都得面对这份困惑，没有转行转岗，也没有上岸财务自由或管理岗位，但市场貌似快容不下这个年龄段的基层老兵了，虽然他们看个界面都能大致猜到是哪个模块在抽风

想起了那句 “5 年，5 年，你知道我这 5 年是怎么过的吗？”，大佬这是 3 个 5 年，“今天这个 bug 我吃定了，3 个耶稣都留不住”

这两天忙，才看到回复，误会，主要被上次借招聘打广告的帖子把神经挑逗起来了，我的错，我的锅