前言



我们在刚刚接触测试这个领域的时候,可能就时不时地听到这两个词:黑盒、白盒,当然,在近几年,可能又会听到一个新的说法:灰盒。


那这几种测试的方法,到底是什么意思,网上也有一些说明,但是真的太过晦涩、书面化。在这里我会用更实际的例子对这几个概念做一下阐述。








黑盒测试



不考虑程序内部的结构和实现方式,着眼于输入、输出的正确性校验。


通常,我们做一些网站(web)网页的测试、APP的测试的时候,在大多数情况下会用这样的方法。


例如,要测试一个网站的登录功能。测试人员考虑到帐号存在与否、密码是否正确等情况,在web界面上输入不同的帐号+密码组合,查看是否跳转到登录后的主页。这就是一个很典型的黑盒测试场景。




白盒测试



在全面了解程序内部的运作机制情况下,设计测试用例,去覆盖不同的代码分支逻辑。


如果还是针对网站的登录功能去进行测试,使用白盒测试的手段,会是怎样的一种过程呢?


例如,QA(测试人员)去阅读了登录这一块的源代码,发现这一段登录代码是:1. 先验证当前用户是否已经是登录状态,如果是登录状态则直接跳转;2. 拿着输入的用户名去查询了数据表中的name和email两个字段;3. 对传入的密码参数进行MD5加密,与数据库中取得的密码字段进行校验...


于是,QA不仅仅去设计了用户名+密码的组合,还去构造了“已经是登录状态下,再次访问登录界面”的case。这就是白盒测试的手段,结合代码,去设计更充分完备的测试场景。




灰盒测试



介于白盒与黑盒测试之间,除了关注输入、输出之外,也会关注程序内部的运行状况。


在我看来,这个“运行状况”在大多数的产品中,指的是日志、数据库变化等。


依然是登录场景,我们考虑到登录成功之后,系统中可能发生的变化有:1. 日志记录一条某用户登录成功的时间、状态;2. 用户的最后登录时间记录,更新为当前时间...


于是,我们本身还是测试功能,只不过去更加关注到了程序运行的状态,我们需要了解有哪些关键点被加上了日志,需要了解不同的业务对应到哪些数据库、数据表、字段。


有的时候,我们会结合代码去得到这些信息,但并不意味着我们每次测试的时候都要去对照代码来进行测试用例的设计。




总结



在大多数的互联网产品开发流程中,白盒测试的手段对测试人员的要求很高,测试的过程也更加耗费时间,互联网的节奏不允许这种“效率低下”的测试方法占据主流。当然,对于一些非常核心的系统,还是会有白盒测试的影子存在。例如百度搜索引擎的后端服务中,就有部分模块使用白盒测试的手段。


实际上,大部分的QA其实还在采用黑盒测试的手段,这也导致一个现象:QA跳槽难、工资低。毕竟,如果只是点界面,我招聘一个校招生、实习生,和你这样工作了3、5年的QA似乎区别并不大。


因此,如果要提升自我的竞争力,不妨尝试着去尽量采用灰盒测试的手段,去更多地了解系统的运行状况,而不仅仅把自己定义为一个“点界面的”。