浅议自动用例技术与桩代码生成技术

czo

首先是自动动态测试，我认为在实际工作中几乎是没有应用价值的，指望自动生成的测试用例来测试是不现实的。例如，一个字符串参数，它可能是一个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++程序员都能实现。自动生成的桩，能做到的不过是使编译链接通过，仅此而已，它是不可能代替原来的函数的，原因跟前面所述的一样：工具不可能自动了解代码的功能，也就不可能生成可以代替原函数的桩。问题不在于人工修改桩，这个不难，难的是：不同的用例可能需要不同的桩（例如返回不同的值），难道执行每个用例时都去改一下桩代码？显然不现实。所以，工具要能够解决这个问题，实用价值才比较高。