|
例如一个C语言编译器项目
预处理器 -》
词法分析器 -》
语法分析器 -》
代码生成器
对于后面三个模块的多数函数来说,主要输入都是token序列,当然还会有其他输入,但最主要的是token序列,我们把这种输入称为核心输入。
即使是大规模的项目,核心输入也极少。
生成核心输入的代码,通常很难用自动桩来代替,由于这种代码并不多,可以提前开发,或开发一个简单的临时版本,不一定完善,只要能生成核心输入就可以,一般是不难做到的。例如,C语言编译器项目,只要有一个函数,可以把C代码转换为token序列,基本上全部模块就可以并行开发测试了。
除核心输入外,还会有很多其他输入,用桩来代替可以进行测试,但一般很难解决失真的问题,测试效果有限,所以工具最好要有底层模拟功能。桩造成的失真是单元测试的十大难题之一,下面的例子可以说明:
struct DATA;
extern int subfunc(int* pvar, DATA* pdata);
int CMyClass::func(int arg, struct DATA* pdata)
{
int a, b;
a = subfunc(&b, pdata);
if(a <= 10)
{
//其他代码
return b;
}
else if(b < 0)
{
//其他代码
return b;
}
//其他代码
return b;
}
subfunc就是一个底层函数。
1) subfunc未实现或被隔离。这时VU会自动生成桩,桩代码大概是这样的:
int subfunc(int* pvar, DATA* pdata){return 10;};
由于桩代码只是简单返回10,此外什么也不做,会导致测试难于进行,因为调用subfunc后,a总是10,而b未初始化,后面的路径是不可控的,想用等价类法测试各个功能点很困难。手工修改桩代码也不可行,因为在不同用例,subfunc的输出应该不同,不可能每执行一个用例就修改一下桩代码。这时,我们可以通过底层模拟,在每个用例中直接设定subfunc的输出(即a和b的值)。
[ 本帖最后由 VisualUnit 于 2008-10-27 10:03 编辑 ] |
|