拼多多测试工程师（二面）——用例设计

好不容易下定决心辞职之后，想去大厂试试。这段时间一直在准备去拼多多的第二次面试。一面是技术面，有一定的难度。按道理来说二面的通过率应该比较高才对，不过最近的二面通过率可能不到50%，一面的通过率一般比较稳定保持在30%以下，所以两面全过的概率大概只有15%左右，可能更低。

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

二面是一道用例设计题

大概是给你一袋盐，或者给你一件衣服，写出一些测试用例。

大部分人可能会这么想：假如是一袋盐，那么要看看装盐的袋子是不是会漏？

我可能会想，那应该是要漏还是不要漏？很多人可能会对我的想法愣住，完全意识不到我为什么会这么想。

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

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

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

 

比如

装盐的袋子不能（不是）漏

衣服的颜色是红的

衣服的材料是80%的棉，20%的涤纶

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

上面是最基本的用例设计，主要考察的是思维的全面程度，以及设计用例的最基本要求——可以执行，没有歧义。

如果对软件测试、接口测试、自动化测试、面试经验交流。感兴趣可以关注我们爱码小士，公众号内会有不定期的发放免费的资料链接，还有同行一起技术交流。这些资料都是从各个技术网站搜集、整理出来的，如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。

另外还问了我一些有技术深度的问题。

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

1.为什么mysql用主键去查询会很快？
2.mysql的主键和数据都是怎么存储的？
3.能不能画一下mysql的B+树的大体结构？
4.什么是联合索引？
5.给你几个真实的例子，概述索引命中的情况

这些问题其实做过mysql性能调优的朋友们应该大体都会，没做过的话可能就是强人锁男了。

让我在现场写一个生成器的例子，并介绍一下生成器的主要应用场景。随便开个网页，指定个元素让我在当场定位。让我解释appium协议与webdriver协议最大的不同点。

诸如此类，在兼顾考察广度的情况下顺便考察深度。

看上去是不是很难？

其实不然。

我觉得更重要的是用例设计能力。要么设计的不够全面，要么就是基本没有可执行性。

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

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