通信软件被普遍认为是白盒测试最难实施的领域，一方面，通信软件以C语言为主体语言，先进的白盒测试技术尚未有效渗透到这个区域，另一方面，通信软件通常是嵌入式实时系统，搭建测试环境非常复杂，又加上通信软件通常体积庞大、结构复杂，把通信软件的单元测试或集成测试做好确非易事。

        笔者有幸在通讯领域工作多年，近些年又因为咨询的关系与国内众多企业打交道，感触颇多。国内企业普遍对白盒测试没感觉也不重视，少数比较注重质量的公司努力尝试了，但处处碰壁，不是缺少方法就是缺少合适的测试工具，或者因为管理不善白盒测试最终做不起来。当然，想做没做成，找不着道的企业不在少数，许多公司一开始就走错方向了，在叉路上徘徊很久而混然不觉。

        国内通信企业在单元测试与集成测试方面做得好与不好的，差别很大，我们划分三种境界：混沌、有序、自发，这三种境界指的就是三种发展阶段。当然，这里分门别类的意义并不在于区分出高低上下，而在于尝试指出白盒测试的发展方向，另外，对历史经验作一次总结，通信软件因其复杂性，白盒测试无法一蹴而就，某些特定阶段必须要亲身经历，我们划分三种发展境界同时，也尝试说明在各种境界下如何实施白盒测试？重点在哪？要规避哪些问题？

境界之一：混沌状态
        混沌状态是刚实施或从未实施白盒测试的发展阶段，在这个阶段，一个企业内只有零星的单元测试或集成测试实践，缺少成功案例，该阶段最典型的特征是：每一个人都很忙，整天忙于市场救火。

        企业上上下下谁都在忙，本该在实验室做测试的测试人员被赶到市场一线，在客户的机房上跳下蹿，低头忙于调测，抬头忙于跟客户掩饰问题。本该呆在家编码的开发骨干也时不时被逮到现场，架调试环境，使出混身解数来定位问题，遇到棘手些问题通常要耗上数天才能定位，也有许多时候现场定位不了，就偷偷地复位一下设备，谎称问题解决了，然后赶紧溜回公司，一行行翻阅代码通宵达旦的继续定位。

        混沌状态最大的特点是大家都忙于救火，系统测试的投入尚无保障，更别说代码级的测试投入了。该阶段会造就众多“救火英雄”，而“纵火犯”的责任难以追究，按照通信业界的通行规律，一个产品60%的BUG应在白盒阶段曝露，当公司尚充斥着众多“救火英雄”时，白盒阶段发现的BUG通常不到20%，甚至个别公司是零。

        混沌状态还有一个重要特点，公司成员普遍对白盒测试缺少概念，大致知道代码审查、单元测试、集成测试该怎么去做，但一涉及具体场景，对某模块实施单元测试或跨模块、跨子系统实施集成测试时，通常茫无头绪，不知从何下手。处于混沌状态的组织，还可能流行一种观点：产品不稳定是测试人员的责任。因为许多人认为，尽管单元测试与集成测试没做，或做少了，只要系统测试做好总能发现所有问题的。其实这种观点早已谬之千里了，令人费解的是，持这种观点不在少数，为什么会这样？就像该阶段出现的特有现象，明明某个开发人员水平很差，写的代码老出问题，但他在市场上救过几次大火，其兢兢业业的态度、忘我的投入，又为公司挽回多少多少损失，所以领导们毫不犹豫的将他评为“功臣”。

境界之二：有序状态
        一个企业实施过多次单元测试或集成测试，数次成功后进入到有序状态。这个阶段尽管个别项目的白盒活动不成功，但多数项目稍见成效，也有个别项目效果显著。此时，企业内会有特定的组织负责推动白盒测试，白盒测试过程也逐渐融入研发流程，典型的例如：将白盒测试发现的问题纳入统计，研发过程中会以缺陷密度（每千行代码发现多少BUG）作为衡量白盒测试是否充分的指标，另外还会以覆盖率指标作为检查个人是否充分测试的依据。将白盒测试纳入流程监控，主要控制一个项目是否做白盒测试，实施过程是否规范，实施结果是否合乎预期，对于不符合流程要求的行为QA有权要求返工。

        进入有序状态须满足两个条件：一是白盒测试在少数项目获得成功，成为可拷贝的活动；二是实施白盒测试有组织与流程保证。如果这两个条件无法同时满足，说明单元测试或集成测试在这个企业中仍缺少保障，即使有人偶尔做成功了，也是不可靠的，个体行为难以转化为组织行为。

        有序状态是通信企业白盒测试必经历阶段，多数比较漫长，快则一、两年，慢则十余年，要有长时间技术积累，以及组织与流程的优化。另外，从有序状态转向自发状态，会涉及白盒测试理念的大幅转型，从现实操作角度考虑，这些是很难在一两个项目周期就能跨越过去的。

        有序状态的发展过程中，多数企业会遇到如下问题或现象：

1. 开始认识到单元测试该由开发人员去做

        多数尚处于混沌境界的企业会认为，单元测试应由测试人去做，可能会觉得开发人员自己编码又自己测试会陷入惯性思维，测试效果不佳。但让测试人员现实操作几次，又会冒出几个难以逾越的问题，首先是测试效率，测试人员不熟悉代码，他上手把源码读懂然后想办法做测试，要知道，单元测试面对众多琐碎的函数，随意一个开发人员一天就能写一堆新函数，所以，测试人员若把单元测试做好，通常要比开发人员自测多付10倍的精力，这一情况很致命，单元测试必然难以为继。其次，测试人员做单元测试，经常不能断定某种现象是不是问题，还得找相应开发人员去定位，问题定位了，修正问题又是个麻烦，测试人员不拥有给产品编码的权限，大量时间又浪费在反复沟通上。

        所以碰过几次壁后，多数企业都会回到这种操作方式：每个开发人员自己写代码，自己做单元测试（主要是模块级白盒测试）。这是主流运作方式，非主流的，还可能间或让两个互相熟悉对方代码的开发人员，交叉一下做单元测试，这也是比较有效的方式。