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

Web测试中的一些总结