解决编译差异和平台差异

　　跨平台单元测试，例如在PC上测试嵌入式项目，或在windows上测试Linux项目，由于编译环境可能不同，代码中通常会出现一些非标准的特殊关键字，以及数据长度可能不同。这些差异可以用工具自动解决。

　　上图是解决编译差异和平台差异的示意界面。工具可以自动屏蔽特殊关键字或代码片断,也可以转定义关键字来解决数据长度差异。这样，在不修改产品代码的前提下，可以比较便利地解决编译差异和平台差异。

　　“可编程的桩”不能解决内部输入

　　也许很多人都会认为，编写桩代码可以解决内部输入问题，内部输入有六种情形，我们来具体分析一下。

　　自然输入：自然输入调用实际代码，是不需要特别解决的，跟桩无关。

　　不可控：不可控调用的也是实际代码，不是调用桩代码，因此也不能解决。也许有人会问，另外编写桩代码来代替实际代码行不行？在应该调用实际代码的时候，要想调用桩代码可能是很麻烦的，例如，底层函数位于同一个文件，或同一个类，如何去调用桩？

　　难于初始化：也是调用实际代码。

　　静态输入：静态输入只涉及到局部静态变量，没有调用底层函数，当然也不能用桩来代替。

　　中断输入：中断输入在不确定位置，中断调用不确定的代码，也不能用桩来代替。

　　失真：失真是打桩造成的，调用的是桩代码。编写桩代码可以解决一部分失真，我们来具体分析一下。在比较简单的情形下，可以用命名法来控制桩代码的输出，即给每个用例命名，桩代码中判断用例名来决定输出，VU2.0最初的设计就是采用这种方法，但是经过应用，

　　发现只能解决简单情形，所以放弃了。如果在同一个用例中，多次调用同一个桩，每次要求输出不同，命名法就无效了。这种情形是很常见的，例如在循环中调用桩代码。一个被测函数可能调用多个桩，一个桩又可能被多个被测函数调用，这种多对多的关系下，很难维护用例与桩的对应。用例可能很多，还可能要不断增加和修改，维护用例与桩输出的关系也很麻烦。