基于状态模型的测试在基于状态模型的测试中，你把程序可见的行为模拟成一个状态机，并驱动程序在各状态之间转变，检测与预期模型的一致性。关于这种测试方法的深入讨论在www.model-based-testing.org网站上。
一般而言，用自动测试把软件行为比作模型，所以存在的失误比较容易发现（易于评估）。
通常，基于模型的测试是可靠的、有激发性的、易于解决的。可是，因为有太多的状态（El-Far 1995），基于模型的测试经常是被简化的，它着眼于操作方式而不是状态之间的转变。有些抽象的操作方式是明显的、可信的，而对一些相关者来说，其它的似乎是过于宽泛的或不固定的，从而简化测试。另外，如果模型过于简化，那么模型暴露出来的错误会难以解决（Houghtaling,2001）。
讨论Harry Robinson（2001）在创建软件状态模型方面的经验，他报告：在自动测试完成之前，在建模时就会产生很多缺陷。Elisabeth Hendrickson（2002）训练测试人员把状态模型当作探测测试工具来工作--她的模型不是自动测试产生的，其价值是指导测试人员进行分析。
El-Far,Thompson & Mottay（2001）和El-Far（2001）讨论在构建一个优秀的基于模型的测试集合时需要考虑的事项。比如，权衡考虑其中的详细程度（越详细的模型找到的缺陷越多，但越难于阅读和维护）。
更进一步的说明，请参考www.model-based-testing.com网站上的论文。
大批量的自动测试大批量自动测试包括了大量的测试数据，把结果与一个或更多局部oracle数据库进行比较。
最简单的局部oracle数据库进行反崩溃运转，如果程序崩溃，那肯定存在BUG。详尽描述及经验报告请参见Nyman（1998,2002）。
如果停止规则是基于测试结果而不是覆盖准则的，那么基于状态模型的测试就是大批量的。关于随机的基于状态测试的概括性概念，请参见Whittaker（1997）。关于基于状态模型的测试是以覆盖规则结束的讨论，请参见Al-Ghafees & Whittaker（2002）。
Jorgensen（2002）提供了大批量测试的另外一个例子。他的测试从一个有效文件的应用开始，然后他用各种方法在各种环境下毁掉它，把这个已经毁掉的文件供给应用程序。应用程序拒绝了大多数毁坏的文件并继续毁掉了一部分。有时，有的应用程序在处理这些文件时会失去控制。缓冲超限或其它失误允许测试人员来接管应用程序或运行应用程序的机器。如果测试人员能在获取程序前修改数据流，那么任何读取所有类型数据流的程序就都属于这种类型的测试。
Kaner（2000）描述了其他几个大批量自动测试方法的例子。一个常用的方法是：把随机数据应用给要测试的应用程序和另外一个做参考的应用程序进行比较。另一个方法是：运行回归测试，输入一个任意长的随机序列，测试程序能不能一个接一个的通过测试。内存泄露、堆栈毁坏、无用指针或其它无用的东西随着时间不断累积，最后在这个长序列中发生错误。然而另外一个方法是：用长序列动作和用户探查（把测试作为程序的一部分，记录警告和错误信息以响应发生的意外情形。）测试程序以暴露问题。
大批量测试是一个多变的组合。其本质是这类测试的结构是由人设计的，但每个测试用例的开发、执行、解析是有计算机进行的，它能够为人们的复查标记出可疑错误。几乎完全自动化使运行大量的测试成为可能。
单个测试通常是微弱的，但他们可以弥补大批量测试的不足。
因为这种测试不是手工的，所以一些测试暴露的问题不是特别可信或有价值的。一个熟练的测试人员通常把问题设想成在一个比较明显的或重要的环境下出现的问题，然后用一个手工测试来证明它。
有些大批量测试方法产生的错误很难解决。很容易发现错误发生在一个特定的测试下，但导致错误发生的一个必要条件可能在真正失败之前已经经过了成千上百个测试。解决这些问题的方法就是设计一些比其他测试更有效的测试集合。
探索性测试探索性测试是“测试人员积极地在设计测试的同时执行这些测试，利用在测试中获取的信息设计新的更好地测试”（Bach 2003a）。
Bach指出测试是一个跨越纯脚本（测试人员根据脚本明确的开展工作）和纯探索（测试人员的行为不是预先设计好的，并且除了BUG报告他们没有必要产生任何测试文档）的结合体。在这个结合体中任何给定的测试都是投劳的。甚至是由熟练的测试人员执行的杰出的、执行脚本前的测试也是探索性的测试。
“在原型用例中（Bach称之为“自由的探索性测试”），探索性的测试人员不断地学习他们正在测试的软件、产品的市场、产品会失败的各种情形、产品的弱点（包括在应用历史中哪里出现过问题以及哪些开发这是解决哪种错误的），并用最佳方法测这个软件。在学习这些的同时，探索性的测试人员也在测这个软件，报告他们发现的问题，主张解决他们发现的问题，并根据他们学习过程中获得的信息开发出新的测试。”（Tinkham & Kaner,2003）探索性的测试人员可以使用任何类型的测试--域测试、基于规范的测试、压力测试、基于风险的测试、其中任何几个。根本性的问题是不管哪类测试是最好的，只要此时此刻能尽可能地展现测试人员寻找的信息即可。
探索性测试不是纯粹自发的。
测试人员需要做深入的研究，比如了解有竞争力的产品、这个或类似产品的失败历史、与程序员和用户交流、阅读规格说明书、与产品一起工作。
熟练的探索性测试与其他方法以及拙劣的探索性测试的区别是什么，区别是在测试的同时，做探索性测试的人也在忙于工作，学习、计划以及运行测试。好的测试用例提高了测试人员在寻求信息目标方面的知识。探索性测试很高程度上是目标驱动的，但是在测试人员获取到新知识时目标很快机会改变。
结论生成“好的”测试用例没有简单的公式或规定可以遵循。即使是多年以来在测试方面感兴趣的人也很难做到这一点。
测试对展现你寻求信息的目的有好处。
我见过很多测试团队中大多数都坚持使用少数几类测试，以场景测试为主或以域测试为主，等等。只要他们擅长于他们偏爱的测试类型，他们的测试在某些方面就会变得极好。不幸的是，我们希望的测试类型不是在任何方面都极好的测试。为了让测试结果多样化、广泛化，我们必须有各方面的技术。
致谢这项研究部分是由EIA-0113539 ITR/SY+PE：“提高软件测试者的教育”给予的支持。感谢Andy Thinkham,Al Jorgenson,和Pat McGee给以上的稿件的评论。
