例如一个银行信用卡的应用，其中有一个类：计算(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。
5.由行为模型(状态、活动、顺序和合作图)导出的测试
状态转换图(STD)可以用来帮助导出类的动态行为的测试序列，以及这些类与之合作的类的动态行为测试序列。
为了说明问题，仍用前面讨论过的account类。开始由empty acct状态转换为setup acct状态。类实例的大多数行为发生在working acct状态中。而最后，取款和关闭分别使account类转换到non-working acct和dead acct状态。
这样，设计的测试用例应当是完成所有的状态转换。换句话说，操作序列应当能导致account类所有允许的状态进行转换。
测试用例：
open+setupAcct+deposit(initial)+withdraw(final)+close
还可导出更多的测试用例，以保证该类所有行为被充分检查。
小资料
OO软件测试的主要目标与传统软件测试一样，即用最小量的投入来最大限度地发现软件存在的错误。但由于OO软件具有的特殊性质，OO软件测试在内容、策略和方法上与传统软件测试不完全相同。
(1)OOA(Object-Oriented Analysis)和OOD(Object-Oriented Design)的评审与传统软件的分析和设计相同，应给出相应的评审检查表。
(2)OOP(Object-Oriented Programming)后，单元和组装测试策略必须做相应的改变。
(3)测试用例设计必须说明OO软件特有的性质。
文章来源于领测软件测试网 https://www.ltesting.net/
