测试的分类比喻
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
其实测试工作不一定只能通过软件工程进行理解，实际上，现实生活里我们都没有逃脱测试的魔爪，咱们就通过“陪老婆/女友逛商场”这个示例，比较一下几种测试方法之间的区别~~
黑盒测试：老婆从商场的某一个入口进入，你在商场外面等待，这时候商城对你来说就像一个不透明的黑盒子，你并不知道商场内发生了什么，你也不去关心里面发生什么，你只知道如果一切运转正常，结果是老婆带着一堆商品从某一个出口（可以与入口相同）出来。这是原定正常的情况，这时候我们就不需要管商场里面发生了什么，只需要知道老婆进去转了一圈，你的这月工资报销了，一切正常，这就OK了。否则，在多次逛商场（多次黑盒测试）过程中，频繁发生无法达到正常结果的情况，例如老婆与人发生争执、老婆带的钱不够、老婆有选择困难需要与你协商等情况的发生，这就需要相关人员（你）通过别的检测手段进到商场（黑盒）里进行检查解决了。
白盒测试：老婆从商场的某一个入口进入，你随着陪同进入商场，全程陪伴，这时商场对你来说是个白盒子，就是透明的，你可以看到他内部的全部细节。这时你要观察老婆购物的每个细节，了解其走过的每一步，发生的每个小情况，随时准备应对支付、拎包、与人对骂、按摩揉腿（我。。。已经写不下去了。。。）等突发事件，记录整个期间出现错误需要修正的问题（当然，整个过程你也不免出现走神情况，例如偷看别的美女，错过老婆喜欢某种商品的信号，结果可能就是重测。。。也就是再逛一遍），最后结果是，你抱着一堆商品陪着老婆从某一个出口出来，这月工资还是报销了。
单元测试：老婆进入商场后，专门盯着某一个专卖店，查看其是否有新品、是否有活动，一天去三次，一周去三天，一月去三周，各级别VIP全办齐，面对任何一个店员都可以刷脸，达到对该专卖店了如指掌，对店铺的任何细节都确保万无一失之后，再转向下一个专卖店……
压力测试：响应打折号召，原本互不认识的老婆们瞬间组成联盟，组团进入商场进行大量扫货，每天进行，天天坚持，持续一段时间，看商场是否顶得住，观察这种压力下商场是否会出现断货、服务员暴走、刷卡机宕机等问题。
性能测试：这个概念比较广，包括整个商场的运转稳定性，如能否做到每天开业、24小时开业、服务员被大妈折磨后的情绪控制能力等；商场安全性，保安能否保护顾客安全、防火防盗措施、小三专用逃生通道（例如程序里的特殊值、边界值处理）等。
因此，其实软件测试并不是什么新鲜的概念，我们在现实生活中，一直在对各大商场进行“集成测试”，大量的商场被老婆团们以各种苛刻的测试手段所淘汰。因此，各位都是伟大的测试人员，并且，这项测试是永久存在的，永不宕机的，不要幻想产品终版发布的那天到来。
共勉。
--------------------------------------------------------
2015.9.20补充吸收@Jasin Yip的建议，提一下回归测试：
每当店铺根据顾客需求（bug记录）上线了新品（修改bug）之后，老婆们需要到该店铺，进行全方位从新检查是否出现新的购物机会，并体验该店铺全部功能是否正常，如刷卡。。。不放过任何一丝消费的机会。。。
2015.10.12补充@Julia Jo 冒烟测试（Smoke Testing）：
经过我认真阅读（你信吗）冒烟测试的概念，我脑中浮现出如下画面。当我跟随老婆进入商场后，发现有几处新装修或新开张的店面，我与老婆立刻呈现出截然相反的面部表情，欢喜与惊恐，接下来进入店面（不可能出现无视路过的情况。。。），由于对这个新店面所知较少，所以没有既定计划，只是根据店面应该提供的服务（软件功能），进行随意闲逛、随意询问店员、挑选商品、疯狂砍价（如果具备此服务~）、完成支付（在劫难逃啊）等行为，整个过程并无特殊针对性，只是围绕店面应该存在的服务随意体验（测试），这好像是女生逛街的基本模式吧~如果发现哪里不合心意（无意中发现bug，即冒烟），基本上会立刻失去兴趣，呈斜眼撅嘴状（停止测试），等待再次装修后再来闲逛~
UAT测试：版本1. 老婆对长期坚守的某个商场非常有信心，因此就对家人、朋友、同事、陌生人一致推荐此处，于是各路被忽悠组队而来的“某某”观光团进入商场进行购物（测试），并表达购物感言（反馈）。版本2. 换个角色~你的男/女友，对你完成长期测试（我也不知道都要测试什么--）后，感觉这段感情可以上线运行了，于是就将男/女友带到家中，由家人进行测试审核（感觉有点跑题。。。），然后家人群体表达测试结果~
总之：不同的测试方法有不同的侧重点，虽然名称差别很大，也许实际上只是细微的形式上的差异。然而如同陪老婆逛街一样，虽然各种形式差别不大，并且结果都是一样（当月工资报销~），但是当我们对这些事情（我真的指的是测试。。。）从事过大量的重复体验之后，会发现，就是这一点点细微的差异，在面对不同的测试需求时却是那么的恰如其分。
反正这些测试方式不是强硬规定出来的，而是刚好这种测试能够测出当前存在的问题，所以需要进行某个方式的测试。所以，深入了解不同测试方式的侧重点，然后在适当的时候选择最合适的测试方式，最终发现隐藏的问题，这，才是核心价值。哪怕你用在教科书中没有的方式也是可以的，比如自己写测试脚本等。
就这样吧，看我写的多认真（完全没看出来），给个赞再走啊~
