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

先坚定思想

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 渗透需要知道的操作。

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

同问，转行做啥去了

实话说，我自己发现的很多 bug，最后排查下来更多靠研发，因为完整的代码和本地调试环境都在研发手上。

不说最有成就感，说最有印象的俩 bug，是生涯前两年自己执行自己设计的测试用例发现 bug 后，对着研发的代码做 review 帮他们定位出来，并告诉他们怎么改。还记得一个是 php 后端少了参数类型和值的校验，一个是 go 做哈希值判断写错了大于小于符号。

我之前的老板，05 年本科毕业，大概 08 年进入在腾讯，应该在腾讯呆了约十年出头，可以说什么互联网移动端红利吃个透了，单腾讯股票就不知道赚了多少钱，生活富足美满，出来工作也就是继续保持收入，根本不打算和在座各位卷，该什么时间下班立马跑路。

但又能怎样？每个行业都有这样的幸运儿，选择大于努力，而选择要做对又需要一些运气，如果看不透这个行业外的机会，还不如老老实实沉淀自己，以免过几年回头还后悔当年没有好好做该做的事情。

如果有实际可行的想法，当然建议跑路也是要趁早。

以自己写可控、定向的脚本为主。
自动化遍历有理论可行性，但是遍历到的页面不可预测，不同的校验点在哪里（如哪些文案有可能超长、哪些地方有可能翻译不对等），确定性不够强。

裁测试的逻辑我感觉就 2 个吧：

1. 看研发测试配比，研发要减员，测试自然也要减员，这个定律在任何互联网大厂都通用。一般是大环境不好，要无差别进行业务裁员以节省成本，对应的运营、产品等各种配套角色也会按比例缩减。
2. 只裁测试，研发不裁或基本不裁。这种一般是业务还想保着发展，但是成本预算超标，要快速进行人口控制。这种裁员并不是意味着不需要测试，而是研发兼职了测试，一般是发生在小体量产品上，质量对产品的发展影响不大的阶段。

你这是要跳出来 kuang kuang 打脸 如果我是这个板块的管理员，我是不会让这种水平的问题审核通过

社区应该是欠缺了一些有篇幅有深度的个人分享，现在帖子大多以企业号、职场讨论、还有简单的技术问答为主。

mark，找时间学习一下~