在IT研发领域，个体能力对研发效率的影响很大，个人能力强的开发人员，其工作效率通常要比能力差的高出2~5倍，在特定情况下，差距还甚至扩大到10倍。所以，在软件研发项目中，我们听到项目经理抱怨，几位技术牛人就能决定一个大型产品的成败，为什么将个体成功演进到团队成功就那么难呢？

　　嵌入式产品的白盒测试是IT研发最难推动的软件过程之一，个人素质对测试效果的影响尤为显著。大家知道，做好白盒测试需要凭借测试工具，但某些优秀员工不依赖工具，仅在代码中插入assert、print语句，也同样把白盒测试做得很好，本文尝试分析白盒测试个体成功的主要因素，以及如何将这些因素规范下来，进行推广到整个组织，引导个人成功走向团队成功。

一、高效测试是推动白盒测试的基本前提

　　白盒测试之所以难做，瓶颈首先在于测试操作的效率远低于研发进度对它要求。

　　优秀员工不用测试工具也能做好测试，首先因为他个人习惯保证测试过程是高效的，比如：编程高手总是先理清思路再编码的，编码与写用例都是一次性作业，而普通开发人员是边想边写、边写边调整，少不了有许多反复；再如，高手总是尽可能少做调试，尽量拿测试代替调试，冒出问题常常只看源码就能解决，而刚入门做开发的人，若不在调试器一步步跟踪，他简直要丧失继续生活的勇气；再有，开发高手总喜欢代码写一点测一点，在随时处于稳定的系统中，测出问题与解决问题的效率非常高，而常人更喜欢先把代码写完整再集中做测试，各式各样问题纠缠在一起，定位不容易、解决起来也不容易。

　　不借助测试工具也可能做好测试，但并不意味着有好工具了也不去用。这里有个误区，通常大家认为写脚本了才算正式测试，其实不是，在被测代码里嵌入一条assert指令，它能反复执行，结果能自动判断，本质上这就是一个测试用例，而且，此形式的用例除了可维护性差些，它的开发效率其实还是很高的，直接重用被测代码的运行过程，用脚本构造测试环境与发起测试都省略了。所以，我们说“高效测试”，而非“使用工具”，是推动白盒测试的基本前提。

　　有一个指标——测试同比——可以评估嵌入式产品的白盒测试是否有效，测试同比是指保证恒定软件质量的前提下，每新增1千行代码所需的开发投入，与新增测试设计投入之比，前者开发投入主要指：低层设计、编码与调试，后者测试设计投入主要指：编写用例、调试用例。

　　根据我们的经验数据，测试同比为0.5，即写一天代码要测试两天，表示当前测试效率很低，这时推行白盒测试难逃失败的厄运。测试同比为1，即写一天代码要测上一天，表示测试效率尚可接受，此时白盒测试若有强大的执行力度，比如有良好定义的流程支撑，有完善QA审计把关，该软件过程仍然可以成功，但如果执行力度不足就很容易失败。当测试同比达到2，即写一天代码半天就能测完整，白盒测试就进入良性循环，稍加引导就能促使大家从被动测试转变到主动测试。

　　如上图，测试同比曲线被划分为3个区间：强制推动区、组织推动区、自发推动区，当测试同比过低，只有不计成本的强制推动才能让白盒测试获得成功，而测试同比提高到2以上，意味着少许投入即获得巨大好处，研发人员不断自测，少曝Bug少挨骂，效率提高了不必天天加班，白盒测试就很容易固化为他们的自发习惯。

　　在实际操作中，我们常拿上述“分区推动理论”评估一个组织的白盒测试能力，结果与实际情况非常吻合。测试同比为1是拐点，测试效率处于拐点附近白盒测试可以谨慎乐观，但如果远低于拐点，情况就很不妙了。我们遇到过许多产品，尽管产品组对白盒测试非常重视，但他们所遵循的方法论与支撑工具不够高效，或者组织机构欠完善，白盒测试还没开始就已经注定要失败了。

　　既然测试效率这么重要，我们该如何改善它呢？《第4代白盒测试方法概述》对此有过精辟论述，可以从测试方法与支持工具两个层面去考虑，下面我们列举几个要点：

1. 形式化、脚本化描述测试逻辑有助测试效率提升

2. 在线测试可以大幅提高用例设计、调试与维护的工作效率

3. 把调试操作重用到测试设计，也大幅提高测试效率

4. 持续集成模式让代码稳定性在调试与测试中重用，有力促进整体研发效率提升