所以，越早测试就越能节约成本，白盒测试作为早期测试，跳过不做是得不偿失的。
依据上述原因，我们评估白盒测试效率时，通常将发现问题总数乘上一个系数K，以此为据再与其它测试方段的发现问题效率做对比，来权衡白盒测试值不值得去做。系数K取值与产品形态相关，按照实际经验，系数K取值区间为1.5~2.5，产品越复杂，出现问题越不容易解决的，K值要往大调。
三、白盒测试能彻底解决编码阶段引入的问题
前面我们分析了白盒测试是高效的测试，值得一做，下面我们要接着说明白盒测试必须要做，不可或缺。
先看一个案例，在某交换机产品的系统测试中，发现ISDN话机拨打某新业务号码时，在特定线路上，若一位一位的拨至18位，不会有问题，但如果先拨完号码再成组发送，会导致系统死机。这是一个导致死机的致命问题，最后定位出问题所在：呼叫处理的某段代码判断有误，本应小于18的判断，错写成小于等于18。
这个问题本该在单元测试去发现，由于单元测试没做，问题就遗留到系统测试，庆幸的是没把它遗留到网上，否则问题就大 了。我们从另一个角度去反思，这个问题是特定线路下的特定终端，按特定方式拔打特定业务才暴露，在系统测试好不容易把它揪出来，但类似的其它问题呢?如何 保证在系统测试阶段都能测得出来?
不同阶段的测试发现问题的特点各不相同，比如：单元测试阶段，容易发现逻辑问题、边界条件(如上例“小于18” 的错误)、变量未初始化、内存越界等问题，而集成测试容易发现接口错误、任务配合问题等，系统测试容易发现业务流程问题、界面操作问题等。如果某阶段的测 试没做，把问题遗留后面阶段，又如何能保证查错的彻底性。比如使用非法内存，出问题是否表现出来是随机的，如果操作非法内存当前被系统还认为是有效的，系统并不死机，但某些情况下，操作非法内存会死机，而另一些情况，非法内存操作将不期望变化的变量改写了，会导致其它莫名其妙的问题。类似这样的问题，在白 盒测试阶段很容易发现，也容易定位解决，但遗留系统测试阶段，就很难去发现、去定位。
在V模型中，软件开发过程与测试行为具有不同层次的对应关系，如下图：
单元测试针对编码阶段引入的问题，集成测试与功能测试针对软件设计中引入的问题，验收测试针对需求与规格。单元测试不要或缺的重要原因是：编码阶段引入的问题占很高比例，不进行单元测试就难以保证系统最终的稳定性。
文章来源于领测软件测试网 https://www.ltesting.net/
