飞花摘叶还是重剑无锋[1]

　　有来面试的同行问个一个问题：“如果微软的开发和测试工程师都需要写代码，那么两者写出来的代码有高下之分吗?”

　　当时我只能简单的解释一下。现在可以多说一些了。

　　举个例子，单元测试。适合不同语言的工具有一大堆，各个论坛上都能搜到大堆文章。出现频率最高的不外乎CppUnit，NUnit，JUnit三种。比起NUnit和JUnit，CppUnit因为C++语言特性的关系，用起来较不方便。

　　这里我给大家秀一下，解决这个问题，测试工程师会如何的“不择手段”。

　　单元测试往往需要解决以下几个问题：

　　1. 用户能在产品代码中指定需要测试的函数

　　2. 用户能在测试代码中指定需要执行的函数

　　3. 用户能指定各种控制执行过程的参数，比如优先级、重复、初始化/清理函数等等

　　其它就先不说了，待会大家就知道再多的都能做到，现在先做到这三个需求就挺不错了。需求1是可选的。Visual Studio从2005开始有这个功能，但是如果没有，估计大家也不会太在意，对吧?

　　那么，CppUnit如果要做到NUnit和JUnit的样子会遇到什么困难呢?首先就是C++缺乏反射(Reflection)功能。

　　你看NUnit和JUnit都是定义了一大堆attribute。用户通过为函数指定恰当的attribute，就能标明这个函数需要作为test case执行，之前执行初始化函数Setup，之后执行Cleanup，还有重复100次，优先级2什么的，其它的往上堆attribute就行了。

　　Visual Studio 2005之后为实现需求1，通过.NET Reflection找出一个类的全部成员函数，然后列个表让你选要测试的函数，最后代码架子都给你搭好。

　　而CppUnit得用模板，还有另外一个我忘了名字的C++单元测试工具用的是宏。他们费这么些劲是为了什么呢?其实是为了取得这些信息：

　　具有特定标记的函数的名字或者入口地址/函数指针

　　附加在该函数上的各种整数，字符串或者函数指针的值

　　拿到之后呢?CppUnit也好，NUnit或JUnit也好，都是按照取得的信息规划每个函数的执行，保证异常和错误不干扰其它函数的执行，统计整理执行结果和记录日志，没什么区别。

　　我们来看看，Reflection对于取得那些信息是不是必需的呢?

　　没错，Reflection是能够在执行时(runtime)取得上述信息，然后在执行时利用它指导test case的执行。

　　等等，我鸡蛋里挑个骨头：非要把“取得信息”和“指导test case执行”放在同一段执行时期里面吗?或者说，先“取得信息”，停一下，再“指导test case执行”，行不行?

　　甚至，“取得信息”放在一个程序里先执行，“指导test case执行”放在另一个程序里后执行，又如何?

　　更甚之，“取得信息”是让别的程序做的，之后让“指导test case执行”捡现成的呢?

　　可见，Reflection提供了比我们所需要的多得多的功能，实际上我们只需要知道“怎样指导test case执行”就够了。

　　那可以如何实现呢?

　　一、 编译链接两次

　　对，你没听错!编译链接之后除了可执行文件还会产生不少有用信息，最有用的当属PDB文件，包含了所有标识符(Symbol)的信息。Visual Studio 2003开始就带有一个DIA SDK，可以在其安装目录的DIA SDK文件夹下面找到头文件、库文件、COM组件DLL和示例程序。用它分析一个DLL或者EXE可执行文件对应的PDB文件，你可以取得每个编译单元(用.c/.cpp编译得到的obj或者lib)里全部函数的情况，包括函数名字、是否成员函数、返回类型、全部参数的名字和类型、全部局部变量的名字和类型，甚至它在哪个文件的哪一行定义。

原文转自：http://www.ltesting.net