我也遇到过两任奇葩老板，但不至于这么离谱，虽然老板奇葩好歹多多少少还是有些收获（就是时间有点被浪费，本来可以有更多收获）。
工作越久越感觉选择大于努力，跟对业务、跟对老板，才是最重要的事情，只要这两个选择对了，很快就能兑现到一些收获。

我的观点：

1. 测试左移理论上是正确的，而且优秀高效的测试团队确实在不同形式实践测试左移的理念 —— 但是往往实践不会和理论一模一样，会做一些删减；按照测试人数被压到较少的常态现状下，需求都是倒排的形式插入，测试多数以配合交付为主，确实没有人力在需求最早期就参与进去的，属于心有余而力不足；如果真的能做到这种程度，我个人倾向于认为是外企、国企，或者很成熟的行业才能这么考虑人力利用。

2. 不做测试左移，或者没做好测试左移，不代表测试团队能力不足（作者没表达类似观点，我属于插播）—— 测试左移只是保障质量的其中一种手段，搞质量需要先认清当前测试人力容量，在能以至少及格分水平支持需求交付的测试之外，再额外做一些中长期对质量有改善的工作，包括但不仅限于流程改进、度量运营、灰度发布、线上监控、研发构建效率等很多不一定是传统测试领域的事情。测试左移可以适当投入，做到 70 分程度 ROI 就不错，如果要做到 80 分甚至 90 分，必然有边际效应。

3. bug 数作为绩效考核，听闻很多公司都会用这种办法去衡量产出，至少在大厂里对外包也会做 bug 数的横向对比以考虑某外包是否留下（还会结合该外包经手的需求质量）；可以说它粗暴，但是不能说明它不合理。因为想把它做得很合理是要成本的，当 “这个成本 超过 拍脑袋决定绩效 导致的损失” 之后，就显得无足轻重。所以它确实有问题，但除非能提出更好的办法而且足够低成本，不然…… 那就忍受

有些 SRE 团队确实是不配 QA 的，东西都是他们自测上线…… QA 资源不是所有团队都会配置，尤其是很多内部不直接面向外部用户的系统；至少我司在以前是没有 SRE QA 的，不过现在我记得是有了

是楼主理解错，还是我理解错。

tps = Transactions Per Second

Total Througput 就是吞吐，随着线程数一直提高（相当于请求总量也提高了），服务器那边有性能瓶颈达到上限了，所以 Transcation Response Time（不是 tps）的 95 分位数在升高，我感觉很合逻辑。

身边有类似的案例，但还没去到这种程度…… 我的建议：

1. 所以谈话保持全程录音，并保证对方说话要说完整，以便未来取证
2. 细看劳动法，防止自己被对方钻空子搞，也要去钻对方的空子；在合法完成工作的前提下，多出来的准备面试
3. 如果自己耗得起就硬刚，耗不起的话还是认栽尽快跑

实话说，运维系统团队还不一定有配测试呢……

别说磁盘空间不够，业务增长导致表唯一 id int32 位不够用出问题都见过……

原来标题的【一线】是指一线城市……单看标题还以为是逆天言论，测试竟然还可以不在一线

先坚定思想

IT 是一个挺卷的行业，这个行业很多人进来并不是自愿，而是因为相对其他行业稍微高一些的工资，所以大可不必去模仿大佬的生活，你自己的生活如果已经想清楚该怎么过就怎么过。

并不是每个人都可以逼迫自己去持续学习，对于你自己来说，所谓的【进步】也不一定非得是技术上的精进或升职加薪才叫【进步】，而是适合你自己的，让你的生活往下一个你更喜欢的状态去推进也是【进步】。

优秀的 IT 从业人员大多数也是因为热爱这个行业、热爱技术，既然楼主对技术不喜欢，或者说至少不感兴趣，那就没必要继续苟下去浪费年华。尤其是这种想离开/有退路的想法一旦种下种子就会一直发芽。

我的建议

废话不小心说太多了。当你产生这个想法并且上来论坛问，其实就代表着离开的想法已经足够壮大了，回老家考公上岸是很不错的选择。不然就是去个很稳定的国企外企继续过日子，但是得考虑被裁的长远风险有没有足够的资金应对。这个时候空闲下来多看看老家有什么机会，对应这个机会你要储备什么，然后针对性地学习（比如你要考公那就要学考公技巧和刷题）。如果你自主学习动力不足那就果断报班，永远不要高估自律能力。

有几个点其实深究就很难解释清楚：

1. 会做好自动化，会干性能测试，会分析性能问题 —— 这里的 “会”，到底去到什么程度？是因为熟悉业务所以有经验，还是因为技术思路、排查实践都很熟练？这里面前者并不一定通用，后者才是通用的硬实力，有时又要两者结合。所以 “会” 实在很难下定义
2. 一个增删改查的开发，多多少少也创造了产品，如果没有这些开发，连能给我们测试的东西都没有。所以谁是第一创造者，谁的钱更多也无可厚非……

1. 如果线下就能拦截所有 bug，那为什么还需要小流量、灰度、众测这些东西？有多少个团队能在线下发现全量 bug？还是说产品太简单……
2. 片面追求线下拦截所有 bug，要考虑人效和能力（是否允许足够长的时间测试，是否有足够多的 bug 发现手段），你的组长能拍出这样的决定，证明他对这些东西没考虑全面
3. 有些 bug 在当下迭代不会出问题，随着未来的用户量级提高，用户环境会越发复杂，或者未来某个代码变更触发隐藏问题，这种 case 那个组长怎么判断？又该不该扣绩效？

如果只会追责到人，不会分析事情本身，打绩效如此粗暴，证明这个组长水平有限。我建议是换老板、换团队、换公司任选一个。

云原生那本书有没有机会上到社区的积分兑换里面？

表示被 openssl 这玩意儿的版本坑过好几次，记得有两次是编译 python 源码，两次是装 ruby 环境

这个过程中，个人最难的还是用例的持续维护，要面对诸如人员离职、架构变动、工作调整等一系列主动/被动变化带来的影响，对应的用例运营机制一定要明确、可执行可管理、考虑严谨。一旦维护跟不上就有破窗效应，越做越烂，最后被放弃。

感觉自己没有资格留言，来围观一下

就这个具体案例，那你可以同一个全局变量来保存这个 id 值，查了一下 pytest 有个叫 pytest-ordering 的插件可以控制用例运行先后顺序，然后在后置用例里再检查全局变量是否有值和可用，不可用报错，可用就正常跑这样。

基本原则是用例之间不能耦合。

如果一定要这么搞，你就只能在依赖数据的用例里，加判断去看前置数据是否准备完毕（这个判断可以是一个全局变量，可以是一条数据库标志性数据等），如果前置数据没准备完，要不阻塞，要不直接跳过不跑（但是显然都不合适）。

个人建议的做法是，把前置依赖的那块数据 mock 好，这才是正规做法；也可以让他们合并成一个用例一起跑，至于怎么合并就看你实际用例怎么写

那大概是因为不需要做什么也能水涨船高跟着往上走吧。顺风舒服，逆风翻车，管理要做好真的需要一直绷着一根弦，要十分清醒不能松懈，即使事情规划得很好，但还是依赖到下面的人能否有效执行，还要兼任一定程度的过程管理，确实累。

我赞同楼主的说法，所以从很早开始我自己就思考过这个问题，在测试职业一直走，职业生涯无非就是成为测试技术专家或者成为测试团负责人（也就是管理者）。

日常有很多机会给我观察不同的管理者，有的是只有 20 个正式员工出头的一线管理者，有的是上百个正式员工出头的二级管理者（就是老板的老板），甚至还曾经有机会看到带领上千人的质量部门的负责人，和他们一起开会，或者在他们附近的工位短暂工作。

这些观察给到我的共同感受是：

1. 管理者的时间是碎片化的，越是接近一线的管理者会越碎片化，非常要求时间管理能力
2. 要保持刻意自主的辩证思考，脑海里要不停在演化推导想法，思考的东西包括但不限于某个事故分析、团队大方向规划和质量布局、下面的人做的各种事情是否符合规划框架、团队人员分工是否合理、不同人的 scope 是否清晰，大家的发展路径是否明确……
3. 能一针见血直达本质，时刻保持敏锐的数据嗅觉，同时有自己的渠道去了解到真实的一线信息，不容易被下面的人忽悠

总结一下，管理者的核心工作无非围绕着做什么拿到更好的业务结果、做什么沉淀出更好的不依赖人的标准能力、做什么让团队整体以及下面的每个个体有更好的发展。但往往会有很多杂事在打断这些核心工作，所以对于管理者来说，必须要十分清楚自己此时此刻正在做什么，做这个事情是否有意义，对时间使用层面的容错会更低，意味着要有更多的自我意识和技巧。

我自己权衡一下，感觉还是搞搞技术来得更容易……

所以你的关键就是【担心的是很难出彩影响晋升加薪 以及后续跳槽相关】

回到我给出的三个反问，如果这些基本信息没有，没法去理解你的现状，也没法去定义 “出彩的工作”，是需要上下文的。

没特殊情况一般都给，只是看测试是否主动索取而已，不问别人当然就没想到要给啦。

不过，大厂的外包是看不到代码的，要额外申请其他权限；正式员工就正常申请，一般都给过，很少会卡，除非代码很机密。而我当时，因为业务涉及内部安全，也不是所有代码都给我看，有些还是私下找关系好的开发要才给我，开发团队的老板还不想给测试看……

没什么信息量，暂时给不出有效建议。我反问几个问题：

1. 新公司自动化正在俺不推进的计划是什么？
2. 新公司目前自动化推进到什么程度？
3. 为什么觉得未来出彩的地方不多，是什么原因让你没把握？

有点太广告化了，建议补充一些详细使用说明，或者技术原理说明

我是直接把代码库拿过来看，当时是用 php 的 yii 框架。

如果一定要自己识别，那就只能谷歌百度查了，这些大概是 web 渗透需要知道的操作。

转成开发也能叫转行吗 这应该叫平移

同问，转行做啥去了