面向?qū)ο蟮能浖y試

Chapter9

面向?qū)ο蟮能浖y試主要內(nèi)容1.基本概念2.測試計劃3.測試模型4.面向UML的測試5.類的測試6.面向?qū)ο蟮募蓽y試一、軟件測試的基本概念軟件錯誤軟件系統(tǒng)的功能和性能與預(yù)期的功能和性能不一致軟件測試是發(fā)現(xiàn)軟件錯誤的過程盡早測試，經(jīng)常測試，充分測試目標(biāo)發(fā)現(xiàn)軟件中的錯誤，提高軟件質(zhì)量注意：軟件測試中沒有發(fā)現(xiàn)錯誤并不意味著軟件就沒有錯誤=>測試不充分,潛在錯誤未能發(fā)現(xiàn)軟件測試的方法白盒測試已知程序內(nèi)部工作流程，通過測試檢驗程序內(nèi)部動作是否按規(guī)格說明書的規(guī)定正常運作黑盒測試根據(jù)已知程序的功能和性能(而不是內(nèi)部細(xì)節(jié))，通過測試檢驗每個功能和性能是否正常白盒測試問題：如何設(shè)計測試用例?覆蓋準(zhǔn)則語句覆蓋分支覆蓋路徑覆蓋黑盒測試黑盒測試測試軟件是否滿足功能和性能要求，不涉及模塊的內(nèi)部過程性細(xì)節(jié)主要的黑盒測試技術(shù)等價分類法邊界分類法軟件測試的步驟需求分析概要設(shè)計詳細(xì)設(shè)計編碼單元測試集成測試確認(rèn)測試軟件開發(fā)過程軟件測試過程面向?qū)ο筌浖y試有何不同面向?qū)ο缶幊痰奶匦岳^承、多態(tài)數(shù)據(jù)隱藏使測試復(fù)雜化開發(fā)過程以及分析和設(shè)計重點的改變單元、集成分析模型、設(shè)計模型和代碼之間的映射能盡早進(jìn)行測試面向?qū)ο筌浖臏y試內(nèi)容模型測試類測試交互測試系統(tǒng)測試接收測試發(fā)布/自我測試二、測試計劃測試需考慮的問題：誰執(zhí)行測試？測試什么？什么時候測試？怎樣測試？測試應(yīng)進(jìn)行到何種程度？測試計劃及其關(guān)系項目測試計劃類/組件測試計劃集成測試計劃系統(tǒng)測試計劃用例測試計劃三、測試模型為什么測試要基于模型：測試必須是系統(tǒng)的測試必須是集中的測試最好是自動的模型的要素主題飛機模型、氣象模型、經(jīng)濟模型、被測模型論點/理論能夠指導(dǎo)識別相關(guān)的問題及信息表示方程式、圖形技術(shù)建模方法狀態(tài)機狀態(tài)機是一個系統(tǒng)，它的輸出是由當(dāng)前的輸入和過去的輸入決定。狀態(tài)機的構(gòu)成：狀態(tài)轉(zhuǎn)換事件動作狀態(tài)機的機制機器開始于初態(tài)；機器在一個不確定的時間間隔等待一個事件；如果一個事件在當(dāng)前狀態(tài)沒有被接受，則被忽略；如果事件在當(dāng)前狀態(tài)被接受，則說指定的轉(zhuǎn)換被觸發(fā)；從2開始重復(fù)這個周期，直到結(jié)果狀態(tài)變成終止?fàn)顟B(tài)?；跔顟B(tài)的行為建模的范圍JavaAWT,MS/Windows,UnixX-Windows等的GUI界面元素的行為；商業(yè)對象（類）的行為和它們的生存循環(huán)：訂單，顧客，存貨單等；通信設(shè)備：路由器，modem控制器，電話，手持無線設(shè)備等；具有重試、重新開始、重新恢復(fù)功能的設(shè)備驅(qū)動器；命令語法分析器；長期的數(shù)據(jù)庫事務(wù)；移動控制系統(tǒng)：航空電子控制系統(tǒng)，自動巡航系統(tǒng)，機器人等?；跔顟B(tài)的測試設(shè)計實現(xiàn)必須符合指定的狀態(tài)機的約束。了解實現(xiàn)如何與觀察到的約束不相符合，為測試設(shè)計提供了重點，也為評估測試設(shè)計策略提供了基準(zhǔn)。控制錯誤一個控制錯誤允許一個不正確的事件序列被接受或產(chǎn)生一個不正確的輸出動作序列。例如：交通燈直接由紅變綠控制錯誤的類型丟失的或不正確的轉(zhuǎn)換丟失的或不正確的事件丟失的或不正確的動作多余的、丟失的或訛誤狀態(tài)潛行路徑（一個不應(yīng)被接受的消息被接受）非法消息的失效（一個不期望的消息引起的失效）陷阱門（實現(xiàn)了沒有定義的消息）示例：丟失轉(zhuǎn)換選手1發(fā)球選手2發(fā)球P2_WinsVolley()P1_WinsVolley()對一個有效的事件/狀態(tài)對，實現(xiàn)沒有作出響應(yīng)。示例：不正確的轉(zhuǎn)換選手1發(fā)球選手2發(fā)球P2_WinsVolley()P1_WinsVolley()實現(xiàn)的行為就像到達(dá)一個不正確的結(jié)果狀態(tài)。游戲開始示例：丟失動作對一個轉(zhuǎn)換，實現(xiàn)沒有產(chǎn)生任何動作。選手1發(fā)球選手2發(fā)球P2_WinsVolley()P1_WinsVolley()游戲開始P1_Start()/simulateVolley()示例：不正確的動作選手1發(fā)球選手2發(fā)球P2_WinsVolley()/simulateVolley()P1_WinsVolley()/This.p1AddPoint()對一個轉(zhuǎn)換，實現(xiàn)產(chǎn)生了錯誤的動作。示例：潛行路徑選手1發(fā)球選手2發(fā)球P2_WinsVolley()P1_WinsVolley()實現(xiàn)接受了一個非法的或在這一狀態(tài)沒有被規(guī)定的事件。選手2贏P2_Start()示例：訛誤狀態(tài)選手1發(fā)球選手2發(fā)球P2_WinsVolley()P1_WinsVolley()實現(xiàn)計算一個無效的狀態(tài)，或是類或狀態(tài)不變量被違反。選手1贏P1_WinsVolley()[this.p1_Score()==20]/this.p1AddPoint()8-(@!*B+{示例：非法消息失效選手1發(fā)球選手2發(fā)球P2_WinsVolley()P1_WinsVolley()實現(xiàn)沒有正確處理一個非法消息。xDEADBEEFP2_Start()選手2贏P2_WinsVolley()[this.p2_Score()==20]/this.p2AddPoint()示例：陷阱門選手1發(fā)球選手2發(fā)球P2_WinsVolley()P1_WinsVolley()實現(xiàn)接受了一個非法的或在這一狀態(tài)沒有被規(guī)定的事件。選手1贏P1_WinsVolley()[this.p1_Score()==20]/this.p1AddPoint()ScrollLockKeyPress產(chǎn)生原因：當(dāng)一個類被修改時，已廢棄的特征未被刪除；繼承過來的特征和子類的需求不一致；為調(diào)試而增添的特征；懷有犯罪或惡意的目的，而作出的蓄意破壞。開發(fā)可測模型并非所有的實現(xiàn)都非常適合基于狀態(tài)的測試。當(dāng)被測實現(xiàn)的責(zé)任包括順序行為時，則有效的測試設(shè)計依賴一個完全的、一致的、正確的狀態(tài)模型的開發(fā)。一個測試模型必須正確地表示需求，準(zhǔn)確地反映被測實現(xiàn)。使用檢查表。狀態(tài)模型檢查表（一）：結(jié)構(gòu)1.模型在結(jié)構(gòu)上是完全和一致的1.1一個狀態(tài)被指定為初態(tài)并且只有一個離開的轉(zhuǎn)換；1.2至少有一個終止?fàn)顟B(tài)并且只有一個進(jìn)入轉(zhuǎn)換；1.3沒有等價狀態(tài)；1.4每一個狀態(tài)都可以從初態(tài)到達(dá)；1.5從任何一個狀態(tài)都可以到達(dá)終止?fàn)顟B(tài)；1.6每一個被定義的事件和動作至少出現(xiàn)在一個轉(zhuǎn)換上；1.7除了初態(tài)和終態(tài)外，每個狀態(tài)至少有一個輸入轉(zhuǎn)換和輸出轉(zhuǎn)換；1.8對任一給定狀態(tài)，同樣的事件不能出現(xiàn)在多個轉(zhuǎn)換上；1.9狀態(tài)機是完全確定的。狀態(tài)模型檢查表（二）：狀態(tài)名稱2.不好的狀態(tài)名經(jīng)常是不完全和不正確設(shè)計的征兆2.1狀態(tài)名稱在應(yīng)用領(lǐng)域中是有意義的；2.2當(dāng)懷疑一個狀態(tài)名時，就把它刪掉；2.3不要用“等待的x”或“等待x”作為狀態(tài)名；2.4狀態(tài)名沒有表達(dá)不相關(guān)的信息；

2.4.1沒有名稱重復(fù)狀態(tài)變量不變式——100<x<1000；

2.4.2沒有名稱描述和動作相關(guān)的過程——computex；

2.4.3沒有名稱用于輸入描述——鼠標(biāo)點擊，用戶參數(shù)。狀態(tài)模型檢查表（三）：受監(jiān)視轉(zhuǎn)換3.條件轉(zhuǎn)換3.1在狀態(tài)轉(zhuǎn)換的條件集中，條件表達(dá)式產(chǎn)生的真值的全部范圍必須被覆蓋；3.2對一個轉(zhuǎn)換，每一個條件都和其它的條件相互排斥；3.3一個抽象狀態(tài)模型的條件變量是被測類的客戶提供的輸入；3.4一個具體類狀態(tài)模型的條件變量是由被測類的實現(xiàn)定義——例如self或this；3.5條件表達(dá)式的計算對被測類不會產(chǎn)生任何副作用。狀態(tài)模型檢查表（四）：好的子類行為4.子類的行為是良定的4.1子類沒有刪除任何超類狀態(tài)：在超類中接受的轉(zhuǎn)換也被子類接受；4.2子類不會減弱任何超類狀態(tài)的狀態(tài)不變量；4.3子類不會破壞任何超類狀態(tài)的狀態(tài)不變量；4.4子類或者加強超類狀態(tài)不變量或者僅僅繼承它；4.5子類可以添加由子類引入的實例變量定義的正交狀態(tài)；4.6超類轉(zhuǎn)換中所有的條件和子類轉(zhuǎn)換相同或弱于子類；4.7所有被繼承的輸出動作和子類的責(zé)任一致；4.8發(fā)送到對象的消息不會對被測類產(chǎn)生副作用。狀態(tài)模型檢查表（五）：健壯性5.模型規(guī)定了健壯行為5.1

對沒有被明確拒絕的事件，有一個明確規(guī)定的錯誤處理和異常處理機制；5.2對于一個非法消息的結(jié)果，實現(xiàn)的狀態(tài)不會被錯誤地改變、被訛誤或沒有被定義；5.3對每一個動作，沒有改變和這個動作相關(guān)的結(jié)果狀態(tài)的副作用或異常；5.4對前置、后置條件，不變式的沖突，規(guī)定了明確的異常、錯誤注冊和恢復(fù)機制；5.5對丟失或延遲的事件規(guī)定了明確的異常、錯誤注冊和恢復(fù)機制；5.6對每一個超時，規(guī)定了明確的異常、錯誤注冊，恢復(fù)機制；5.7被測系統(tǒng)的目標(biāo)環(huán)境的主要和不重要的失敗模式被分類，對每個失敗模式，規(guī)定了一個明確的異常機制；5.8對每一失敗模式，指定了結(jié)果狀態(tài)，或硬性的終止?fàn)顟B(tài)；5.9重新開始機制被建模并定義了一個到一個正常狀態(tài)的路徑。四、面向UML的測試UML的靈活性允許準(zhǔn)確，也允許模糊。片斷性、不完全性、不一致性和二義性的模型很容易產(chǎn)生。用UML開發(fā)一個嚴(yán)格的應(yīng)用模型是可能的。以圖中的關(guān)系為基礎(chǔ)進(jìn)行測試。用例圖的測試需求關(guān)系測試需求（至少有一個測試用例檢查）執(zhí)行者和用例通信每一用例每一執(zhí)行者的用例用例1擴展用例2每一個完全的擴展組合用例1使用用例2每一個完全的使用組合類圖的測試需求關(guān)系測試需求（至少有一個測試用例檢查）關(guān)聯(lián)關(guān)聯(lián)關(guān)系的特定應(yīng)用聚集類和構(gòu)件的獨立創(chuàng)建和析構(gòu)構(gòu)成類和構(gòu)件的順序創(chuàng)建和析構(gòu)類和構(gòu)件失敗的獨立創(chuàng)建和析構(gòu)泛化在每一個子類中，每一個超類的特性被使用依賴依賴關(guān)系的特定應(yīng)用精化精化類中被精化類型的每一行為順序圖的測試需求關(guān)系測試需求（至少有一個測試用例檢查）客戶調(diào)用服務(wù)者（同步）客戶調(diào)用服務(wù)者并返回客戶調(diào)用服務(wù)者（異步）客戶調(diào)用服務(wù)者并返回，服務(wù)者繼續(xù)執(zhí)行客戶調(diào)用服務(wù)者1、2…客戶調(diào)用服務(wù)者1、2…客戶重復(fù)到服務(wù)者的調(diào)用客戶重復(fù)到服務(wù)者的調(diào)用客戶遞歸調(diào)用服務(wù)者客戶遞歸調(diào)用服務(wù)者活動圖的測試需求關(guān)系測試需求（至少有一個測試用例檢查）動作1在動作2之前動作2跟隨動作1動作依賴于同步點動作跟隨同步點動作2、3…跟隨動作1動作2跟隨動作1動作3跟隨動作1…動作依賴信號在信號到達(dá)之后執(zhí)行動作同步點跟隨動作在動作之后到達(dá)同步點狀態(tài)圖的測試需求參見基于狀態(tài)的測試協(xié)作圖的測試需求關(guān)系測試需求（至少有一個測試用例檢查）消息1在消息2之前消息1和消息2客戶發(fā)送消息到服務(wù)者客戶發(fā)送消息到服務(wù)者并返回客戶也許發(fā)送消息到服務(wù)者（條件調(diào)用）客戶發(fā)送消息到服務(wù)者并返回客戶不發(fā)送消息到服務(wù)者客戶重復(fù)到服務(wù)者的消息客戶重復(fù)到服務(wù)者的消息并返回向自己發(fā)送遞歸消息客戶遞歸地調(diào)用自己客戶到服務(wù)者的異步調(diào)用客戶發(fā)送消息到服務(wù)者并返回，服務(wù)者收到消息構(gòu)件圖的測試需求關(guān)系測試需求（至少有一個測試用例檢查）構(gòu)件發(fā)送到接口的消息客戶發(fā)送消息到服務(wù)者并返回構(gòu)件依賴構(gòu)件特定應(yīng)用配置圖的測試需求關(guān)系測試需求（至少有一個測試用例檢查）構(gòu)件運行在節(jié)點上在每一個指定的主機節(jié)點上，構(gòu)件能被加載并且運行節(jié)點和節(jié)點的通信打開、傳送、關(guān)閉到每一個遠(yuǎn)程構(gòu)件的通信五、類的測試類的測試相對于傳統(tǒng)單元測試。為什么？若類的測試不足，則很多錯誤不能被查出；通過客戶類去測試服務(wù)類是困難的；錯誤發(fā)現(xiàn)得越晚，糾正的代價越大；有效的類測試減少開發(fā)時間，提高生產(chǎn)率。類測試的內(nèi)容方法范圍的測試設(shè)計類范圍的測試設(shè)計繼承的測試方法范圍測試：基本過程1.設(shè)置測試消息的參數(shù)、類變量、全局變量為希望的狀態(tài)。2.設(shè)置被測對象為希望的狀態(tài)。3.從驅(qū)動模塊向該MUT發(fā)送測試消息。4.測試檢查：（1）比較從該MUT返回的值和期望的值。若不同，記錄未通過。（2）比較該MUT的狀態(tài)和期望的狀態(tài)。若不同，記錄未通過。（3）若使用按引用調(diào)用，比較測試消息參數(shù)的狀態(tài)和期望的狀態(tài)。若不同，記錄未通過。（4）捕獲所有異常。假如是期望的異常，確定它是否正確。假如無異?；蛴幸粋€不正確的異常，記錄未通過。（5）假如一個斷言的違反是期望的，確定它是否正確。若不是期望的，記錄未通過。（6）假如必要，比較類變量、全局變量的結(jié)果狀態(tài)與期望的值，假如有不期望的，記錄未通過。5.假如發(fā)生任何未通過，診斷和矯正該問題測試提示：記錄所花費的時間，對度量進(jìn)一步的測試預(yù)算有益。方法范圍測試設(shè)計樣式1. 范疇劃分2. 組合功能測試3. 遞歸功能測試4. 多態(tài)消息測試范疇劃分目標(biāo)根據(jù)輸入/輸出分析，設(shè)計方法范圍測試包。上下文和故障模型假定故障與消息參數(shù)和實例變量值的組合有關(guān)，也假定這種故障將導(dǎo)致遺漏或錯誤的方法輸出。策略標(biāo)識每個功能的輸入?yún)?shù)的范疇，范疇必須導(dǎo)致不同的輸出；把每個范疇劃分為選擇；通過枚舉所有選擇的組合產(chǎn)生測試實例。組合功能測試目標(biāo)為了根據(jù)狀態(tài)和/或消息值的組合選擇狀態(tài)，設(shè)計一個測試包。上下文和故障模型一個方法根據(jù)消息參數(shù)和實例變量的組合，選擇很多不同動作中的一個時，選擇輸入組合以便適當(dāng)?shù)貦z測選擇邏輯。策略對每個動作最少開發(fā)一個測試。遞歸功能測試目標(biāo)對一個調(diào)用自己的方法，設(shè)計一個測試包。上下文和故障模型遞歸方法接受不正常的參數(shù)值、沒有足夠的?？臻g或基本條件不能到達(dá)時，都會使遞歸失敗。策略零次遞歸；一次遞歸；遞歸最大允許的或可行的深度；破壞初始調(diào)用、下降階段和上升階段的前置、后置條件。多態(tài)消息測試目標(biāo)多態(tài)服務(wù)執(zhí)行所有客戶與服務(wù)器的編聯(lián)，對這種多態(tài)服務(wù)的一個客戶開發(fā)測試。上下文和故障模型不能滿足所有可能編聯(lián)的前置條件；不希望的名字解析或指針的不正確構(gòu)造，發(fā)生一個不希望的編聯(lián)；服務(wù)類的實現(xiàn)發(fā)生了變化或擴充。策略對MUT中每個多態(tài)消息的每種可能編聯(lián)最少檢測一次。類范圍測試設(shè)計樣式1. 不變量邊界2. 非模態(tài)類測試3. 準(zhǔn)模態(tài)類測試4. 模態(tài)類測試類的模態(tài)性非模態(tài)類對接受的消息序列不強加任何限制，DateTime示例；單模態(tài)類對可接受的消息序列有限制，但不管其內(nèi)容，TrafficLight示例；準(zhǔn)模態(tài)類對隨對象的狀態(tài)而改變的可接受消息進(jìn)行順序限制，Stack示例；模態(tài)類對可接受的消息序列進(jìn)行消息和域的限制，Account示例。不變量邊界目標(biāo)為由復(fù)雜的和原始的數(shù)據(jù)類型組成的類、接口及構(gòu)件選擇能高效測試的測試值組合。上下文和故障模型在IUT的范圍內(nèi)為所有的變量提供值，隨后運行一個測試；實例變量值的有效和無效的組合可被類的不變量指定。策略assert((txCounter>=0&&txCount<=5000)&&(creditlimit>99.99&&creditLimit<=1000000)&&((!account1.isClosed()||!account2.isClosed()));非模態(tài)類測試目標(biāo)為不限制消息順序的類開發(fā)一個類范圍測試包。上下文和故障模型拒絕一個合法的順序；一個合法的順序產(chǎn)生一個錯誤的值；接受非法的修改參數(shù)導(dǎo)致錯誤狀態(tài)；錯誤的計算導(dǎo)致類不變量被破壞等。策略隨機序列；質(zhì)疑序列。準(zhǔn)模態(tài)類測試目標(biāo)為類產(chǎn)生一個類范圍測試包，該類對隨類狀態(tài)改變而改變的消息序列進(jìn)行限制。上下文和故障模型容器和收集類通常是準(zhǔn)模態(tài)的；有效的測試必須區(qū)別決定行為的內(nèi)容和不影響行為的內(nèi)容。策略定義不變量邊界，集成操作序列。模態(tài)類測試目標(biāo)為一個在消息序列上有固定限制的類，開發(fā)一個類范圍測試包。上下文和故障模型對可接受的消息序列和域兩方面的限制；需要驗證所有合法狀態(tài)：1）將要被接受的消息被接受；2）在這些狀態(tài)下非法的消息被拒絕；3）對接受或拒絕消息所得到的結(jié)果狀態(tài)正確；4）對每個測試消息的響應(yīng)是絕對正確的。策略基于狀態(tài)的測試。繼承的測試重測試父類方法是為了確定繼承的屬性可在子類的環(huán)境中正確的運行。盡可能地復(fù)用父類測試包。測試子類中細(xì)化的/新的方法。對子類可以使用類范圍內(nèi)的測試。六、面向?qū)ο蟮募蓽y試集成測試是探尋導(dǎo)致構(gòu)件交互錯誤的構(gòu)件錯誤，集成測試策略包括：哪些構(gòu)件是集成測試的重點？構(gòu)件接口應(yīng)該以什么樣的順序進(jìn)行檢測？應(yīng)該使用哪種測試設(shè)計技術(shù)檢測每個接口？增量式集成是最有效的技術(shù)：一次增加少數(shù)幾個構(gòu)件，然后測試它們的互操作性。范圍面向?qū)ο箝_發(fā)中的集成測試開始得早，在所有范圍中都會進(jìn)行，并且在每個開發(fā)增量中重復(fù)：在一個類中在一個類層次中在一個客戶和它的服務(wù)者中在一個相關(guān)類的簇中在一個子系統(tǒng)中在一個應(yīng)用系統(tǒng)中集成故障（1）配置/版本控制問題遺漏、重疊或沖突的函數(shù)文件或數(shù)據(jù)庫使用不正確或不一致的數(shù)據(jù)結(jié)構(gòu)文件或數(shù)據(jù)庫使用沖突的數(shù)據(jù)視圖/用法破壞全局存儲或數(shù)據(jù)庫的數(shù)據(jù)完整性由于編碼錯誤或未預(yù)料到的動態(tài)綁定導(dǎo)致的錯誤方法調(diào)用客戶發(fā)送違反服務(wù)對象前提條件的的消息客戶發(fā)送違反服務(wù)對象的順序約束的的消息錯誤的對象和消息的綁定（多態(tài)目標(biāo)）集成故障（2）錯誤參數(shù)或不正確的參數(shù)值由不正確的內(nèi)存管理分配/回收引起的失敗不正確的使用虛擬機、ORB或OS服務(wù)目標(biāo)環(huán)境的服務(wù)已經(jīng)過時目標(biāo)環(huán)境當(dāng)前不支持試圖使用的新服務(wù)構(gòu)件之間的沖突資源競爭集成測試的設(shè)計樣式（1）大爆炸集成：試圖通過同時測試所有的構(gòu)件以論證系統(tǒng)穩(wěn)定性。自底向上集成：依據(jù)使用相依性來交錯進(jìn)行構(gòu)件和集成測試。自頂向下集成：依據(jù)使用控制層次來交錯進(jìn)行構(gòu)件和集成測試。協(xié)作集成：根據(jù)協(xié)作的構(gòu)件和它們之間的相依性選擇一個集成次序，通過一次測試一個協(xié)作組來檢測接口。基干集成：結(jié)合了自頂向下、自底向上和大爆炸集成，以達(dá)到一個支持迭代開發(fā)的穩(wěn)定系統(tǒng)。集成測試的設(shè)計樣式（2）層次集成：增量式的檢測一個層次體系結(jié)構(gòu)中的結(jié)構(gòu)和構(gòu)件?？蛻?服務(wù)器集成：檢測一個構(gòu)件松散連接的網(wǎng)絡(luò)，其中所有構(gòu)件使用一個公用的服務(wù)器構(gòu)件。分布服務(wù)集成：檢測一個對等構(gòu)件松散連接的網(wǎng)絡(luò)。高頻集成：開發(fā)并重運行一個集成測試包進(jìn)行每小時、每日或每周測試。大爆炸集成目標(biāo)通過少數(shù)測試運行檢測整個系統(tǒng)來論證系統(tǒng)的穩(wěn)定性。上下文和故障模型不考慮構(gòu)件之間的相依性或風(fēng)險；只有少數(shù)幾個構(gòu)件被加入或修改；每個構(gòu)件都通過了充分的構(gòu)件范圍測試；無法分別對構(gòu)件進(jìn)行檢測。策略在系統(tǒng)范圍應(yīng)用一個測試包。自底向上集成目標(biāo)從具有最少相依性的構(gòu)件開始，按照使用相依性的次序?qū)?gòu)件加入被測系統(tǒng)，以證實穩(wěn)定性。上下文和故障模型具有最少相依性的構(gòu)件最先測試，當(dāng)這些構(gòu)件通過測試后，用它們的客戶對象替換驅(qū)動模塊，再開始下一輪測試。策略以在相依性樹中從葉子移動到根的方式進(jìn)行，如果樹有n級，則需要n個階段。自頂向下集成目標(biāo)從頂層控制對象開始，以控制層次的順序向SUT增加構(gòu)件以論證穩(wěn)定性。上下文和故障模型首先測試控制對象；增量式開發(fā)；并行硬件/軟件開發(fā)；并行軟件開發(fā)；框架開發(fā)。策略從最高控制層構(gòu)件開始測試，以樁的形式實現(xiàn)服務(wù)對象。每一層按寬度優(yōu)先進(jìn)行，用實現(xiàn)代替樁，并為下面低層服務(wù)對象設(shè)置樁對象，指導(dǎo)系統(tǒng)測試完。協(xié)作集成目標(biāo)通過向SUT中加入構(gòu)件集合證明穩(wěn)定性，該集成被要求支持一個特定的協(xié)作。上下文和故障模型檢測協(xié)作參與者之間的接口并根據(jù)協(xié)作組織集成；它們的順序可以根據(jù)相依性或順序激