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

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

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

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

　　所以碰过几次壁后，多数企业都会回到这种操作方式：每个开发人员自己写代码，自己做单元测试(主要是模块级白盒测试)。这是主流运作方式，非主流的，还可能间或让两个互相熟悉对方代码的开发人员，交叉一下做单元测试，这也是比较有效的方式。

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

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

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

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

　　会有白盒测试无用论产生

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

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

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

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

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

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

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

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

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