|
是够冷清的,我来说几句,抛砖引玉吧。
首先是自动动态测试,我认为在实际工作中几乎是没有应用价值的,指望自动生成的测试用例来测试是不现实的。例如,一个字符串参数,它可能是一个SQL语句,可能是一行C代码,可能是一个报文....工具能生成这些有意义的输入吗?
测试工具不可能自动了解代码的功能,无论厂商如何吹,自动用例都跟功能无关,价值不大,例如:
int Add(int i, int j){return i-j;}; 我把加号写成了减号,哪种自动测试工具能自动发现这种最简单代码中的最简单错误?
自动用例的价值仅仅在于:一些特殊值会导致崩溃,异常,超时,溢出等可捕获的极端行为,从而发现错误,也就是说,可以让工具生成大量的自动用例,来“碰”这些错误,仅此而已。这些极端错误本身是比较容易暴露的,真正麻烦的是功能方面的错误,特别是部分比较少见的输入产生的功能错误,人工用例为主才能实现起码的测试,过度夸大自动用例的功能,只会令人失望。
为了让自动用例“碰”到错误的可能性大一些,自动用例的数量应该尽可能多,因此,人工去设定自动用例的预期输出是不明智的,例如,int Add(int i, int j){return i-j;}; ,输入两个整数,假如整数预设了五个值,两两组合可以生成25个用例,人工去设定这25个用例的正确输出,累不累呀?
自动生成用例的技术是一种简单技术,工作原理大致如此:任何数据类型都可以分解为基本数据类型,基本数据类型是很少的,只有十来种,只要预先设定好这些基本值,把参数分解为基本类型,把基本值填进去就OK了,多个参数再排列组合一下。有经验的程序员可以很轻松地实现这种功能。还有一些对路径进行分析然后生成用例的技术,都不成熟,主要难题是很多条件值是跟底层调用有关的,并不仅仅跟直接输入有关。
至于没有参数的函数,我认为也并不是不需要用例。参数只是用例输入中的一种,此外还有全局变量、成员变量、中间输入(底层代码产生的输入)。
至于桩代码,生成桩代码也是一种简单的技术,只要把函数解析出来,生成它的声明,有返回值的返回一个简单的值就OK了,随便一个有两年经验的C++程序员都能实现。自动生成的桩,能做到的不过是使编译链接通过,仅此而已,它是不可能代替原来的函数的,原因跟前面所述的一样:工具不可能自动了解代码的功能,也就不可能生成可以代替原函数的桩。问题不在于人工修改桩,这个不难,难的是:不同的用例可能需要不同的桩(例如返回不同的值),难道执行每个用例时都去改一下桩代码?显然不现实。所以,工具要能够解决这个问题,实用价值才比较高。
随便说说,不对之处请指教。
[ 本帖最后由 czo 于 2008-6-4 08:02 编辑 ] |
|