聪明猴子测试的代价

　　好的聪明猴子工具的创建代价是很高的。像所有测试自动化一样，构建聪明猴子测试工具需要开发和测试资源。而最昂贵的代价是创建模型或状态表。通常一个适当复杂的产品需要50000个节点的状态表。持续地增加新的功能特性可能导致状态爆炸，状态节点的数量呈几何级增加。因此创建状态模型不是一次性的代价；对于大的模型或状态表，维护成了一个主要的成本考虑要素。

　　一个好的状态表基于Petrinets（一种用于表达离散平行系统的并发事件的自动化建模技术）或者马尔可夫链（一个加权图表：所有权值都是非负的，并且输出的总的权值的边界都是正数）可让聪明猴子所利用 – 这可以部分地帮助调整一些代价。即使如此，创建状态表的代价，以及猴子利用这些状态表来运行测试要付出的代价通常超过找到的bug带来的回报。更可怜的是大部分聪明猴子不容易被移植到其他项目。你的猴子往往只会在这个为其设计的项目中“玩”并且找到bug。

使用有用的笨猴子

　　我在若干年前开始使用笨猴子，在Windows NT 4.0的产品周期中。我的团队使用一些商业工具作为测试的引擎来寻找操作系统的bug。我们为好几百个流行的应用程序开发了一个自动化的测试套件，并且在操作系统的产品周期中持续地运行它们。但是还有上千的应用程序，如果我们有时间和测试人员来为它们创建测试的话。某些测试能找到很好的bug，但我们需要更廉价的测试方式。

　　我们尝试用笨猴子来测试那些应用程序。我们的笨猴子能理解Windows的基本元素。他们知道菜单，他们会选择找到的菜单选项。他们也会识别出普通的Windows控件，例如命令按钮、选择框、输入框等。他们为每一个控件运行一组预先定义的测试来确保它是正常工作的。他们还能识别出一些普通的命令按钮（例如“OK”和“Cancel”），而那些“久经世故”的猴子能自动调整自己以适应不同的本地化版本的Windows。

　　我们用几种流行的自动化工具来创造猴子。虽然我们组关注在Windows操作系统，但是实际上类似的猴子能为其他GUI操作系统而创建出来，使用那些操作系统版本的自动化工具。

　　拥有GUI悟性的猴子能操作很多Windows应用程序。但是一些应用程序依赖个性化定制的控件来向用户暴露他们的功能。大部分自动化工具在测试那些应用程序上存在困难，因为工具不能找到那些控件。如果自动化工具不能找到这些控件，则猴子也不能找到它们。我们通过几种方法来处理这种问题：

　　我们让猴子在每次碰到一些新的窗体的时候随机地点击几下。有时候猴子会点击到其中一些隐藏的界面元素，从而改变程序的状态。

　　如果程序有一些有趣的区域，例如工具栏，对猴子来说是不可见的话，我们让它集中点击那些区域。

　　如果应用程序依赖用户做很多的鼠标和键盘操作，我们还能叫猴子随机地执行一些鼠标动作，例如左键单击、右键单击、拖拽，或者是在当前的插入点输入随机的文本。

　　（拥有这些技能的猴子能在画图程序或Corel Draw上画出不可思议的、未来派的作品）

　　我们有些时候把这些工具叫做“通用状态表”猴子，因为他们需要知道5个状态才能有效地工作：

　　1、  被测试应用程序没有在运行。

　　2、  被测试应用程序在运行中，并且可能在等待接受测试的输入。

　　3、  新的窗体出现了。

　　4、  新的窗体有一些猴子能识别出来的窗体控件。

　　5、  新的窗体离开了。

　　给出这样一个简单的只有5个基本状态的状态表，可以让我们的猴子记录更加有用的关于程序错误和失败的信息。猴子看到的大部分这些错误都是含糊的；必须检查错误日志来判断发生了什么事情。我们把这些称为“猴子噪音”bug，我们尽量避免它 – 通常忽略它。相反，猴子以debug方式运行程序，我们则用调试器监视猴子的测试。我们需要找到那些令人厌恶的和恐惧的“蓝屏”bug；调试器在“诱捕”这些bug方面很有用。它会自动中断猴子，并允许开发人员检查bug发生时的机器状态。