案例一
    某公司项目众多，使用了多种嵌入式开发环境。当我们的工程师在演示VU4时，一位主管强烈质疑：“我们买过一款单元测试工具，演示的时候都挺好的，买了后，只有一种环境下的项目能勉强跑得起来，但也不好用！你们是不是也这样：演示时好看，实际上没法用？！”
    我们的回应是：请把每种环境最难测的项目找出来，我们免费提供试用、免费提供支持，确认好用再说别的。如果还是不放心，可以先租用，过半年或一年再采购。
    客户经过试用评估后直接采购，并长期满负荷使用，从此，单元测试不再是公司的难题。
 
 案例二
    某研究所有一Qt项目急于完成单元测试，但手中的三种商业单元测试工具均不能支持，后来找到我们。VU4具有良好的适用性，当然能支持Qt，不过，客户在试用时却发现有些文件的测试跑不起来。这种问题的产生原因，通常是某些全局变量初始化时崩溃，程序未进入main函数。我们的工程师在现场排查，过程比较艰难，因为此项目需要复杂的环境支持，在测试机上无法启动调试，不能跟踪程序的初始化过程。对全局变量的分析也没有发现可疑之处。最后用排除法反复尝试，终于找出两个类的构造函数会导致崩溃，有趣的是，这两个类并没有用于可见的全局变量，估计是某个DLL中使用它导致崩溃。此项目还有一些测试难点，比一般Qt项目困难得多，有些代码甚至需要VU本身做一点改进才易以测试。故事的结局还是美好的：客户按期完成了此项目的单元测试。
 
 案例三
    某研究所的单元测试团队，以没有编程经验的美女为主，这帮可爱的“程序员鼓励师”，有些连基本C语法也不明白，更看不懂编译错误。她们测的项目又多又杂，有些还工期很紧张。这家客户对VU4的易用性以及我们的技术支持工程师的耐心是一个有份量的考验，还好，我们经受住了考验。目前，这家客户已采购了第二批VU4，并培养出了一批成熟的单元测试工程师。
 
 案例四
    某公司虽然工程师极力推荐VU4，但负责采购的部门认为国产工具不如国外工具，采购时将大部分份额给了某款国外单元测试工具，只采购了少量VU4。结果真正能派上大用场的恰恰是VU4。目前，该公司已再追加采购了两批VU4。
 
 评述
    以上案例均绝对真实。当然，您可以不相信我们，但我们建议您选择工具时，用实际的项目试一试。在项目中随机挑几个文件，至少包括几十个函数，来检验工具是否好用易用。试的过程您会发现：单元测试并不像想象那么容易，有很多坑，如果工具对付不了这些坑，测试工作就会随时卡住，举个例子：
    while(1)
    {
        ….
    }
    在不修改被测代码文件的前提下，想让这个死循环变成可测的有限循环，比如第1个用例循环2次，第2个用例循环3次，您选择的工具做得到吗？这只是一个小小的坑而已。话又得说回来，如果您试用时能发现这些坑，那么工具已经不错了，至少能把测试跑得起来。