开发和测试工程师写代码的高下之分

第第页开发和测试工程师写代码的高下之分开发和测试工程师写代码的高下之分

发表于：2023-05-12来源：：点击数：标签：代码测试工程师开发高下

有来面试的同行问个一个问题：“如果微软的开发和测试工程师都需要写代码，那么两者写出来的代码有高下之分吗？”当时我只能简单的解释一下。现在可以多说一些了。举个例子，单元测试。适合不同语言的工具有一大堆，各个论坛上都能搜到大堆文章。出

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

没错，Reflection是能够在执行时（runtime）取得上述信息，然后在执行时利用它指导testcase的执行。

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

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

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

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

那可以如何实现呢？

一、编译链接两次

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

在这些信息中可以过滤出用户预先指定的信息，用来拼成另一个C/C++源文件，这个源文件叫做执行表，里面包含了所有需要执行函数的名字列表以及各项参数的静态定义。“指导testcase执行”是可以预