聊一下测试工程师的招聘 出处: permalink 作/译者:黄 利 最近一段时间都在做集中招聘,参加了许多面试,累个半死。加上之前在团队中最近几年也做了不少面试,关于测试工程师招聘的话题,刚才没事特意google了一下,除了一些面试题外居然没有几篇心得方面的文章。上午招聘轮空,抽空写一下自己的看法,仅供参考。记得看完即焚。 所有团队的招聘,基本上都是要找最“合适”的人,而不是技术最强的人,或者最优秀的人。技术最强的人不一定合适,原因有很多,
1. 岗位一定的情况下,并不需要超出岗位能力特别多的人,完全没有这个需求。 2. 性价比问题。因为这些人比较“贵”。如果不给比较高的待遇和级别,无法吸引这类候选人。 3. 如果团队的整体技术水平是6分(满分10分),但候选人是个10分,你觉得他会很乐意跟水平是6的人合作吗?就像把詹姆斯请到cba来打球,即便你付得起薪水,詹姆斯自己也会很郁闷,在他眼中“不怕神一样的对手,就怕猪一样的队友”。 4. 对管理的挑战比较大,一般来讲,强人一般在融入团队方面有点小问题,除非遇见了比他更强的人。可以参加下文的非技术部分。 招聘的目的就是要找到最“合适”的人,跟结婚很像,要选择跟自己搭得上的,自己不帅还要那些脸蛋漂亮、身材火爆的,没用,早晚得离,弄不好还给自己带一顶绿帽。
在团队管理中也要充分发挥每个人的长处,扬长避短,让合适的人做适合的事情,才能让团队的贡献最大化(这是另外一个话题,以后有时间再写)。所以在招聘中要试图去发现候选人更多的优点,而不是找他的缺点。你很容易就用一道特别难的题把候选人给问住,或者使劲在他不熟悉的领域让他难堪,除了打击一下候选人的自信之外没啥意义。所以整个面试过程中,多数时间都花费在找优点上。只要不是特别严重的缺点,都可以通过后期的团队管理来弱化其影响。 技术方面首先要确定,测试工程师是一个技术岗位。为了彰显这一点,许多公司都把测试岗位的 title 改为测试开发工程师,像微软的sdet(software design/develepment engineer in test)、谷歌叫set(software engineer in test)等。纯粹的手动黑盒测试工程师早已不复存在。所以,技术技能是最基本的要求,我会针对初级岗位、高级岗位或专业岗位的不同要求来讲对招聘的要求。 代码能力对于测试开发工程师的招聘,由于其是基础岗位,要求也是最基本的编码能力,所以针对这类岗位,我一般会花费80%的面试时间在技术考核上。之前很多团队遗留下来的恶习,总是觉得测试对技术的要求不高,强调“Test Sense”的重要性,我不是否定它的重要性,但对于应届毕业生或者初级岗位的人,压根儿没做过测试,他有个屁的test sense,还不如去花点时间考核候选人的逻辑思维能力靠点谱。我一般喜欢让候选人现场写写代码,对绝对不是那种巨变态的算法问题,一般都是二分法、字符处理、简单数据结构相关的小题目,只是想看看候选人有没有基本的代码功底。在review代码的时候可以有针对性地对编码语言的一些关键字提问,看看候选人的代码掌控能力。基本上,只要能把自己想法通过代码实现且没有大的逻辑错误,在代码考核这一关都会放过。但如果要得到很高的分数,那必须在代码的可读性、异常处理、算法效率、可测试性方面有比较好的表现。我认为对于测试工程师来说,写代码的能力是必须要有,但不一定要求到达“精通”的地步,特别是在算法效率方面。很多的测试工作,都是在工程系统的验证层面上,你要那么牛逼的算法背景做甚? 未来转岗去开发吗?有人可能会在这里崩出来说了,编码语言不精通说明潜力不足。潜力是什么?潜力只能说明你现在能力很差而已,有很大的上升空间。幸亏我写这篇文章的时候只是沉溺在自己的思维世界里,否则还不被那些唱反调子的人给恶心死。好了,继续聊我的。具备了基本的代码能力,可以写自动化的程序或者工具即可。在测试程序的算法效率和巧妙性上花费太多的时间,我觉得这是一种不务正业的表现,除了有助于提高你的个人技术之外,对于公司的项目没有任何的价值,对于测试来说,其自动化用例的编写的效率要比执行效率重要的多。在实际的工作中,脚本语言是也是测试代码的最爱,life is short, test in Python,道理大家都懂。 测试思路(“Test Sense”)对于一些稍微高端的岗位,例如资深测试开发工程师或者测试专家的招聘,需要考核更多的测试思路和测试技术(参见下一段),不再是简单的程序设计问题。关于测试思路,在写完一段代码之后,会被要求来测试这段代码。这个时候,候选人的测试思路就会涌现出来,尝试尽可能多的测试方法与思路来测试这段代码。一般的候选人会考虑正常情况下的使用场景、边界情况、bad case等功能性的方面问题,这说明你入了门,知道基本的思路,而经验丰富的候选人,会在性能方面多考虑一些,例如performance test, load test, stress test(不知道他们的区别,我只能说你不是性能测试专家,赶紧去google一下吧)。在这里,肯定又有好事者会跳出来说了,哥是来应聘性能测试专家的,你让我写代码我就认了,你还让我针对这些代码做性能测试,我可是正经的性能测试出身,之前都是用的loadrunner、jmeter这些高端大气上档次的性能工具,根本不用自己写代码针对某个函数做性能测试。哎,遇到这种人,也不知道是他的不幸还是我的不幸,但在面试官面前我觉得你还是应该低调一些,如果你公开拒绝,我除了认为你比较坦诚之外还会认为你很有“潜力”,注意这个潜力是上一段中所说的潜力。废话少说,白盒的性能测试或者叫性能分析能力,在跟踪定位性能问题的时候特别重要,如果你还能把gperftool(google perfmance tool)、operfile等工具原理及使用场景告诉我,加分!性能测试绝对不是简单的系统方面的性能测试,能够指出整个系统的性能结果只是第一步,系统级别的性能测试工具loadrunner可以做到,但如果想定位到性能瓶颈所在、并提供改进方案那你就必须要掌握刚刚提到的白盒性能分析能力,从系统层面到模块级别、再到函数级别的问题定位,这才能彰显牛逼人的牛逼之处。就是比普通人多那么一点点。发现我的废话还真多,继续说测试思路的事情,优秀的候选人会提供功能、性能方面的思路,再优秀的人会提供更多的思路,例如稳定性方面,这段代码在持续运行24小时之后怎样?函数的响应时间、内存和cpu的占用情况还跟调用之初一样吗?是否符合预期?还有一些人会考虑安全方面的场景,在多线程的调用下程序会出错吗?是否线程安全?多进程的情况下呢,是否有共享的进程间数据安全问题,有没有被死锁的可能等等。还有很多测试思路方面的点子,在这里就不再一一罗列,你要感兴趣,我们可以私下交流。总之,对于有丰富测试经验的人(可不是工作年头),总是可以提出很多思路和方法,而获得这些知识的唯一来源就是实践,否则几个问题深入下去你就露馅儿,而在面试过程中“诚信”永远是底线,不可违背。 测试技术针对高级测试岗位需要一些有针对性的测试技术类问题。例如,针对前端测试岗位,在技术提问上会由针对性地在前端提问,没有自己写过前端程序的人也很难把前端测试做好,html/css/js/Wartir/Selenium/Webdriver等方面的知识必不可少,开源的工具没用过,没有关系,你只要能把类似的思路说清楚也可以。怎样精准定位web页面上得元素、如何得到这个对象而不是另外一个相同类型的元素、背后原理是怎样的,等等这种有针对性的问题很容易试探出候选人在前端测试方面的技术深度。再例如,一个测试工具开发的候选人必须知道框架、工具、平台的区别,框架如何提供接口给业务测试人员使用,哪些是框架要解决的问题哪些是业务测试自己要解决的问题,他们的问题域和解决方案都必须要了如指掌。类似地,在单元测试、api测试、安全测试、mobile测试、后端服务测试、大数据测试等方面,都会有针对性的问题等着你。相比较之前的代码能力,面试官一般更看中测试技术本身的掌握能力,代码能力只能说明你有潜能,而测试技术是未来会在项目中真实用到的技术,会真正地帮助到测试本身的技术。 技术热情在之前的面试中,遇到很多候选人,但被问及为什么来选择来做测试时,有些会说“我是女生,我很细心”。卧槽,适合不适合做测试跟细心有个毛线关系,我承认细心体贴是中华女性的传统美德,可测试真不是靠细心就能做的很好的。而且我发现有一批人的确就是这么想的,所以有必要在这里啰嗦几句。可以这样说,细心地观察是可以发现一个事物的某处缺陷,就像“鉴宝”节目中你要细致地观察,你细心你可以发现某个青花瓷藏品中是否砂底有釉,但如果你不了解元青花背后的知识背景即便你发现了这个缺陷你也无法做出正确的判断,相比较细心,更重要的是背后积累的技能知识。知识技能的增长因素中,很重要的就是技术热情。所以即便候选人技能还不到火候,但如果技术热情饱满,我还是会认为这样的人是真正有潜力的人,甚至会给一个通过。俗话说,“活到老,学到老”,背后依赖的就是热情。没有热情的人就像是一潭死水,工作对他而言更多的是一份工作,毫无声色与激情。在技术日新月异当下,没有热情,慢慢地你就“死”了。
|