最屌的是现场编一个，而且容易圆回来

反正我自己确实不会去记忆（也没办法记忆）任何一个十分具体的问题，因为上下文太多，一个问题过了两个星期你让我在交流的时候当场说都没法把细节说满，何况还在面试这种时间很紧张的环节，稍加思考片刻就觉得要被否决。
至于那种做过整体复盘很完善很深刻的，往往又和公司的各种内部平台耦合，太多背景知识要解释，也不知道说出来合不合适。

哦，那确实不一样，如果都问到什么兴趣爱好这种和工作不直接相关的问题，就已经是面试尾声了，反正马上就会结束

可能是因为现在真的比过去更卷，也没以往那么有吃苦耐劳的风气吧。或许也有一些宏观因素？比如各种红利正在消失（人口、房地产），上升通道开始收缩等等……

基本方法大概是先和上级对齐你的角色定位，明确 ta 对你的产出预期，就确定基本的试用期考核方向了（如果上级连招你进来要干嘛 ta 自己都不知道，那我建议赶紧换个上级）。

下面枚举一些可能性吧，问得太泛也就只能回答得泛一些，肯定是不全的，仅供参考：
从整体来说，高级质量工程师的目标都是围绕着【支撑需求交付、提高测试环节效率、保证线上严重质量问题数低于 xx 个】去开展的。那么从一些大方向来说可以有：

1. 测试环节效率：流程规范、各种专项测试……
2. 测试左移：自动化技术、流程卡点……
3. 测试右移：线上监控、故障响应与容灾演练……

上面只是一种大方向的分类，你还可以从线下线上这样去分类展开，也可以从业务 1、业务 2、业务 3 这样的分类去展开

还有有这样的说法么？
感觉这个问题像开盲盒一样，如果我是面试官可能不会选择问这个问题，主要是日常 bug 太多，怎么还记得来什么广度深度 。除非有刻意做过这方面的总结，但是做过这类总结好像又不能代表什么

隔行如隔山，好多问题连看都看不懂

明确地说，除非有特殊要求，否则不会。
不然这个工作量招多少人都不够……实际上大多数版本之间的差别非常小，还是得聪明地减少工作量

1、在做接口自动化的过程中，参数的数据应该从哪里来比较好。是写死（这种切换一下环境就不能用了，不太好对吧？），还是从数据库里提取？（那如果数据库里有脏数据，会造成测试接口返回信息不准确吧？）

参数数据主要来源肯定就是你的用例设计，其他来源都是补充。补充来源可以是线上流量（access log 里面可以抽取）、可以是埋点上报、也可以是数据库数据。但是关键问题是补充来源的数据是否全部可行，要加什么筛选标准，肯定不是随便一条数据就能拿来直接用，一方面有些数据涉及用户隐私安全，一方面有些数据不完整，一方面有些数据根本没权限拿，所以很多时候最关键的就是搞明白筛选标准和你的测试范围，不是万能的。
【是写死（这种切换一下环境就不能用了，不太好对吧？）】没看懂你说的写死是什么意思，是人为确定的参数？为什么切一下环境就不能用呢？能不能按照不同环节做兼容？还是说你的环境本身就有问题？

2、如果是动态数据，比如需要上一个接口查询商品，下一个接口添加购物车。如果上一个接口出问题，那么下一个接口也跟着出问题。这种接口传参怎么样比较好呢？

上个接口出问题用例应该直接报错结束吧，没什么特别的方法。上游你的控制不稳定，自然就不用想着下游能好过。这个解决的下手点不在于接口怎么传参，而是确定前置条件有无满足

3、请问你们已经落地的接口自动化，是在测试环境跑还是预发布、生产环境呢？因为感觉做出来只在测试环境跑，发现不了线上的问题。整个接口自动化意义不大。

全量用例是在测试环境跑，我们内部的预发布约等于生产环境，生产环境只跑很小一部分，而且都是读接口。在线上跑写接口就是给业务加脏数据污染，纯纯地坑研发，不仅可能发现不了线上问题，甚至可以引入问题让别人排查半天。这里的建议是把思路打开一些，发现线上问题除了接口自动化（巡检）外还有很多，比如监控、用户反馈跟进，更牛逼一点可以是舆情监控等手段

4、如果在线上跑接口自动化，涉及到钱的接口，要怎么去跑呢？

基本原则是涉及到钱就别在线上去跑自动化，出问题就是事故，老老实实线下自动化或者线上手工验证，不差那么点工作量。一方面钱相关的一般是线下有 mock，自动化会比较安全倒还好，但是线上没有 mock，第三方支付也很少会给你在线上开这样的测试口子，所以就别去较劲，要是自动化把别人的接口打挂了还要担责；另一方面，如果线下测完了没问题，线上还出问题，我觉得可以想想为什么两者的结果不一致，再去尝试排除这些差异点，至少保证己方是没责任的。建议先了解一下依赖的财经支付方在线上有什么限制再考虑

这三角关系很乱，我没看懂为什么研发部门老大会问为什么不解决延期处理问题，ta 是在问产品还是在问测试？

解决问题的到底是测试还是产品还是研发？

研发老大跑来问测试为什么不解决延期处理问题，我怎么感觉他思路有点清奇。不知道是问题里写错了还是咋样

看不懂问题

单纯拉个开源项目就是一顿看，效率很低，建议有目的性地看。
比较实际的，testerhome 上不是有一些开源测试平台吗，这些咱也熟悉，你就看他们的代码，想了解哪个功能的实现就看哪个。
这样很快就有感觉了，主要训练到一些全局搜索、调用关系猜测、常规模块实现思路等基本技能。
看多了，有些操作就如同肌肉记忆一样，实现什么功能需要考虑什么细节。

• 好
  • 全局效率更优，专业的人做对口的事情，不容易被其他事情分心
  • 不同团队的职能更加单一更容易管理
  • 需求集中到工具部门，可以从全局决策集中投入人力搞，同时工具的收益更容易被量化
• 坏
  • 破坏整体技术氛围，有综合诉求的人才会加速流失
  • 工具部门无法以同样优先级支持不同业务线的特殊需求，所以更倾向于选择通用需求或者核心部门的需求去做，一方面通用就是不好用，另一方面总有业务线的需求不受待见

具体要看公司发展到什么阶段，要 case by case 分析。如果公司只是很早期的阶段，这样做无可厚非，因为人本来就少，业务线内部重复建设再浪费一些人力确实在 CTO 眼里是不合适的。如果是其他阶段，说法又不一样了。

观感：内容写得很丰满，但是看不到重点，整体偏罗列没组织，给人的感觉是什么都做但是什么都做不深，是事情的参与者而非主导者，含金量打折。

修改意见：

1. 「内容做减法，一些常规的工作可以直接删掉，或者合并在一起」
   • 如 xx1 项目的 1、2、3、4 点，典型如【负责编写测试计划文档】，【负责编写测试结果分析总结文档】，这些都是测试同学最基本的工作，写和没写区别不大，建议删除 2、3、4 只留 1。要是真的不想删就合成一句话，如果最终合并成诸如【负责同测试团队共同构建测试各阶段质量规范标准的定义、编写测试计划文档、编写测试结果分析文档】，当我没说……
2. 「项目经历中做好分类，每一个项目中突出一个重点」
   • 明确区分出 主导 和 参与 的区别，突出你主导的东西，如果全都是你主导的话，那这 3 年经验应该胜过不少 5 年的人。首先需要把事情分类，粗的类别可以是【业务测试】和【自动化】，细的类别可以是【流程规范】、【质量卡口】、【线上监控】、【xxx 自动化】等，这些就自行分类好了；然后突出主导的事项，项目中给出持续时间，肯定有些项目长有些项目短，到时候面试也重点引导面试官往你主导的比较熟悉的工作去问，对你也是有利的，不然问到不熟悉的一下子问死了。另外，技能列表也要做分类归纳。
3. 「数据导向去阐述项目，做到心里有数」
   • 这个是加分项，对于 3 年的同学没有数据导向的思维也不意外。要呈现的感觉是：发现问题 -> 数据上阐述问题（如测试代码覆盖率很低，只有 xx%）-> 数据下钻细化，确定子任务的数据预期（如测试代码覆盖率低，可能拆分为缺失用例补充、冗余用例优化、手工用例自动化等不同提升方式）-> 每种方式贡献了多少数据，为什么会有这样的贡献 -> 最终收益结果。介绍的时候可以这么去介绍，简历上不需要写得这么详细，这个只能自己思考怎么去呈现了。

字节的后端 golang 就是默认语言，不过后端测试对 golang 的掌握度也没有特别要求，毕竟实话实说还没去到帮研发改 bug 的程度

全世界的大厂都在搞 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. 单车智能和车路协同，应该不是此消彼长的状态，最终状态猜测是部分路况复杂的需要车路协同，部分路况简单的或许可以单车智能，两者在成本上有多大差距？