找錯——面向對象軟件的測試技術與方法

　　　　　　　　　　　　　　　　　　　　　　

       面向對象技術所獨有的多態、繼承、封裝等新特點，使OO程序設計比傳統語言程序設計產生錯誤的可能性增大，使得傳統軟件測試中的重點不再顯得那么突出，也使原來測試經驗和實踐證明的次要方面成為了主要問題。

用戶使用低質量的軟件，在運行過程中會產生各種各樣的問題，可能帶來不同程度的嚴重后果，輕者影響系統的正常工作，重者造成事故和財產損失。軟件測試是保證軟件質量的最重要的手段，它使用人工或自動手段來運行或測定某個系統的過程，其目的在于檢驗它是否滿足規定的需求，弄清預期結果與實際結果之間的差別。

面向對象技術是一種全新的軟件開發技術，正逐漸代替被廣泛使用的面向過程的開發方法，被看成是解決軟件危機的新興技術。盡管面向對象技術的基本思想保證了軟件應該有更高的質量，但實際情況卻并非如此，因為無論采用什么樣的編程技術，編程人員的錯誤都是不可避免的，而且由于面向對象技術開發的軟件代碼重用率高，更需要嚴格測試，以避免錯誤的繁衍。

一、評審

因為OOA、OOD階段所建立的OOA和OOD模型不能執行，所以在每次迭代之后，一定要進行評審。

1．正確性

OO開發模式為演化（重復迭代）性質，即系統的初期為非形式化表示，以后發展為類的細節模型、類的連接和關聯，系統設計和配置，以及對類的設計（通過消息組成對象連接模型）。每一階段都要進行評審。

正確性主要在分析和設計模型表示所使用的符號語法是否正確，語義是否正確（即模型與真實世界領域是否一致），以及類的關聯（實例間的聯系）是否正確地反映了真實世界對象間的關聯。

2．一致性

由于演化性質，OOA和OOD模型（包括分析、設計和編碼層次，即類、屬性、操作、消息）不僅要正確，而且要一致。一致性可以用模型內各實體間的關聯性來判斷。

二、測試

1．單元測試

OOP完成以后，就可以進行單元測試了。與傳統的單元（模塊）不同，OO中的單元是類。每個類都封裝了屬性（數據）和管理這些數據的操作（也被稱做方法或服務）。一個類可以包含許多不同的操作，一個特殊的操作可以出現在許多不同的類中。

傳統的單元測試只能測試一個操作（功能）。而在OO單元測試中，一個操作功能只能作為一個類的一部分，類中有多個操作（功能），就要進行多個操作的測試。

另外，父類中定義的某個操作被許多子類繼承。但在實際應用中，不同子類中某個操作在使用時又有細微的不同，所以還必須對每個子類中某個操作進行測試。

類的測試可以使用多種方法，如基于故障的測試、隨機測試和分割測試等。每一種方法都要檢查封裝在類中的操作，即設計的測試序列（用例），要保證相關的操作被檢查。因為類的屬性值表示類的狀態，由此來確定被檢查的錯誤是否存在。

2．組裝測試

傳統軟件的層次模塊間存在著控制關系，而OO軟件沒有層次控制結構。所以傳統的自頂向下和自底向上的組裝策略在OO軟件組裝測試中就沒有意義了。

另外，一個類每次組裝一個操作（傳統軟件的增量法）在OO軟件組裝中是不夠的，因為組成類的各個成分之間存在著直接或間接的交互作用。OO軟件的組裝測試有兩種不同的策略：

（1）基于線程測試(thread-based-testing) 基于線程的測試就是把合作對應一個輸入或事件的類集合組裝起來，也就是用響應系統的一個輸入或一個事件的請求來組裝類的集合。對每個線程都要分別進行組裝和測試。

（2）基于使用測試(use-based-testing) 基于使用的測試就是按分層來組裝系統，可以先進行獨立類的測試。在獨立類測試之后，下一個類的層次叫從屬類。從屬類用獨立類進行測試。這種從屬類層的順序測試直到整個系統被構造完成。傳統軟件使用驅動程序和連接程序作為置換操作，而OO軟件一般不用。

OO系統組裝時還必須進行類間合作（強調上下級關系）的測試。類的合作測試與單個類測試相似，可用隨機應用和分割測試來完成。另外，還可以用基于腳本測試和行為模型導出的測試進行。

3．確認測試

確認測試是在系統層進行測試，因此類間的聯系細節出現了。與傳統軟件一樣，OO軟件確認測試也主要集中在用戶可見活動和用戶可識別的系統輸出上，所以OO軟件也使用傳統軟件的黑盒子測試方法。確認測試大多使用基于腳本（scenarios）的測試，因而使用用例成為確認測試的主要驅動器。

三、測試用例設計

這種設計目前正處于形成階段。

傳統軟件測試用例設計是從軟件的各個模塊的算法細節得出的，而OO軟件測試用例則著眼于適當的操作序列，以實現對類的說明。

黑盒子測試不僅適用于傳統軟件，也適用OO軟件測試。白盒子測試也用于OO軟件類的操作定義。但OO軟件中許多類的操作結構簡明，所以有人認為在類層上測試可能要比傳統軟件中的白盒子測試方便。

OO測試用例設計包含OO概念，在OO度量中所講的五個特性:局域性、封裝性、信息隱藏、繼承性和對象的抽象，肯定會對用例設計帶來額外的麻煩和困難。

Berard提出了一些測試用例的設計方法，主要原則包括:

（1）每個測試用例應當給予特殊的標識，并且還應當與測試的類有明確的聯系。

（2）測試目的應當明確。

（3）應當為每個測試用例開發一個測試步驟列表。這個列表應包含以下一些內容：

列出所要測試對象的專門說明。

列出將要作為測試結果運行的消息和操作。

列出測試對象可能發生的例外情況。

列出外部條件（即為了正確對軟件進行測試所必須有的外部環境的變化）。

列出為了幫助理解和實現測試所需要的附加信息。
1．基于故障的測試

在OO軟件中，基于故障的測試具有較高的發現可能故障的能力。由于系統必須滿足用戶的需求，因此，基于故障的測試要從分析模型開始，考察可能發生的故障。為了確定這些故障是否存在，可設計用例去執行設計或代碼。

基于故障測試的關鍵取決于測試設計者如何理解“可能的錯誤”。而在實際中，要求設計者做到這點是不可能的。

基于故障測試也可以用于組裝測試，組裝測試可以發現消息聯系中“可能的故障”。

“可能的故障”一般為意料之外的結果、錯誤地使用了操作/消息、不正確引用等。為了確定由操作（功能）引起的可能故障必須檢查操作的行為。

這種方法除用于操作測試外，還可用于屬性測試，用以確定其對于不同類型的對象行為是否賦予了正確的屬性值。因為一個對象的“屬性”是由其賦予屬性的值定義的。

應當指出，組裝測試是從客戶對象（主動），而不是從服務器對象（被動）上發現錯誤。正如傳統的軟件組裝測試是把注意點集中在調用代碼而不是被調用代碼一樣，即發現客戶對象中“可能的故障”。

2．基于腳本的測試

基于故障測試減少了兩種主要類型的錯誤：

（1）不正確的規格說明,如做了用戶不需要的功能，也可能缺少了用戶需要的功能。

（2）子系統間的交互作用沒有考慮，如一個子系統（事件或數據流等）的建立，導致其他子系統的失敗。

基于腳本的測試主要關注用戶需要做什么，而不是產品能做什么，即從用戶任務（使用用例）中找出用戶要做什么及去執行。

這種基于腳本的測試有助于在一個單元測試情況下檢查多重系統。所以基于腳本測試用例測試比基于故障測試不僅更實際（接近用戶），而且更復雜一點。

例如：考察一個文本編輯的基于腳本測試的用例設計。

使用用例：確定最終設計

背景：打印最終設計，并能從屏幕圖像上發現一些不易見到的且讓人煩惱的錯誤。

其執行事件序列：打印整個文件；移動文件，修改某些頁；當某頁被修改，就打印某頁；有時要打印許多頁。

顯然，測試者希望發現打印和編輯兩個軟件功能是否能夠相互依賴，否則就會產生錯誤。

3．OO類的隨機測試

如果一個類有多個操作（功能），這些操作（功能）序列有多種排列。而這種不變化的操作序列可隨機產生，用這種可隨機排列的序列來檢查不同類實例的生存史，就叫隨機測試。

例如一個銀行信用卡的應用，其中有一個類：計算（aclearcase/" target="_blank" >ccount）。該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.anti-gravitydesign.com