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

我的回答原文如下:

既然是对非技术人员解释,就不能用专业术语。
这样说吧,有个打孔机,类似这样。
image.png
纸条从盒子左方插入,从右方出来时,分别打出圆形、正方形、三角形三个样式的孔。
image.png

某天,打出来的纸条,只有一种图形。
image.png

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

会分成两类:

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

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

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


↙↙↙阅读原文可查看相关链接,并与作者交流