有来面试的同行问个一个问题:“如果微软的开发和测试工程师都需要写代码,那么两者写出来的代码有高下之分吗?”
当时我只能简单的解释一下。现在可以多说一些了。
举个例子,单元测试。适合不同语言的工具有一大堆,各个论坛上都能搜到大堆文章。出现频率最高的不外乎
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
的那个源文件,改为执行表,再编译链接一次,大功告成。
问题是怎样产生第一个可执行文件呢?用户使用单元测试工具的时候不都实现了一些函数吗?那就能产生用户的编译单元。我们可以预先提供一个定义
DllMain
的壳
lib
,它与用户的编译单元链接在一起就成为被
DIA SDK
分析的
DLL
。然后像前面说的,最后换成执行表的编译单元。
你注意到了吗,用这个方法,别说
CppUnit
,做
CUnit
都可以。
二、
用
struct
表达
attributes
刚才并没有提到如何像
NUnit
和
JUnit
一样取得
attribute
所定义的信息。我们要求需要执行的函数定义成返回
BOOL
类型,只有一个参数,一个结构的指针。
如果用户定义的这个结构像这样
struct SIGNATURE_001
{
SIGNATURE_001()
{
const char* title = "Test case 1";
const DWORD priority = PRIORITY.P1;
const char* Setup = "MySetup";
const char* Cleanup = "MyCleanup";
…
}
};
用
DIA SDK
分析就会发现,这个函数的参数类型具有构造函数,其中有局部的常量名字如何,值多少。依靠这些信息,我们足可以判断一个函数是不是需要执行,所需要的参数都是怎么样。
为了简化,我们可以用一个简单的宏帮助定义这一切,放在函数前面就可以了。当然它不是必需的。
在
C
下面可不能这么用,但办法还是有的。
三、
用注释表达
attributes
既然我们能把函数定位到某一行,那么往前扫描源文件行,遇到三个斜杠开头的就滤掉“
///
”读进来,如果我们预期这些注释看起来是这个样子
/// <TestCase>
/// <Title>Test case 1</Title>
/// <Priority>1</Priority>
/// <Setup>MySetup</Setup>
/// <Cleanup>MyCleanup</Cleanup>
/// </TestCase>
那么只要分析这段
XML
文本,接下来的事情就跟前面说的一样了。
四、
自动运行整个过程
用户需要的是写好测试代码,执行一个命令就能得到所有可执行代码。我们可以利用
makefile
把这一切连接起来:先写好需要分析的
DLL
的依赖关系,然后让执行表依赖上述
DLL
,命令为执行分析代码产生执行表,最后让目标
DLL
依赖执行表即可。又或者用
Visual Studio
的
Build Steps
来驱动也可以。
到这里,大家可以看到,为了实现最终目的,我们突破了习惯的限制(只使用语言特性),并且充分利用现有的技术和工具(
DIA SDK
和
XML Parser
)。只要能实现目的,“无所不用其极”。
你可能觉得折腾这么一套东西动作也挺大的。我得说,“看菜吃饭”。
另一个例子,有一个测试框架,万事俱备,就是没法把
test case
自动传送到
Apple Macintosh
的机器上。现有的代码可以让
test case
在
Apple Macintosh
上执行,也可以把
test case
从服务器下载到
Windows
测试机器上发动执行,但是没法跟
Apple Macintosh
交流。
怎么办?在
Apple
上开发谁都不懂。在
Apple Macintosh
上写一个客户端跟服务器交流,够忙半天的了。面对一整套已经完备的测试框架,让它尽快用于新的环境,比做什么都重要。
别人告诉我,可以
Apple Macintosh
上开一个共享夹,然后
Windows
的机器可以用
UNC
路径往里面读写文件。
OK
,这就足够了。
Windows
测试机器上发动执行的只是一个脚本,把需要用到的文件往指定
Apple
机器的共享文件夹上写。写完之后再写一个文件,名字是约定好的,例如“
ready
”,里面包含启动
test case
的命令行。然后不停的隔一段时间检查共享文件夹里面一个叫做例如“
done
”的文件,出现之后把它作为结果返回服务器,最后把它和其它文件都删掉,退出。
Apple Macintosh
上面则运行另一个脚本,始终不退出。它不停的隔一段时间检查其指定的共享文件夹里面一个叫做“
ready
”的文件,出现之后执行里面的命令并且等待它结束。这个命令必须生成一个叫做“
done
”的文件,包含执行结果。然后,不停的隔一段时间检查“
done
”是不是还在,不在了就回到最初的检查“
ready
”的代码。
这就足够了。两个脚本加起来
50
行不到。
你觉得它太粗糙了吧?这么简单的协议?
事实上,它并不需要十分健壮。
一、
Windows
和
Macintosh
双方的网络文件系统协议解决了很多问题
二、
测试机器是不会有人去用的,你可以安全的假设只有你的程序在执行
三、
服务器和
test case
都已经测试过,他们应该负担起若干健壮性的需求。事实上,他们比这两个脚本更适合做这个,不是吗?
这就是“看菜吃饭”:不需要的功能,是不需要去实现的,无论它看上去有多么的
cool
;必需的功能,无论如何都要做到,无论它看上去有多么的
boring
。
其实,无论开发测试,都是为了让人们更好的发挥自身的潜力。开发工程师让人们可以专注于自身的事业而不用过多学习计算机技术;测试工程师让开发工程师可以发挥自身开发的潜力而不用过多参与质量保证的事务。代码高下之分,只能通过让人们发挥了多少潜力来检验。
《神雕侠侣》里提到独孤求败晚年“飞花摘叶皆可伤人”,皆因“不滞于物”,达到“无剑胜有剑”的境界。
所以,开发和测试工程师写出来的代码高下之分,对于这个问题,我会这样回答:皆可伤人,何须理会是花叶还是刀剑;都能发挥人们的潜力,不必关心来自开发还是测试的手笔;优劣之分,或者只来自于用剑者本身。