近两周我的面试非常多，大概一天一个。我是二面面试官，一面是技术面，有一定的难度。按道理来说二面的通过率应该比较高才对，不过最近的二面通过率可能不到50%，一面的通过率一般比较稳定保持在30%以下，所以两面全过的概率大概只有15%左右，可能更低。

那么二面的通过率为什么那么低呢？我想举几个例子就可以说明了。

二面我一般都会问一道用例设计题，大概是给你一袋盐，或者给你一件衣服，写出一些测试用例。

我的心理预期是15个可执行的用例。

有的候选人是这么回答的。

假如是一袋盐，那么要看看装盐的袋子是不是会漏？

这时候我一般会反问，那应该是要漏还是不要漏？很多候选人这时候会愣住，可能完全意识不到我为什么会这么问。

我这么问是因为我有个怪癖，那就是我希望测试用例都是可以执行的。可以执行的意思是，你要告诉我你究竟是希望袋子漏还是不漏。如果你希望袋子是不漏的，那么袋子漏的时候测试用例就是不通过的，反之也成立。如果你告诉我看看袋子漏不漏，那么因为我是很笨的，我不知道如何去执行这个用例，因为我不知道袋子究竟是需要漏呢还是不能漏。

与之类似的，在测试衣服的时候，有的候选人会回答要看衣服的尺码是不是合适。那么我会反问，对于L号，衣服多长是合适，多长又是不合适呢？这是因为合适不合适是没有执行标准的，对于一个身高不高的人——比如1米49家穷人丑的我——来说，L号是不合适的，太长了。而对于身材匀称的其他人来说，L应该是合适的。所以合不合适没法量化，加上又有模棱两可的是不是这样的词语推波助澜，这种用例执行起来是相当困难的。

所以写用例，要想可执行，首先的第一条原则是，不要包含一些似是而非的词语，比如是不是，要不要，有没有之类的。换句话说，就是用例里大概率要么包含是，要么包含不是这样的词。

比如

• 装盐的袋子不能（不是）漏
• 衣服的颜色是红的
• 衣服的材料是80%的棉，20%的涤纶

像这样的是或者不是的句型，我们可以称之为断言。

上面是最基本的用例设计，主要考察的是思维的全面程度，以及设计用例的最基本要求——可以执行，没有歧义。另外我还喜欢根据候选人的经历去问一些稍微有技术深度的问题。

如果有候选人有性能测试的经验，那么我会问他关于他被测系统的系统架构问题，架构图起码大致要能画出来。这是因为如果不了解系统的架构，那么测试环境搭建，测试策略的选择都会难以下手，测试的结果也比较难有可信度。

如果候选人的简历上写有精通/熟悉mysql调优，那么我就会问为什么mysql用主键去查询会很快？mysql的主键和数据都是怎么存储的？能不能画一下mysql的B+树的大体结构？什么是联合索引？给你几个真实的例子，你能告诉我索引命中的情况不？这些问题其实做过mysql性能调优的同学应该大体都会，没做过的话可能就是强人锁男了。

简历上写精通python的同学我大概率会让他在现场写一个生成器的例子，并介绍一下生成器的主要应用场景。写精通selenium测试的候选人我会随便开个网页，指定个元素让其当场定位。写精通appium的同学我会让其解释appium协议与webdriver协议最大的不同点。诸如此类，在兼顾考察广度的情况下顺便考察深度。

看上去是不是很难？

其实不然。基本上我不是很关注候选人技术深度题有没有答出来，如果是二面的话。大部分情况下，候选人无法通过面试的原因大抵都是用例设计能力不过关。要么设计的不够全面，要么就是基本没有可执行性。

技术不好的话其实是可以教的，用例设计的不好那么入职以后可能还没等到好好教就出线上问题了。

写好每一条用例，大概应该是很多测试同学厚积薄发的第一步吧。