当时我只能简单的解释一下。现在可以多说一些了。
举个例子，单元测试。适合不同语言的工具有一大堆，各个论坛上都能搜到大堆文章。出现频率最高的不外乎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）里全部函数的情况，包括函数名字、是否成员函数、返回类型、全部参数的名字和类型、全部局部变量的名字和类型，甚至它在哪个文件的哪一行定义。
在这些信息中可以过滤出用户预先指定的信息，用来拼成另一个C/C++源文件，这个源文件叫做执行表，里面包含了所有需要执行函数的名字列表以及各项参数的静态定义。“指导test case执行”是可以预先分离实现的模块，把它include进来即可。最后，把原先用来产生可执行文件的全部文件，把定义main或者DllMain的那个源文件，改为执行表，再编译链接一次，大功告成。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/