重温黑盒、白盒与灰盒测试方法

对于黑盒、白盒与灰盒测试方法的理解，几年前我在某乎做过一个概念性的回答，当时提问者询问：如何跟非技术人员解释黑盒、白盒、灰盒测试的区别？

我的回答原文如下：

既然是对非技术人员解释，就不能用专业术语。
这样说吧，有个打孔机，类似这样。

纸条从盒子左方插入，从右方出来时，分别打出圆形、正方形、三角形三个样式的孔。

某天，打出来的纸条，只有一种图形。

黑盒测试员只能说：“这个打孔机坏了！”

灰盒测试员把打孔机的盖子掀开，发现打孔机的造型原来是这样的。

于是他说：“机器仍能打孔，说明主机没坏；三个桩子也都是好的；但只打印出了圆形，可能因为连接正方形和三角形桩子的地方有问题。”

白盒测试员把机器拆开，查看内部的电线、电路、控制器等等，发现连接正方形和三角形的电线烧坏了，于是说：“原因找到了，换根电线吧。”

彼时，我还是一位测试小鸟，在研习了不少理论知识后，回答了这个问题。现在，我算不上测试老鸟，但能算个测试大鸟，在工作中，越发频繁地接触这三种测试方法。

如果你要问我哪种测试方法更好，我不置评价，每个人的口味不一样，别人适合的不一定自己适合。

对于黑盒测试方法来说，是每一位测试的必备技术，没有谁不会：发现问题，抛出问题。

简单、轻松、快速，是黑盒测试的优点，特别是在项目特别赶，测试时间无限被压缩的时候——只需要抛给开发问题，剩下的让开发自个儿玩去吧。

但黑盒测试人员常常被人诟病只知道点点点，抛开此类“鄙视”不谈，接着上面继续，我们是不是忽略了一个事实：项目既然赶，那开发的时间亦不充足，如果恰好遇上稍稍复杂的bug，并搭配不靠谱的开发，一个bug的生命周期可能会拉得极长，效率特别低下。

这么说，那用白盒测试方法呗，看代码，查原因，丢给开发后，留下一个高大帅气的背影，让开发心里默念——这个测试不简单。

白盒测试可以，但使用它时，你需要盘算盘算：

• 是否有充足的时间研究代码以及和代码相关的环境部署、配置设置等？
• 付出和产出是否成正比，如同自动化测试，能达到高性价比吗？

白盒是一种选择，但同样是一个难题。更别说白盒对于测试技术的高要求。

废话了这么多，你一定会说：风风，你不就是拐弯抹角地推荐灰盒测试嘛。

我不知道该怎么回答你，就像刚开始说的，每个人的口味不一样，适合自己的测试方法，最醇最香。

但说实话，日常工作中我使用灰盒测试方法的场景相对较多，总结来说，就这么一个流程：

发现问题-->我大概知道你是怎么玩的-->初步定位问题原因-->同开发确定问题-->接下来呢？

会分成两类：

1、我定位的原因并不是真正的原因。但我能通过这个过程学习到新知识、新业务，积攒个人经验（很多人往往弃步于此）

2、我定位的问题是真正的原因。就此打住吗？并不是。你能提出问题的解决建议吗？你的建议是否比开发的修改 or 产品给的方案更好，更具有可实施性？

合理地提出解决问题的建议，这才是你关注的重点，而不是因为找到问题原因而沾沾自喜，迷失于他人的赞许中。