白盒测试持续改进的关键

白盒测试持续改进的关键

单元测试与集成测试三种发展阶段。

初始阶段一：

发展阶段二：

白盒测试过程也逐渐融入研发流程，典型的例子：将白盒测试发现的问题纳入统计，研发过程中会以缺陷密度(每千行代码发现多少BUG)作为衡量白盒测试是否充分的指标，另外还会以覆盖率指标作为检查个人是否充分测试的依据。个体行为难以转化为组织行为。

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

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

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

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

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

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

会有白盒测试无用论产生

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

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

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

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

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

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

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

嵌入式产品的单元测试该不该上单板?这个问题更多的可归结为实践上可不可行，从理论上讲没人规定单元测试就不能上单板。但现实操作中，通信产品上单板做单元测试大部分都失败。依据实践的推论，通信软件的单元测试应在仿真环境下按纯软件的方式去做，集成测试倒是可以上单板，在真实环境下去做。

成熟阶段三：

设计用例的效率提高了，做测试不再是沉重负担。开发人员自测也上升到个人意愿，即使领导不强制，流程也不限定白盒测试必须要做，开发人员仍自愿去做测试。白盒测试已成员工的普遍行为与自发行为。

一批白盒测试专家，他们很清楚哪些被测对象是可以做白盒测试的，哪些不大容易做。即使处于白盒测试最高境界，也并非所有系统都适合完整的做测试，尤其那些严重依赖特定硬件环境的软件层，当白盒专家识别出哪些模块不宜做单元测试或集成测试后，他会考虑替代方案，比如加强代码审查、加强同行评审、为特定接口追加模拟器设计等。

总结

核心焦点是要解决测试效率的问题，只要效率提高了，接着通过组织结构与流程措施的优化，巩固已有成果，然后着重解决持续测试与深入测试的问题。