感同身受，我前后大概面试了近 300 个校招/实习同学（集中在 20~21 年），22 年降本增效嘛，就没怎么面了……刚好分享一下我的感想

对于校招面试，有几个主要印象：

1. 校招面试绝对是一个体力活，体现在校招同学的经历高度相似，如项目经验，面试形式大多数只能从项目展开再去到八股文，要追求高效面试没有其他办法
2. 选择测试和测开岗位，确实就是研发岗自我感觉达不到要求，退而求其次的选择（这很正常，岗位要求差异是客观原因，同时对于没实习过的同学，本来就很难理解岗位之间的真实差异）
3. 测试和测开，很多电子通信专业的同学会投过来（本质上是和计算机有交集但不深入的专业，科班出身倾向于投研发）

我在面试时的偏好：

1. 代码题上，【逻辑明确的工程题】要比【奇技淫巧的算法题】更优先。算法题讲究个临场发挥，需要专门训练，而工程能力是在日常编码中积累，和学校经历更贴切
2. 面试表现聪明机敏优先，校招生看的终究是潜力和意愿，如果各方面发挥没有达到不及格的地步，人比较聪明我也是会通过
3. 以挖掘亮点为主，而不是刻意去寻找同学的缺点去证明他无法通过
4. 对于后期参与面试的同学，因为已经经历过很多轮其他公司面试的洗礼，在交流沟通的要求上我会稍稍提高一点点
5. 有真正思考过的同学，对于某个技术点，能表现出触类旁通，能沉淀出知识脉络，会使用工具去提高效率（如看书后会梳理脑图），我是很喜欢的

印象比较深刻的，就是遇到一个本硕都是化学专业的同学，在研二开始刻苦自学计算机，白天在实验室做化学项目，晚上在宿主自学理论知识和实践项目，最后拿了我们的测开 offer。

如果有这种问题，建议关注 Testerhome 官方微信视频号，上面有以前的大厂分享录播，可以看看别人家遇到什么问题，是怎么去解决的。还有历届 MTSC 大会的 PPT，拿点思路。

楼主应该是平时很少主动去了解业界，多去看看就知道了。

社区太棒了，这些周末的质量保障分享一定捧场！

我可能会答非所问，我的观点是：

1. 不要把技术和业务放在对立面，对于绝大多数公司而言，明确了业务是要先于技术，业务要活下来，才有技术的事情。
2. 对于个人而言，业务和技术的全面发展，我觉得要优于专精业务而荒废技术。毕竟我们本质上是技术人员，不是业务人员，技术技能是通用的，而业务技能可能和公司岗位绑定的。
3. 一定要分清楚，自己当下的产出和成绩，是依托公司这个平台才做出来的，还是靠自己做出来的，不要把公司的成绩归因在自己身上，容易膨胀。
4. 有些时候看着别人和老板关系混得很好，扶摇直上，不要产生负面心理，客观地去分析比较自己和别人的优缺点，尝试自己在老板角度去看待，再下判断，找出自己后续需要改进的点。不要忽略别人晋升背后的逻辑，同时无法改变环境那就改变自己。

最后的教练总结属实戳到心里去了

理论总结的不错~

针对偶发性问题，希望提前挖掘出来一般 2 种做法：遍历测试、探索测试。这些测试，都可以引入各种故障异常的条件，比如磁盘打满、弱网等。

那假设确实无法提前挖掘，想后置复现出来怎么做：流量回放（服务端流量 + 移动端操作的录制与回放）、埋点跟踪、日志回捞…… 利用这些手段去缩小排查范围，最后还是要人肉找出问题。

不要想着有什么神仙方案能全自动化，太不切实际，更多是经验导向，可能这个问题一出现，基于经验和对系统的熟悉就能猜出大概是哪几方面的排查思路。

固定机型，不过是少了一维变量，转化一下就是固定机型下的偶发性问题罢了，同样的思路。

有开源的话希望拜读一下

打卡~

字节的全球真机房好像只是内部使用，定位上确实是用来做评测和本地化验证

应该要在研发内部推广一下 git rebase，把无效的 commit 合并在一起，这样提交记录才干净且可 review
参考：http://jartto.wang/2018/12/11/git-rebase/

这篇之前发过的老文，把它搬过来当专栏~ 后面把 testerhome 当成一个自己沉淀的主要阵地了

本质就是 持续且高质的输出。

途径可以是：

1. 图文输出 - 个人博客、各类论坛社区、公众号、专栏
2. 音视频输出 - 各类视频社区
3. 代码输出 - 参与开源项目，或其他形式分享自己的代码
4. 行业大会

输出类型可以是：

1. 技术输出 - 最纯粹的技术，单点技术、技术体系等
2. 观点输出 - 趋势、新技术评论？
3. 领域知识输出 - 质量保障各方面
4. 经历输出 - 工作经历、自己的实践

当然，如果在业界本身做出很好的成绩，带出很好的团队，自然也会有名气。

看来我提了不少 bug

这么说也确实有道理

已阅

请问这次三个分享有公开的 PPT 可以下载么？

具体看 app 是怎么实现的，WiFi 和 移动网络很多时候会有细分的网络策略，这些策略可能会具体到底层网络协议等在网络传输性能方面的影响，大厂会有相关专门团队做网络策略优化，具体就很深了我也没什么了解。

如果 app 本身的实现没考虑这些，那本质上我理解就是弱网区别而已，WiFi 也可以去构造弱网。

看了一下没太理解是啥，不全知道你怎么用多线程。可能要贴一下代码才比较好判断，可以把代码中的敏感信息打码掉

可能他都没看完全文，只看了前面一点点就直接拉到下面评论了

都是典型问题，老板估计也是想看看你线下线上全流程有没有相关经验，我自己的理解

问题 1：测试的既定流程已经测完，仍然会导致一些 BUG 流入到线上，如何规避？
答：回答思路上，可以先完善线下测试的评估标准，就是楼主说的覆盖率、研发效能度量一类的。
不过，线下内部测试不可能解决全部问题，之所以这么说，一方面是问题挖掘有局限性，体现在场景很深、环境碎片化、数据复杂等特性上；另一方面问题修复同样有局限性，不是所有的 Bug 研发都会修，都修复到位。所以线下测试本身是不可能发现所有问题的，整个质量保障体系应该是线下测试延伸到线上。
那回到实际逃逸的 Bug ，首先在思路上，先分析逃逸的原因是什么，有多少问题在线下是可以拦截，多少是无法拦截，其中能拦截但逃逸的是为什么，能力不够成熟？能力没用好？流程有问题？评估不准确？最后总结归纳找出痛点（标准、流程、能力），这样就知道下一步的建设是什么。
上面说的是虚的思路，实际在做的时候就有很多细节，准入准出标准、发布测试能力方案，灰度发布流程，线上验证流程，线上监控建设，用户反馈舆情分析等等……

问题 2：一个产品已经由某测试工程师测试了两三年以上，但是还是会有一些体验/友好上的问题，如何规避此类问题？
答：体验/友好上的问题，看起来很模糊需要被定义，比如是端上的交互体验问题还是性能问题（卡顿、耗电），还是服务端性能机或时延问题，因为每个领域都有很多细拆的东西去探讨。
“规避” 这个词也非常模糊，应该要澄清面试官到是想问如何去挖掘暴露问题，还是如何去解决修复问题，抑或是两个都想问。
挖掘问题，白盒黑盒的形式都可以，移动端和服务端的形式又不一样，移动端一般有埋点统计、竞品评测、用户问卷、用户反馈 NPS 分析等。服务端可以日志数据打点、压测、拨测等。
修复解决问题，这个话题更偏向于研发，就不展开了。

请问白盒分析、路径规划是怎么理解呢，有公开的关于 X-Monkey 的资料可以学习么？（比如大会 PPT、录屏等）

谢谢~

我给楼主一下可实施的建议，这个问题很典型，研发团队质疑测试团队，不知道你们在干嘛，看不到专业产出，这时作为测试 leader，应该要有一点危机感了。

首先澄清观念：产出 ≠ 苦劳，结果是最终大家看的，过程辛苦和中间难度可以说，但要主次分明，否则听起来就不太专业，给人一种你很虚你在打感情牌的感觉。

回到上面的问题，一些实际有效的改进点：

现象 1：研发不知道测试在干什么，觉得测试人多价值低

• 原因：中间过程黑盒，做的事情没清楚外漏，说人话就是平时没给研发刷脸刷得够多，接入研发流程的地方不够多，计划对齐不够清楚，没有度量数据来说问题
• 解法：需求变更多——测试卡口，规范提测流程；测试很苦逼，自动化维护工作量大——数据说话，需求提测，缺陷数量，缺陷解决时长，测试执行周期等，网上一搜一大把。

现象 2：自动化掰不清

• 原因：没理清楚自动化的价值
• 解法：自动化能不能发现问题，有没有用——数据；自动化维护成本如何——数据；哪些用例要做自动化，自动化整体如何持续运营——机制、流程、运营计划

现象 3：研发觉得测试的人一直在 “学习”，其实就是含蓄的说在划水

• 原因：人员的工作规划不清晰，大家的目标不够明确
• 解法：1v1 沟通，明确每个人的职和责，每个人有固定的 Topic，定期 review 产出，而不能永远以储备知识为借口来说没产出