测试和研发之间的考核方式本身就不冲突吧，并不是说测试找到 bug，研发就要打低绩效。

研发肯定从产品价值维度去论证他们的技术产出，核心还是做了什么事情，产品的日活或者留存或者收入或其他啥得到提升；测试更多是从质量维度去考核，发现、处理、预防质量问题，也可以延伸到产品价值维度。

我有几个问题比较好奇：

1. 不同厂商的云脑竞争，大家都想往路上加装设备，就像极了共享单车竞争的情况，最后有些厂家退出，安装好的设备怎么办？这方面是不是会被公家管辖准入？
2. 汽车要接受路边设备的信息，如果使用一个统一的协议，是不是可以第三方恶意伪造数据，像手机虚假基站那样的感觉，要如何避免？
3. 单车智能和车路协同，应该不是此消彼长的状态，最终状态猜测是部分路况复杂的需要车路协同，部分路况简单的或许可以单车智能，两者在成本上有多大差距？

很不错，这里面提及的问题我自己踩了个遍，甚至有些点到了现在还会因为自己的角色职能所限不会第一时间意识到，要反复给自己提醒

【为什么手游启动必有热更过程，其它手机软件却全都没有？】这是一个错误的结论。

题主可能只关注到手游存在更新进度条的交互过程，国内大厂绝大多数 app 都有热修复、插件更新等机制，这些都是所谓的热更过程，也就是不需要在应用商店升级 app，就可以让 app 某部分的功能得到升级。尤其是 Android，简直各种花式搞。

只是非游戏类的 app 像游戏那样有个很明确的更新交互过程，如 6 楼所述，其本身更新的目的不一样，所以技术实现的最终结果也有些差异。

Android 界比较著名的如 https://github.com/Tencent/tinker，有幸和这个项目的创始大佬开过一些会议。

发现很多类似这样的观点：测试/测试开发的技术能力比研发差，所以测试能搞的，研发都能搞，只要研发愿意做，测试就会失业。

如果只是单纯说代码技能、开发技能，熟练度和深度上比研发差那是肯定的，人家在写代码上花的时间就是要更多，非常合理。
但测试搞技术平台，它就真的只是怎么去开发这个平台这么单一的事情么？

为什么看不到如何发现质量痛点，如何深入挖掘抽象分析，如何明确要打造一个平台的这个过程本身的难度呢？

这是一个比较系统性的工作，它可能涉及数据统计、问题分析、技术选型、快速验证、运营落地等很多 “不纯粹” 的 “乱七八糟” 的事情，它最大的难度可能并不是在怎么设计好技术架构、怎么应用设计模式、怎么优化代码性能诸如此类……

所以我觉得，能做到测试顶点的人必然有 ta 的优势，可能不是技术能力上的优势，而是其他维度的优势。在做出第一步职场选择的时候，已经明确了两种岗位未来的技能树分支是有差异的。我自己亲身见过，有的测试后来转了 PM、PMO、研发等各种不同职能的角色。做测试最大的优势在于起 “多面性”，当然也引入了劣势，就是啥都懂一些但没一样懂得多，这就靠自己去做取舍。

为什么会有研发经理和测试经理，为什么研发经理还会和测试经理一起沟通如何支持产品的发展，研发经理不就直接把测试都管了就好了嘛，干嘛还要招个人。

再回到最开始那个观点，为什么会有这种说法。内部巨佬是这么回答：

测试这个 “动作” 本身，是研发过程中自然发生的，开发写完代码，肯定需要自测一下才能交付，但是随着团队变大，分工细化，测试这个 “角色” 就产生了。但是一定要注意的是，产生这个角色时，一方面发生了职能的转移，另一方面也产生了新角色的核心竞争力：测试团队需要保证如何更有效的测试，通过各种方法（当然最自然的想法就是手工测试）。如果你没有搞明白这一点，而是成为 “职能的转移” 的下游角色，那必然会有鄙视链的存在。但是换个角度，你提供的是可测性能力，让研发自己更好的测试，更有效的测试，你的角色价值就产生了。

测试最忌讳就是搞穷举遍历求个心安，不妨换个问题去想：如果只给你 1 天/2 天/3 天的时间做完成测试，不同情况下你会怎么去测？

手动点赞

要不就是这个老哥之前的坑位太爽了赚大发，要不就是这个老哥被这个公司的这个岗位定制化了技能导致出去不适合其他公司。
反正，能赚一年是一年，高薪我不在于天长地久，只在乎曾经拥有

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

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

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

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

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

以下是亲眼见过的做法：

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