面试场景1

以小明为例

问：“假设你所在的团队负责研发一款手机计算器程序，你是这款产品的测试负责人，你准备怎么开展工作？ ”

小明听我说完后，考虑了些许时间，问到：“是不是要写测试用例？”

旁白：听到这样的回答会让我心凉，因为这个问题我只会对2年以上工作经验的人提问，所以如果面试者这么回答，说明了这个人起码理解能力方面有问题。

我接着提示：“小明，在答题前，你想一下，作为一个项目的测试负责人，一开始就去设计具体的测试用例，是否太片面了？”

听完我的提示，小明思索了一下，回答道：“我以前工作的时候就是这么做的。”

旁白：既然我这样提示，很显然就是没让你写测试用例。而这个时候如果再强调以前的做法，是不是在挖坑往里跳呢？

眼看提示无效，我换一种方式引导，又问：“那你觉得该怎么设计测试用例呢？”

小明自信地说道：“我要测加减乘除运算，开方运算......”

我不忍再继续听下去，打断她，问道：“你设想一下，如果用例设计完成了，你准备怎么样执行这些用例呢？”

小明：“就在手机上去执行啊。”

我问到：“什么样的手机？”

小明说：“就这样的手机啊。” 然后晃了晃自己的手机。

我说：“是不是拿这部手机就可以了，换一款行不行？”

说道这里，小明停顿了一下，若有所思的说：“对啊，你还没有说我们这个计算器程序应该运行在什么手机上。”

我：“现在你是测试负责人啊，你是否应该在设计用例之前，弄清楚这件事啊？”

听到我的话，小明不住的点头，刚才的自信开始消失，取而代之的，是眼神中的紧张。

我安慰道：“放松，你循着这个思路，重新来制定测试计划。我以为他会因此开窍，心中窃喜。

“我的计划是，在华为、iPhone、三星、vivo、小米、oppo上执行这些测试用例……”

旁白：听到这样的回答，差不多可以pass了。

我想说的

上面这个问题很难吗？据我所知，这类面试的题目是各大IT企业面试软件测试工程师的必考题，这类题目可以称之为测试设计，一般是要求应聘者测试一个大众化的产品（不局限于软件产品比如一直笔，一部电梯，一块表，一台银行ATM机等）。题目看起来非常的简单和直观，但它能从多个维度全面的考察应聘者作为测试工程师的潜力。正如上面大家看到的真实面试案例，如果应聘者没有系统了解科学的项目测试理论，就很容易因以前的工作模式陷入思维定势，无法自拔。

这类问题怎么解决/回答？其实方法流程很简单：

1.明确测试任务

2.分析测试范围

3.制定测试计划和测试用例

在上面的案例中，小明在做手机计算器程序的测试设计时，在没有明确测试任务的情况下，就盲目的展开测试用例的设计，这样，会引发诸多问题。

比如，在面试题目中，并没有明确产品可以运行在什么手机平台上，对平台的支持需求不同，测试的设计的差异性是很大的，所以，在回答该问题之前，先应该向面试官发问，明确产品支持的手机平台，之后，才能有的放矢的开展具体的设计（或者即使不问面试官支持哪些平台，在回答的时候也要说清楚先跟团队确定运行的平台）。再比如，应该明确产品的研发周期等信息，只有了解了项目进度安排等信息，才能制定有效的测试策略，在测试的深度和项目开发时间要求上取得较好的平衡。比如，有的项目是时间驱动的(Date-Driven)，这类项目的特点是预先制定发布时间，要求到了那天，产品就一定要发布，对这类项目，我们在设计测试计划时，就应该更多的考虑解决和项目发布相关的质量问题；另外有些项目，可能是质量驱动的(Quality-Driven)，这类项目的特点是对发布时间没有强行的规定，但要求产品的质量必须达到一定的指标，并且需要在发布以后，实时监控产品质量，那么，在测试中，我们不仅要做好项目当下版本的测试工作，还需要考虑构建长期、高效地测试系统和平台，保障产品质量能够实时度量。另外，明确产品的功能设计、产品的核心竞争力、可用的测试资源等信息，对于接下来做产品测试都是至关重要的。

那么问题来了，也许有的人会质疑，我招的是测试工程师，不是测试经理，不需要考虑这么多吧，如果按照我这种要求，怕是一年也找不到一个，况且的确有很多人受公司制约，甚至有人大学刚毕业，肯定回答不上来这类问题。

我想说，企业招人的目标永远都是奔着“合适”去的。我这么去面试，自然是因为工作中遇到的实际问题导致我不得不去关注这些。在实际工作中，经常会遇到测试人员接到测试任务以后，什么也不考虑就去测试了，测试完了以后告诉我工作完成了。 然后我问他这次测试任务的范围是什么？开发为什么要做这些改动？这些改动是开发自己提出来的还是客户要求的？如果客户要求的客户的关注点在哪里？这次改动具体改了什么内容？怎么改的？你觉得这样的改动合理吗？改动以前是什么样子的？......  这些问题最初的时候我问十个人，九个人都答不上来，还有一个回答的模棱两可。那么，从一个测试经理的角度，让我怎么相信这个测试负责人的工作是有效的？怎么让我相信他的工作覆盖率是全面的？我无法相信连改动原因、改动内容和改动方法都没有了解清楚的人，能很清楚的知道测试通过的准则。...... 同理，做测试前先思考是一种习惯，如果这个问题回答不好，我很难相信他在实际工作中会做到我刚说的那些（何况我提问的时候是不断引导的，这个问题也不会拿去问2年经验以下的新人）。

关于如何跟开发沟通确定测试范围，可以翻一下这篇博文：http://www.cnblogs.com/scios/p/5624707.html

也许还有人觉得，上面这个案例，提及的知识是一个“知不知道”的范畴。只要有所准备，就能做到从容不迫~

我想说的是，我在带新人的过程中，不断灌输这套做事的方法论。他们的确是“知道了”，但是真正用好还花费了很长时间。所以面试的时候也不要过于乐观，是临时抱佛脚，还是日常工作中就按照这种方式去工作，作为资深的面试官都能分辨出来。劝君不要抱侥幸心理。

也许还有人说，面试时间那么短，面试的时候受限于时间关系想不了那么全。

其实，这种情况不也说明面试者的思维不够敏捷，不是吗？毕竟面试官做了那么充分的引导。

面试场景2

问题：假设你是QQ这个产品的测试负责人，你怎么去测试QQ传文件这个功能？说一下测试点，你可以发挥自己的想象力，不必局限于它现有的功能。

这个问题，问过不下五十人，能在面试时回答出超过15个测试点的，坦白说一个没遇到。

多数应聘者都是想到哪说道哪。

我更想听到的答案有两种，一种是按照传文件的流程（客户端A-网络-服务器-网络-客户端B），一种是是按照测试框架回答（比如系统的说明从UI、功能、性能、兼容性、安装部署、服务器端、网络、安全。。）。

也许有人问，这个问题就是考察“测试思维”，实际工作中用不到那么多，或者只要准备一下，也能比较轻松的回答我这个问题。

测试人员最重要的素质是什么呢？ 的确存在有些人思维发散度很不错，虽然不会设计用例，但是很会找bug。但是这样的人可遇不可求的。而且通过面试去发现一个人的思维发散度有多好不太现实，我还是更保守的通过看一个人的思维模式来判断他是不是我想要的人。 我现在所负责的系统架构比较复杂，涉及到方方面面，测试过程中需要思考的问题，跟上面这个案例差不多。一个人是真的懂，还是临时抱佛脚，可以通过不断的深挖来发现。所以， 如果想要在面试时“不露马脚”，仍需要在工作中就培养这样的思维模式。

最后，国内很多公司存在面试官看“眼缘”决定是否录用。。。这样的情况不在本次讨论范围之内。

欢迎关注我的微信公众号和个人微信，如果觉得我的分享对您有所帮助，欢迎加我微信红包打赏一下。