最近在一些微信群里看到某互联网大厂裁员的消息，跟老同事确认了一下，他们部门的指标是 20%，5 个人里就要走 1 个，冰冷的数字背后是一个个鲜活的身影，一段段故事以及一声声的叹息和一阵阵的无奈，作为从业者，也不免有鸟尽弓藏兔死狐悲之感。

作为一个 35 岁以上，可能会被大部分用人企业所婉拒的老互联网人，老测试人，我今天一直在思考，假如我被裁员了那应该怎么办？

还完房贷

我想第一步可能是想尽办法还清房贷。这可能有点反直觉，丢了工作难道不应该先开源节流吗？房贷等与是长期定投，而且相对来说利率是较低的，失业之后把现金流丢到房贷里去岂不是没有任何的抗风险的空间了吗？其实我们可以反过来想，如果现在手上有些资金不去还房贷，那么很可能会去想办法创业或换个赛道做些自己不擅长的事情，这样一来如果投资或者创业失败，就目前的经济情况来看市场普遍缺乏信心，投资获益的可能性是比较低的，假如一不小心蚀了本金，那么房贷就难以为继，最后断供法拍，征信受损，大家可以了解一下失信的惨重代价。所以还清房贷，降低未来几十年的利息支出反而是更理智的选择。另外没有了房贷，每个月的生活成本其实是要低不少的，这样生存的压力也会相应降低，一石二鸟，何乐而不为。

节流节流

今年居民负债率没有提升，可能是因为大家手上真的没钱了吧。没有富余的资金，杠杆也撬不动空气。如果在这个节骨眼上没有了收入，那么我会选择尽量的降低生活成本，先活下去熬过这段时间，如果整个社会对经济都没有期待，那么经济的复苏反而指日可待。节流的方式有很多种，比如每天老老实实买菜在家里做饭，尽量少出行，不仅省钱还能预防新冠，卖掉一切不需要的东西，比如汽车，这样可以省油费，停车费和保险费用；停掉一切可能产生账单的服务，比如注销掉之前因工作需要而办理的手机号，停掉有线电视等等。这样算下来一天 100 块的话一家三口就可以生活下去，一年只需要 3.6 万，加上其他的一些成本和支出，一年最低的生活成本大概在 5 万，如果稳健理财每年的年化收益是 4%的话，那么有 125 万的本金就可以完全靠利息苟延残喘下去，寒冬总会过去，现在步入黑暗，但我仍然心向光明。

坚持交社保和保险

社保是一种对未来的投资，坚持交其实就是对未来不确定性的对冲，不过现在社保和商业保险的成本还是比较高的，应该是苟活阶段家庭年度支出的大头。

锻炼身体

前几天看到一个数据，大约在 2050 年，全球 65 岁以上人口的数量将是 5 岁以下人口数量的两倍。所以等我们这代人老去的时候，将是全球步入人口老龄化的时候。掐指一算，还有 28 年，按照中国人口结构和医疗水平推算，这个时间点可能会来的更早一些。最近一年见过一些生老病死，经历了一些世事无常，强烈的感觉到等我们步入老年之后

• 身体的健康和神智的清晰是最大的福报
• 社会上应该有不少岗位会向高龄人群开放

假如未来真是这样的话，为什么不在社会对 35 岁左右群体横眉冷对的时候蛰伏一段时间，锻炼好身体，不让年轻时候的工作透支年老时的健康，积极学习，跟上时代的脚步，过些年之后，当最后一波人口生育高峰的红利过去，也许届时会有更好的复出和发展的机会。总之健康生活的越久，在未来的社会可能会越有竞争力。

开源开源

做一些低成本的小生意，能赚就赚到，赚不到就当交了学费，当成是提升自我的必要投资。如果恩格尔系数过高，那么想办法种点菜补贴家用，灵活就业，赚不了大钱但心态好些就当是体验了生活。

读万卷书或行万里路

合格勤勉的打工人是没有太多时间读书充实自己的。没有工作了可以多读书，一来可以了解这个世界是如何运转的，二来可以通过不同人群的视角去展望未来，也许以后的机会就在我们对未来的憧憬中慢慢萌芽。低成本的行万里路真正让我们认识到这个世界，尽管我们是农耕民族，但迁移的基因也许从我们的祖先由非洲出走时就扎根在了我们的基因里，我们大部分人还是希望在有生之年可以亲眼看一看更大的世界。另外时不我待，前几天我去爬了座山，强烈的感受到如果年纪再稍微大一些，那么这项运动可能会跟我割席断交，失之交臂，当时就感叹，有些事情应该趁年轻去做。工可以留着年纪大了再打，毕竟从趋势上看，未来是属于老年人的，到时候孩子也长大了，每天睡的时间也少了，吃的也不多了，心态也更加平和了，模范的打工人就这么完美的炼成了。读书的经济成本不高，不过难在坚持，旅行与节流冲突，需要权衡和取舍。

培养一门爱好

有一门爱好可以全身心投入的话，那么人可能就不会那么焦虑吧。不过爱好除了投入时间之外还需要持续投入金钱，在经济压力比较大的情况下，一些烧钱的爱好可能就不太方便参与了。

多陪陪家人

打工的时候春节假期往往令人矛盾，想回老家跟家人团聚，奈何时间紧票难买；想多请几天假，奈何卷王当道，难以启齿。没有工作了终于可以多陪陪家人了，亲情也是一种治愈，能让人不那么焦虑。

总之

如果在这个时间节点我没有了工作，在有选择的情况下，我会跟家里人沟通，告诉他们我想先退一步海阔天空，调整好身体状态和心态，尽可能长的苟延残喘一段时间，然后充实自己，等待合适的机会复出；如果没有选择的话，我会默默的找出之前的简历，然后在开头加上一段话：“xx 年工作经验，xx 年管理经验，沟通能力强，有很强的抗压能力，能够适应高强度的工作”，加粗保存，发给之前有联系的一众猎头。最后盘算着离职补偿可以撑多久，从撑不住的那天倒推，给自己的求职行为立项，定目标，编 okr，最后跟家人对齐 deadline。好一似食尽鸟投林，落了片白茫茫大地真干净！

当今接口测试越来越重要，一般情况下我们总是会对接口的返回的 json 字符串进行验证，看返回是否跟我们的预期相符。不过很多情况下我们会遇到下面的问题

• 响应结果在测试中不停的发生变动，比如昨天还是 3 个字段，今天可能返回值里只有 2 个字段了，测试这边没有比较好的方式感受到后端的变化
• 我们需要对 json 的返回值进行一些校验，需要写很多的断言，大部分时候这些断言都是相似的，或者是重复的，比如说校验某个字段的长度必须小于 10 之类的

那如何解决呢？

• 与前后端沟通好返回值的字段，类型以及校验规则，最好有前后端+测试端统一一份合约，大家都按照合约来进行数据的处理
• 测试的时候通过合约里定义好的校验规则进行数据校验

这时候 json schema 就派上用场了。

json schema

JSON Schema 是一种 JSON 媒体类型，用于定义 JSON 数据的结构。 JSON 模式旨在定义 JSON 数据的验证，可用于验证响应和请求 JSON。 在 JSON Schema 中，我们可以验证数据类型、字段是否为必填、最小长度或最大长度等。

举例

下面的数据代表了一个员工的信息

• id: employeeId
• 员工名称: employeeName
• 年龄: employeeAge
• 职称: jobTitle
• 爱好: hobby

{
  "employeeId": 1,
  "employeeName": "Fulan",
  "employeeAge": 23,
  "jobTitle": "SDET",
  "hobby": [
    "watch movies",
    "play football"
  ]
}

上面的定义其实是有一些疑问的，比如

• id 是什么意思
• employeeName 的最大长度是多少
• employeeAge 的最小值是什么
• jobTitle 是必填吗
• hobby 可以填几个

我们可以通过生成 JSON schema 来回答上面的问题

测试计划在国内其实不是很流行。之前在外企工作的时候，每一次的测试工作基本上都是以编写测试计划开始的。好的测试计划可以让团队成员对测试整体进行和测试策略以及方法有一个大体的认识，在一定程度上可以节约沟通成本。最近正好在 github 上看到一份测试计划文档，我们就一起来学习一下其中的精华吧。项目地址：https://github.com/fityanos/awesome-quality-assurance-roadmap#test-plan-sample

1 介绍

1.1 项目介绍

介绍项目上下文

1.2 读者

描述一下读者人群，比如来自 A 团队的 alice 以及来自 B 团队的 bob

2 测试策略

2.1 测试目标

比如完整的回归测试，还是增量的功能验证等；

2.2 测试假定

假设某些东西不需要考虑或者满足某些条件，比如测试环境上可能没有配置负载均衡，这时就可以假定大家都理解这个点，并可以进行适当的忽略

2.3 测试原则

比如所有 bug 必须 fix 之类的原则性的东西

2.4 测试范围和级别

这里可以定义测试的范围，该做的就做，不该做的就先约定清楚。比如可以定义

• 功能测试范围和时间以及交付物
• 性能测试范围和时间以及交付物
• 回归测试范围和时间以及交付物
• UAT 测试的范围和时间以及交付物

2.5 LOE(level of effort)

这里就是工作量的分解了，越清晰越好。

3 执行策略

3.1 开始和退出条件

比如功能测试的开始条件是产品体验通过和开发自测通过，结束的条件是所有的 bug 都被 fix

3.2 测试轮次

• 第一轮
• 第二轮
• ……

对于敏捷测试团队来说，其实可以忽略测试轮次的概念。对于瀑布流开发团队来说则需要定义清楚，因为每一轮的时间都很宝贵。

今天在 github 上看到一份测试同学的成长之路图谱，不敢独享，在这里给大家汇报一下。

基本概念

首先明确几个基本概念

• STLT: Software Testing Life Cycle 软件测试生命周期
• SDLC:Software Develop Life Cycle 软件开发生命周期
• TDD: Test Driven Development 测试驱动开发
• RPA: Robotic Process Automation 过程自动化

必须掌握的基础能力

测试策略

• 白盒测试
• 灰盒测试
• 黑盒测试

测试类型

• 功能测试
  • 单元测试
  • 冒烟测试
  • 集成测试
  • 回归测试
  • 健全性测试(sanity testing)
  • 用户接受性测试(uat)
• 非功能性测试
  • 负载测试
  • 压力测试
  • 安全测试
  • 性能测试

上面的负载，压力以及性能测试在国内其实不怎么分，可以统一看作是性能测试，只不过测试策略不同而已。

STLC 管理工具

• qTest
• TestLink（常用）
• Zephyr
• Testrail

项目管理工具

• Jira(常用)
• Youtrack
• Trello
• Assembla

软件研发模型

• V 模型
• 敏捷模型：迭代式，较为常用
• 瀑布模型

深度手工测试技能

手工测试目前看来还是软件测试工程师的核心能力，优秀的手工测试能力可以让你的职业生涯发展更加平滑。

原文地址: https://www.stickyminds.com/article/exploratory-testing-why-it-not-ideal-agile-projects

下面是 gpt4 的总结。

探索性测试是一种灵活的测试方法，它不需要预先定义测试用例，而是让测试人员根据自己的判断和发现来设计和执行测试。探索性测试有以下优点：

• 它可以适应需求不明确或变化频繁的场景，提供及时的反馈和建议。
• 它可以发挥测试人员的创造力和直觉，发现一些预期之外的缺陷或风险。
• 它可以节省测试文档的编写和维护的时间和成本，提高测试效率。

然而，在敏捷软件开发中，探索性测试并不是最佳选择。原因有以下几点：

• 探索性测试缺乏可追溯性和可重复性，难以评估测试覆盖率和质量。它也不利于与其他团队成员或利益相关者分享测试结果和经验。
• 探索性测试依赖于测试人员的经验和技能，可能导致测试结果不一致或遗漏重要的缺陷。它也不利于培养新手测试人员或提高团队的测试能力。
• 探索性测试不利于自动化和持续集成，无法实现敏捷开发的快速反馈和交付。它也不利于与开发人员协作，实现测试驱动开发或行为驱动开发等敏捷实践。

因此，作者建议在敏捷项目中使用结构化的测试方法，结合需求分析、测试设计、测试执行和测试评估等步骤，提高测试效率和质量。

同时，也可以在适当的时机进行探索性测试，以补充结构化测试的不足。例如，在需求分析阶段，可以使用探索性测试来理解用户需求和业务流程；在回归测试阶段，可以使用探索性测试来检查系统的稳定性和完整性；在发布前阶段，可以使用探索性测试来模拟用户场景和操作。

有没有人从 QA 转到开发？

前几天在国外论坛上看到个帖子: 有没有人从 QA 转到开发？提问者表示:

我和我的经理谈了谈职业发展，这是我得到的其中一个选择。尝试转为开发人员工作。

在寻找新的 QA 工作时，外面没有那么多 QA 工作，相比之下，开发工作就很多了。

因此，这让我想，由于有更多的机会，是否应该从 QA 转为开发？

个人认为如果有能力转的话还是转一下比较好，毕竟开发的机会更多一点，而且天花板相对也比较高，不过高赞回答提供了另一种视角，我觉得也很有道理。

下面是高赞回答的内容。

我是一名软件测试开发工程师（SDET），拥有计算机科学学位，对高级编程原理有扎实的理解。在我的整个职业生涯（5 年以上）中，我一直在考虑转行。以下是我要说的话：

是的，对开发人员的需求更高，但该行业的开发人员数量也比 SDET 数量多得多。成为最优秀的 SDET 候选人比成为最优秀的开发人员候选人更容易（竞争更弱）。

开发(SWE) 通常薪酬更高，因为他们是构建产品的必需品。他们是新项目的第一个被雇佣的人，也是最后一个被解雇的人。如果没有开发人员，就没有必要有 QA。然而，在许多情况下，SDET 的薪水几乎和他们一样高。我自己在低收入地区: 蒙特利尔，加拿大，我可以赚到超过 150,000 美元的年薪。

这也意味着开发人员通常被视为更重要。很多人看不起 QA，尽管 SDET 经常对编程原理有同样好的理解，我们只是不经常使用它，因为我们遇到的编码问题没有那么难。

做开发人员的坏处是您可能需要工作更多，并承受更大的压力。作为开发人员，您必须遵守严格的交付时间表，同时还必须始终处于新技术和工具栈的最前沿。在工作与生活平衡（WLB）与薪酬方面，我 100%认为 SDET 更胜一筹。我比开发人员工作少 50%，但收入却是他们的 90-100%。这实际上可以让我接一些兼职合同并将我的收入翻倍。

归根结底，这取决于您更优先考虑什么。您是否想留在编码世界并晋升为首席开发人员？还是想拥有更好的工作生活平衡、获得更多产品知识并过渡到 PO/PM 角色？这完全取决于你。

简单来说高赞回答觉得测试开发比开发更好，因为竞争小，收入高，也不需要经常更新技术栈，不过这也意味着市场需求不旺盛，坑比较少，总之是有利有弊吧。

不知道大家对这个问题有什么样的看法，欢迎留言讨论。