共计 1201 个字符，预计需要花费 4 分钟才能阅读完成。
对于黑盒、白盒与灰盒测试方法的了解，几年前我在某乎做过一个概念性的答复，过后提问者询问：如何跟非技术人员解释黑盒、白盒、灰盒测试的区别？
我的答复原文如下：
既然是对非技术人员解释，就不能用专业术语。
这样说吧，有个打孔机，相似这样。
纸条从盒子左方插入，从右方进去时，别离打出圆形、正方形、三角形三个款式的孔。某天，打进去的纸条，只有一种图形。
黑盒测试员只能说：“这个打孔机坏了！”
灰盒测试员把打孔机的盖子掀开，发现打孔机的造型原来是这样的。
于是他说：“机器仍能打孔，阐明主机没坏；三个桩子也都是好的；但只打印出了圆形，可能因为连贯正方形和三角形桩子的中央有问题。”
白盒测试员把机器拆开，查看外部的电线、电路、控制器等等，发现连贯正方形和三角形的电线烧坏了，于是说：“起因找到了，换根电线吧。”
彼时，我还是一位测试小鸟，在研习了不少理论知识后，答复了这个问题。当初，我算不上测试老鸟，但能算个测试大鸟，在工作中，越发频繁地接触这三种测试方法。
如果你要问我哪种测试方法更好，我不置评估， 每个人的口味不一样，他人适宜的不肯定本人适宜。
对于黑盒测试方法来说，是每一位测试的必备技术，没有谁不会：发现问题，抛出问题。
简略、轻松、疾速，是黑盒测试的长处，特地是在我的项目特地赶，测试工夫有限被压缩的时候——只须要抛给开发问题，剩下的让开发自个儿玩去吧。
但黑盒测试人员经常被人诟病只晓得点点点，抛开此类“鄙视”不谈，接着下面持续，咱们是不是疏忽了一个事实：我的项目既然赶，那开发的工夫亦不短缺，如果恰好遇上稍稍简单的 bug，并搭配不靠谱的开发，一个 bug 的生命周期可能会拉得极长，效率特地低下。
这么说，那用白盒测试方法呗，看代码，查起因，丢给开发后，留下一个高大帅气的背影，让开发心里默念——这个测试不简略。
白盒测试能够，但应用它时，你须要盘算盘算：
- 是否有短缺的工夫钻研代码以及和代码相干的环境部署、配置设置等？
- 付出和产出是否成正比，如同自动化测试，能达到高性价比吗？
白盒是一种抉择，但同样是一个难题。更别说白盒对于测试技术的高要求。
废话了这么多，你肯定会说：风风，你不就是旁敲侧击地举荐灰盒测试嘛。
我不晓得该怎么答复你，就像刚开始说的， 每个人的口味不一样，适宜本人的测试方法，最醇最香。
但说实话，日常工作中我应用灰盒测试方法的场景绝对较多，总结来说，就这么一个流程：
发现问题 –> 我大略晓得你是怎么玩的 –> 初步定位问题起因 –> 同开发确定问题 –> 接下来呢？
会分成两类：
1、我定位的起因并不是真正的起因。但我能通过这个过程学习到新常识、新业务，积攒集体教训（很多人往往弃步于此）
2、我定位的问题是真正的起因。就此打住吗？并不是。你能提出问题的解决倡议吗？你的倡议是否比开发的批改 or 产品给的计划更好，更具备可施行性？
正当地提出解决问题的倡议，这才是你关注的重点，而不是因为找到问题起因而沾沾自喜，迷失于别人的称许中。
