功能测试面试指南.docx
《功能测试面试指南.docx》由会员分享，可在线阅读，更多相关《功能测试面试指南.docx（10页珍藏版）》请在冰豆网上搜索。
功能测试面试指南
功能测试面试指南
功能测试面试指南
功能测试求职者要想要取得面试胜利，把握面试指南很重要，下面阳光网我已经为你们整理了功能测试面试指南,希望可以帮到你。
功能测试面试指南
你将和谁交谈?
在面试中，你通常会遇到三种角色。
这些角色会是一个人或者多个人，取决于公司的大小：
软件工程师
工程师经理（技术leader，中级经理，总监）
高层领导（VP，CTO，CEO，部门经理）
对每一个角色我都有不同的问题，我将在下面一一列出来。
留意我有时会重复用同一个问题问不同的角色然后看看他们的回答有何不同。
这是一篇很长的文章，所以它的意义更多是作为参考，而不需要通篇细读。
假如我今日要去参加面试，我会带着这篇文章并在面试期间参考一下。
这些问题中的多数都没有一个"正确'或者"错误'的答案。
它们是用来关怀你了解这家公司、以及其文化、流程和组织。
它们通常也作为交谈的开始，这在你面试中出现大脑短路时特殊有用。
作为礼貌，我常常在面试一开始就告知面试官我希望有一点时间来提问。
这有助于他们合理支配时间。
通常，他们会在面试的最终让我提问，所以留意面试的时间支配，也让他们提前意识到你的意图。
问完每一个问题，停顿一下，问一下面试官你是否可以继续提问以及面试还剩余多长时间。
软件功能测试工程师的问题
1、每天你怎么知道需要做什么事情?
这个问题的目的是确认功能缺失。
我希望从2-3名工程师哪里获得答案。
假如公司的领导说他们遵循特定的流程，但是工程师却不谈这个流程，那是一个功能缺失的迹象。
假如从不同的工程师那里得到不同的答案，那是另一个功能缺失的迹象。
在一个高质量的团队中，这个问题我所得到的回答是一致的。
每一个开发者都知道这个流程，并且这个流程足够轻量级到对工程师提供关怀而不是压制他们。
好的回答示例（还有许多其他的）：
"我们会制定N-星期的sprint，在每一个sprint中工程师会提交一系列的功能和bug修复最终交付。
每一天我们会相互汇报进度。
我们有一位杰出的产品经理负责和客户交涉，以保证我们优先开发功能和修复bug。
'
不好的回答示例（还有很多其他的回答）：
"我到办公室然后看看哪里需要救火。
大多数时候我都被紧急状况中断。
'
留意我没有提到"Scrum'或者其他特定的方法。
相比实际的日常开发怎么完成，我对公司在他们的过程中所使用的标签没什么兴趣。
2、你用什么来做版本管理?
好的工具是好的团队的一个指示。
假如一个团队在使用一个古老的版本把握系统，他们或许还在使用一堆其他过时的工具。
而且，他们可能不重视良好工具投资所获得的效率提升。
紧接着一个很好的问题是关于工作流。
你使用分支吗?
你宠爱使用rebasing还是merging（git术语）?
这些问题会告知你他们所选的工具有多么专业，这将会告知你很多他们的娴熟程度，反过来告知你假如你接受这项工作，将会有什么期盼。
例如，你将是"本地的git专家'还是你将向名副其实的LinusTorvalds学习?
这个问题可以引发一场通用工具的商议 ，这通常会给你一些好的见解。
3、在这里工作你宠爱的是什么?
强回答：
我从我的工作中获得许多满足。
强回答：
在工作中我们有很多乐趣。
强回答：
我宠爱和真正聪明、友好的合一起工作。
强回答：
管理敬重工程师。
强回答越多越好。
我不必获得以上全部回答来给公司打高分。
请记住，有些人不是自然而然的"装腔作势'，所以在这里你可能不会获得精彩的反应，这可能是正常的。
但是假如我听到了类似以下的回答，并且没什么强回答，我会担忧：
弱回答：
它付我工资。
弱回答：
我不需要很努力的工作。
弱回答：
这里交付没有太大压力。
弱回答：
即使我犯了大的错误也没关系。
弱回答：
（静默）
不要以为是我想象的这些回答。
我在真实的面试中听到过这些回答。
我不会听到这些弱回答就自动将这家公司看成不好的公司，但是假如只有这些回答，我通常不会考虑这里。
4、你写单元测试吗?
在通过一个团队的单元测试实践对他们做出结论时要很留神。
假如在我问道单元测试时一个团队特殊兴奋，这通常是一个好的迹象。
另一方面，假如他们不能解释为什么要使用单元测试，或者说单元测试的缺陷时，这是盲羊教条的一个迹象。
假如他们提供一些不好的理由来解释为什么不写单元测试，如"我们没有时间'，那对我而言是一个不好的信号。
假如工程师告知我他们会写单元测试，并且他们尝试告知我单元测试的考量，比方需要多长时间来运行单元测试，他们有多少测试用例，以及代码覆盖率等，那对我是特殊有吸引力的。
这告知我他们有很好的工具，并且他们知道怎么使用这些工具。
另一方面，假如他们信任100%的代码覆盖率就能保证代码中没有bug，我表示怀疑。
我想提前知道在这家公司我是否会在一套浩大、陈旧、无法测试的代码上工作。
这将关怀我管理自己的预期，并且确定是否接受这份工作。
后续问题：
你宠爱单元测试还是集成测试?
你们有验收测试吗?
你使用什么（哪些）测试框架?
你宠爱吗?
你的单元测试需要耗费多长时间?
5、你使用持续集成吗?
我所知道的最好的软件开发团队使用Jenkins，Travis，Buildbot等工具。
假如这个团队没有持续集成，我尝试了解他们是否熟识这个概念。
假如他们不熟识这个概念，以我的阅历这是一个不好的迹象。
使用持续集成意味着这个团队或许信奉自动化，以我的阅历这通常是一个很好的迹象。
对于有的团队，这自然会引导到持续发布的商议 ，这是一个和持续集成相关但是又不同的概念。
假如是一个web开发者职位，我希望这个团队至少听说过持续发布，强的团队应当使用持续发布，至少有一部分在使用。
后续问题：
当CI报告失败时，你们的团队需要多长时间来修复?
你宠爱/不宠爱CI系统的哪一点?
你们的CI运行一次需要多长时间?
你有让它更快一些吗?
6、你们怎么测量?
这是一个开放问题，主要是看看这个团队是否花精力去测量他们的软件。
对于web开发团队，答案倾向关注性能，如响应时间、请求吞吐量、用户数量、客户端反应灵敏度等。
但是也可以商议 使用不同语言的用户数、浏览器故障、缓存命中率等许多其他的事情。
假如一个团队没有花时间去测量，很有可能他们没有根据真实数据来做确定。
他们可能已经提前优化。
我重视使用真实数据来做确定的团队，尤其是有关性能方面，但是它适用于很多其他方面。
假如面试官知道这些问题中多数答案，那是一个很好的信号说明这是一个优质的团队。
假如他们对为什么要关注这些测量没有任何想法，这是一个负面的信号。
再次声明，教条主义同样适用于此。
假如一个团队看起来已经锁定了一些不会产出价值或者可操作信息的测量指标，并且不能对此给出满意的解释，这可能是一个警告信号。
后续问题：
你们产品最重要的测量指标是什么?
你们使用什么测量系统?
（例如：
MixPanel，statsd等）
7、你们怎么觉察并修复bug?
强队通常都有专用的测试人员，团队的开发人员专注于质量。
一个真正的强队有强大的自动测试。
有的团队太小而没有专用测试人员或者自动测试，但是并不意味着他们是一个不好的团队。
当我问这个问题的时候，我是想感受一下他们的流程。
他们是否总是火烧眉毛?
他们是否有清晰的流程用于觉察bug并为bug排出优先级。
他们是否依靠用户觉察bug。
后续问题：
怎么为bug排优先级?
使用什么bug追踪系统?
（你厌烦它的哪一点?
）
你们使用Excel来跟踪bug吗?
（不!
!
!
）
在你的bug跟踪系统中你有几个bug?
修复一个bug你需要多长时间（最少、最多、平均）?
8、你们使用什么合作工具?
以我的阅历，优质的团队会使用许多合作工具。
他们常常使用聊天服务（Slack，IRC，HipChat，Jabber），代码Review服务（Gerrit，GitHub，GitLab，ReviewBoard），当然还有电子邮件。
我在查找每个开发者知道其他开发者在做什么的信号。
我不是在查找疯狂的详情，更多的是想了解一般意识。
此外，我宠爱看到集成合作工具。
最简洁的例子就是当自动编译失败时会自动发送一封邮件。
web开发团队的另一个例子是当严重错误发生时或当关键指标跨越某个阈值时自动错误log服务发送通知到团队的聊天室。
9、你们使用什么框架?
我个人偏爱框架两个方面：
1、我宠爱现代的东西
2、我宠爱新（对我而言）东西
所以假如一个团队在使用Motif开发一个AIX桌面应用，我可能不会感兴趣。
但是可能你会宠爱。
这是一个深刻的个人爱好问题，你应当对自己的爱好有一个很好的了解。
不管你个人对框架的爱好是什么，了解他们为什么已经选择了他们的框架特殊重要。
他们是跟风?
他们常见的更换框架?
他们的代码库就是一堆本月框架榜单中的代码积累?
他们始终使用古老的版本?
在为什么这个主题上，我希望了解在选择技术时开发者有多少自由。
管理层是否授权技术选择?
管理层是否听从开发者?
为了了解这些问题，我通常会问"你们是怎么开始在项目中使用框架X的?
'。
假如开发者不知道答案，这或许是一个不好的迹象，也有可能他们在公司的时间不够长还没有参与做这个确定。
我宠爱看到团队为他们使用的开源项目奉献代码。
这说明他们不仅能够使用开源代码，同样还足够娴熟到为它奉献代码。
这是我宠爱共事的开发者。
假如公司情愿为开源项目付费，那就更好了。
这说明公司理解了成为开源公民意味着什么。
假如团队重新造轮子而不是使用已有的工具来关怀他们开发项目，我会感到紧急担忧。
这条规则也有例外。
例如，当Facebook也曾开发他们自己的框架，我不会反对他们那样做的。
10、我们什么时候可以结对?
假如你真的想清楚了解与这个团队共事是什么样子，尝试真正的和他们一起工作。
我个人从未这么做过，但是我有一位伴侣就这么做了。
我觉得这是一个很棒的想法。
假如你想了解这个团队的每一件事情，去和他们一起工作半天。
这可能需要签署NDA协议。
假如这个团队情愿考虑这个建议，我觉得是一个很好的迹象。
你可能需要通过管理人员来支配，所以设计这个问题主要是想看看开发者的反应。
他们可能会感到震惊，因为他们觉得不值得提到管理层。
11、你的下一个最终期限是什么时候?
（由EvanFarrer奉献）
这个问题是希望更多的了解公司实际遵循的开发流程。
单从这个问题不会获得特殊有用的信息，但是当你添加上这些问题，事情就变得好玩得多：
谁来设置最终期限?
你的上一个任务在最终期限前完成了吗?
假如没有，为什么没有?
高质量的团队会一致同意并承诺最终期限。
随便设置最终期限是功能缺失的迹象，或者至少说明工程师在设置最终期限时没有发言权。
12、搭建一个全新的开发环境需要多长时间?
（由EvanFarrer奉献）
这个问题关怀推断公司花费了多少精力在开发者体验上。
一位新的开发者是需要数小时、数天还是数周才能拥有搭建好环境可用于开发的电脑?
这个过程是自动的还是手动的?
这将告知你这个团队在"支持活动'上的高效并不和开发工作直接相关，但是这种高效却有助于他们的开发。
团队有认真对待这件事情吗?
有的公司引以为傲的是：
他们有开发环境搭建流程，可以快速的让新的开发者在第一天就能提交代码到生产环境。
这说明公司很认真的对待为开发者提供无摩擦体验。
问经理的问题
1、您上一次写代码是什么时候?
我宠爱有强技术背景的经理。
无意冒犯我的MBA伴侣，我觉察我真正宠爱的经理就是那些已经做过我正在做的事情的人。
2、您是怎么成为经理的?
我宠爱选择成为经理的"经理们'，因为他们是真的乐在其中并且他们天生就是那块料。
而不是被迫处在那个位置。
我同样宠爱看到经理们专注于为他们的团队服务。
我最宠爱的经理是那些着眼于让团队成员的工作的更舒心，而不是想着"掌控'。
他们将自己当成关怀者和团队的守护者。
他们有服务的看法，并且他们将"让团队成员工作的更舒心'作为其最重要的工作。
3、您的工程师怎么知道每天该做什么事情?
由于我已经问了工程师同样的问题，我会将他的回答和经理的回答比较看他们是否一致。
假如他们的说法不一致，也意味着功能缺失。
最糟糕的功能缺失就是没意识到的功能缺失。
我信任去确认像这样的悬殊差异并修复它是经理的工作。
4、目前您的团队面临的最大挑战是什么?
他们通常会回答人员短缺。
因为这是一个一般而明确的回答（毕竟他们正在聘请），我会继续问他们第二大的挑战是什么。
我在查找进度支配脱节、产品质量问题、和人际关系问题等等红色标记。
你会知道这些红色标记当你观看他们的时候。
每一个团队都有问题，所以你得到的回到依靠于几个因素：
经理对问题的意识
经理情愿对你坦诚
这个团队问题的严重程度
5、您怎样衡量每一个员工的表现?
娴熟的经理人对待这件事情有很好的技巧。
最好的经理人在评估团队成员的表现时会很细心的搜集整个团队成员的反馈。
糟糕的经理人会根据自己的观看做出推断，而不会咨询团队成员。
6、您会做正式的绩效评估吗?
我宠爱为重视反馈并且关怀团队成员提高的经理人工作。
绩效评估会成为令人难受的或主动向上的体验。
根据我的观看，我觉得大多数人都将他们看做令人难受的。
一个真正杰出的经理人当然了解这一点，他会实行一些方式使得绩效考评杰出的完成，使你影响深刻并且情愿为其工作。
后续问题：
您能共享一次关怀某位员工提高其绩效的阅历吗?
在考评中是怎么指导他们的?
7、您每年都会加薪吗?
我知道为了和我对公司做出的奉献匹配，会对我的补偿做出调整，我也知道至少每年会做一次官方调查。
对于适用的公司，我会询问股权。
您会给我股票期权吗?
您会每年给我更多的股票期权吗?
有的.工程师不习惯问像这样的经济问题。
不要这样。
工程师通常花很少的时间思索这些问题，但是经理人总是在进行这样的面谈。
这些问题对经理人都不会不自由：
您怎么预算加薪?
您团队去年加薪的平均水平是多少（百分比）?
一年后我可以预期多少加薪?
最好状况，最差状况?
我不会将这些问题作为签署合同的一部分或者作为将来加薪的保证。
我只是想了解公司时怎么运作的。
我是必需要求为我加薪还是有标准的流程?
8、我可以将描述公司福利的材料带回家吗?
（由EvanFarrer奉献）
我知道大多数人都知道问这个问题，但是为了完好性还是值得一提。
大多数公司都会为你预备一堆材料或者一个网站为你描述公司的福利。
了解这些特殊的重要，因为这通常是你补偿的很大一部分。
这或许只适用于美国，我不确定在其他国家有多少公司为了刺激工作会提供医疗保险。
9、您会为您的员工排名吗?
（由MattRyan）
有的公司会将全部的员工依据最正确到最差的顺序排序，然后强行将确定百分比的员工划入"优秀'、"一般'和"差'的分类，并根据这个分类来确定其加薪和奖金（我没有这样做）。
我从未遇到宠爱这个排名的工程师。
这在大公司中尤为常见。
他会影响你和水平相当的同事之间的沟通，因为你知道某一天你会因为钱和他们竞争。
当我遇到这种状况时，或许不会马上认为这家公司就是一个糟糕的工作场所。
在这样的公司里，通常会有一些不公开的可操作空间。
问一问面试官他们怎么看待这个系统?
有的经理人会特殊坦率的说他们不宠爱这个系统，并且有的经理睬告知你他们为了整个团队的利益，会实行一些策略来"对抗'这个系统。
假如你遇到了这样的经理人，你可以不用理睬这个排名系统。
同时也请记住，不是每一个人都厌烦这个系统。
只是我没有遇到过宠爱这个系统的人，并不代表他们就不存在。
后续问题：
您真的以为你的员工中的那X%是"不好'的?
这对你的聘请过程有什么看法?
（这是一个大胆的问题-谨慎对待）
您应用某种曲线来确定表现最正确的人吗?
您使用什么标准来给员工排序?
您怎么知道这些指标搜集精确?
您怎么知道这些指标能够区分出表现最正确的人?
为了了解更多的信息，MattRyan对此有一篇特殊好的分析文章。
给高层领导的问题
我并不是总是和公司的高层领导交谈，尤其是大公司，但是当我这样做的时候，我把它作为评估公司财务可行性的机会。
我没有资格做这件事情，但是有一些明显的问题我有时会在面试中觉察。
此外，我想知道自上而下的文化是什么样的，因为这些信息会告知我公司怎么看待员工，正面的和负面的都有。
1、你们是怎样创立的?
我在努力了解公司背后的资金。
我想了解他们是否由风险投资，私募股权，公共股票或通过自筹的资金创立。
通常我可以在面试前弄清楚这一点，但公司的领导层常常会增加通过Google或CrunchBase找不到的见解。
2、你们盈利吗?
假如盈利，特殊棒!
假如尚未盈利，你们准备盈利的目的准备是什么?
有的创业公司会有盈利的准备，而其他的公司收购或者IPO查找出路。
后续问题：
过去几个季度/年的历史收入。
呈增长趋势吗?
影响利润率的风险如竞争，意外开销和意外的收入缺乏等。
跑道：
在筹集更多资金前，公司可以运营多长时间。
3、您对外包的看法是什么?
我想了解我所申请的这份工作在将来是否可能被外包，或者这个职位变成外包管理工程师。
我这里说的不仅仅是离岸外包。
承包商也算。
4、跟我讲讲公司文化吧
这是我用来调和工程师的观点与领导层的观点的另一个问题。
我正在查找可以作为能障碍迹象的差异。
假如他们节奏一致，这说明了良好的自上而下的沟通。
我想知道高层领导是否与海内外员工脱节。
我也想看看领导层是否坚决的远见并和员工进行了良好的沟通。
我最宠爱为有一个强大的，共同的愿景的公司工作。
一些公司特殊重视文化，这可能是件好事。
至少你会清楚公司的价值观。
对于其他公司，你必需通过隐含的，有时候是不言而喻的微小差异来了解。
公司文化是特殊重要的。
有政治斗争吗?
敬重专业吗?
敬重诚信吗?
强调加班吗?
5、你有什么来保障公司会胜利?
这个问题我是在查找真实的证据，而不仅仅是不实的市场宣扬。
假如高层领导告知我一些实际的数据如收入、市场规模和市值，这是一个好的迹象。
同样，假如我能通过其他渠道证明这些信息，那就是一个更好的迹象。
另一方面，这些数字可能表示特殊糟糕，还是在画饼。
6、你们的汇报结构是什么样的?
对我而言，这个问题最好的回答是一个简洁的回答。
假如能够绘制一个图表来解释汇报结构，我也会很满意。
我个人的爱好是是为小型，灵敏的公司工作，组织和沟通开销最小。
您的个人爱好可能不同，没有关系。
不管你的爱好是什么，这个问题都是为了给你提供你所需要的信息，以便做出明智确实定。
升级会员 