同意，如果业余学习的东西有机会结合到工作里是最好的。但对于测试同学来说，往往没这样的机会，日常业务测试已经占了很多时间，剩下的一点时间即使有机会做技术，也是做一些比较通识的技术，一般不涉及很深入很晦涩的领域（要么有专门的团队解决，要么根本还没到遇见这种问题的阶段），所以能做到学习结合工作的机会个人感觉可遇不可求。

之前和其他同学闲聊发现大家其实都有这么个想法，就是内部交流太少了。明明是同一个部门，但是大家的东西都是收在自己盘子里不外露。这个时候哪怕站出来多说一点，影响力就很容易打开，因为大家都不说，就你说。

所以我觉得搞分享，一方面是考虑自己学到什么，一方面也利于影响力。所以即使和工作没直接关系的分享也不碍事，但这类分享就不能和绩效挂钩，不然太假。

年轻的我，那时时间多，每周那仅仅两三次和妹子在一起的时候，还会写日记记录我们的点滴，写了几十篇。后来去了卷到飞起的地方，就没时间了 。被迫装得成熟

做法一可能很看人，越是校招同学越容易被卷王带起来，因为大家时间都很多，而且学习欲望强，只要有输入有反馈很容易兴奋，所以引入卷王比较适合年轻的团队。
相反，对于年龄结构偏大的团队，大家都工作了五六年，什么都见过了，也知道自己想要什么，对工作和业余都规划好，这种情况下招卷王就有点让人讨厌了。
所以，这只能是一个思路。

以下是亲眼见过的做法：

1. 招到自驱力很强的人进来，带活整个团队的氛围 —— 就是找一个很卷的人，给大家压力让大家卷起来
2. 找大家各自聊一下对分享的看法，要聊真实的想法，可能对这个事情看待不一样 —— 或许大家都认可，但是形式不对；又或许有人不认可因为觉得工作已经很忙碌了；找到障碍去解决

以下是我自己想象的做法：

1. 如果就技术分享，可以由你自己去找课题，做成一个多元化的课题池，让大家自行挑选他们感兴趣的课题做分享，半任务半自由的形式
2. 自发的分享，要注意有一定的激励机制，求有不求多

有感而发，勿喷

行业内大家都在焦虑 35 岁，其实我觉得这个奇怪的不安全感往往是自己给自己的。
在我的身边（深圳互联网大厂，够卷了吧？），超过 35 的一线研发同学虽说不多，但也不是没有（毕竟算算这个行业才多长时间，也没那么多 35 的人）。
前面说的是研发同学，测试/质量同学也分很多种，纯业务、业务 + 专项、纯专项、偏 PMO 的质量管理……不同方向技能点要求不一样，只是有些对技术实践的能力要求高，有些对沟通推进能力要求高，有些对业务理解要求高。这些不同方向的质量同学，也有好些是 35 的。
所以我想说的是，并不至于到了 35 就寄，真正在 35 职业生涯终结的是那些年龄和经验不匹配，一直从事复杂度很低的事情，对自己没有要求没有规划的人。

如果我是面试官，我接受候选人把这个写进简历里，但得注明是业余实践学习，不能强行和工作搭上关系。一旦发现我会选择当场否决，会认为候选人搞小动作不老实。
真正工作和业余实践相差很远，一个人随便折腾，很多细节根本就不严谨，完全不能当商业化的经验，特别容易暴露，劝不要这么整。

关键：如果你自己没有目标，不知道 roadmap 路线怎么走，那过半年甚至一年可能和现在一样没本质区别
其次：如果没有找到一个合适自己现状的计划，尝试做苦行僧也很难得到提升

我的建议：

1. 不要再浪费时间在学哪门语言上，先去找一个你最想做的自动化测试方向，比如你是想搞 UI 自动化，还是接口自动化，还是啥啥啥【贪多吃不完，挑一个就好，不要高估自己的精力】
2. 根据这个方向，你去搜索业界最流行最多人用的方案是什么，这里面推荐的学习路径是：
   • 方案的价值在哪里，优缺点是什么
   • 方案涉及什么基础技术、框架、能力、工具。不要从头去学，直接找一些案例来学习，比如一些 github 项目，或者一些视频教程，效率比从头系统慢慢学要高很多，一边实践一边学习
   • 方案在业务实践上踩坑点是什么，有何技巧做好落地
   • 【备注：很多人可能只会关注技术层面的东西，但在实际工作中，落地实践的重要性一点不亚于技术】

不知道是什么上下文，就不乱支招了，觉得有这么大怨气很可怕，帖子中的两个人我都不想跟 ta 们做同事 😂

一不小心又到了适婚生育年龄😂，快了快了

一不小心就 5 年半了，还在互联网和大家卷。不过兴好慢慢从卷体能开始向好趋势变化，有了点自己的竞争力，对外能侃侃而谈舔好甲方，对内能沉心做点实事带带资浅同学

接入自动审批也是要💰的，其实人工审核一下还好，刚好切合一天上午下午晚上几个时间点定时过来看看

我可能是开发同学口中的傻逼用户

听起来是这个构建系统不是很完善，目前只是一个裸 jenkins 在做构建工作，其实很多上下游的事情可以稍微画点时间就能舒服很多，如：

1. 【可我们 Jenkins 里有一堆项目，如果版本更新了，开发要不忙就告诉我们构建哪些】，哪个版本要更新，理应是可以通过代码合入去感知的，这其实就是配置一个 merge request 的 webhook 就差不多了。如果有更严格的条件，那应该和开发一起制定规范，比如你有个 TAG 的严格自增，那稍微搞个数据库存一下最新序号做个匹配就只能哪里应该构建
2. 【我咔咔构建一堆之后，还有构建失败的，于是就得联系开发再查，他们修改完告诉我，我再试着构建，就挺麻烦】。有两个解决办法，一个办法是构建失败自动通知，不同项目配置好通知不好开发；一个办法是统计构建失败频率，选出 Top 失败的项目，推开发去做规范写文档，让大家可以自行解决常规的构建失败问题，让开发自己去关注构建成功率

其实谁去维护都一样，按照你的上下文本身没有很复杂，就是大家都懒得去做改进而已

第一次了解到比较真实的国外 IT 从业生活~

①接口测试是否需要针对必填参数验证？感觉必填参数校验，有一个脚本就够了
需要，而且很必要，P0 用例。具体在测试执行上，如果接口的必填参数很多逐个验证很麻烦，可以按场景去写需要的脚本，爱怎么搞就怎么搞，能测好不就达成目标了么

②接口测试数据，是否要枚举，比如：长度、特殊字符、中文
异常场景用例设计主要看测试时间，如果时间非常充裕，可以测得细一点，比如你说的各种异常情况枚举。如果时间相对紧迫，没条件这样去搞，那就要例行筛选优先级，适当砍用例。当然，更好的做法是直接看研发的代码，比如代码里都写清楚了，每个接口调用前都会有参数校验逻辑，校验逻辑已经统一把这些异常情况做过处理，那就可以大大简化这些用例，只要你在一个接口字段上验证过，就没必要再到处重复了。

这真的好吗，很多时候一旦定了指标，就会引导大家往指标体系意想不到的方向发展。

或者从另一个角度说，只负责搞日常业务测试的同学倒是可以比较好的融入，很多不同角色的同学在这个体系里估计很惨。

测试本质就是保质量，质量出问题一样背锅，所以其实写不写项目测试都差不多，这是本职工作，如果用 OKR 的话一个 O ，KR 里列出几个需要重点投入的项目足矣。
其他的无非就是围绕着质量领域的效率提升和成本降低。一般首先被关注到的，无非是流程优化、各个端的功能自动化、性能/安全等专项测试工具能力、监控建设、反馈跟进……说白了就是造框架、工具、平台、方案。
只要不是本身就对测试部门有怨气，其实是不会理解歪的。这个场景我觉得应该是测试部门之前做得不好，让楼主觉得这个目标是不务正业吧 。

我没做过真正意义的游戏测试，只是说说自己的看法。

• 功能测试，我尝试分解一个游戏构成要素：

  • 客户端：数值系统（任务属性、装备属性、技能属性）、视觉交互（技能效果、交互效果）、对战系统（匹配机制、房间机制、副本机制、地图系统）、世界系统（频道机制）、通信协议（协议细节、消息广播），以及围绕着装备、技能、属性等各种强化机制玩法。本质上一方面是游戏业务逻辑的功能测试，一方面可能会把 Unity 做一层或轻或薄的封装，可能也需要对封装的引擎接口做一些测试（UI 级的、函数接口级的）
  • 服务端：这就是普通的服务端接口测试，没什么特别的，前面提及的各种数值计算、数据下发、匹配等都属于服务端逻辑

• 性能测试：

  • 客户端：有现成的性能测试工具，如腾讯 perfdog 是大家都在用的。就关注 cpu、内存、帧率/流畅度，结合业务需求去设计测试场景即可
  • 服务端：常规压测

• 稳定性测试：更多是客户端概念，最简单的实践就是上个 monkey 随即遍历点击，进阶的就是将随机点击化为有效点击只点能交互的要素 + 遍历策略算法

• 兼容测试：游戏客户端，不同的机型系统版本

• 其他专项测试：安全测试一般是游戏必不可少的，服务端和客户端都的越权、加密、注入等；当然还可以有其他的专项测试，比如资金、数据流量……

看团队，卷不卷很大部分由 leader 和同事决定。

大多数时候公司对产出的压迫没那么恐怖，大家都是正常人也并不想卷的，排期合理评估好按计划走。但是，可能你的 leader 10 点还不下班，可能你的同事晚上 12 点还在群里发消息 @ 你。
其实大家本心不坏，有时候确实周期到了要加快产出，然而当卷王集体出现你还不卷就显得十分 “突出”。

总体来说，测试肯定没有研发卷。

你这个说法挺可怕【现在测试组每天都是正常打卡上下班，几个月没加班了】，意味着潜意识里把加班当成常态，不加班就是闲，细思极恐😂。

不过既然闲下来，是不是可以搞一些更高价值的事情来丰满大家的工作。

一般这种送命问题：

1. 说有优化空间，那直接砍
2. 说刚刚人够用，领导观察一段时间，找你说还是砍一点，辛苦大家压力大一点，分担一下吧
3. 说人不够还要加人，领导说别加了，就这么多吧

1. 是否有推行代码扫描：看团队，有些团队有有些团队没，但总体来说更多团队愿意尝试
2. 开发配合：这个是强要求开发配合的项目，在推广之前就需要和开发从上至下对齐这个事情的重要性和解决问题的方式；除非测试自己有权力和能力去直接改开发的代码，不然扫出问题就是要开发修改，开发如果一开始就不打算配合那测试单方面做是自嗨
3. 测试单方面配置有无必要：同上，我觉得测试单方面是无法开展的
4. 效果：代码扫描分两种，一种是单纯的编码风格扫描，这个一般开发内部自己推广；另一种是我们更关注的代码缺陷扫描，它本身就是一种前置发现潜在问题的手段。从这边的数据简单去看，尤其是一些线上空指针问题，这种工具在发现能力上是相对可以的，但其实也没有说很多线上问题它都能发现，很多时候它是一个治理隐患的手段，发现效果也因工程的复杂度而异，越是复杂的工程越容易有隐患，用这种工具理论上可以更有帮助

在具体开展上，我觉得可以这样去尝试：

1. 先拿到线上问题数据，拿有问题的代码去扫，看能不能通过扫描发现问题 —— 这一步是回答整个代码扫描的实际价值，如果这里发现代码扫描根本没有抓到多少历史线上问题，那就没必要做了
2. 和开发商量好启用什么扫描规则，不同扫描规则扫出来的问题是否提成 bug 去跟进，对应的优先级又是什么
3. 每个版本，甚至开发每一次的代码合入（Merge Request），开始卡口，先卡增量问题，保证每个版本没有新增问题，再慢慢消费存量问题

基本上大家的套路就是这样

持续输出，确实考验意志力，还会倒逼自己去加深学习

工作半年多就开始焦虑这个问题，我那会还不知道在哪里玩泥沙呢 😂。

我的建议是：

1. 多留意身边，多关注上下游，认清自己的工作是为业务质量负责，还是从业务角度而不是技术角度去思考问题
2. 测试开发和业务开发是两种截然不同的选择，两者无法直接对比好坏，也不存在因为编程语言不一样而无法转开发的说法，本质上看的是编程熟练度，其次是解决问题的技术复杂度（我个人感觉熟练度是转型第一位，其实业务开发也不见得技术一定有多好）
3. 可以多看看测试开发大会，了解一下同行做什么比较高精尖的事情，这样也方便对测试开发这个岗位做的一些相对有难度的东西建立一些认知

手动点赞