在专门的测试团队中做测试

我理解这种是测试同学属于一个质量保障大部门独立运行，测试同学以资源小组的形式打散到不同业务中去支持业务发展，与业务线的产品研发不在一个大部门中。

• 优点：人多力量大，这种架构下质量大部门下会孵化出单独的中台质量技术团队，去探索先进测试技术，会做质量平台和工具来提效，这时候测试同学有更多机会往技术深入的方向发展，测试的方法论和目标一般会好，工作更加讲求效能逻辑、效能、计划。另外，不同业务线中的同学，有机会互相交流探讨不同业务形态下的测试工作差异。
• 缺点：并不是每个人都可以去干最有含金量的事情，看清现实吧……其实还是要看所支持的产品线，如果产品线资源很紧张迭代非常快，其实测试同学也没精力去搞啥技术，只能从大部门中把测试拿过来业务上落地。不过这并不妨碍个人从大环境中学习成长。

在开发团队中做测试

我理解这种是测试同学跟业务绑定，和产品研发同属于一个团队。

• 优点：研发测试沟通协作或许会更好（只是或许，不一定比第一种就好），有更多机会深入到业务中做建设，跟研发交流。
• 缺点：缺少测试技术标杆，一般这种团队下成长起来的测试同学对测试体系的理解不深，更多是带着研发视角来看待问题。而且由于缺少大部门高纬度的工作方针指导，也没了大部门的撑腰，测试同学很可能沦为产品研发的下游角色，只负责最低端的测试工作，发展上限低。

总结：我更偏向于第一种，因为第一种才真正代表着质量保障团队在发展壮大，测试同学才可以跟着大部门水涨船高，对于大多数人来说单打独斗是非常难做出彩的，长期来看少了对应指导也会让职业中后期产生认知和视野上的劣势。

1. IP 和域名瞎猜是落地保存但是有过期时长或过期策略，好细节真的给干不会了
2. 问题 2 已经看不懂了，不知是否问题表述上有出入【让服务器再次向 DNS 请求后再与被请求域名服务器建立 TCP 链接？】
3. 同 2
4. 每次请求前都清一次本地 DNS 缓存？（至于清理的方法，得靠搜索引擎了 ）

4 楼回答得很棒，我做个精简版：

1. 异步请求发起时 —— 响应方立即的接口反馈是否符合预期，比如最基本的异步消息入队是否成功
2. 异步请求发起后 —— 验证中间态数据，着手点一般有：流量染色（服务调用链）、中间日志、数据库数据
3. 异步请求结束后 —— 最终数据状态一致性，如请求结束各方是否工作完毕并正常

细节纠偏，radis -> redis

其实还好啦，代码文件拉下来就 2000 来行，一大堆注释和增加可读性的空行，实际代码感觉不足 1000 行，拿两个小时出来专心点看一看，把过于细节的部分省掉只看核心，就是纸老虎了

招招招，只要是素质好的全都要，HC 很足呢~

尝试以相对狭隘的视角去理解题主的问题，限制在小的范畴去回答。

1. 理解业务形态，针对性做建设
   不同业务形态对应不同的质量风险或测试难点，如图文资讯、视频直播、电商购物必然意味着不同的前后端问题类型，深挖所负责的业务全链路，每个环节上研发做了哪些技术工作，再来看这个技术工作是否合理，做体系化（“体系” 这两个字难度真的很大）的建设和查漏补缺

2. 不标准不规范的地方会引入混乱和沟通成本，找出并解决
   比较好下手的就是研发流程，狭义上我们说需求提交、UI 设计、技术评审、测试评审、技术开发、研发自测、测试执行、灰度上线、全量上线、线上监控等等的环节，从人工执行的环节下手，做好各种标准规范去约束混乱的自发行为；再拓展一下，可以细化到每个环节的具体，比如编码实现环节，施加质量层面的编码规范（数据信息的安全隐私、组件使用的姿势等等）

3. 研发效能提升
   其实质量或测试本质上就是研发效能的一部分，拓展一下其实可以把研发效能也纳进来。是否有更好的工具平台来提升研发测试体验，如全链路日志检索平台、接口自动化平台、用例管理平台…… 这些平台数不尽说不完，还是要看研发测试的痛点。另外一些就是测试提效或测试深度，如接口抓包 mock 平台、UI 自动化框架、monkey 工具……

针对社招同学的话，基本都需要 3 年到 5 年以上的工作经验（如果年限不足也没关系，我们看实际能力灵活看）。
校招同学当然就没有年限要求了，有实习经验最好~

求大佬帮忙吸引一下人才

就是 4 楼的意思。因为审核导致我没法及时回复，但是我又想回复别人，难道用户还要用笔记本记一下我几个小时后再上来论坛给别人回复消息吗

2

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

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

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

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

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

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

认真看完，打卡~

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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