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

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

测试奇坦，BUG不见了。

大家好，我是谭叔叔。

几年前，我对黑盒、白盒、灰盒测试方法的理解给出了一个概念性的答案。当时提问者问：如何向非技术人员解释黑盒、白盒、灰盒测试的区别。

我的原答案如下：

既然是对非技术人员的解释，就不能用技术术语。

假设有一个穿孔机，就像这样。

纸条从盒子的左边插入，当它从右边出来时，分别打三个圆形、方形和三角形的孔。

有一天，打字的纸条上只有一个图案。

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

灰盒测试仪掀开冲头的盖子，发现冲头的形状竟然是这样的。

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

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

那时，我是一只测试鸟。在学习了大量的理论知识之后，我回答了这个问题。现在，我不能算作一只测试鸟，但我可以算作一只测试鸟。在工作中，我越来越频繁地接触到这三种测试方法。

如果你想问我哪种测试方法更好，我不会评论，每个人的口味不一样，别人适合的不一定自己适合.

对于黑盒测试法来说，是每个人都要测试的必备技术，没有人做不到：发现问题就扔出去。简单、容易、快速是黑盒测试的优势，尤其是项目赶时间、测试时间无限压缩的时候，——只需要抛给开发问题，剩下的就留给开发自己玩。

然而，黑盒测试人员经常被批评只知道一点点，把这种“轻视”放在一边，然后继续上面。我们是不是忽略了一个事实：既然项目赶时间，开发时间又不够，如果碰巧遇到开发不可靠的稍微复杂的bug，那么bug的生命周期可能会特别长，效率特别低？

所以，我们用白盒测试法，看代码，查原因，丢给开发，留下一个高大帅气的身材，让开发可以打坐——，不容易。

白盒测试是可以的，但是在使用它的时候，你需要计算：

您是否有足够的时间来研究代码以及与代码相关的环境部署和配置设置？

努力和产出之间是不是成正比，就像自动化测试一样，能不能达到高性价比？

白盒是一种选择，但也是一个难题。更不用说白盒对测试技术的高要求了。

说了这么多废话，你肯定会说：谭叔叔，你只是拐弯抹角地推荐了灰箱测试。

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

但说实话，我在日常工作中使用灰盒测试法的场景还是比较多的。总而言之，只有一个过程：

找到问题——我可能知道你是如何处理的——首先找到问题的原因——然后确定开发的问题——下一步是什么？

将分为两类：

1.我定位的原因不是真正的原因。但通过这个过程，我可以学到新知识、新业务，积累个人经验(很多人往往就此放弃)。

2.我定位的问题才是真正的原因。就这样？没有。你能提出解决问题的方法吗？你的建议是否比已开发的修改或产品给出的解决方案更好、更易实施？

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

实践是检验真理的唯一标准。碰巧最近遇到了一个问题，碰巧用的是灰盒测试法，就和大家分享一下。

首先描述业务：

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

再说一遍bug:

我删除了配置系统中的一条数据。结果，A类用户没有读取这段数据(预期结果)，但是B类用户确实读取了这段数据(意外结果)。检查数据库。库A没有删除的数据，但库b仍有删除的数据

可以说，当您到达这一步时，您可以向bug系统提交bug以进行开发和解决。但是我觉得开发最近每天晚上都在加班，我的前提有几个bug反复修改，所以开发效率很低，一上线时间就压缩了。所以，我抽出一点额外的时间来简单地定位问题。

这个问题似乎很简单。无非是两个库的数据由于同步不一致。可以得出两种猜测：

一、同步不触发。

二是触发了同步，但是数据没有掉在B库中。

然后，我做了一个实验：我在配置系统中修改了一条数据，库A和库B的数据是一致的。因此，猜测一是无效的。

然后，我又做了一个实验：我进入A库，删除了数据库中的一条数据。奇怪的是，B库中的数据被删除了，第二次猜测无效。

两种猜测同时被证明是无效的，那么问题出在哪里呢？

于是，我去了服务器，再次删除了配置系统中的一条数据，触发了同步操作。我在日志中发现了两个sql:

截断t

able xxtable;

insert into xxtable……;

到此，我恍然大悟。

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

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

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

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

一如既往，做个总结

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

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

03 和开发打好关系（或强制要求），让他们在解决bug的时候注明bug产生的原因。

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