例如一個銀行信用卡的應用，其中有一個類：計算(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軟件特有的性質。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
