全世界的大厂都在搞 ChatGPT 竞品，但个个都是半成品，一两个月 rush 出来的东西怎么跟正版比

云手机是指模拟器那种？下面就当是模拟器来回答。

没大规模使用过，但是可以确定模拟器无法替代真机，因为模拟器在底层的接口支持和真机不一样，也就会导致部分模拟器上会出现的问题在真机上根本不存在，而真机会有的问题模拟器又测不出来。

有部分场景可以考虑使用模拟器：

1. 核心场景 UI 自动化、性能防劣化等，有明确固定的测试场景，重复一样的测试操作
2. 和平台底层接口、显式样式等无关的功能验证
3. 真的没钱买这么多真机，模拟器是在设备上去扩展部署的，成本低弹性高资源利用率高

1 楼观点 +1，看着像公司问题不是岗位问题

1. 兼容测试。多系统多版本多机型同时运行测试用例，如果能自动断言问题更好，没有自动断言那人肉观察也总比同时操作五六台手机的效率高
2. 本地化验证。如果这个【不同地区】设计到一些网络关系，比如外国的机架，那就很有必要在当地的网络环境下去做用户体验测试，找优化点
3. 版本问题 debug。如果是一个高概率复现的 bug，装不同版本的 app，在多台手机上做同一个复现路径，应该更容易 debug 问题

如果希望一键全自动搞完是没有的。

看你需要什么方面的性能数据，机器方面的性能（cpu、内存、gpu、io、流量）这些 perfdog 应该都支持；至于业务相关的时间，启动时长、渲染时长、页面切换速度，这些都是你业务定义的口径，你要测自家的小程序勉强还能用埋点统计，你测别人的小程序就只能从用户角度去录屏分帧算。

所以，但凡涉及竞品评测，除非你能拿到竞品的源码，或者有能力支撑你低成本做逆向分析，不然只能从用户角度去想黑盒获取数据的办法。

之前不也挖过你么，记得当时你也是有 offer 了，害

我们这边 6 月份会有新一批 HC，到时候还感兴趣的话可以加个 wx 再私聊一下~ wx 号 zingphoy

测试和研发之间的考核方式本身就不冲突吧，并不是说测试找到 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 年半了，还在互联网和大家卷。不过兴好慢慢从卷体能开始向好趋势变化，有了点自己的竞争力，对外能侃侃而谈舔好甲方，对内能沉心做点实事带带资浅同学