聪明猴子通常从一个状态表或者模型获取到关于产品的知识。通过随机地遍历这个状态模型，它们选择对于当前状态有效的选项，从一个状态转移到另外一个状态，然后验证到达了下一个期待的状态。如果模型包括错误处理状态的话，你还可以添加非法的输入到“猴子”的指令表。

        笨猴子则不一样。（“无知的猴子”听起来更准确些，但是“笨”听起来更普遍一些。）它们不会使用状态表；它们不知道被测试应用程序的当前状态是什么，也不知道什么输入是合法的，什么输入是不合法的。最重要的是，它们当它们碰到bug的时候，不知道是bug。纯的笨猴子是Beizer的“键盘狂抓”测试工具的最佳例证，对于大部分项目而言不是非常的有用。“不是那么笨的猴子”则比较有用些。“不是那么笨的猴子”虽然对你的项目而言也是无知的，但是他们拥有一定的环境知识，足够找到像崩溃、挂起这类的bug。

        这样的工具已经被使用了一段时间。在80年代早期Lisa和Macintosh项目组中开发了一个笨猴子测试工具，这个笨猴子有一定的Apple操作系统的知识。有些开发人员被要求他们的产品在发布之前必须承受一定量的猴子测试时间。现代的测试猴子比早期的Apple的“类人猿”工具知道更多关于操作系统的知识。

        作为讨论方便，我们认为笨猴子是对程序无知，但是能理解环境的。
        什么时候使用聪明猴子？

        在理想的世界里，你可以通过评审规格说明书以及代码来找到程序的所有bug。你不需要在最终产品上运行任何测试，因为它不会有bug。我羡慕在这样的条件下生产软件（我希望某天能在这样的项目中工作）。但是大部分人不能达到这么高级的目标。原因有很多，其中最主要的是软件程序的复杂度。要做完整的评审，我们必须理解软件的操作环境，并且在脑海里演练程序的运行。在有合适的培训和技巧的情况下，我们可以在嵌入式系统这样做-或者在一些在指定装置下运行的复杂的软件。但是当软件必须工作在事件驱动的系统时，必须与其他成千上万的软件产品一起工作时，我们对情况的把握，以及评审的质量都会不及格。再加上成百上千的用户同时在使用我们的产品，我们仅仅通过评审来找bug的能力在缩小。

        良好构建的聪明猴子在这种环境下能很好地找到bug。如果你精确地把环境事件建模到状态表，那么上千个聪明猴子就能读取这个表，并对你的产品上演那些事件。猴子会找到人们在评审时永远都不会考虑到的组合和顺序，尽管用户在发布后的版本可能创建这些组合和顺序。大部分的商业压力或负载测试工具以来这些聪明猴子的技术。

        Brian Marick在《软件测试的艺术》中说：复杂的测试会比简单的测试找到更多的bug。但是大部分的自动化测试都是简单的。我们期待一个输入后得到一个主要的输出，然后程序回到一个已知的基本状态，然后执行另外一个简单的测试。如果测试是深思熟虑的，则会找到好的bug。但是仍然是简单的测试。当我们回到程序的基本状态，则丢弃了前面测试的“历史”。而真正的用户不会这样操作，他们把一系列简单的动作串起来，形成一个复杂的环境。

        我们的简单测试不会模拟那些用户行为。因此如果一个简单的动作引起了另外一个动作的失败，我们的简单测试不会找到那个bug…但是我们的用户会找到它。但是使用聪明猴子，可以让我们的简单自动化测试变成复杂的用户场景。在测试中去掉“回到程序已知的基本状态”。然后让猴子决定运行哪个测试，用怎样的顺序执行。猴子会创建非常复杂的测试，并且持续测试你想要的时间长度。并且每次运行它都会创建不同系列的复杂测试。

        这种简单变复杂的测试的另外一个好处是我们可以确保程序在运行过程中正确地处理内存和资源分配。运行相同系列的测试，即使是复杂的测试，但是以相同的顺序和路径，即使一遍又一遍地运行也很少机会能发现内存和资源使用的bug。

        相反，我们需要使用复杂序列的、以前未使用过的测试。在这方面猴子比人更有效。