白盒测试质量和效率概况分享

说到价值无非两个方面，质量和效率。今天笔者也从这两点简单介绍下自己进行白盒测试的一些收获。

效率提升

底层代码单测

因为底层，所以单测。一个转码函数，开发改下，有单测几秒钟完事，没有的话黑盒需要测试在各种不同环境下的UI展示、网络请求中的中文转码、日志记录等等。

而且这个底层代码，一般都是逻辑复杂，低耦合（什么，你们底层代码也是高耦合，让开发重构去）。这种实在是做单测的上上选，基本上回归一次就能回本。

频繁改动的逻辑代码

因为频繁，所以单测。和上面有点类似，不同的是这部分的单测可能不好做。比如一个跨进程消息传递的框架，我们做单测就需要用到各种mock、fake等等手段。但是如果一个逻辑复杂的模块，又经常改，那么每次都黑盒肯定就没有白盒的划算了。

一定程度上来说，白盒的最大的贡献不是发现了多少Bug了，而是监控了多少代码。相对于黑盒，频繁回归的模块白盒优势就很大了。

开发工具简化测试方法

因为简单，所以白盒。这里强调下，白盒测试不只是单测，代码调研、走查等等都可以算是白盒测试。一个弹泡样式改了，正常黑盒可能需要构造各种环境看看泡的样式是否正确。这时我们就可开发个工具直接调用代码里的一些接口，将各种各样的泡搞出来，测试流程就变得简单了很多，就类似于目前像TestBird这样的测试机构都会自研一套测试工具或平台进行一系列的测试。

可能大家觉得这个有点像自动化，不错，很多这种情况我们都是用自动化解决的，不过有些直接调代码接口会简单很多。没有倾向性，最适合的就是最好的。

质量提升

疑难问题

因为疑难，所以白盒。简单问题你做不过黑盒，要是黑盒不好弄的疑难问题你也搞不定，那要你有何用。白盒相对于黑盒，就是直接接触代码，对于每个Bug的前因后果都可以了解到很清楚（注意我说的是可以，想不想是你的事）。

之前我们也有过一些疑难模块，线上频繁报问题，但我们自己这边又很难复现。没办法只能去啃代码，根据问题现象，猜测原因，寻找问题代码。放心，有问题就有原因，一点点啃，推着开发一点点改，突然一天，就发现线上的反馈少了许多。

这个可能难度会较大，疑难模块的代码一般都不简单（想想开发干嘛的），你可能需要花大量的精力去啃，还要求有较好的代码功底。我狗就有些很高级的开发，不怎么写产品代码，哪有问题他去哪。所以不用想就知道，这是件很有挑战的事，但同时也是很有成就感，并且能提高自己的事。

复杂逻辑

因为复杂，所以白盒。和上面疑难问题同样道理，不搞这些要我们这群做白盒的干嘛。不过不一样的是，复杂逻辑至少还有逻辑在，我们只需要搞清楚代码逻辑，设计好足够的用例，就OK了。

比如一个线程间任务调度模块，我只需要搞清楚，不同线程的调度算法、回调的逻辑、并发的处理等等，然后用单测也好、工具也好模拟出各种情况验证就好。让黑盒来测试这个，麻烦不说，很多细节的逻辑也很难测试到。

开发工具暴露接口

因为隐蔽，所以白盒。这个和效率里的工具很类似，因为目的不一样所以放到质量里。有些接口，黑盒根本就接触不到。这里可以通过代码调研，用工具将其暴露出来。

可能有疑问，既然黑盒都走不到，为啥还要测。当然要了，比如我们的一些异常处理代码，有些异常我们真是构造不出来，但保不齐线上不会出现。为了高质量，这部分代码还是要测到的。