说到价值无非两个方面,质量和效率。今天笔者也从这两点简单介绍下自己进行白盒测试的一些收获。
效率提升
底层代码单测
因为底层,所以单测。一个转码函数,开发改下,有单测几秒钟完事,没有的话黑盒需要测试在各种不同环境下的UI展示、网络请求中的中文转码、日志记录等等。
而且这个底层代码,一般都是逻辑复杂,低耦合(什么,你们底层代码也是高耦合,让开发重构去)。这种实在是做单测的上上选,基本上回归一次就能回本。
频繁改动的逻辑代码
因为频繁,所以单测。和上面有点类似,不同的是这部分的单测可能不好做。比如一个跨进程消息传递的框架,我们做单测就需要用到各种mock、fake等等手段。但是如果一个逻辑复杂的模块,又经常改,那么每次都黑盒肯定就没有白盒的划算了。
一定程度上来说,白盒的最大的贡献不是发现了多少Bug了,而是监控了多少代码。相对于黑盒,频繁回归的模块白盒优势就很大了。
开发工具简化测试方法
因为简单,所以白盒。这里强调下,白盒测试不只是单测,代码调研、走查等等都可以算是白盒测试。一个弹泡样式改了,正常黑盒可能需要构造各种环境看看泡的样式是否正确。这时我们就可开发个工具直接调用代码里的一些接口,将各种各样的泡搞出来,测试流程就变得简单了很多,就类似于目前像TestBird这样的测试机构都会自研一套测试工具或平台进行一系列的测试。
可能大家觉得这个有点像自动化,不错,很多这种情况我们都是用自动化解决的,不过有些直接调代码接口会简单很多。没有倾向性,最适合的就是最好的。
质量提升
疑难问题
因为疑难,所以白盒。简单问题你做不过黑盒,要是黑盒不好弄的疑难问题你也搞不定,那要你有何用。白盒相对于黑盒,就是直接接触代码,对于每个Bug的前因后果都可以了解到很清楚(注意我说的是可以,想不想是你的事)。
之前我们也有过一些疑难模块,线上频繁报问题,但我们自己这边又很难复现。没办法只能去啃代码,根据问题现象,猜测原因,寻找问题代码。放心,有问题就有原因,一点点啃,推着开发一点点改,突然一天,就发现线上的反馈少了许多。
这个可能难度会较大,疑难模块的代码一般都不简单(想想开发干嘛的),你可能需要花大量的精力去啃,还要求有较好的代码功底。我狗就有些很高级的开发,不怎么写产品代码,哪有问题他去哪。所以不用想就知道,这是件很有挑战的事,但同时也是很有成就感,并且能提高自己的事。
复杂逻辑
因为复杂,所以白盒。和上面疑难问题同样道理,不搞这些要我们这群做白盒的干嘛。不过不一样的是,复杂逻辑至少还有逻辑在,我们只需要搞清楚代码逻辑,设计好足够的用例,就OK了。
比如一个线程间任务调度模块,我只需要搞清楚,不同线程的调度算法、回调的逻辑、并发的处理等等,然后用单测也好、工具也好模拟出各种情况验证就好。让黑盒来测试这个,麻烦不说,很多细节的逻辑也很难测试到。
开发工具暴露接口
因为隐蔽,所以白盒。这个和效率里的工具很类似,因为目的不一样所以放到质量里。有些接口,黑盒根本就接触不到。这里可以通过代码调研,用工具将其暴露出来。
可能有疑问,既然黑盒都走不到,为啥还要测。当然要了,比如我们的一些异常处理代码,有些异常我们真是构造不出来,但保不齐线上不会出现。为了高质量,这部分代码还是要测到的。