单元测试的效益如此之高，为什么真正成功实施的单位却很少？因为很多看起来非常吸引人的方法或技术，只能应用于简单独立的代码，无法适应复杂项目，华而不实。单元测试工具必须“专而精”，才能在有限的时间内顺利完成测试。“专而精”表现在：深入复杂应用，发现并解决阻碍测试工作各种难题。在介绍Visual Unit 2之前，我们先探讨一下单元测试会遇到哪些难题：

　　可测性问题：如果测试无法进行，就归引咎于代码可测性差，要求改进开发流程，提高可测性，对吗？代码可测性差有其必然性，程序是客观事物的反映，客观事物本身互相关联、互相纠缠，代码间的多数耦合不可能消除，解决可测性问题是单元测试工具的首要职责。试图通过优化开发流程来提高可测性是不现实的，优化流程是一个长期、渐进的过程，不可能短期内实现飞跃，更不可能解决客观事物间的“耦合”。

　　可编程的桩：桩代码通常是脚本或源代码，当然是“可编程的桩”，但应用中会发现，编写桩代码并不容易，例如，子函数通过参数传递输出，要求第一个用例输出1，第二个用例输出2，第三个用例输出3，这是最简单和常见的应用，如何实现桩输出与用例的对应关系？VU2最初的设计是：用户可以给用例命名，桩代码中判断用例名来决定输出，但发现根本无法适应复杂项目，因为：一个桩可能被同一函数多次调用，每次要求输出不同；一个桩可能被多个函数调用；一个函数又可能调用多个桩；一个函数可能需要十几个用例，随时可能补充和修改用例。要维护用例名和桩行为的对应关系，无疑是一场噩梦。

　　白盒覆盖：工具统计出覆盖率就算完成任务了吗？不！如何实现覆盖才是大问题。传统的白盒方法（如用于语句覆盖的基路径法，用于MC/DC的真值表法）效率太低，工具如果不能提供快速设计白盒用例的方法，实现高覆盖根本做不到，仅仅统计出一些数据又有多少实际意义？

　　测试效果：如何保证测试效果？有了覆盖率就可以了吗？实践证明：

　　1）白盒覆盖基于现有代码，再高的覆盖率也不能发现代码缺失错误；

　　2）用例必须反映程序的功能，测试才有价值，单纯追求覆盖率容易导致“跟着代码走”，使测试失去意义；

　　3）程序员和测试员都容易遗漏边界、非法输入，这种错误常常导致程序崩溃。因此，测试工具不仅应能统计覆盖率，还应将数据集中，便于人工根据设计功能来检查，并且自动生成边界用例检查非法和边界输入。

　　还有很多问题可能使测试工作“卡住”，例如：

　　局部静态变量需要每个用例设定不同值，但却无法在用例中访问；

　　程序未把计算好的数据输出（如通讯程序中计算好的报文直接发送出去），如何判断计算结果是否正确？

　　底层函数的输出难于控制（如取环境温度的函数，需要即时返回各种不同温度）；

　　嵌入式代码，中断可能在某个时刻改变了某个全局变量；

　　层函数的输入可能很复杂，难于初始化。

　　上述问题如果无法解决，测试工作必然会遇到大量的困难，要么付出巨大成本，要么被迫搁置。经过长期的实践和技术攻关，“十年磨一剑”， VU2已成功解决了这些难题，并已在众多企业和尖端行业成功应用。

　　VU2具有：自动解决可测性问题、高效建立和管理测试用例、超过航空标准的覆盖准则、高效完成白盒覆盖、黑盒/白盒/自动相结合实现彻底测试、方便的回归测试、快速排查错误、支持可视编程、完整的统计、易于浏览的报告等“雪中送炭”式功能，使单元测试可行、易行、高效率、高效益。

　　一、自动解决可测性问题

　　“可测”，包括两方面含义：测试任务能够独立运行，代码功能逻辑能够完整覆盖。“可测”的关键难点在于内部输入，即底层函数产生的数据，以及静态输入和中断输入。底层函数可能不存在、无法调用、不可控、打桩造成失真、难于初始化，只有便利地模拟底层函数的各种行为，并在用例中控制局部静态变量和模拟中断造成的全局变量修改，才能完整测试函数的功能逻辑。

　　1、自动将测试任务分离出来，实现独立测试

　　VU2可以一次性将一位测试人员的测试任务隔离出来，自动生成驱动代码和桩代码。下图为设置测试任务的界面，需测试的文件设为T，不测试但可能调用的文件设为N，其他文件自动打桩隔离。