水杯测试----误人子弟啊！！！欢迎指教

Mr.曾

近来有位朋友在面试时遇见一个问题，其实这个题目很多人都听说过，那就是水杯测试，
在51或者各大测试网站上都有过水杯测试的文章，不少公司也将水杯测试当做面试题目，其实就软件测试这个行业而言， 我个人觉所谓的水杯测试其实是一个失败的问题，不管是回答这道题目的人还是出这道题目的人，我都想说，水杯测试是对测试员的误导，也是一种错误的认可，就水杯测试本身而言是对用例的设计方法的一种教学案例，培训新人时也许用的到，但是我们有很多人却将这个水杯测试的功能无限放大，甚至希望通过这个测试来选择一些优秀的人才，来看看测试员是否具备测试思维，
    在这里我简单的分析一下水杯测试，首先水杯是一个产品，是一个实实在在存在的东西，如果你的公司是以实物产品为主打的，那自然无可厚非，不过与其说这样是测试，倒不如说是质检，质量检测，水杯测试和我们软件测试这个行业真的是没有多大关系。
    其次软件测试的基础，是对业务的了解，在测试的最开始的环节是对需求的掌握，是对业务流程的掌握，而试问水杯测试却是绕过了这两个环节，能够用在水杯测试上得测试思维实际上少的可怜，也许有些小聪明的新人会去问问有什么需求。是用来做什么的，但是这还是不够的，他缺少一个构成软件的流程，业务流程，或者说先后顺序，你会去考虑 没有加水的时候能不能喝吗？ 但是在软件的时候经常需要考虑如果没有上一个操作能否进行下一个操作，水杯的功能是单独的，而不是贯通性的，
在这里也引申一下，所有的实物测试均和软件测试有本质上得不同，如果我们只是针对功能进行测试的教学，那么是可以借用的，可如果是在了解测试基础后就不需要再去过多的研究，而公司招人更不应该将此作为一个参考，如果根据这类问题你招到得员工看似优秀考虑方面较为全面而实际上却不能将业务联系起来，其真实能力却还是需要培训。。。
   下面我们来对比已知的水杯测试经典用例
水杯测试
-------以下内容来自互联网，由于流传甚广，没有办法确定这个案例的由来--------
测试项目：杯子
需求测试：查看杯子使用说明书
界面测试：查看杯子外观
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或者细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24 小时检查泄漏时间和情况；盛上汽油（案例二）放24 小时检查泄漏时间和情况等
压力测试：用根针并在上面不断加重量，看压强多大时会穿透
跌落测试：杯子加包装（有填充物），在多高的情况下摔下不破损
震动测试：杯子加包装（有填充物），六面震动，检查产品是否能应对恶劣的铁路\ 公路\ 航空运输
测试数据：
其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法
期望输出：
该期望输出需查阅国标、行标以及使用用户的需求
说明书测试：检查说明书书写准确性
   相信这份文档不少朋友已经通过各种途径看过或者听说过了，然而实际上这种测试甚至可以列为无效测试，原因如下。
    原因之一，从软件的角度来讲，我们只需要关心能不能实现而不用考虑实现的质量，但是实物测试不同，大家都有喝过粘稠状的液体，比如玉米糊，乳酸奶等，一旦液体的粘稠度超过了一定的限度，我们要考虑的就不只是能不能被喝到，而是怎样喝道，假设粘稠度足够高，那么很有可能这些物质就会粘在杯底，不管是喝得时候还是对水杯做清洁的时候都会极为不便，这一点是功能度。
   原因之二，水杯作为日常生活中离不开的生活用品，与我们的健康息息相关，而我们的用例思想还停留在产品的使用上，这里面就有一个影子，因为软件关心的就是能不能使用，毕竟不管软件能不能使用都不会影响到我们的健康，而水杯不然，这里我提出一点，水杯装的液体在什么情况下不会影响到人体健康，比如塑料杯在装开水时就会因为化学作用产生一些对人体有害的物质，纸杯在温度过高时，内部的一层油膜也会溶解在液体里，诸如此类的因素在软件上都是不必考虑的因素，而作为实物来讲，确是不容忽视的因素，这一点是针对所谓的水杯测试的安全性。
    原因之三，可靠性，从资料中显示，在这里要记录水杯从不同高度的损害程度，其实这里有原因二的因素，我们可以将此理解成破坏性测试，要做的就是对水杯照成破坏，可是有些破坏是肉眼难辨的，我们将玻璃杯放在火焰中灼烧，一段时间后取出，你会发现玻璃杯实际上没有什么变化，但是这个玻璃杯已经不能使用了，因为里面有有毒物质，而就软件而言，1就是1,0就是0，是不应该存在模拟两可的情况的。
    原因之四，可移植性，软件上得可移植性实际上是指系统在不同的运行环境是否能够正常运行，而水杯不是，除了放置的地方，还要考虑其他环境，比如放在水里，你依然能做喝水的动作，但是很显然这是不必要的，而置于凸起得位置，要如何判断能不能正常使用呢，你依然可以往里面装水，依然可以做取水喝水的动作，但是却也会打翻杯子的情况， 再看置于火里，如果我们默认材质是不能燃烧的，也就是在火力依然能保、证水杯的完整，可是温度的因素你又不能不考虑，你敢用肌肤去接触100多度的铁制品吗？
   其实很多情况我们自己心里仔细想想不难发现里面的不合理之处，我们是做软件测试的测试人员，思考问题的角度抛开行业业务不谈，至少我们思考问题的出发点是系统的质量，完整性，可使用性，而实物的测试要考虑的问题与我们要考虑的完全不同。
   毫不夸张的说，我们拿着所谓的经典水杯测试的用例去生产水杯的工厂给懂水杯的人看，一定会被骂的狗血淋头，对于这些做实物的人，我们的经典用例就是外行人不懂乱说，水杯需要考虑的长宽高，弧度，面积，体积，容积，还有符合国家的相关规定，这些都是我们无法获知的，或许有朋友会觉得这只是我们发散的思想而已，我相信这样认为的人不在少数，我也只能说，最关键的地方你没有考虑到，你就算想再多的地方又有什么用，为了这篇文章我查阅了不少水杯测试的资料，大家或多或少，有的夜的确可以列为经典，然而即使这些经典的用例也完全离开了水杯测试的基础，完全没有考虑水杯测试的一个核心，除开上文我多次提及的对人体的危害，还有国家制定的各种元素成分，材料成分，这些东西是否超标才是水杯等一系列实物测试的核心思想。
   而我们将水杯这类实物测试放在软件测试上并以此来锻炼测试人员的思维发散本身就是错误的，就好比一个男人穿上了女人的衣服，不管你怎么要求得到的结果都是不伦不类的，四不像。
按照软件测试的思路写出来的水杯测试用例，既不符合水杯的实际情况，又违背了软件测试的基础。
上文我从水杯的实际情况来谈论了下水杯测试，下面我们再从软件测试的方面来提及下。
   因为大家都是同行这里我就不在一个测试点一个测试点逐个对比了。
   有过工作经验的朋友都知道，在实际项目中，测试人员首先要做的就是确保业务能够正确执行，也就是一个业务流程能够正确的走通，而不是走到一半就走不动了，单一的功能点测试其实是很低级的测试，基本不具备过多的测试思想，而对实物，对水杯，是没有办法去考虑业务流程的，你会无聊的去设置一个流程看看水杯没水能不能到水吗，但是在系统中我们就经常需要思考没有完成这一个步骤能不能执行下一个步骤。这也是为什么大家都在强调身为测试员一定要对业务足够了解，不出意外测试人员对项目的了解程度是仅次于甚至超越项目经理的。
   我相信有人还会认为，这个水杯测试只是发散给新人的锻炼思维，可是我还是想说，虽然大家公认软件测试很简单，易学，但也不要将软件测试的基础定位在功能点的实现上，要知道现在通过功能点直接发现的缺陷越来越少，更多的开发人员在发布版本之前都会进行自测，而自测的内容往往就是功能能不能实现，按钮能不能点击，能不能进行操作，身为软件测试人员的基础应该在业务上，核心思想也应该 是从业务流程上出发。
   再来看水杯测试，设计出来的用例没有业务可言自然也就没有业务流程，软件测试的基础都不曾体现，如何称为经典测试？
   除了四不像之外，我实在找不到语言来形容了，用软件测试的思想来为实物设计测试用例，既不满足实物测试的基础，也不满足软件测试的基础。用实物测试来锻炼软件测试的思想，这种锻炼出来的思想在实际项目中所设计出来的用例其价值，其覆盖率，其有效性可想而知。。。。
   谨以此文，提醒广大的新人朋友不要盲目的学习，也希望同行朋友能够从软件测试人员的角度再来看看“水杯测试”是否真的堪当“经典用例”
   当然，写此文的目的也只是希望能结交到更多的测试的朋友，大家一起探讨，一起进步，虽然之前的几篇文章效果不是多大，但还是希望咱们做测试的，大家多多交流，毕竟测试的体系尚未完善，还需要我等添砖加瓦。
   如果觉得我写的不错，那就多介绍点朋友一起交流学习，如果觉得我写错了，那就将你的想法告诉我，我们探讨下，大家一起研究下，我相信如果10个人单独做同一件事很有可能10个人都会做错，但10个人一起做一件事情，那么很有可能就会成功。
-------mr.曾
PS欢迎大家来我博客空间做客 多提意见，多评论，实在是不提倡闭门造车啊。http://www.51testing.com/?434556

cd07180001

最近面试的几家单位，都在问这个。当时就想到了这个帖子，并在心中默默鄙视他们的面试水准。

Mr.曾

回复 40# manbg


    其实 需求并不代表软件的所有，一般的需求只提供了功能点或者，较少的业务思想。优先考虑的业务问题需求上很难体现，因为业务常常伴随着的是一个流程。而对于水杯实在很难理出一条有价值的流程，这就造成了无意义的测试，顺着这个思路下去，在真的做测试工作时就会出现很多无意义甚至重复的工作量，不要奢望用例能实现百分百的覆盖，而应该有目的的覆盖常用的功能，至于一些较冷门的功能或者不牵扯业务的小功能是可以降低一些用例的使用的，可以参考一下2 8原则

manbg

这个不是要先问客户需求，然后才开始测试么？？

Mr.曾

回复 38# shiweiguangw


    这话说的好肤浅。。。。  黑盒测试 白盒测试。我们讨论的时候 似乎没有区分这两个的区别、
只是针对测试的角度， 黑盒测试和白盒测试只是根据测试技术的一个分类，基本的测试思想并没有什么不同。  并且 黑盒测试 也并不是你所想像的只是实现功能就可以。 比需求更深一步的了解业务流程，在模拟用户操作的同时 思考用户业务所需要的一个流程 ， 判断功能点的实现是否合理， 这也是黑盒测试，不要把黑盒测试看的太肤浅了。黑盒测试白盒测试只是从测试技术上来分的类 ，他们是平级关系，而不是你所谓的牛角尖
  或者 我没有明白你的意思， 同时也坐观其他朋友的观点

shiweiguangw

就是一个黑盒测试，非要联想到白盒，牛角尖而已

dgjunshuai

学习了  。。。。嘎嘎

千里

我也比较纠结为什么好喜欢问杯子如何测试，这明显是个硬件。

Nana.ceshi

学习···学习···

Mr.曾

回复 33# 云层


    这点 绝对支持 呵呵

云层

所以以后改问windows计算器吧。

Mr.曾

回复 29# ermine


    我没有否认水杯测试的工用，只是对由水杯测试散发出来的思维 对于软件测试本身的价值提出质疑

Mr.曾

回复 27# 云层


    云层老大 的话是对的，只是我们围绕水杯测试讨论的是对新人的误导性 以及 根据实物设计用例的价值性啊0 0   如果换成是一个软件  那么 回答的范围就和软件测试这个职业相符合，根据软件散发的思维形成的用例也有价值的多。

小鱼儿乖乖

确实是这样啊，LZ很强大。

ermine

回复 24# Mr.曾

所以我说,我不喜欢水杯测试这类的问题,但是,不能否认的是,多多少少,算是考察一个人的逻辑和表达能力.
也许测试点在软件上没有价值,但是一个人的思考能力是通用的.

就像从一个行业的测试到另一个完全不同的行业, 面试管一般也会问原来的公司,是怎么样测试的.
虽然不了解原来行业的业务,但是可以看看一个人测试的思路是不是很清晰.
PS:
就想云层老大说的,测试是逐步深入的,你要一个没接触过金融测试的人,哪怕他天天用到银行的产品,在一个做金融测试的面试管面前,也讲不够,会觉得肤浅.
所以还不如用大家都比较熟悉的实物.

shanxiwamm

光看着这么多人讨论的观点，都可以学到很多东西了。。。

云层

but你换任何一个被测对象还是一样的效果，这是需要逐步深入的，而不是测水杯不好！是我们测不好而已

Mr.曾

呵呵这就是我的观点了。 软件测试要考虑的东西在实际上实物那边完全行不通， 同样的实物要考虑的在软件上也根本行不通，也就是能够正确回答水杯测试这道题的 只能说适合做实物测试 也就是你说的水杯生产商，研制人员，不代表他适合做软件测试，而我们觉得一个人回答水杯测试回答的很好，非常好，在水杯生产商这类实物的生产圈子里 恐怕只是笑话而已

云层

其实总的来说是水杯这个例子一般外面写出来的用例太肤浅，会让很多新手认为这个问题就这点深度。

软件更大，要考虑的东西会貌似很多，就会产生软件测试>>>>>水杯测试 这样的感觉，但是水杯测试做深了一样很复杂的。

我们在这里说水杯怎么测，我估计专业的水杯生产商，特别是里面的研制人员，看到一定哈哈大笑，就你们这样测，能测出我这个杯子有没有问题才怪呢！单元测试都没，集成测试也没，就系统测试，而且测试的那么不系统。

啥时候我在玻璃原料里面或者加工工艺的玻璃成型上随便做点啥你都不知道，怎么保证玻璃里面没起泡，怎么保证玻璃柄能喝杯子结合在一起？

Mr.曾

ermine   我不反对你的说法哦，只是你的说法和我的说法实际上不存在冲突，我的观点是水杯测试确实能考验到人的思维，但是 这种思维对于软件对于新人来讲是否具有价值，排除特定的行业，你针对水杯测试所考虑的测试方向在软件行业是否有用，当然我的观点很明显， 多数根据水杯等这种与软件无关的实物考虑的测试点在软件上市不具备或者具备极少价值的，