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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文转自：http://www.uml.org.cn/Test/200709172.asp