给软测社招应聘者的建议

​

关注 BeTester ，学习更多知识

让碎片成体系，让测试更专业

得亏HR的大力挖猎，本周三邀请到一位资深软件测试工程师（本文暂且称其老李头）进行了深度沟通与交流，我们在面试结束后直接与老李头表达了强烈的邀约，衷心希望老李头能够加入到我们团队中来。我认为这是一次绝佳的面试体验，即便我们早早进入老李头设下的圈套。

简单介绍下老李头的背景，老李头2010年毕业后先在华为工作四年，从事测试工具开发工作。2014年加入到腾讯至今，在五年的时间里始终坚持为测试提效而努力（至于老李头在腾讯的职级恕不能透露更多）。

究竟在这一次面试过程中，老李头是如何击破我们的防线？容我一一道来。

一、开场白

简单扼要的套路：我是谁，我来自哪里，我做了什么。

各位面试官好，我叫老李头，目前就职于腾讯科技CSIG下的xxx产品测试负责人，主要工作内容是负责xxx产品的质量效率提升工作，如组建了xxxx实验室用于提升xxxx的测试，使得例行的xxx测试内容从xx人天降低到x人天，并且人力和物料成本大大降低。

腾讯之前，我曾在华为担任4年的工具开发工程师，负责MTG产品核心算法的开发与工具推广，目前已从运营商BU的探索型项目转为2012实验室项目在全公司大力推广。

短短的两段话里，重点突出，引导着面试官向腾讯的质量效率提升及MTG工具的问题上来。之前在《给应届软测应聘者的建议》说过，自我介绍内容并不重要，重要的是让面试官在倾听过程中产生愉悦感。

让面试官愉悦地倾听体现在：声音洪亮，吐字清晰，说话流畅，自信演绎。

二、试探阶段

在老李头完成开场白后，我们相互之间的信任感实际还没有建立起来，于是面试官开始一轮试探，探究老李头的真材实料。稍微汇总了当时的问题：

1. MBT与MBD（Model Based Development）的区别是什么？有了解过工业级MBD的实践吗？
2. 使用MBT中，使用的核心UML图是哪几个？选择这几个UML图的原因是什么？
3. 请说出dcot模型的自动生成测试用例的逻辑，并与微软PICT工具进行对比。
4. 如何定义每个节点的扩展数据？自动化脚本如何与MBT结合？
5. MBT的模型与产品需求模型如何关联？二者能否关联？
6. MBT生成出来的用例如何与测试用例管理系统关联？每次自动生成的用例如何与上次生成的用例结果进行比较？
7. 推行MTG工具过程中遇到的最大阻碍是什么？目前MTG所取得的成果如何？
8. 在腾讯，你取得了哪些自我感到骄傲的成果？
9. 你在开发xxx工具时，是如何迭代优化的？
10. xxx工具推广以来，实际产生的效益是什么？目前的应用范围是多大规模？
11. 你是如何开展音视频同步测试？业界主流的测试手段有什么不足？
12. 如何评估工具开发的所带来的效益？如何进行ROI分析？
13. 简要说一下华为和腾讯的开发模式差异以及各自的优劣。
14. 你认为华为和腾讯的测试技术，哪一家更有优势。
15. 什么原因让你离开华为？又是什么原因让你想从腾讯出来寻找其他机会？

在经历了这十多个回合的针锋相对，作为面试官的我们逐渐卸下防备，慢慢对老李头的专业技能产生认可。作为面试官，我们会依据应聘者简历上的内容循序渐进地试探与深入了解。

在相互试探之后，双方逐渐建立起了信任感，尤其是在面试过程中，我会不经意间透露出我也曾在华为工作，也曾使用过MTG工具。这样我们之间在某个时空产生了连接，使得双方的信任感进一步加强。

本次面试重点突出了MBT工具，这是笔者认为后续测试的很重要的方向（模型化）之一，也为了再次强调之前UML专题的重要性及对未来的展望。

三、交流阶段

结束试探阶段后，我们会考验应聘者在面临新的困境，会如何破局，会如何化腐朽为神奇。我们给出了几个假设场景：

1. 如果你加入到一个全新的团队，重新开发类似MTG的工具，你会如何开展？
2. 在推行MBT工具过程中，遇到开发、产品 甚至是测试团队的阻力，你会如何继续推进？
3. 相信你对我们公司产品也要一定的了解，如果让你深入负责A模块的测试，你会如何实施？
4. 如何考虑MBT的下一步发展？是否能与 AI（人工智能）结合？

在交流阶段，面试官更多地会把自身工作中所遇到的困难或未来的工作期望展示给应聘者，考察应聘者在模拟的场景下，能否结合自身经验，给出一个合理的解决方案，并且能够契合应聘单位的实际情况。

稍让我意外的是，在讲到推广MBT时，老李头先给我泼了冷水：老李头认为MBT并不是适合所有团队，团队需要具备一定的知识储备。同时老李头认为，在实施初期，测试设计工作将会比以往带来更多的负荷。

在这个阶段，应聘者已然不再是应聘者，面试官也不再是面试官，我们会像一起共事的同事，在讨论部门的发展方向以及技术的解决方案。

四、解惑阶段

原以为“交流阶段”结束，就意味着面试的结束，最后老李头还给我们上了一课。

起因是，我们在探讨如何有效评估代码覆盖率有效性时，老李头突然说：曾经华为一位美国的资深工程师跟我们讲，纯唯覆盖率会丧失团队的原动力。

1. 首先，即便代码的语句覆盖率达到100%，很有可能是创造出来的数据，其质量大概率远远比80%的覆盖率差。开发工程师少写一行代码，就能进一步提升覆盖率。
2. 其次，功能代码的实现本就是开发工程师，让其对着正确性未知的代码进行测试，缺乏有效的说服力。
3. 最后，代码覆盖率只是检测哪些代码被测试过，哪些没有测试过，但是无法说明哪里有遗漏代码。

有时候我们很容易陷入到知识的诅咒当中，这时就需要有人不断给予我们反馈与方向上的指引，让不偏不倚，始终坚持正确的方向。

五、小结

在笔者有限的面试经历中，这绝对是一次充满乐趣的面试。面试并不去刻意刁难应聘者，而是去挖掘应聘者所潜藏的能量与应聘岗位的匹配度。

同时，也正因为这次面试，让我更加坚定对面向模型测试的决心。

---- 更多文章 ----

• 给应届软测应聘者的建议
• Stack Overflow 2019开发者调查报告