一字不拉的看完了，和楼主一模一样的状态；为了不让自己处于迷茫的状态，目前我是按照这样的标准执行的：
1、工作中：对内总结梳理团队中不足的地方，规范和提高测试组项目中各环节的流程和输入输出规范，提高测试效率；对外不断宣传和同步质量意识（不是每个人有全员质量意识的概念的），这部分是循序渐进的过程；
2、生活中：给自己报了个测试开发技能学习班，拓展不一样的测试技能和视野，除此之外，把更多的心思用在小孩的教育和陪伴上，固定时间和自己的家人联系和慰问。
总而言之，不要胡思乱想，不要让负面和颓废的情绪影响到自己，人无完人，接受不完美的自己，对于工作和生活，都应该同等的对待，我不愿意把所有的精力都给了工作，我爱工作，但更爱自己的家庭

如果非要走技术、自动化测试技术这条路，现阶段，一定要记得：CI/CD、DevOps，孤立的自动化测试就是屎，毫无价值
不能从全流程提升研发效率、不能有重心的提高产品质量或发布效率，自动化测试做的再好，也只是自嗨，无法赢得开发、产品的尊重和信任

互联网前后的变化

楼主开篇也提到了在进入互联网前后经历的瀑布式和敏捷式的开发模式。 我也是工作了 7 年半的人了，经历过楼主描述的过程。 先讲述一段关于小故事吧。 小步快跑，试错迭代的思想在上个世纪漫威的崛起中就已经有成熟的应用了 (我是漫威迷 )，斯坦李可不是一口气直接创造了漫威宇宙。而是在一开始尝试性的创建了有性格缺陷的神奇四侠。在斯坦李的笔下，石头人敏感易怒、霹雳火轻佻自负……超级英雄终于不再是高高在上的神话故事，而是一群有血有肉的普通人。(不同于 DC 的超人蝙蝠侠神奇女侠，他们几乎是完美的) 这种设定迅速激起了年轻人的共鸣，《神奇四侠》大受欢迎，拯救了处于垂死边缘的漫威。随后，斯坦李用这种更加贴近人性的配方，开始用流水线大规模地生产超级英雄。斯坦李一个超级英雄一个超级英雄的试错，一点点找到大众更喜欢的角色。 然后 1940 年的一期漫画，海王和霹雳火在漫画 pk 了起来，漫威的超级英雄第一次有了交集，之后是美队和霹雳火和那摩等集结打纳粹。再然后漫威宇宙一发不可收拾，原著中的内战涉及的超级英雄之多令人咂舌。漫威宇宙 2000 多位超级英雄就是这么被创造出来的。 跟大家说漫威的故事就是想说明这个模式。这种小步快跑，试错迭代的思想被充分的利用在了互联网里。 因为它能更快，更有效率的找到用户更需要什么，如果漫威一开始就设计一个恢弘庞大的漫威宇宙，那它当初早就被 DC 干死了。 尤其是在互联网中竞争对手无处不在，抢时间抢用户抢地盘。慢一步，步步慢。 当初阿里云诞生之初把评估的工作排期直接压缩了 2 倍，誓师大会上所有人喝酒宣誓，3 月前必须上线。 所有杭州团队的人直接飞北京，光差旅费就花了百万以上，没需求文档没设计文档什么都没有，沟通全靠吼。就是要快，当初的目的就是赶在腾讯云之前上线。如果慢了，很可能就没有现在阿里云的传奇了。 所以在这种商业背景下，传统软件的研发模式必然是淘汰的结局。 这是互联网对传统研发模式的打击。 同时互联网对传统软件公司也造成了一种降维打击。即便是我们这种 TO B 业务的公司，也或多或少的走这种模式。因为你慢了，你就死了。

所以在这种背景下，像以前一样那么长周期的测试活动肯定是不会存在的了。TO B 企业还好一些，互联网就完全是快节奏。 所以才需要大量的自动化来缩短测试周期，也许这时候的测试是不完全的，但这时候的测试是能满足用户需要的。测试人员需要转换一种思维，就是我们的目的是做一个能满足用户需求的产品，而不是一个完美的产品。 经常能看到一些开发吐槽，比如都什么时候了还在这跟我提这些无关痛痒的 bug。这就是测试人员还活在自己世界中的表现，也是没有产品意识的表现。 一个成功的技术团队 (包括产品，研发，测试，设计等) 要有一个共同的目的，在这个共同的目标下，所有人都要互相妥协。 最后的产出，就是各方为了这个目的互相妥协出来的。 所以像以前那样，质量部门产品部门研发部门互相独立的团队很难存活下去。 现在已不是单打独斗的时代。 相比测试思维，我们更加需要团队思维，整体思维和产品思维。

关于测试人员规范流程的事

根据之前说的，测试人员要跳出纯测试的框框来，从整个团队考虑。 测试人员介入流程规范，约束开发这个事其实没毛病。 有能力就可以做。 我的测试 manager 现在兼职管着 PMO 的事，管着 TS(技术支持) 的团队。而我现在是 CICD 的 owner，老大了我一帮子比我技术好的研发人员做为我的资源让我搞。 产品上，所有关于 k8s 的需求和设计由我组织，甚至好多需求是我本人提的。 运维上，一些 k8s 和 hadoop 集群也是我和我同事在维护。 你看我们的工作涉及到了多少非测试的事？ 不止是 QA，我们的研发多少跨界客串一把产品人员的， 客串一把交付人员的。 我觉得一个好的团队是不会给团队划分固定角色的，谁有能力做，谁有时间做，谁愿意去做，那谁就可以去做。 每个人都有自己擅长的领域。 那在自己擅长的领域里跨一把界，是对团队有好处的。 比如我们这种技术架构这么复杂的产品， 有些模块，让研发人员去做产品的角色就是比产品人员自己搞来的高效，正确。

关于测试人员背锅

关于线上出问题了以后让 QA 背锅，这个是要分情况的，要 case by case 的分析，但这种无脑背锅的事倒是存在的，一个不成熟的团队会有这种不成熟的思维。 质量是所有人的，不是 QA 的，有时候该怼就怼。 做 QA 要是还怕得罪人，还玩个蛋了。

关于测试人员的技术

这个楼主去面试的时候是碰到不太好的团队了。 做到不懂代码的人员也可用的这种思维是无奈之举，一定是团队中不会写代码的人太多了。 没办法而为之的。 但基本上这种关键字驱动框架我就没见过有人做好的。 最后规模大了都是维护噩梦。 只能测测业务层，而且是小规模的。 case 多了能累死人。 一个测试人员追求技术是没毛病的。

至于开发人员吐槽你一个测试跟我们聊什么技术。 那还是因为测试的技术没有给他们带来价值，不信你来我们公司看看，会有人吐槽测试的技术么？ 技术不在于有多高明，而是它能为你带来多少价值。 当你的技术能力，产品能力，团队能力达到了一个点的时候，就会呈现出爆发的姿态。

关于思维

我一直建议测试人员跳出测试活动这个小框框来，往整体上看，往产品上看，往团队上看。 思维跳出来以后就会发现，你可以为了产品质量做很多很多事。 不要为自己设限。

发现你真的很善于总结，由于激动我的内容写毫无重点，你竟然剥丝抽茧的将我的所有疑问都解答了，谢谢你的分享，我想要的答案你都给我了，复制下来，没事的时候看看，和开发吵架了就读一遍，和产品有争议了就读一遍，背黑锅了也读一遍，我们的目的是做一个能满足用户需求的产品，而不是一个完美的产品