37 岁的大头兵路过~~~~ 我的目标是干到 45， 祈祷~

你们这样比较危险吧， 没有经过用户授权就直接拍摄人体信息。 我们这里肯定不敢的。

不会的， 不论我还是标注组的那个妹子， 我俩都是临时被抓了壮丁干这个活的， 我们都有自己的主营业务。

肯定是要拿到客户的授权的， 现在不拿授权不敢偷偷采数据的

额。。。。 不危险吧。。。不是什么高危的工作，不会有生命危险的， 最多就是累点

我在外地出差， 等我有空我总结一下给你

嗯，也是当初运气好，进了一家特别能锻炼人的公司

算虚岁的话， 今年 37 了。 身体状态还好， 因为没有特别熬。 一般晚上 11 点多睡， 早上 7 点起，可以保证 7 个小时的睡眠。 半个月前刚去做了肠胃镜（因为前几年拉肚子拉的太厉害了， 每天都窜好几次，后来中医说是脾虚和有湿气，所以吃中药调整了 3 个月，就好了很多， 但还是不放心，半个前就去做了肠胃镜），现在正在吃药，主要是有胃炎，我理解应该没大事。 有脂肪肝了（虽然我特别瘦，才 120 斤不到），以后要注意饮食。 等胃看好了去查查颈椎， 感觉有几次头疼难受是供氧不足引起的。 其他的就没感受到身体有什么不舒服了。 岁数上来以后就比较重视体检， 每年都体检然后感觉不舒服就去医院（有补充保险，花不了多少钱）。现在精神状态和身体状态感觉都还行，起码目前没大毛病。

我觉得工作上的熬看是怎么熬的吧， 要是常年的那种睡眠不足的熬夜，再加上工作压力特别大， 一般来说会这样的。 如果只是半夜 1 点睡， 但是 8,9 点多也才起床， 并且这个作息时间比较稳定。 那其实还好， 只要作息稳定，并且睡眠足够，人体的生物钟会自己调整的。现在很多大厂的上班时间都比较晚（上午 10 点），所以大多数人只要别浪，回家别玩游戏别刷手机，倒头就睡，周末去外面锻炼锻炼身体，爬爬山什么的，不至于身体被消耗的很厉害。 当然像华为和 PDD 这种常年压力和加班并存的地方， 确实容易出问题。

能不能活到 70 岁以上我也不知道， 人是很脆弱的，随便一个意外，一场疾病能就没了， 所以我很少想这种事。 我现在的原则就是在不拼命的前提下，尽量努力。 多挣一些钱，给我们小两口的晚年和孩子更多的保障。

看是怎么熬的吧， 要是常年的那种睡眠不足的熬夜，再加上工作压力特别大， 一般来说会这样的。 如果只是半夜 1 点睡， 但是 8,9 点多也才起床， 并且这个作息时间比较稳定。 那其实还好， 只要作息稳定，并且睡眠足够，人体的生物钟会自己调整的。现在很多大厂的上班时间都比较晚（上午 10 点），所以大多数人只要别浪，回家别玩游戏别刷手机，倒头就睡，不至于身体被消耗的很厉害。 当然像华为和 PDD 这种常年压力和加班并存的地方， 确实容易出问题。

你也在到家呆过啊~~ 冬梅那个害群之马还在么

我看看能不能找到以前的简历了~

我这几天其实计划想把自己的简历，脱敏一下发出来，一起讨论一下的

因为每个人能选的出路毕竟不一样， 对我来说最靠谱的方式就去培训机构找个讲师做， 或者开发这些机构的测试产品。 但这个路不是每个人都适合去走的。 大家还是要选择对自己来说最靠谱的方式。 所以我不敢把话说死了， 说跑去干培训最靠谱。

大厂的人失业了，再去找另一个大厂，要是岁数大了就大幅度降薪去小厂，岁数再大了降薪小厂也不愿意要了就去做外包做子公司。 岁数再大了外包也不要了就再降薪去个培训机构做老师做销售。 水平不差的话肯降薪总是能混到 40 多岁的。总归是比送外卖开滴滴强。 要是说等 45 了以后咋办，嗯，好问题。 45 以后了失业除了真大佬以外（反正我不是）真是谁也没招，英语好的看看有没有外企的坑（这年头外企的坑比纯牛马的头发还少），混圈子的看看能不能在培训机构继续当老师当销售当助教开发测试产品。有人脉和资源的看看能不能转行干别的。也可以选择学习开发技能然后做个独立开发者接私活，开发小游戏，接众包（我有些朋友选择了这条路）。 实在不行滴滴外卖快递这些该做也得做，都是为了生活，不寒碜， 不怕大家笑话，我以前甚至想过 50 岁以后去做保安（50 岁以下的人家嫌弃你岁数小当保安不合适）。 所以如果真是生活所迫， 什么快递外卖滴滴保安收银员都不是问题，该干都得干。

总之无法在公司里继续做测试，也不想去送外卖/快递开滴滴这些工作， 那就一定要去学一些新的技能，接触一批新的人去适应另外一个领域，这是躲不开的。 之前有同学问我这个问题的时候我说可以去做独立开发者接接私活。但那个同学说我要是想写代码当初就不做测试了。 然后这个天就聊不下去了， 因为不管你建议他做什么，他都是这个想法，有各种各样的理由来搪塞说这个事情对他来说不靠谱， 不想学新东西。比如跟他说去外企试试， 他说英语不好也不想学。 跟他说去培训机构做老师做销售，他说不会讲课性能内向，反正就是怎么地都不行。 那这就一点办法都没有了。

不过其实对于我身边的人来说，很多人的想法其实都是在 45 岁之前，或者 40 岁之前攒够钱，然后就躺平。 这也是为啥 pdd，华为那种拿命换钱的地方还是有大把大把的人去。 大家都知道自己干不了多少年。 必须在这些年里把钱挣够了。 我现在也是这么个想法。 能多干一年是一年， 尽全力去延长自己的职业生涯。能干到 45 岁就是我现阶段最大的目标（我算了算，以现在的收入，只要不浪费，干到 45 岁攒个几百万的，回老家养老也是个退路，老家也有房子， 这几百万就存银行吃利息都行，老家那个消费水平一年 5，6 万块就够了），为了实现这个目标。就要不停的学习，不停的卷，领导说干啥我就干啥，尽量在公司里体现自己的价值。 所以我从很久之前就不再嘲讽很喜欢卷的同事了， 都是家里的经济支柱，是不能倒下的。 当然我也要做好干不到 45 岁的准备， 或者到了 45 岁但没攒够养老的钱，继续找个营生接着挣钱的准备。

我来了~~ 我回答一下楼主：

关于第一个问题

其实不管是 K8S 还是其他技术， 这些技术对于测试的主要意义在于产品是否用到了这些技术，产品用到了这些技术那么就需要去学习它，熟悉它，这样才能设计出更完善的测试场景，才能执行相关的测试方案。如果测试人员希望能够测试的更加深入，那么就需要学习产品中使用到的主要技术栈，这是通往高阶测试职位的必经之路。 尤其对于 K8S 这种基础的底座平台，如果对它完全不了解， 那么在产品出现什么问题的时候， 测试人员连日志都不懂得要怎么看， 这就是非常尴尬的。 当然如果是外包同学，我们对他们的要求就是在 UI 上点点点就可以了，出了任何问题都直接扔给研发。如果是这样的话，是不用学 K8S 的。

我再举几个测试需要用到 k8s 的例子，通常在 k8s 场景中会有一些比较独特的测试类型：

• 容量测试（性能测试的一个分支），这跟 k8s 的资源模型有关系（limit 和 request），需要熟悉 k8s 在资源上面的设计和相关的监控手段。如果出现过度超卖要怎么办，软驱逐和硬驱逐应该怎么设置是合理的，评估容器的内存使用应该用 RSS 还是 working set。
• 混沌工程：如何在 k8s 环境中注入故障是一个需要研究的方法（当然现在有 chaos-mesh 这样的开源工具了）， k8s 在高可用上是如何设计的，业务应该如何配合 k8s 的特性完善自己的高可用场景，如果业务没有配合 k8s 会的高可用设计会发生什么行为， 应该向哪里注入故障，注入故障后又应该预期发生什么样的容灾行为。 这些也是要去了解后才能测试的。
• 稳定性测试：在不注入故障的前提下，长期运行自动化测试或性能测试，验证系统会不会稳定性运行。 这个测试方法和普通的场景是一样的。只是在 k8s 中常规监控工具无法满足这种测试类型的需要，需要根据 k8s 的 ListAndWatch 机制开发相关的监控工具。
• 云原生的测试：一般产品上了 k8s 就是云原生架构，那么 k8s 的一些特性可能会进入到产品里，比如云计算，边缘计算，AI 等等。

除了上述的测试类型， 我们也需要依赖 k8s 的特性开发一些测试工具，比如我之前写过的 mock server，故障注入工具，监控工具等等。 为了更形象说明一下， 我这里分享一个我在测试中发现的bug 总结

首先说一下 k8s 和 linux 在内存上的策略：

为了确保节点的可用性，不至于让用户进程把所有内存吃光。在每个 k8s 的节点上都会有 3 层内存回收机制的保障：

• K8S 驱逐策略: 由每台机器上的 kubelet 进程控制，用户可以根据自己的需要配置驱逐策略的阈值。当节点内存达到一定用量时，就会触发驱逐策略，按一定的优先级开始把 Pod 驱逐到其他节点上，这样可以保证节点不至于因为内存吃满而瘫痪，也可以保证系统的核心服务依然正常工作。

• Linux 内存回收：分为异步的 kswapd 和阻塞的 direct reclaim，当驱逐策略没有生效时，系统内存到达一定的阈值后，会开始触发 Linux 自己的内存回收策略。

• OOM Killer：当 Linux 内存回收的资源也无法满足进程需要时，就会触发 Linux 的 OOM Killer， Linux 也会给每个进程计算一个 oom score 来划分优先级。当内存不足时，就会强行杀死进程来释放内存。

Bug：产品服务没有设置合理的优先级

K8S 的 Pod 优先级策略

根据 CAP 和 BASE 理论， 当系统出现故障或者资源吃紧或者压力过高时，如果无法保证系统完全不受影响，那么可以牺牲部分非核心服务或者用户的可用性，来保证核心能力的可用，这也是架构设计中熔断和降级策略的来源。而 K8S 的驱逐策略就是这样的设计理念，当业务高峰期来临， 导致节点资源不足时， 为了保证核心模块的可用性，会把低优先级的服务驱逐到其他节点上释放资源。 而 K8S 在触发驱逐策略时，为了保证驱逐的是低优先级的服务，在 K8S 中专门设置了两种策略来让用户设置优先级。 这样驱逐策略才能保证按优先级进行驱逐。这两种优先级策略分别是由资源配额和抢占优先级两种配置来决定的。

资源配额的优先级

K8S 会按照资源参数 reqeust 和 limit 的设置把 Pod 分为三类优先级：

• Guaranteed(有保证的)：

  • Pod 中的每个容器都必须设置 CPU 和内存的 reqeust 以及 limit。
  • Pod 中每个容器的 CPU 和内存必须设置相同的 reqeust 和 limit。

• Burstable(不稳定的)：

  • Pod 不符合 Guaranteed 的标准。
  • Pod 中至少一个容器设置了内存/CPU 的 limit 或 request。

• Best-Effort(尽最大努力)：

  • Pod 中的容器没有设置内存/CPU 的 request 或 limit。

从这些定义就可以知道它们的优先级了，当驱逐策略触发时，k8s 会最先驱逐 Best-Effort 类型的 Pod，如果释放的资源仍然不足以满足要求，会开始驱逐 Burstable 类型的 Pod，最后是 Guaranteed 类型。

抢占优先级

除了通过资源配额推理出优先级外， k8s 也准许用户手动为 pod 设置优先级。在 Pod 中有一个字段叫 priorityClassName 专门负责此事。 用户可以定义名为 PriorityClass 的对象，事先约定更好一组优先级。比如：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "此优先级类应仅用于 XYZ 服务 Pod。"

bug 出现的原因

产品设计上并没有给服务设置合理的优先级， 导致在驱逐策略发生时，核心服务被驱逐掉导致产品在一段时间内不可用。

总结

所以要测试出这样的 bug， 前提就是需要把高可用设计原则（知道原则你才知道什么样的行为才是正确的，高可用没有需求文档，全靠测试人员和开发人员对高可用的理解）和 k8s 中的驱逐和优先级机制了解的门清才可以。 所以同学们想要有能力分析出这种 bug 么，想要拿金 bug 奖么， 那就更深入的学习吧。

关于第二个问题

K8S 要掌握到什么程度， 这当然是越深越好。 不过人的精力有限， 所以我的建议是如果不是专攻云原生方向的，那就把 K8S 的普通特性学习好就可以了。 就按自己可以在 k8s 中从 0 到 1 的部署一个高可用版本的服务为基准，自己来这么一遍就差不多把大多数常用的特性学的差不多了， 也可以在出问题的时候知道怎么查看日志和其他信息。 而如果是专攻这个方向或者有意深入了解 k8s 的， 还需要懂得 k8s 内的机制：比如 listandwatch，比如 operator，比如各种更复杂的内部机制，需要懂得根据 k8s 的 api 开发工具，总之学的越深越好。

关于第三个问题

• 极客时间上 k8s 的课程
• 我写过一本书《云原生测试实战》PS：我再一次无耻的推销一下自己的书

好久没研究过单测框架了， 现在出了新技术么， 以前 java 系就 testng 和 junit 这俩选择

可能只是发帖的人没有那么多了， 确实不少优秀的作者都离开了，他们可能更专注在生活上，可能工作太忙没有精力了，可能大环境不好没有心情发帖了，可能躺平了不想卷了， 可能觉得自己也没学到什么东西就不发帖了，又或者只是单纯的累了，不想坚持下去了， 每个人都有自己的原因。 所以对还在坚持在社区分享的人表示感谢。

楼歪了楼歪了，讨论讨论着火药味就出来了。 这几年就业环境很差是事实，不管是哪个级别的，都会感受到工作不好找。 岗位少，人选多就是现状。 以前只要会 123 的，现在还要求会 456 才能入选， 以前要求会 456 的，现在得掌握 789。 现在是买方市场，公司有大量的人可以挑，所以他们就不停的提高要求，反正人有那么多，当然要从这么多的人里选最好的那批。 所以很多人觉得不管怎么努力也是没用的只能躺平，这也是无可厚非的，毕竟要打败绝大多数同领域的竞争者不是一件容易的事，很多时候，努力能产生的效果真的没有那么高，运气和机会也占了不小的比重， 所以早日寻找另一条路也没准是个合适的决策，就算躺平了，起码也能落下个轻松自在。 而有同学说的需要把技能挖掘的更广更深入的这个看法也没有错，毕竟在此种环境下，要打败大多数同行最靠谱的方法当然就是掌握大多数同行都不懂的技能。 而且在经济还没有变差的时候测试这个角色的边界就已经不清晰了， 早就不是在 UI 和接口上进行测试的工种了。 各种更加底层的测试，更加专项的测试都开始执行了，比如混沌工程，CICD，算法测试，大数据测试，线上监控，数据分析。 甚至测试也要去做一些原本不属于测试定位的事情了， 比如我们这两天刚刚开发了工具在线上环境中采集了 800 路设备的图像数据，所以很多时候大家坚持的原则在公司面前在领导面前都是泡沫幻影。 领导要你负责一个事，你如果说这个东西不是传统测试人员负责的范围，那不是找死么。 所以为了生存，有些同学选择与时俱进 也是没有错的。 大家各自有各自的活法， 都各自去尝试好了。最终时间会证明哪一方是正确的（在这个行业中生存到最后的那一拨人会总结自己的经验的）

最后说一下我其实不懂什么国际局势， 但看周围人分析在美联储减息之前经济环境是不可能好了。 在这之前就业就是很难的， 祝大家都能度过这波寒冬。

同事跟我说最近在内网上有很多人发 lastday 的帖子， 感觉虽然公司没有明着说， 但其实已经在裁员了。 而我知道的飞书在大裁员， 阿里也有大批的员工离职事件。 其他公司应该也都明着暗着的裁员。 市场的人太多了， 竞争太激烈。 这个时候如果你不是特别优秀的，都会感觉工作不好找。 即便很优秀但可能年龄偏大了，也是不好找的。 我猜啊， 如果我现在被裁了， 我的情况应该也不会很好。毕竟已经 36 岁了， 找不到工作应该不至于， 但可能很难能找到比较好的岗位了。

所以大家面临的情况应该都是差不多的（除却少数人外）。 尽量在简历中，面试中突出自己的优势， 毕竟我也说过我们不是在跟公司博弈 ， 而是在跟同行博弈

薪资高低是相对的， 在上海吧， 可能对于功能测试来说 20K 几乎是天花板了。 但对于测试开发来说可能 20k 只是起步的， 所以你看俩 JD 上都是 20K 起，按一般规律给区间的按中位数算，也就是这俩 JD 我们算最后给的待遇算 30K/月。 对于很多功能测试来说这个数字很高了吧。 对于一般的测试开发来说这个数字应该是正常的。 而对于已经在大厂拿到对应职级的人来说这个薪资就是根本看不上的那个级别。 所以不同的人看这个事情感受不同。

不光写代码的搞不过写 PPT 的， 任何一个工种都搞不过写 PPT 的。 写 PPT 是表象，核心人家有办法让老板信任， 所以啥工种都比不上这种能拿捏老板的。

大多数都是对着模型测， 只有人工智能平台这类的， 或者像百度腾讯有自己的深度学习框架这样的才需要算子测试（但其实很多都是算法人员自测的）

所以这就是为啥都挣着去有一定规模的公司， offer 里有大厂就选大厂的原因之一吧。 还有就是其实也有很多小厂也用 docker，k8s 这些，比如我就是从一个不到 200 人规模的小厂里学到 docker 和 k8s 的。 现在这俩东西只是技术成本比较高，倒不会要花很多钱才能搞这个。 所以只要开发人员水平到位都可以做。 很多小厂上云后都是面对这些东西。

当然这些是要看运气的， 你进入到一个使用的技术比较前沿的团队就更容易掌握这些有门槛的技术。 没有进入这样的团队必然就会陷入 hard 模式。 但怎么说呢，我在文章里经常会说一个观点， 大概意思就是很多时候是学习了这些知识之后才获得了做这样工作的机会， 而不是先给了你做这个事情的机会才去学习这些知识。 我意思是既然已经进入到 hard 模式了， 为了跳出 hard 模式就只能自己去自学这些东西然后期望跳槽到一个更好的团队去。 这是没有办法的， 要不然就只能躺平了，下一次再出现在种工作的时候还是无能为力。