通信软件白盒测试的三种境界

<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>

通信软件被普遍认为是白盒测试最难实施的领域，一方面，通信软件以C语言为主体语言，先进的白盒测试技术尚未有效渗透到这个区域，另一方面，通信软件通常是嵌入式实时系统，搭建测试环境非常复杂，又加上通信软件通常体积庞大、结构复杂，把通信软件的单元测试或集成测试做好确非易事。
　
　　笔者有幸在通讯领域工作多年，近些年又因为咨询的关系与国内众多企业打交道，感触颇多。国内企业普遍对白盒测试没感觉也不重视，少数比较注重质量的公司努力尝试了，但处处碰壁，不是缺少方法就是缺少合适的测试工具，或者因为管理不善白盒测试最终做不起来。当然，想做没做成，找不着道的企业不在少数，许多公司一开始就走错方向了，在叉路上徘徊很久而混然不觉。
　
　　国内通信企业在单元测试与集成测试方面做得好与不好的，差别很大，我们划分三种境界：混沌、有序、自发，这三种境界指的就是三种发展阶段。当然，这里分门别类的意义并不在于区分出高低上下，而在于尝试指出白盒测试的发展方向，另外，对历史经验作一次总结，通信软件因其复杂性，白盒测试无法一蹴而就，某些特定阶段必须要亲身经历，我们划分三种发展境界同时，也尝试说明在各种境界下如何实施白盒测试？重点在哪？要规避哪些问题？

境界之一：混沌状态

　　混沌状态是刚实施或从未实施白盒测试的发展阶段，在这个阶段，一个企业内只有零星的单元测试或集成测试实践，缺少成功案例，该阶段最典型的特征是：每一个人都很忙，整天忙于市场救火。
　
　　企业上上下下谁都在忙，本该在实验室做测试的测试人员被赶到市场一线，在客户的机房上跳下蹿，低头忙于调测，抬头忙于跟客户掩饰问题。本该呆在家编码的开发骨干也时不时被逮到现场，架调试环境，使出混身解数来定位问题，遇到棘手些问题通常要耗上数天才能定位，也有许多时候现场定位不了，就偷偷地复位一下设备，谎称问题解决了，然后赶紧溜回公司，一行行翻阅代码通宵达旦的继续定位。
　
　　混沌状态最大的特点是大家都忙于救火，系统测试的投入尚无保障，更别说代码级的测试投入了。该阶段会造就众多“救火英雄”，而“纵火犯”的责任难以追究，按照通信业界的通行规律，一个产品60%的BUG应在白盒阶段曝露，当公司尚充斥着众多“救火英雄”时，白盒阶段发现的BUG通常不到20%，甚至个别公司是零。
　
　　混沌状态还有一个重要特点，公司成员普遍对白盒测试缺少概念，大致知道代码审查、单元测试、集成测试该怎么去做，但一涉及具体场景，对某模块实施单元测试或跨模块、跨子系统实施集成测试时，通常茫无头绪，不知从何下手。处于混沌状态的组织，还可能流行一种观点：产品不稳定是测试人员的责任。因为许多人认为，尽管单元测试与集成测试没做，或做少了，只要系统测试做好总能发现所有问题的。其实这种观点早已谬之千里了，令人费解的是，持这种观点不在少数，为什么会这样？就像该阶段出现的特有现象，明明某个开发人员水平很差，写的代码老出问题，但他在市场上救过几次大火，其兢兢业业的态度、忘我的投入，又为公司挽回多少多少损失，所以领导们毫不犹豫的将他评为“功臣”。

境界之二：有序状态

　　一个企业实施过多次单元测试或集成测试，数次成功后进入到有序状态。这个阶段尽管个别项目的白盒活动不成功，但多数项目稍见成效，也有个别项目效果显著。此时，企业内会有特定的组织负责推动白盒测试，白盒测试过程也逐渐融入研发流程，典型的例如：将白盒测试发现的问题纳入统计，研发过程中会以缺陷密度（每千行代码发现多少BUG）作为衡量白盒测试是否充分的指标，另外还会以覆盖率指标作为检查个人是否充分测试的依据。将白盒测试纳入流程监控，主要控制一个项目是否做白盒测试，实施过程是否规范，实施结果是否合乎预期，对于不符合流程要求的行为QA有权要求返工。
　
　　进入有序状态须满足两个条件：一是白盒测试在少数项目获得成功，成为可拷贝的活动；二是实施白盒测试有组织与流程保证。如果这两个条件无法同时满足，说明单元测试或集成测试在这个企业中仍缺少保障，即使有人偶尔做成功了，也是不可靠的，个体行为难以转化为组织行为。
　
　　有序状态是通信企业白盒测试必经历阶段，多数比较漫长，快则一、两年，慢则十余年，要有长时间技术积累，以及组织与流程的优化。另外，从有序状态转向自发状态，会涉及白盒测试理念的大幅转型，从现实操作角度考虑，这些是很难在一两个项目周期就能跨越过去的。
　

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

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

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

[NextPage]
　

2.       会发现只拿覆盖率评估测试是否充分是不够的

　　引入业界工具实施覆盖率测试，当一个企业白盒测试做到一定程度时，会陷入一个困惑：拿覆盖率评估测试充分与否是否足够？为覆盖率而覆盖率，目标太容易达成，运行一两个高层次的业务调用，覆盖率很快就上去了，也即，如果有人想作弊，他完全可以只写很少用例就让覆盖率满足要求。有人就这个问题进一步思考，又产生另一个困惑：白盒测试到底测什么？测看得到的代码吗？代码覆盖率直观的表达了可见代码是否跑到，但如果规格有要求又忘实现了，覆盖率能说明什么？

3.       不同员工做白盒测试，效果差别巨大

　　这种现象是每个公司都会遇到的，在白盒测试推行初期表现尤为明显。能力强的就是很少漏测，很少遗漏问题到后续阶段，能力差的，尽管他很努力的想把每件事做好，漏测总还很多。

4.       会有白盒测试无用论产生

　　产生白盒测试无用论，多半不是从理论上反对白盒测试，而是实践走不通，做了不少单元测试，效果不佳，发现问题留于表面，深层次逻辑问题或接口问题发现不了，所以就认定白盒测试没多大用处。

　　也常见一种情况，发现白盒测试没效果会认为自己没掌握测试方法，所以想方设法寻求“见血封喉”的致命武器，几经努力后，仍无特效药可买，这种情形继续发展，白盒测试无用论很可能就产生了。

　　白盒测试没效果的本质是难以突破“机械测试”的盲区，所谓机械测试，是指依据可得见的代码做测试，典型的比如，被测代码有“1+1=2”语句，所以设计用例，结果也验证“1+1”必然是等于2的，测试用例总数、覆盖率都达标了，就是发现不了多少问题。突破“机械测试”盲区的法宝是“按规格去设计用例”，但这么一条简单的规则说起来容易，做起来很难，能力强的会不自觉得遵守这条规则，能力弱的常想不起来，想起来也经常无处着手，思维被条条框框禁锢住了。所以，许多时候个体很见效的白盒测试难以上升到组织行为。

5.       白盒测试能否成功很大程度上依赖于牛人经理或牛人QA

　　这一点也是白盒测试推行初期经常出现的，执行力强一些的经理或QA，白盒测试可以推行成功，执行力弱一些的就不成功。不少企业因为尝试几次单元测试都失败了，就全盘放弃白盒，只做黑盒测试了。

　　有一些企业坚持下来，在一两个项目组取得成功，然后针对性的优化组织机构，比如设置专门工作推动组，建设白盒测试专家资源池，为各个项目提供测试引导人员，进一步优化流程，把白盒测试的监控点纳入流程来控制。当一个企业的组织机构与流程逐步完善，白盒测试能否成功就较少依赖于个别牛人了。

6.       阶段化实施白盒测试，测试用例无法维护

　　集中一段时间编码，编码完了再集中一段时间做单元测试，单元测试完了开始集成，这时又集中时间做一次集成测试，这是多数企业实施白盒测试的模式。这一模式下，单元测试或集成测试只是特定时间段内（比如一个版本周期内的一两星期中）才实施的活动，但产品修改代码却是时时刻都在进行的，毫无疑问的会带来一个深刻问题：用例维护与产品代码维护不同步！所以，大家就经常会看到，某个产品的第一个版本可以把单元测试完整实施一遍，而此后时不时为解决问题改代码，或为追加功能改代码，单元测试很难继续，常导致单元测试只在V1版本做一遍，其后V2、V3等版本无法再做。

　　不间断的代码修改与阶段化的白盒测试明显不协调，这问题表面看起来并不严重，解决起来却远没想象的简单，该问题可以上升到操作模式问题，解决这个问题，必然要引入一种时时测试的模式，很自然，大家马上猜得出用什么模式？就是持续集成！

　　或许有人会觉得，为让白盒测试在版本周期内坚持做下去，不见非得引入持续集成吧？试想一下，从编码到版本进入维护，开发人员独立无干扰的编码时间有多少？而从两两开始集成之后，又占去多少时间？无疑后者占去大部分时间。如果开始集成后的每次版本修改都有测试跟进，大家岂非天天写测试用例，这不是持续集成是什么？如果不想天天补充用例，隔周、隔月，或隔一个版本补充用例，怎知你增补的用例会覆盖全部变动过的代码？

[NextPage]

　　通信领域的代码普遍很庞大、很复杂，一个版本周期通常是30~40星期，从开始编码到第一次两两合版本，通常是2~3周时间，之后就进入持续集成测试的阶段，该阶段会延续很长时间，通常10周以上，所以，如果坚持阶段性测试，必然导致白盒测试难以为继，每个人写的用例难以维护，写一次用一次，然后就扔了。

　　为清晰起见，我们将阶段性测试称作一次测试，与之相对的持续集成方式下的测试称作持续测试。尽管很多人不认为阶段性测试的用例只用一次，但现实情况好不到哪儿去，集中一段时间写的用例，当源码有较多修改后，再集中一段时间维护旧用例会很痛苦。

7.       每个研发阶段结束，尝试将每个人的用例合并起来

　　合并测试用例是一次测试思维的自然延续，其出发点是为了让测试集能更好的维护，但事与愿违，越是合并的用例越是无法维护，除非被测系统非常简单，也很少去变更，当然，如果系统很少变更，维护用例的需求也不强烈了。

　　合并之前的脚本尚有明确的维护责任人，但合并之后测试脚本该由谁去维护？况且按照经验，一次充分的单元测试，测试脚本的规模应与被测代码相当，各人编写用例的运行环境又千差万别，如此庞大的体系合起来并不容易，合起来后也无法维护。所以，合并用例是企业处于有序状态特定阶段才做的事，通常只做几次，达不到效果就不会反复去做了。事实上，遵循一次测试模式的组织内，大家自己管自己，用例不合并都已经很难维护了。

8.       仍有员工试着要上单板做单元测试

　　嵌入式产品的单元测试该不该上单板？这个问题更多的可归结为实践上可不可行，从理论上讲没人规定单元测试就不能上单板。但现实操作中，通信产品上单板做单元测试大部分都失败，失败的情形笔者见过的不是两三个，而是十数个，尤其是大公司，每个产品组中总有一些自信满满的员工，都愿意相信上单板做 UT才是正道。

　　当然，本文并不否定上单板做UT就不能成功，而是说成功的机率比较低，况且，是否成功的定义也是因人而异，见仁见智的。打个比方说，一个开发人员写一天代码，然后用一天时间就把新写的代码测试完了，这种情况下，白盒测试是可维持的，做得下去的，而当种种条件限制（比如上单板每次下载都要消耗很长时间，单元测试面对初始代码，没测几分钟板上程序就会跑飞），写1天的代码要用10天才能测完，这种测试是很难维持的。

　　以上单板做单元测试的致命因素是测试效率，试想一下，主流通信软件使用C语言，想把纯软件C语言工程的白盒测试做好，相对java、C++等工程已属不易，上单板在实时操作系统下把UT做成功，更是难上加难。所以，依据实践的推论，通信软件的单元测试应在仿真环境下按纯软件的方式去做，集成测试倒是可以上单板，在真实环境下去做。

　　任何事物都有3种发展方向：前进、原地踏步、倒退，上面我们描述了白盒测试在有序境界下的行为特征，字里行间还点出了各种行为的改进方向，有针对性的改进了，白盒测试就不断前进，反之出现倒退，回到混沌状态。比如在推行初期，白盒测试能否成功很大程度受项目组的执行力度影响，改进这一点须要优化组织结构与流程方法，若任其自然，在个别项目已成功的白盒实践仍无法拷贝到其它项目。
　
　　有序状态介乎混沌状态与自发状态之间，因其时间跨度较长，我们还可经细分出有序初期阶段与有序后期阶段，在有序初期阶段什么都不规范，白盒测试也常在成功与不成功之间晃动，而在有序后期阶段，应该具备某些自发状态的表现特征了。具体而言，有序状态向自发状态发展，要跨越两大考验，其一，要解决一次测试的问题，要向持续测试过渡，其二，要在组织运作层面解决“机械测试”的问题，上面提到不同员工做测试效果差别很大，有差别是正常的（否则优秀员工无法称之为优秀），但能否将能力差异对结果影响缩小到系统测试那样呢？
　
　　通常，白盒测试能力强的员工编码能力也强，测试能力差的编码能力也差，极少听说测试能力很强但编码很差。所以，要让白盒测试做得更深入、更有效，重点是解决思维方式问题，通过培训、日常锻炼也能起到一定效果，但终归不明显，毕竟项目组内个个都是得道高僧比较少见。根据实践经验，解决这个问题的最有效的措施是测试先行，如果编码之前就写用例，只能依据规格做测试设计了，这对能力强的与能力弱的都一样，思维方式强行改变，其测试无疑是最彻底、最见效的。
　
　　从有序前期阶段过渡到有序后期阶段，如何看待测试代码也有很大变化，在前期，开发是开发，测试是测试，测试操作连同测试代码是附加的，可选的，到有序后期阶段，大家会把测试代码也看成一种产品代码，是必需的，也自然而然纳入产品维护。
　

[NextPage]

境界之三：自发状态

　　自发状态是白盒测试的共产主义境界，此时生产力高度发达，设计用例的效率提高了，做测试不再是沉重负担。所谓自发，就像共产主义社会里劳动是个人意愿而非生存手段，开发人员自测也上升到个人意愿，即使领导不强制，流程也不限定白盒测试必须要做，开发人员仍自愿去做测试。自发状态是白盒测试的最高境界，它的典型表现特征是：白盒测试已成员工的普遍行为与自发行为。
　
　　白盒测试进入自发状态，必须经历两大转变，一是测试效率要有数倍提高，这是基础，二是测试实践能够深入，能有效发现各种问题。目前已有一些公司经历过这两种转变，前者测试效率提高主要依赖于在线测试、持续测试、黑盒调测等理念（详情请见《第4代白盒测试方法概述》中拉通测试小循环、拉通研发大循环、调试转化为测试等章节），而后者有效发现问题，测试先行（TDD）已接受广泛的实践检验。当上述两大转变完成了，白盒测试就成为每位员工的必须行为，就像调试操作，每位员工写完代码，正常都要“调一调”，在自发境界下，随时“测一测”是每位员工自然而然要做的事。自发境界下的一个组织，实际操作中“测一测”很大程度上代替了“调一调”，这时，员工数月不开调试器是常见的现象，