基于状态模型的测试
在基于状态模型的测试中，你把程序可见的行为模拟成一个状态机，并驱动程序在各状态之间转变，检测与预期模型的一致性。关于这种测试方法的深入讨论在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)描述了其他几个大批量自动测试方法的例子。一个常用的方法是：把随机数据应用给要测试的应用程序和另外一个做参考的应用程序进行比较。另一个方法是：运行回归测试，输入一个任意长的随机序列，测试程序能不能一个接一个的通过测试。内存泄露、堆栈毁坏、无用指针或其它无用的东西随着时间不断累积，最后在这个长序列中发生错误。然而另外一个方法是：用长序列动作和用户探查（把测试作为程序的一部分，记录警告和错误信息以响应发生的意外情形。）测试程序以暴露问题。
大批量测试是一个多变的组合。其本质是这类测试的结构是由人设计的，但每个测试用例的开发、执行、解析是有计算机进行的，它能够为人们的复查标记出可疑错误。几乎完全自动化使运行大量的测试成为可能。
单个测试通常是微弱的，但他们可以弥补大批量测试的不足。
因为这种测试不是手工的，所以一些测试暴露的问题不是特别可信或有价值的。一个熟练的测试人员通常把问题设想成在一个比较明显的或重要的环境下出现的问题，然后用一个手工测试来证明它。
有些大批量测试方法产生的错误很难解决。很容易发现错误发生在一个特定的测试下，但导致错误发生的一个必要条件可能在真正失败之前已经经过了成千上百个测试。解决这些问题的方法就是设计一些比其他测试更有效的测试集合。
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51Testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
