处于强制推动区，企业应更关心选择高效率的测试工具，让白盒测试能做得下去，所以测试工具的使用效率与易用性最为关键，要达到一定的基准（否则如果用不下去就一票否决了），此阶段的白盒测试即便没有太明显的绩效也算成功了，因为测试做得下去，就有了可改善的基础。在组织推动区，须要解决一些基础的质量保证问题，至少，要保证白盒测试实践富于实效，测试能深入进去，比如测试先行等实践能有效的支撑起来。到了自发推动区，工具在测试效率、易用性与质量保证各环节都达到较高水准，对质量环节提升的要求更多些，此时质量要求集中于“平稳、无风险、可拷贝的运作”。

　　本评估模型的一个实例化表格如下：

工具选型常见误区

　　上面已详细介绍嵌入式白盒工具选型的过程与方法，这里我们再补充选型中常见的认识误区：

1. 过于追求不必写脚本的测试
   
   业界有少数白盒工具，宣称不必编写脚本（一行都不写）就完成测试，因为所有用例都是自动生成的。此类工具学习成本较低，易用性无疑比较好，但不见得完全符合测试的价值，如果它生成的脚本是自闭的，不允许用户修改，那么这个优点会立即变为致命缺点。
   
   因为测试代码与被测代码是对等的，代码的性质，包括复杂性与易变性很接近，甚至，如果进行完备测试的话，测试脚本的规模应接近于被测代码的规模，所以，一行脚本都不写的测试有点难以理喻，如果不是功能太弱，就是操作太复杂，这是必然的，操作界面一个接一个，表面上易用性提高了，但用例的设计、调试、维护效率直线下降。
   
2. 找一款让白盒测试一步到位的工具
   
   相对产品研发的其它软件过程，白盒测试总体还不够成熟，还没有充分发展，尤其是嵌入式领域的白盒测试，运行环境复杂，又主要针对C代码做测试，推动白盒测试的门槛较高。所以，我们不必寄希望引入一个工具就解决所有问题，至少，白盒测试过程不纯粹是工具的问题，还与流程管理、人员素质等因素相关。
   
   
   企业应该规划白盒测试的发展线路图，从强制推动区到组织推动区，再到自发推动区循次渐进的去发展。许多事情不可一躇而就，尤其在组织推动区向自发推动区迈进时，测试要向深层次发展，推行测试先行等实践需要有个过程。这对工具选型提出要求：最好选择跨越各阶段，能够持续促进的白盒工具。
   
3. 追求功能大而全
   
   
   商用白盒工具除了支持写脚本做测试，还通常具备其它辅助功能，比如：静态代码检查，代码可维护性评估，编程规范检查，支持性能测试、内存泄露检查等。毫无疑问，一个工具支持功能越多当然越好，但如果因为多支持一些功能而大幅抬升售价，评估者就不能不小心权衡了。
   
   

   一般而言，多数附带上述辅助功能的商用工具，辅助功能的品质往往不能与专业工具相提并论，比如C/C++语言的代码检查，业界最佳是pclint，代码质量或编程规范检查，业界较佳的是logiscope，内存泄露既有商用工具purify、BoundCheck，也有不少免费工具，如Visual Leak Detector。如果一个白盒工具的拥有良好的外部命令扩展能力，其它工具如pclint、Visual Leak Detector等能顺利的嵌入或配合着使用，就达到最佳组合，不仅整体功能强大，支付费用也低。
   
4. 不从自己的需求出发，以某工具现有功能为基准罗列评估条目
   
   
   前面已提及，这里再强调一下，对白盒测试理解尚不深入的企业很容易误入歧途。