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

测试奇谭,BUG不见。

大家好,我是谭叔。

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

我的回答原文如下:


既然是对非技术人员解释,就不能用专业术语。

这样说吧,有个打孔机,类似这样。

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

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

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

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

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

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

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

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

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

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


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

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

对于黑盒测试方法来说,是每一位测试的必备技术,没有谁不会:发现问题,抛出问题。简单、轻松、快速,是黑盒测试的优点,特别是在项目特别赶,测试时间无限被压缩的时候——只需要抛给开发问题,剩下的让开发自个儿玩去吧。

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

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

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

是否有充足的时间研究代码以及和代码相关的环境部署、配置设置等?

付出和产出是否成正比,如同自动化测试,能达到高性价比吗?

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

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

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

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

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

会分成两类:

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

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

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

实践是检验真理的唯一标准。恰好,我最近遇到一个问题,并且刚好使用到灰盒测试方法,分享给大家窥其一二。

先描述下业务:

我测试的X系统会从配置系统拉取几条数据,并保存在数据库A(读写库)中,数据库A又会将新数据实时同步到数据库B(读写库)中。业务上:a类用户从数据库A中读数据,b类用户从数据库B中读数据。

再说下bug:

我在配置系统删除了一条数据,结果a类用户没有读到该条数据(预期结果),b类用户却读到了该条数据(非预期结果)。去数据库查看,A库没有被删除的数据,B库仍然存在被删除的数据。

按理说,走到这一步,便可以到bug系统提交一条bug指给开发解决。不过我想到开发最近天天晚上加班,并且我之前提的几个bug反复修改,开发效率很低,加之临近上线,时间被压缩,于是乎,我额外抽出一点时间,简单定位下问题。

这个问题看起来简单,无非是同步导致两个库的数据不一致,可以得出两个猜测:

一 同步没有触发。

二 同步触发了,但数据没有在B库落库。

接着,我做了一个实验:在配置系统修改了一条数据,结果A库和B库的数据保持一致。据此,猜测一不成立。

紧接着,我又做了一个实验:进入A库,在数据库内删除一条数据,奇怪的是,B库的数据被删除了,猜测二也不成立。

两种猜测同时被证明无效,那问题究竟出在哪里呢?

于是,我上到服务器,重新在配置系统删掉一条数据,并触发了一次同步操作,我在日志上找到了两条sql:

truncate table xxtable;

insert into xxtable……;

到此,我恍然大悟。

原来因为这个业务的数据不多,开发可能是这样处理的:从配置系统拉取数据时,先清空A库的xxtable,再向A库的xxtable插入数据,以此简化数据增删改的逻辑。但我司DBA做过处理,不允许数据库级别之间进行truncate table的同步。

最后找开发讨论,果真是这个问题。

怎么解决呢,将truncate table xxtable换成delete from xxtable即可。

这算是一次我所理解的完整的灰盒测试,也是我一直推荐给组内人员的高效率的一种工作方式:我大概知道你是怎么实现业务的,实践定位问题,达到快速解决问题的目的。

一如既往,做个总结

01 测试时,特别简单的bug建议直接抛出,让开发去玩,没必要浪费精力定位问题

02 复杂问题多总结,定位问题时头脑要清晰且灵活,证实或否定每一个猜测

03 和开发打好关系(或强制要求),让他们在解决bug的时候注明bu*生的原因

04 多花时间在业务上,绝对物超所值

上一篇:今日份bug sql


下一篇:功能测试流程