二、基于接口规格做测试

　　白盒测试之所以难做，瓶颈还在于测试效果因人而异，能力强的很容易发现深层次问题，能力弱的或责任心不强的，白盒测试仅是走过场，效果不明显。这里我暂且不论责任心问题，我们主要探讨技术层面，如何保证白盒测试是深入的、是有效的？

　　对于优秀员工，他设计用例总习惯于回溯规格，因为在动手编码之前，就先已经把规格想清楚了，不管有无形成文档，回溯、检视规格对他来说并非难事。当然，规格有大有小，而且是分层的，在产品层面有产品的特性规格，代码层面有不同层次的接口，比如单元测试，设计用例所依据的规格是被测函数的输入与输出。

　　对于工作习惯欠佳的员工，编码是边写边想的，想到哪儿就写到哪儿，在他脑中软件规格是模糊的、随意的，而且不断的调整变化。此时让他做单元测试，就很难依据规格去设计用例，其结果不难想象。一方面，代码是他自己写的，他会陷入自身的思维习惯中，另一方面，他只关注当前可见代码，不可见代码（如缺省的else分支、遗漏的处理过程等）被忽略了，我们把这种测试叫做“机械测试”，通俗一点讲，测试者把自身当成器物，比如看出代码有一句“1 + 1 == 2”，所以设计用例测试1加上1等于2，测试肯定是通过的，覆盖率也能达标，但测试还是没做好，测试者仅承担编译器或lint工具的角色。

　　在一个组织中，优秀员工与普通员工总是按一定比例存在的，我们很难要求普通员经过简单培训就马上变优秀，所以，让个体成功延伸为组织成功，我们首先考虑在工程方法做改进。极限编程中的测试先行实践（TDD，Test-Driven Development）可以很好的解决上述问题，TDD要求在编码之前做测试设计，代码尚不可见，先有测试用例，这样无论如何都不会坠入“机械测试”的陷阱了。根据已有文献提供的统计可知，TDD实践总体来说较为有效，但也存在一些固有缺陷，比如在看不到代码情况下先做测试设计，容易让人无所适从。第4代白盒测试方法在实践基础对此做了优化完善，让测试先行（第4代白盒方法中称TDF，Test Design Firt）很容易操作起来。

三、平稳、持续的以组织行为推进白盒测试

　　白盒测试若由个体成功延伸为组织成功，还强调该软件过程能持续运作、平稳运行，是标准化可复制的。

　　首先，我们要解决测试评估问题，以覆盖率评估测试程度是大家熟知的方式，但仅以代码覆盖率做评价就足够了吗？答案是否定的，在商用白盒测试工具中，最常见覆盖标准有3种：语句覆盖、分支覆盖、MCDC覆盖。这些覆盖率指标都反映实际代码中被覆盖的程度，但没有准确反映测试意图的实施程度，也就是说，测试操作中还存在经意测试与不经意测试的区别，为某项测试发起的某个函数调用，可能引发众多子函数层层调用，非关注范围的运行代码也会贡献覆盖率。所以，为了保障测试质量，我们在评估代码覆盖率基础上，还得评估测试设计程度。测试设计程度指标具有统计学意义，它分析测试用例的设计规模，再拿它与被测代码的分支总数作对比。被测代码分支数越多，或代码总量越大，那就应该设计更多的用例来测试它。

　　其次，严格的白盒测试应从编码开始，一直贯穿于软件产品的整个生命周期，只要代码有修改，测试用例就有补充、维护的需求，所以，白盒测试不是一次过程，而是长期、连续的过程，我们有必要让白盒测试按一种明确的、简要的规则，能持续平稳的向前推进，否则，作为一个组织是很难将白盒测试坚持到底，首次测试比较容易，但增补代码后，白盒测试及时跟进就困难多了。

　　第4代白盒测试方法在持续集成基础上，要求测试设计在源码修改后立刻跟进，用3个信号灯标识当前被测系统所处的状态，第一个信号灯表示当前测试是否通过，若通过则亮绿灯，否则亮红灯，需要先解决测试问题，第二个信号灯表示当前测试覆盖率是否满足要求，满足了才亮绿灯，否则亮黄灯，需要先改进测试设计，第三个信号灯表示当前测试程度是否满足要求，同样条件满足了才亮绿灯。平稳、持续的推进白盒测试，也就是保证这3个信号灯时常亮起的过程，非绿灯状态是暂态，都要求先解决问题，然后再进入下一轮功能开发。

四、选择一款好工具

　　推动嵌入式白盒测试是一项系统工程，主要受3个因素影响：人的因素、流程因素、工具的因素，这几个因素相互作用，又互为依赖，真正把白盒测试推行起来难度不小。

　　前面提到过，一个组织中优秀员工与普通员工总是按一定比例存在的，帕累托的20/80定律反映了众多自然现象与社会现象，在产品运作中也是如此，所有员工中20%是优秀员工，80%是普通员工，优秀员工为研发贡献80%，而普通员工贡献20%，所以，保障一个组织成功推行白盒测试，不必过于倚重人的因素，而更多的应该让流程来规范执行过程，让普通员工也能发挥出接近优秀员工的价值，以及，选择一款好工具，让总体测试效率与测试质量在组织范围内普遍提高。

　　我们再来分析流程因素与工具因素之间的关系，如果流程很规范，选用测试工具差些，白盒测试仍可推行成功。而同样，如果流程推行不力，但选择的测试工具很好，白盒测试也能成功。评估这两者，我们应识别出哪个因素在本企业更为关键，找出瓶颈问题，有针对性解决了，白盒测试就自然推动起来。

　　根据经验，目前国内大多数做嵌入式产品的企业没能做白盒测试，其关键原因不在于不想做，或不愿做，而在于缺少一个好工具。软件过程的执行力尚在其次，因为只有一个小组创造了成功case，再推行到其它小组并不困难，操作流程还是容易树起来的。这一点，我们从另一个侧面容易得到验证，比如，近些年来风风火火的持续集成测试、测试先行等实践，在java与C#项目开发中有许多成功案例，但在C++项目成功的就不多，在C项目成功的非常少见，这足以说明：当前白盒测试欠缺的还不是方法论，更多是与方法论相配套的工具。