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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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