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

　　集中一段时间编码，编码完了再集中一段时间做单元测试，单元测试完了开始集成，这时又集中时间做一次集成测试，这是多数企业实施白盒测试的模式。这一模式下，单元测试或集成测试只是特定时间段内(比如一个版本周期内的一两星期中)才实施的活动，但产品修改代码却是时时刻都在进行的，毫无疑问的会带来一个深刻问题：用例维护与产品代码维护不同步!所以，大家经常会看到，某个产品的第一个版本可以把单元测试完整实施一遍，而此后时不时为解决问题改代码，或为追加功能改代码，单元测试很难继续，常导致单元测试只在V1版本做一遍，其后V2、V3等版本无法再做。
　　不间断的代码修改与阶段化的白盒测试明显不协调，这问题表面看起来并不严重，解决起来却远没想象的简单，该问题可以上升到操作模式问题，解决这个问题，必然要引入一种时时测试的模式，很自然，大家马上猜得出用什么模式?是持续集成!

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

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

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

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

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

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

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

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

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

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

　　任何事物都有3种发展方向：前进、原地踏步、倒退，上面我们描述了白盒测试在有序境界下的行为特征，字里行间还点出了各种行为的改进方向，有针对性的改进了，白盒测试不断前进，反之出现倒退，回到混沌状态。比如在推行初期，白盒测试能否成功很大程度受项目组的执行力度影响，改进这一点须要优化组织结构与流程方法，若任其自然，在个别项目已成功的白盒实践仍无法拷贝到其它项目。

　　有序状态介乎混沌状态与自发状态之间，因其时间跨度较长，我们还可经细分出有序初期阶段与有序后期阶段，在有序初期阶段什么都不规范，白盒测试也常在成功与不成功之间晃动，而在有序后期阶段，应该具备某些自发状态的表现特征了。具体而言，有序状态向自发状态发展，要跨越两大考验，其一，要解决一次测试的问题，要向持续测试过渡，其二，要在组织运作层面解决“机械测试”的问题，上面提到不同员工做测试效果差别很大，有差别是正常的(否则员工无法称之为)，但能否将能力差异对结果影响缩小到系统测试那样呢?
　　通常，白盒测试能力强的员工编码能力也强，测试能力差的编码能力也差，极少听说测试能力很强但编码很差。所以，要让白盒测试做得更深入、更有效，重点是解决思维方式问题，通过培训、日常锻炼也能起到一定效果，但终归不明显，毕竟项目组内个个都是得道高僧比较少见。根据实践经验，解决这个问题的有效的措施是测试先行，如果编码之前写用例，只能依据规格做测试设计了，这对能力强的与能力弱的都一样，思维方式强行改变，其测试无疑是彻底、见效的。

　　从有序前期阶段过渡到有序后期阶段，如何看待测试代码也有很大变化，在前期，开发是开发，测试是测试，测试操作连同测试代码是附加的，可选的，到有序后期阶段，大家会把测试代码也看成一种产品代码，是必需的，也自然而然纳入产品维护。

　　境界之三：自发状态

　　自发状态是白盒测试的共产主义境界，此时生产力高度发达，设计用例的效率提高了，做测试不再是沉重负担。所谓自发，像共产主义社会里劳动是个人意愿而非生存手段，开发人员自测也上升到个人意愿，即使领导不强制，流程也不限定白盒测试必须要做，开发人员仍自愿去做测试。自发状态是白盒测试的高境界，它的典型表现特征是：白盒测试已成员工的普遍行为与自发行为。

　　白盒测试进入自发状态，必须经历两大转变，一是测试效率要有数倍提高，这是基础，二是测试实践能够深入，能有效发现各种问题。目前已有一些公司经历过这两种转变，前者测试效率提高主要依赖于在线测试、持续测试、黑盒调测等理念(详情请见《第4代白盒测试方法概述》中拉通测试小循环、拉通研发大循环、调试转化为测试等章节)，而后者有效发现问题，测试先行(TDD)已接受广泛的实践检验。当上述两大转变完成了，白盒测试成为每位员工的必须行为，像调试操作，每位员工写完代码，正常都要“调一调”，在自发境界下，随时“测一测”是每位员工自然而然要做的事。自发境界下的一个组织，实际操作中“测一测”很大程度上代替了“调一调”，这时，员工数月不开调试器是常见的现象，因为“测一测”对开发人员来说是让程序跑起来经济实惠的手段，也是查错、检错便利的方式，使用调试器并非必需。

　　在自发境界下，时时测试、持续测试已成一种风气。另一方面，员工从领导层到基层，都普遍对白盒测试有着深入认识，知道白盒测试应该“有所为有所不为”，企业培养了一批白盒测试专家，他们很清楚哪些被测对象是可以做白盒测试的，哪些不大容易做。即使处于白盒测试高境界，也并非所有系统都适合完整的做测试，尤其那些严重依赖特定硬件环境的软件层，当白盒专家识别出哪些模块不宜做单元测试或集成测试后，他会考虑替代方案，比如加强代码审查、加强同行评审、为特定接口追加模拟器设计等。

　　总结

　　本文描述了通信业界的白盒测试三种境界：混沌、有序、自发，这三种境界反映了通信企业在白盒测试领域的一般发展过程。从混沌状态升级到有序状态，核心焦点是要解决测试效率的问题，只要效率提高了，一个组织是很容易从混沌状态进阶到有序状态的初级阶段，接着通过组织结构与流程措施的优化，巩固已有成果，然后着重解决持续测试与深入测试的问题，解决好了升级到有序的高级阶段，升级的关键在于“持续测试”这个理念的转型。从有序状态进阶到自发状态，涉及测试效率与测试质量的全面提升，操作模式会有很大变化，测试工具是关键，工具不仅方便易用、测试效率奇高，而且要方便让大家从“调一调”向“测一测”转变。

　　上述企业白盒测试三种境界，可与孔夫子的人生境界相比拟，孔夫子说：吾十有五，而志于学，三十而立，四十而不惑，五十而知天命，六十而耳顺，七十从心所欲，不逾矩。

　　“十有五而志于学”，这是混沌境界，“志于学”三字点出该阶段要做的事，对于白盒测试来说，处于混沌状态下的企业要勇于尝试，否则永远是原地踏步，没有进步;“三十而立，四十而不惑”对应于有序境界，此时白盒测试已找到门道，“不惑”是坚定自己的信仰，持续做下去，持续优化下去，所以，处于有序状态的企业贵在坚持;“七十从心所欲，不逾矩”，这是自发境界，老夫子的从心所欲，并非无限制的为所欲为(要不，孔圣人不该叫圣人，而应该叫神人)，关键是“不逾矩”，知道规矩在哪才能不逾矩，才能从心所欲，所以，自发境界下的白盒测试还要“有所为有所不为”。我们概括一下：企业白盒测试处在混沌状态贵在尝试，处在有序状态贵在坚持，处在自发状态贵在自知。