在OO软件中，基于故障的测试具有较高的发现可能故障的能力。由于系统必须满足用户的需求，因此，基于故障的测试要从分析模型开始，考察可能发生的故障。为了确定这些故障是否存在，可设计用例去执行设计或代码。
基于故障测试的关键取决于测试设计者如何理解“可能的错误”。而在实际中，要求设计者做到这点是不可能的。
基于故障测试也可以用于组装测试，组装测试可以发现消息联系中“可能的故障”。
“可能的故障”一般为意料之外的结果、错误地使用了操作/消息、不正确引用等。为了确定由操作（功能）引起的可能故障必须检查操作的行为。
这种方法除用于操作测试外，还可用于属性测试，用以确定其对于不同类型的对象行为是否赋予了正确的属性值。因为一个对象的“属性”是由其赋予属性的值定义的。
应当指出，组装测试是从客户对象（主动），而不是从服务器对象（被动）上发现错误。正如传统的软件组装测试是把注意点集中在调用代码而不是被调用代码一样，即发现客户对象中“可能的故障”。
2．基于脚本的测试
基于故障测试减少了两种主要类型的错误：
（1）不正确的规格说明,如做了用户不需要的功能，也可能缺少了用户需要的功能。
（2）子系统间的交互作用没有考虑，如一个子系统（事件或数据流等）的建立，导致其他子系统的失败。
基于脚本的测试主要关注用户需要做什么，而不是产品能做什么，即从用户任务（使用用例）中找出用户要做什么及去执行。
这种基于脚本的测试有助于在一个单元测试情况下检查多重系统。所以基于脚本测试用例测试比基于故障测试不仅更实际（接近用户），而且更复杂一点。
例如：考察一个文本编辑的基于脚本测试的用例设计。
使用用例：确定最终设计
背景：打印最终设计，并能从屏幕图像上发现一些不易见到的且让人烦恼的错误。
其执行事件序列：打印整个文件；移动文件，修改某些页；当某页被修改，就打印某页；有时要打印许多页。
显然，测试者希望发现打印和编辑两个软件功能是否能够相互依赖，否则就会产生错误。
3．OO类的随机测试
如果一个类有多个操作（功能），这些操作（功能）序列有多种排列。而这种不变化的操作序列可随机产生，用这种可随机排列的序列来检查不同类实例的生存史，就叫随机测试。
例如一个银行信用卡的应用，其中有一个类：计算（account）。该account的操作有：open、setup、deposit、withdraw、balance、summarize、creditlimit和close。
这些操作中的每一项都可用于计算，但open、close必须在其他计算的任何一个操作前后执行，即使open和close有这种限制，这些操作仍有多种排列。所以一个不同变化的操作序列可由于应用不同而随机产生，如一个Account实例的最小行为生存史可包括以下操作：
open+setup+deposit+[deposit|withdraw |balance|summarize|creditlimit]+withdraw+close
从此可见，尽管这个操作序列是最小测试序列，但在这个序列内仍可以发生许多其他的行为。
4．类层次的分割测试
这种测试可以减少用完全相同的方式检查类测试用例的数目。这很像传统软件测试中的等价类划分测试。分割测试又可分三种。
（1）基于状态的分割 按类操作是否改变类的状态来分割（归类）。这里仍用account类为例，改变状态的操作有deposit、withdraw，不改变状态的操作有balance、 summarize、creditlimit。如果测试按检查类操作是否改变类状态来设计，则结果如下:
用例1：执行操作改变状态
open+setup+deposit+deposit+withdraw+withdraw+close。
用例2：执行操作不改变状态
open+setup+deposit+summarize+creditlimit+withdraw+close。
（2）基于属性的分割 按类操作所用到的属性来分割（归类），如果仍以一个account类为例，其属性creditlimit能被分割为三种操作：用creditlimit的操作，修改creditlimit的操作，不用也不修改creditlimit的操作。
这样，测试序列就可按每种分割来设计。
（3）基于类型的分割 按完成的功能分割（归类）。例如，在account类的操作中，可以分割为：初始操作open、setup；计算操作deposit、withdraw；查询操作balance、summarize、creditlimit；终止操作close。
文章来源于领测软件测试网 https://www.ltesting.net/
