相關知識點－面象對象（=Object Oriented）技術
1． 對象和類
l 面象對象的編程語言：以對象為中心，以消息為驅動，程序＝對象＋消息
l 類是一種新的數據類型，是設計的核心，是通過抽象數據類型的方法來實現的一種數據類型
l 類是對某一對象的抽象，對象是某一類的實例，兩者密切相關
2． 封裝、繼承和多態性
（1） 封裝：把數據和操作結合一體，使程序結構更加緊湊，避免了數據紊亂帶來的調試與維護的困難
（2） 繼承：可以從一個類派生到另一個類，派生類繼承了父類和祖先類的數據成員和函數，增加了軟件的可擴充性，並為代碼重用提供了強有力的手段
（3） 多態性：多種表現形式，可以用‘一個對外接口，多個內在實現方法’表示。
一．面向對象測試模型
1． 面向對象測試的分類
依據面向對象開發模型（面向對象分析、面向對象設計、面向對向編程），分為：
（1） 面向對象分析的測試（OOA Test）、面向對象設計的測試（OOD Test）：是對分析結果和設計結果的測試，主要對分析設計產生的文本進行的，是軟件開發前期的關鍵性測試
（2） 面向對象編程的測試（OOP Test）：對編程風格和程序代碼實現進行測試，主要的測試內容在OO Unit Test和OO Integrate Test中體現
（3） 面向對象單元測試（OO Unit Test）：對程序內部具體單一的功能模塊的測試，主要對類成員函數的測試，是OO Integrate Test的基礎
（4） 面向對象集成測試（OO Intergrate Test）：對系統內部的相互服務進行測試，如成員函數間的相互作用，類間的消息傳遞。不僅要基於OO Unit Test，還要參考OOD、OOD Test的結果
（5） 面向對象確認測試（OO System Test）、面向對象系統測試（OO System Test）：最后階段的測試，以用戶需求為測試標准，借鑒OOA 、OOA Test的結果
2． 面向對象測試模型
2005-4-25
二． 面向對象軟件的測試策略
1． 面向對象分析的測試
（1） 面向對象分析
是把E-R圖和語義網絡模型，即信息造型中的概念，與面向對象程序設計語方中的重要概念結合在一起而形成的分析方法。通常以問題空間的圖表的形式進行描述
（2） 分析方法
直接映射問題空間，全面地將問題空間中實現功能的現實抽象化。將問題空間中的實例抽象為對象，用對象的結構反映問題空間的復雜實例和復雜關系，用屬性和服務表示實例的特性和行為。
（3） 面向對象分析缺點
對問題空間分析抽象的不完整，會影響軟件的功能實現，導致軟件開發后期產生大量原本可避免的修補工作；一些冗余的對象或結構類的選定，程序的整體結構和增加程序員不必要的工作量，因此 OOA測試的重點在其完整性和冗余性
（4） OOA測試划分的五個方面
對認定的對象的測試、對認定的結構的測試、對認定的主題的測試、對定義的屬性和實例關聯的測試、對定義的服務和消息關聯的測試
| 測試內容 |
概述 |
測試考慮方面 |
|
| 認定的對象的測試 |
認定的對象：對問題空間中的結構、其他系統、設備、被記憶的事件、系統涉及的人員等實際實例的抽象 |
（1） 是否全面，問題空間中的實例是否都反映在認定的抽象對象中了 （2） 是否具有多個屬性，只具有一個屬性的對象不抽象為為獨立的對象 （3） 對認定為同一對象的實例是否有共同的、區別於其他實例的共同屬性 （4） 對認定為同一對象的實例是否提供或需要相同的服務，如果服務隨着實例的不同而變化，認定的對象就需要分析或利用繼承性來分類表示 （5） 如果系統沒有必要始終保持對象代表的實例信息，提供或者得到關於它的服務、認定的對象也無必要 （6） 認定的對象的名稱要盡量准確、適用 |
|
| 認定的結構的測試 |
認定的結構：多種對象的組織方式，用來反映問題空間中的復雜實例和復雜關系，認定的結構分為兩種：分類結構 組裝結構 |
分類結構：體現問題空間中實例的一般與特殊的關系 |
（1） 結構中一種對象尤其是高層對象，是否存在不同於下一層對象的特殊的可能性，即是否能派生出下一層對象 （2） 結構中一種對象尤其是同一低層對象，是否能抽象出在現實中有意義的更一般的上層對象 （3） 對所有認定的對象，是否能向上層抽象出現實中有意義的對象 （4） 高層的對象的特性是否完全體現下層的共性 （5） 低層的對象是否有高層特性基礎上的特殊性 |
| 組裝結構：體現問題空間中實例的整體與局部的關系 |
（1） 整體對象和部件對象的組裝關系是否符合現實的關系 （2） 整體對象和部件對象是否在考慮的問題空間中有實際關系 （3） 整體對象是否遺漏了在問題空間中有用的部件對象 （4） 部件對象是否能夠在問題空間中組裝成新的有意義的的整體對象 |
||
| 認定的主題的測試 |
主題：在對象和結構的基礎上更高一層的抽象，是為了提供OOA 分析結果的可見性，如同文章中各章的摘要 |
（1） 貫徹George Miller的‘7+2’原則。如果主題個數超過7個，對有較密切屬性和服務的主題歸並 （2） 主題所反映的一組對象和結構是否具有相同或相近的屬性和服務 （3） 認定的主題是否是對象和結構更高一層的抽象，是否便於理解OOA 結果的概括 （4） 主題間的消息聯系（抽象）是否代表了主題所反映的對象和結構之間的所有關聯 |
|
| 對定義的屬性和實例關聯的測試 |
屬性：用來描述對象或結構所反映的實例的特性 實例關聯：反映實例集合間的映射關系 |
（1） 定義的屬性是否對相應的對象和分類結構的每個現實實例都適用 （2） 定義的屬性在現實世界是否與這種實例關系密切 （3） 定義的屬性在問題空間是否與實種實例關系密切 （4） 定義的屬性是否能夠不依賴於其他屬性被獨立理解 （5） 定義的屬性在分類結構中的位置是否恰當，低層對象的共有屬性是否在上層對象屬性中體現 （6） 在問題空間中每個對象的屬性是否定義完整 （7） 定義的實例關聯是否符合現實 （8） 在問題空間中實例關聯是否定義完整，特別需要注意‘一對多’、‘多對多’的實例關聯 |
|
| 對定義的服務和消息關聯的測試 |
定義的服務：定義的每一種對象和結構在問題空間所要求的行為 消息關聯：問題空間中實例之間必要的通信，需要定義相應的消息關聯 |
（1） 對象和結構在問題空間中的不同狀態是否定義相應的服務 （2） 對象和結構所需的服務是否都定義了相應的消息關聯 （3） 定義的消息關聯所指引的服務是否正確 （4） 沿着消息關聯執行的線程是否合理，是否符合現實過程 （5） 定義的服務是否重復，是否定義了能夠得到的服務 |
|
2． 面向對象設計（OOD）的測試
（1） 面向對象設計（OOD）
采用‘造型的觀點’，以OOA為基礎歸納出類，並建立類結構或進一步構造類庫，以實現分析結果對問題空間的抽象。OOD歸納的類即可以是對象的簡單延續，也可以是不同對象的相同或相似的服務
（2） OOD與OOA
OOD是OOA的進一步細化和更高層的抽象，所以OOD、OOA的界限很難區分，OOD確定類和類結構不僅是滿足當前需求分析要求，更重要是通過重新組合或加以適當的補充，方便實現功能重用和擴增。因此，對OOD的測試，建議針對功能的實現和重用以及OOA結果的分析
（3） OOD測試划分的三個方面
| 測試名稱 |
概述 |
測試考慮方面 |
| 認定的類的測試 |
認定的類：可以是OOA中認定的對象，或對象所需要的服務的抽象、對象所具有的屬性的抽象。認定的類盡量具有基礎性，便於維護和重用 |
（1） 是否涵蓋了OOA中所有認定的對象 （2） 是否能體現OOA中定義的屬性 （3） 是否能實現OOA中定義的服務 （4） 是否對應着一個含義明確的數據抽象 （5） 是否盡可能少地依賴其他類 （6） 類中的方法是否是單用途 |
| 構造的類層次結構的測試 |
類層次結構：通常基於OOA中產生的分類結構的原則來組織，着重體現父類和子類一般性和特殊性，在當前問題空間中，主要要求是能在解空間中構造全部功能的結構框架 |
（1） 類層次結構是否涵蓋了所有定義的類 （2） 是否體現了OOA中所定義的實例關聯 （3） 是否實現了OOA中所定義的消息關聯 （4） 子類是否具有父類沒有的新特性 （5） 子類間的共同特性是否完全在父類中得以體現 |
| 類庫的支持的測試 |
類庫的支持：也屬於類層次結構的組織問題，但重點是再次軟件開發的重用。作為高質量類層結構的評估 |
（1） 一組子類中關於某種含義相同或基本相同的操作，是否有相同的接口 （2） 類中方法的功能是否較單純，相應的代碼行是否較少（<30） （3） 類的層次結構是否是深度大，寬度小 |
| 因為OOA、OOD階段分析和設計的模型不能進行測試，不能被執行，所以每次迭代后要進行評審，針對兩個方法：正確性、一致性 |
正確性：主要在於分析和設計模型表示所使用的符號語法是否正確，語義是否正確以及類的關聯（實例間的聯系）是否正確地反映了真實世界對象間的關聯 |
|
| 一致性：OOD和OOA模型（分析、設計和編碼層次即類、屬性、操作、消息）要一致，可以用模型內各實體之間的關聯性判斷；評估方法：檢查每個類與其他類的連接，采用CRC（類－責任－協作者）模型和對象－關系圖 CRC模型：由CRC索引卡片構成，卡片中列出類名、類的操作、以及其他協作類，類完成的責任 對象－關系圖：提供了類之間連接（關系）的圖形表示 |
||
| 評估類模型，采用步驟 （1） 再次考察CRC模型和對象－關系模型，進行交叉檢查，保證OOA模型所包含的協作都能體現 （2） 檢查每個CRC索引卡片的描述，以確定是否某被授權的責任是協作者定義的一部分 （3） 反轉該連接，保證每個被請求的服務的協作者正在接收來自合理源的請求 （4） 使用在（3）的反轉連接，確定是否可能需要其他的類，或責任是否被合適地在類間分組 （5） 確定是否被廣泛請求的責任可被組合為單個的責任 （6） 步驟（1）～（5）被迭代地應用到每個類，並貫穿於OOA模型的每次演化中 |
||
| 創建設計模型，應對系統設計和對象設計進行復審 系統設計：描述構成產品的子系統、子系統分配到處理器的方式，類到子系統的分配；通過檢查在OOA階段開發的對象－行為模型，和映射需要的系統行為到被設計用於完成該行為的子系統來進行復審。在系統行為語境中復審並發性和任務分配，評估系統的行為狀態以確定哪些行為為並發存在 對象模型：表示了每個類的細節和實現類間的協作所必須的消息序列活動；針對對象－關系網絡來測試，以保證所有設計對象包含為實現每張CRC索引卡片定義的協作所必須的屬性和操作 |
||
3． 面向對象編程（OOP）的測試
（1） 面向對象程序
把功能的實現分布在類中，能正確實現功能的類，通過消息傳遞來協同實現設計要求的功能。將出現的錯誤精確的確定在某一具體的類上。
（2） 測試重點
忽略類功能實現的細則，將測試的目光集中在類功能的實現和相應的面向對象程序風格上
（3） 測試方面（c++為例）
| 測試方面 |
概述 |
| 數據成員是否滿足婁據封裝的要求 |
數據封裝：是數據和數據操作的集合 基本原則：檢查數據成員是否被外界（數據成員所屬的類或子類以外的調用）直接調用。當改變數據成員的結構時，是否影響了類的對外接口，是否會導致相應的外界必須改動 |
| 類是否實現了要求的功能 |
類所實現的功能是通過成員函數執行的，應首先保證成員函數的正確性 單獨看待成員函數，可以使用面向對象單元測試方法 類成員函數間的作用和類之間的服務調用，需要進行面向對象集成測試 注：測試類的功能，不能僅滿足於代碼能無錯地運行或被測試類所提供的功能無錯，應該以所做的OOD結果為依據，檢測類提供的功能是否滿足設計的要求，是否有缺陷，必要時還應該參照OOA的結果，以之為最終標准 |
4． 面向對象軟件的單元測試
（1） 可以將一些傳統的單元測試方法在面向對象軟件的單元測試中使用，如等價類划分、因果圖、邊界值分析法、邏輯覆蓋法、路徑分析法、程序插樁法，單元測試一般建議由程序員完成
（2） 單元級測試的測試分析和測試用例，規模和難度均遠小於對整個系統的測試分析和測試用例，並且對語句應該有100％的代碼執行覆蓋率。
（3） 設計測試用例選擇輸入數據的兩個假設：
l 如果函數（程序）對某一類輸入中的一個數據正確執行，對同類中的基他輸入也能正確執行（等價類）
l 如果函數（程序）對某一復雜度的輸入正確執行，對更高復雜度的輸入也能正確執行
（4） 針對繼承性，Brian Marick兩方面的考慮
l 繼承的成員函數是否都不需要測試：當繼承的成員函數在子類中做了改動；成員函數調用了改動過的成員函數的部分這兩種情況需要對子類重新測試
l 對父類的測試是否能照搬到子類：可以重新測試或在父類原有的測試要求和測試用例上增加新的測試要求和測試用例，主要針對子類中變動的部分進行測試
5． 面向對象軟件的集成測試
（1） 傳統的自頂向下或自底向上的集成測試策略在面向對象軟件的集成測試中無意義，OO軟件的集成測試需要在整個程序編譯完成后進行，面向對象程序具有動態特性，程序的控制流無法確定，只能對編譯完成的程序做基於黑盒子的集成測試
（2） 面向對象軟件的集成測試兩種策略
l 基於線程的測試（Thread based testing）：集成對響應系統的一個輸入或事件所需的一組類，每個線程分別進行集成和測試，應用回歸測試以保證沒有產生副作用。
l 基於使用的測試（Use based testing）：通過測試那些幾乎不使用服務器類的的類（獨立類）而開始構造系統，在獨立類測試完成后，下一層中使用獨立類的類（依賴類）被測試，這個依賴類層次的測試序列一直持續到構造完整個系統。
（3） 測試目的
能夠檢測出相對獨立的，單元測試無法檢測出的，那些類相互作用時才會產生的錯誤，只關注於系統的結構和內部的相互作用
（4） 面向對象軟件的集成測試過程
l 第一步：靜態測試 針對程序的結構進行，檢測程序結構是否符合設計要求。通過使用測試軟件的‘可逆性工程’功能，得出源程序的類系統圖和函數功能調用關系圖，與OOD結果相比較，檢測程序結構和實現上是否有缺陷，檢測OOP是否達到了設計要求
l 第二步：動態測試 根據靜態測試得出的函數功能調用關系圖或類關系圖作為參考，按照如下步驟設計測試用例，達到如下測試覆蓋標准
v 設計測試用例步驟：選定檢測的類，參考OOD分析結果，確定出類的狀態和相應的行為；確定覆蓋標准；利用結構關系圖確定待測類的所有關聯；根據程序中類的對象構造測試用例，確認使用什么輸入激發類的狀態，使用類的服務和期望產生什么行為等，還要設計一些類禁止的例子，確認類是否有不合法的行為產生
v 覆蓋標准：達到類所有的服務要求或服務提供的一定覆蓋率；依據類間傳遞的消息，達到對所有執行線程的一定覆蓋率；達到類的所有狀態的一定覆蓋率等
6． 面向對象軟件的確認和系統測試
（1） 系統測試：需要測試它與系統其他部分配套運行的表現，以確保在系統各部分協調工作的環境下軟件也能正常運行
（2） 要求：測試環境盡量與用戶實際使用環境相同，保證被測系統的完整性，對暫時沒有的系統設備部件，應采取相應的模擬手段。參考OOA分析結果，檢測軟件是否能夠完全‘再現’問題空間
（3） 不僅是檢測軟件的整體行為表現，另一方面對軟件設計開發的確認。OO軟件的確認和系統測試具體的測試內容與傳統的系統測試基本相同，包括：功能測試，強度測試，性能測試，安全測試，易用性測試，恢復測試，安裝/卸載測試
三．OO軟件測試用例設計原則（Berard）
關注於設計合適的操作序列以測試類的狀態
1． 對每個測試用例應當給予特殊的標識，並且還應當與測試的類有明確的聯系
2． 測試目的應當明確
3． 應當為每個測試用例開發一個測試步驟列表，列表包含內容
l 列出所要測試對象的說明
l 列出將要作為測試結果的消息和操作
l 列出測試對象可能發生的例外情況
l 列出外部條件，為了正確對軟件進行測試所必須有的外部環境的變化
l 列出為了幫助理解和實現測試所需要的附加信息
四．OO軟件測試的方法
1． 基於故障的測試
（1） 具有較高的發現可能故障的能力
（2） 從分析模型開始，考察可能發生的故障，設計用例去執行設計和代碼
（3） 可用於集成測試，發現消息聯系中‘可能的故障’（可能的故障指意料之外的結果、錯誤地使用了操作/消息、不正確地引用等）
（4） 除用於操作測試外，還可用於屬性測試，用以確定其對於不同類型的對象行為是否賦予了正確的屬性值
（5） 是從客戶對象（主動）上發現錯誤
（6） 不能發現的錯誤：不正確的規格說明，用戶不需要的功能或缺少用戶需要的功能；沒有考慮子系統間的交互作用
2． 基於場景的測試
（1） 主要關注用戶需要做什么，不是產品能做什么，即從用戶任務（使用用例）中找出用戶要做什么及如何去執行
（2） 有助於在一個單元測試情況下檢查多重系統，比基於故障的測試更實際，更復雜一點
3． OO類的隨機測試
如果一個類有多個操作（功能），這些操作（功能）序列有多種排列，這種不變化的操作序列可隨機產生，用這種可隨機排列來檢查不同類實例的生存史，稱為隨機測試
4． 類層次的分割測試
（1） 可以減少用完全相同的方式檢查類測試用例的數目，類似於等價類划分
（2） 分類：基於狀態的分割、基於屬性的分割、基於類型的分割
l 基於狀態的分割：按類操作是否會改變類的狀態進行分割（歸類）
l 基於屬性的分割：按類操作所得到的屬性來分割（歸類）
l 基於類型的分割：按完成的功能分割（分類），如初始操作、計算操作、查詢操作
5． 由行為模型（狀態、活動、順序和合作圖）導出的測試
狀態轉換圖（STD）可以用來幫助導出類的動態行為的測試序列，以及這些類與之合作的類的動態行為測試用例，根據狀態轉換圖，設計出最小測試用例，加入其他測試序列到最小測試序列中，保證類所有行為被充分檢查
總結：
本章主要講述了面向對象軟件的測試方法，依據面向對象軟件開發模型划分面向對象測試模型，其中單元測試、集成測試、確認測試和系統測試通過與傳統的單元測試、集成測試和確認測試、系統測試進行比較，得出面向對象軟件的測試內容