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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有序状态介乎混沌状态与自发状态之间，因其时间跨度较长，我们还可经细分出有序初期阶段与有序后期阶段，在有序初期阶段什么都不规范，白盒测试也常在成功与不成功之间晃动，而在有序后期阶段，应该具备某些自发状态的表现特征了。具体而言，有序状态向自发状态发展，要跨越两大考验，其一，要解决一次测试的问题，要向持续测试过渡，其二，要在组织运作层面解决“机械测试”的问题，上面提到不同员工做测试效果差别很大，有差别是正常的（否则优秀员工无法称之为优秀），但能否将能力差异对结果影响缩小到系统测试那样呢？

通常，白盒测试能力强的员工编码能力也强，测试能力差的编码能力也差，极少听说测试能力很强但编码很差。所以，要让白盒测试做得更深入、更有效，重点是解决思维方式问题，通过培训、日常锻炼也能起到一定效果，但终归不明显，毕竟项目组内个个都是得道高僧比较少见。根据实践经验，解决这个问题的最有效的措施是测试先行，如果编码之前就写用例，只能依据规格做测试设计了，这对能力强的与能力弱的都一样，思维方式强行改变，其测试无疑是最彻底、最见效的。

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