我们没有广州岗位哦，业务测试的兄弟团队有广州岗位，不知道你是否感兴趣

同意一楼的观点。
测试开发发展路线有比较多，有的是业务研发出身，后续转到质量中台做测开，再慢慢带团队；有的是纯测开出身，做质量效能工具平台慢慢成为大的质量中台；有的是业务测试出身，对业务测试常见痛点有所了解后逐步向测开转型定点做工具平台解决质效问题（个人觉得这一种是最适合多数人的路线）；

你既然都没有经济压力了，何不放飞一把，怕个啥，大不了多啃几个月的家底。趁着早期职业激情比较充沛，赶紧找下家吧，不然就是温水煮青蛙了

想知道薪资分布与行业背景分布的关系

工作生活大多数时候应该是无法实践的，有害的刻意实践一定要避免。
另外，好记性不如烂笔头，整理阅读笔记并定期回顾，尊重自己曾经在阅读上花的时间，至少在需要的时候能通过笔记快速回忆要点

有这个打算并且正在实践，以前看书不留下笔记，最多划划线（但是不会去回顾），现在开始留下点子文档，一来方便回顾只是，二来方便二次阅读追加理解

认真看完，打卡~

多多少少还是会有，就是程度的多与少或深与浅（大部分时间我觉得收获度不高），今年期望通过一些读书的硬性指标来逼迫自己改掉这个毛病

为了达到月均一本的目标，经常会潜意识选择一些易读低难度的书，避开几斤重的硬核经典书

如何定位自己，得看你如何认识自己。

1. 对技术的热情如何？技术难题是否足够的求知欲、新鲜的技术是否有尝鲜的欲望、线上问题是否有刨根问底的精神……
2. 对技术的态度如何？觉得技术服务于业务还是技术驱动业务还是其他、迎面而来的问题第一反应是从产品/测试/技术的哪个角度看待、你的 idea 会不会主动用技术来实现……
3. 对技术的知识储备程度如何？常见技术问题是否知道解决方案，或更进一步能否自己实操解决、知识是否完备体系、是否有足够优秀的知识获取渠道和习惯、知识是否有足对应的实践经验……

（以上可能有所偏颇，仅做举例说明）

对自己问完这些问题，拿到自己真实的答案，其实已经能大致判别自己当下是否能走技术路线，或者未来有无机会走技术路线。
当然，不要被周边的言论限制了想象力，虽然实际生活中确实很多质量保障的高管是研发出身，但并不是全部都是，依然有部分是业务测试出身或者测试开发出身，殊途同归，起点和成长路径不一样而已。本质上，早起拼的是硬核业务技能，后期拼的往往是通用上层软素质。

我个人的豆瓣上标记了几百本书……
其中很多都是硬技术和软技术相关的高分书，真的去到了 “书荒” 的同学可以去翻翻看看有无合适，我比较懒自己只能一个月看一本。
我的观点有点接近 10 楼，虽然不至于那么功利，但工作之后最缺的确实是时间，看书要把时间投入和收益考虑进去，尽量多看对生活工作有利的少看乱七八糟的。如果已经把看书融入到日常生活分分秒秒当我没说😂。

看主管的背景、定位以及主管想要 “卷” 的程度。

设想一下，如果这位主管北上广深两三套房，家里一两个娃，开着低调奢华的大几十万轿车，这时他已经没有必要在职场去使劲 “卷” 了。如果他对自身没有其他要求，或许来到这个主管的位置就是图个安乐并且钱还可以，水那就是必然的……他的一切行为都会基于怎么保护好自己的位置，怎么让团队保持在自己舒适可控的规模范围内这样的目标。

如果这个主管野心很大，想继续往上爬，那他必然会跟内部成员和多个合作相关团队沟通，去为大家争取 scope 和资源，同时给予业绩压力来激发大家的生产力，让团队处于舒适区之外……

另外一定要明确，好的领导从来都不是一个让大家过得舒舒服服的烂好人，而是能为大家抢肉抢汤的人带着大家拼搏最后各自都拿到应有的收获带大家往上走的人。至于上班玩手机，如果他在行为和思考上依然表现出水平的话，那其实可以不用介意，不排除他是在关注一些对工作有利的信息。

这类小场景工作中也确实出现过几次，楼主很不错竟然去实践了一回（我们都是临时脚本，手动贴一下 cookie 本地跑完就了事了）。

我自己的想法是，用无头浏览器如 Headless Chrome 来登录网站，使用 selenium 去发送任意请求获取请求 headers 中的 Authorization，再利用任意数据库做个 Authorization 的缓存来判断 Authorization 是否需要更新，最终实现楼主一样获取 “永不过期” 的 Authorization。

不过上面的想法有个前提需要解决，就是在无头浏览器中怎么登录……如果是简单的账户密码登录那还好，大家各自使用写个配置文件就行（但是安全性不高易泄露）；如果是复杂的验证码登录，甚至是手机扫码登录，就开始难搞了……

所以还是楼主的方案更有实用性。

哎，待看列表里面又得多加好多东西了

即使阿里、百度、字节、腾讯等大厂，也不是全部团队都写单测的，所以【写单元测试的公司】在国内大概率会很少存在，写不写看的是【团队】维度。当然还是会有一些小而美的技术公司要求写单测，这里不讨论。

做事情都看收益，你一个天天迭代，代码变来变去的项目，写单测来干嘛？嫌竞争对手给你的时间太多了是吧 。除了程序员手痒自嗨，想不到其他原因。对于相对稳定的基础服务、基础组件，影响范围或质量要求特别高的模块，写单测是很合理的。

是传统瀑布（就是需求评审 - 开发（同时写用例）- 接口测试 - 测试），还是敏捷啊？

无论瀑布还是敏捷，都是这个流程，因为确实有先后顺序（难道还能不出需求就开发吗？难道还能没开发出东西就测试吗 ），个人理解核心区别在于每个阶段的时长，以及每个阶段具体包含的要素。

【以下个人理解，可能不对】
瀑布模型相对久远了，现在估计很传统的软件开发（传统 toB）或许还在用，它强调的是单产品单时间只有一个版本或很少的版本分支，后面的阶段要等前面的阶段完全结束，每个阶段要有十分完备的书面文档。在当年硬件资源匮乏，发布难度高，客户关系比较稳固，客户对交付日期要求比较松的大背景下，会有一定的科学价值。

敏捷上，网络资料更多，应该没有 toC 的公司不走敏捷模式，只是标准和不标准的区别。与瀑布最大的区别就是发布时间更短，每次发布带更少的特性，强调快速发布试错、拿到时长反馈、迅速迭代特性，这个方法论与现在公司竞争用户市场的局面下显得很适用，具体理念 11 楼 贴的链接已经说明得很清晰了。

另外，流程建设是要分阶段的，人少产品小的情况下就应该轻量高效，因为人少就不会存在严重沟通 gap，有啥事你在工位吼一声大家都知道，这个场合下强调敏捷，要不就是领导者希望团队提前建设相关氛围方便后面扩张人员，要不就是领导者单纯想实践一下这种模式。case by case，适合才是最好的。

结合自己在工作中观察 leader 对小组成员的不同评价，跟文章很多理念是切合的。

不过有些细节看得不太过瘾，比如对于技术和业务，应该如何区别评价？好业务和坏业务，应该怎么分摊收益或激励？好业务里中等水平的，跟坏业务里中等水平的，是不是本质上就有差距等等…… 这些细节如果未来有机会再开帖子阐述，我继续捧场

“背锅” 这个词其实我们内部经常调侃，但是严谨的含义其实还是责任分担。这个帖子抛的问题不严谨，从表述上看就有点测试与研发对立的意味，所以下面的探讨也不打算十分严谨。

17 楼槽神其实已经说到点了，我也罗列一些其他点来辅助一下：

公共视角

1. 有业务才有测试，业务没了测试就不用存在了，所以从饭碗角度来看，是不是要为自己的饭碗负责，质量做好一些，即使业务在走下坡路，也不至于死得更快
2. 如果这个生产事故的避免难度并不高，那我作为老板，就会考虑花同样的成本能否招来另一群能避免这种事故的测试，然后老测试就被新测试干掉了
3. 研发的真实想法：测试不为产品质量负责 -> 测试没必要参与到产品技术的重要决策 -> 测试不影响产品发展 -> 测试没有地位和话语权 -> 测试是一种随意使唤的资源；我想没有一个人愿意被人当成低级资源使用

个人视角

1. 一个具备专业素养的人一定是对自己的职业有所敬畏，会有基本要求，那么职业上的专业性必然使得自己去为问题负责，去寻找解决方案
2. 成长的机会总是潜藏在风险中，线上问题是最宝贵的实践经验，也是结合公司内部环境大家都可能会犯的毛病，应该把问题摸清楚，问题现象、成因、排查、修复、避免 等一系列要素都要整理出来，成为自己的竞争力

Get

昨天开始，通知恢复正常了，一下子一百多条历史通知，终于可以消费了！

上面已经回答得很好了，我来蹭蹭热度，我觉得的问题有几个：

1. 开发自主优化，私下找你出时间测试 —— 不正规的流程，私下对接的工作不公开，做了事情没人知道，出了锅又无法撇清关系，吃力不讨好。建议让他走正规流程提测，对清楚排期，一般分 “产品需求” 和 “技术需求”，两者可以用不同的测试方式，“技术需求” 你可以要求开发给进出改动细节，一起去评估测试范围和测试用例（产品新增功能需求可能会较少做到好的代码改动评估）
2. 找你测试，但是描述很模糊，导致你不知道要怎么测 —— 这种情况下测试同学就很被动，不去追问细节的话，最后线上出质量问题肯定第一个还是找测试盘问。建议让他澄清改动，否则不排期测试，而且设计出的用例一定要跟他一起评估（出锅一起背，很合理），直接无脑回归，一方面是浪费自己的时间，一方面对自己确实没有思考没有成长纯粹的工作量，从公从私出发都是不利的
3. 手上最近工作也很多 —— 公开你自己的人力排期甘特图，或者其他形式都行，只要是对外公布你手头的事情，这个信息让别人获取到，只要是讲道理的人都知道不会再乱给你事情，插事情进来优先级评估好各方确认就没问题。

所以说，正规的流程，对大家都好，不用再顾虑太多人情世故，大家都遵守规则就好。

首先，测试我理解是一个动作，质量保障是一个体系，不要把自己设限在测试这个动作执行者上。
然后，认可业务价值，理解业务发展，有业务合作落地经验，能度量数据，能改进过程，能发现痛点定义问题找人解决，事情去到你手上能成功落地（但是别人就做不到你的效果），这是业务能力，也是质量保障中的业务方向。
再来，也是大家一直说的技术，其实我觉得如果单纯谈 UI 自动化、接口自动化等事物，已经被玩坏了，业界现成开源能用的方案比比皆是，如果钻研技术不是个人爱好，完全可以就着业界现有成果拿来主义解决问题，不能把 “技术” 定义得太死板。

还是要多从质量保障的初衷目标去看，从上下游质量痛点去看，这个时候质量保障 sense 更重要，举个简单例子，比如发现研发排查问题需要在几个平台上反复横跳效率低下工作困难，我们能否做链路跟踪日志管理平台等。

当跳脱出常规的需求测试之后，其实质量保障的空间还是很广阔的，甚至可以把开发的领域建设都卷过来做。能力衡量上，就是前面说到的几个点：

1. 最重要的是质量保障的 sense，这个决定了你能否主动出击识别问题
2. 其次是逻辑目标规划等能力，一方面是你的视野（关注别人和业界，消化技术信息），一方面是你的经验（实践与思考），这个是往上爬的必备要素，面试过不少十多年经验的同学，技术开发经验很丰富，但是带人能力差，欠缺规划和思考，所以只能局限在【个人共享者】的角色
3. 基础技术能力，之所以放在第三，是因为我觉只要技术能支撑 idea 实现就好，结果导向业务导向，最终可以去到学习能力和技术理解力

5 年也太短了，一眨眼我自己都毕业多年了，刚实习那会自己尝试维护内部的测试平台，结果搞出了糗事的，都还历历在目。个人觉得 5 年还很明显是一个上升期而不是瓶颈期，如果真的 5 年就到了瓶颈，要不就是能力太强学东西太快接触事物很多，要不就是自己设限画地为牢限制了自己成长。

这个后续会有同学排查问题么？ 继续收不到关注人的动态通知，只能收到回复的信息通知

借老哥宝地，发一下字节 移动端端专项测试 的招聘帖：https://testerhome.com/topics/31151