面向?qū)ο筌浖y試

1、第14講 面向?qū)ο筌浖y試1結(jié)構(gòu)化測試自底向上的測試策略，從“小型測試”開始，逐步走向“大型測試”從單元測試開始，然后逐步進(jìn)入集成測試，最后是有效性和系統(tǒng)測試在傳統(tǒng)應(yīng)用中，單元測試集中在最小的可編譯程序單位子程序(如，模塊、子例程、進(jìn)程)一旦這些單元均被獨立測試后，它被集成在程序結(jié)構(gòu)中這時要進(jìn)行一系列的回歸測試以發(fā)現(xiàn)由于模塊的接口所帶來的錯誤和新單元加入所導(dǎo)致的副作用系統(tǒng)被作為一個整體測試以保證發(fā)現(xiàn)在需求中的錯誤2面向?qū)ο筌浖攸c面向?qū)ο蟪绦蚪Y(jié)構(gòu)不再是傳統(tǒng)的功能模塊結(jié)構(gòu)作為一個整體，原有集成測試所要求的逐步將開發(fā)的模塊搭建在一起進(jìn)行測試的方法已成為不可能面向?qū)ο筌浖仐壛藗鹘y(tǒng)的開發(fā)模式，對每個

2、開發(fā)階段都有不同以往的要求和結(jié)果,已經(jīng)不可能用功能細(xì)化的觀點來檢測面向?qū)ο蠓治龊驮O(shè)計的結(jié)果傳統(tǒng)的測試模型對面向?qū)ο筌浖呀?jīng)不再適用3面向?qū)ο鬁y試模型面向?qū)ο蟮拈_發(fā)模型突破了傳統(tǒng)的瀑布模型，將開發(fā)分為面向?qū)ο蠓治觯∣OA），面向?qū)ο笤O(shè)計（OOD），和面向?qū)ο缶幊蹋∣OP）三個階段針對這種開發(fā)模型，結(jié)合傳統(tǒng)的測試步驟的劃分，把面向?qū)ο蟮能浖y試分為：面向?qū)ο蠓治龅臏y試面向?qū)ο笤O(shè)計的測試面向?qū)ο缶幊痰臏y試面向?qū)ο髥卧獪y試面向?qū)ο蠹蓽y試面向?qū)ο笙到y(tǒng)測試面向?qū)ο蟮幕貧w測試4面向?qū)ο蠓治龅臏y試 面向?qū)ο蠓治?OOA):E-R圖和語義網(wǎng)絡(luò)模型信息造型中的概念，與面向?qū)ο蟪绦蛟O(shè)計語言中的重要概念結(jié)合在一起而

3、形成的分析方法最后通常是得到問題空間的圖表的形式描述5面向?qū)ο蠓治龅臏y試（續(xù)）OOA直接映射問題空間，全面的將問題空間中實現(xiàn)功能的現(xiàn)實抽象化將問題空間中的實例抽象為對象，用對象的結(jié)構(gòu)反映問題空間的復(fù)雜實例和復(fù)雜關(guān)系，用屬性和操作表示實例的特性和行為對一個系統(tǒng)而言，與傳統(tǒng)分析方法產(chǎn)生的結(jié)果相反，行為是相對穩(wěn)定的，結(jié)構(gòu)是相對不穩(wěn)定的，這更充分反映了現(xiàn)實的特性O(shè)OA的結(jié)果是為后面階段類的選定和實現(xiàn)，類層次結(jié)構(gòu)的組織和實現(xiàn)提供平臺。因此，對OOA的測試，應(yīng)從以下方面考慮：對認(rèn)定的對象的測試對認(rèn)定的結(jié)構(gòu)的測試對認(rèn)定的主題的測試對定義的屬性和實例關(guān)聯(lián)的測試對定義的服務(wù)和消息關(guān)聯(lián)的測試6面向?qū)ο笤O(shè)計的測試

4、面向?qū)ο笤O(shè)計（OOD）采用造型的觀點，以O(shè)OA為基礎(chǔ)歸納出類，并建立類結(jié)構(gòu)或進(jìn)一步構(gòu)造成類庫，實現(xiàn)分析結(jié)果對問題空間的抽象OOD是OOA的進(jìn)一步細(xì)化和更高層的抽象OOD確定類和類結(jié)構(gòu)不僅是滿足當(dāng)前需求分析的要求，更重要的是通過重新組合或加以適當(dāng)?shù)难a(bǔ)充，能方便實現(xiàn)功能的重用和擴(kuò)增，以不斷適應(yīng)用戶的要求對OOD的測試，應(yīng)從如下三方面考慮：對認(rèn)定的類的測試對構(gòu)造的類層次結(jié)構(gòu)的測試對類庫的支持的測試7面向?qū)ο缶幊痰臏y試 典型的面向?qū)ο蟪绦蚓哂欣^承、封裝和多態(tài)的新特性，這使得傳統(tǒng)的測試策略必須有所改變封裝是對數(shù)據(jù)的隱藏，外界只能通過被提供的操作來訪問或修改數(shù)據(jù)，這樣降低了數(shù)據(jù)被任意修改和讀寫的可能性，降

5、低了傳統(tǒng)程序中對數(shù)據(jù)非法操作的測試?yán)^承是面向?qū)ο蟪绦虻闹匾攸c，繼承使得代碼的重用率提高，同時也使錯誤傳播的概率提高多態(tài)使得面向?qū)ο蟪绦驅(qū)ν獬尸F(xiàn)出強(qiáng)大的處理能力，但同時卻使得程序內(nèi)同一函數(shù)的行為復(fù)雜化，測試時必須考慮不同類型具體執(zhí)行的代碼和產(chǎn)生的行為8面向?qū)ο缶幊痰臏y試（續(xù)）面向?qū)ο蟪绦蚴前压δ艿膶崿F(xiàn)分布在類中能正確實現(xiàn)功能的類，通過消息傳遞來協(xié)同實現(xiàn)設(shè)計要求的功能因此，在面向?qū)ο缶幊?OOP)階段，忽略類功能實現(xiàn)的細(xì)則，將測試的目光集中在類功能的實現(xiàn)和相應(yīng)的面向?qū)ο蟪绦蝻L(fēng)格，主要體現(xiàn)為以下兩個方面數(shù)據(jù)成員是否滿足數(shù)據(jù)封裝的要求類是否實現(xiàn)了要求的功能9面向?qū)ο蟮膯卧獪y試類測試傳統(tǒng)的單元測試的對

6、象是軟件設(shè)計的最小單位模塊單元測試的依據(jù)是詳細(xì)設(shè)描述，單元測試應(yīng)對模塊內(nèi)所有重要的控制路徑設(shè)計測試用例，以便發(fā)現(xiàn)模塊內(nèi)部的錯誤單元測試多采用白盒測試技術(shù)，系統(tǒng)內(nèi)多個模塊可并行地進(jìn)行測試當(dāng)考慮面向?qū)ο筌浖r，單元的概念發(fā)生了變化封裝驅(qū)動了類和對象的定義，這意味著每個類和類的實例(對象)包裝了屬性(數(shù)據(jù))和操縱這些數(shù)據(jù)的操作，而不是個體的模塊最小的可測試單位是封裝的類或?qū)ο?，類包含一組不同的操作，并且某特殊操作可能作為一組不同類的一部分存在一個對象有它自己的狀態(tài)和依賴于狀態(tài)的行為, 對象操作既與對象的狀態(tài)有關(guān), 但也可能改變對象的狀態(tài)。 單元測試的意義發(fā)生了較大變化，我們不再孤立地測試單個操作，而

7、是將操作作為類的一部分10面向?qū)ο蟮膯卧獪y試類測試（續(xù)）類的測試按順序分為三個部分: 基于服務(wù)的測試: 測試類中的每一個方法; 基于狀態(tài)的測試: 考察類的實例在其生命周期各個狀態(tài)下的情況;基于響應(yīng)狀態(tài)的測試: 從類和對象的責(zé)任出發(fā),以外界向?qū)ο蟀l(fā)送特定的消息序列的方法來測試對象的各個響應(yīng)狀態(tài) 11面向?qū)ο蟮募蓽y試傳統(tǒng)的集成測試，有兩種方式通過集成完成的功能模塊進(jìn)行測自頂向下集成：自頂向下集成是構(gòu)造程序結(jié)構(gòu)的一種增量式方式，它從主控模塊開始，按照軟件的控制層次結(jié)構(gòu)，以深度優(yōu)先或廣度優(yōu)先的策略，逐步把各個模塊集成在一起自底向上集成：自底向上測試是從“原子”模塊（即軟件結(jié)構(gòu)最低層的模塊）開始組裝測

8、試12面向?qū)ο蟮募蓽y試（續(xù)）因為面向?qū)ο筌浖]有層次的控制結(jié)構(gòu)，傳統(tǒng)的自頂向下和自底向上集成策略就沒有意義此外,一次集成一個操作到類中(傳統(tǒng)的增量集成方法)經(jīng)常是不可能的,這是由于“構(gòu)成類的成分的直接和間接的交互”對OO軟件的集成測試有兩種不同策略基于線程的測試，集成對回應(yīng)系統(tǒng)的一個輸入或事件所需的一組類，每個線程被集成并分別測試，應(yīng)用回歸測試以保證沒有產(chǎn)生副作用基于使用的測試，通過測試那些幾乎不使用服務(wù)器類的類(稱為獨立類)而開始構(gòu)造系統(tǒng)，在獨立類測試完成后，下一層的使用獨立類的類，稱為依賴類，被測試。這個依賴類層次的測試序列一直持續(xù)到構(gòu)造完整個系統(tǒng)13面向?qū)ο蟮南到y(tǒng)測試通過單元測試和集成

9、測試，僅能保證軟件開發(fā)的功能得以實現(xiàn)。但不能確認(rèn)在實際運行時，它是否滿足用戶的需要。為此，對完成開發(fā)的軟件必須經(jīng)過規(guī)范的系統(tǒng)測試系統(tǒng)測試應(yīng)盡量搭建與用戶實際使用環(huán)境相同的測試平臺，應(yīng)該保證被測系統(tǒng)的完整性，對臨時沒有的系統(tǒng)設(shè)備部件，也應(yīng)有相應(yīng)的模擬手段系統(tǒng)測試時，應(yīng)該參考OOA分析的結(jié)果，對應(yīng)描述的對象、屬性和各種服務(wù)，檢測軟件是否能夠完全再現(xiàn)問題空間系統(tǒng)測試不僅是檢測軟件的整體行為表現(xiàn)，從另一個側(cè)面看，也是對軟件開發(fā)設(shè)計的再確認(rèn)14面向?qū)ο蟮南到y(tǒng)測試（續(xù)）類簇（是一組相互合作的類）類簇測試主要考察一組協(xié)同操作的類之間的相互作用, 是系統(tǒng)集成測試的一個子階段在單個類分別進(jìn)行測試后, 根據(jù)系統(tǒng)中

10、類的層次關(guān)系圖, 將相互有影響的類作為一個整體, 檢查各相關(guān)類之間消息連接的合法性、子類的繼承性與父類的一致性、動態(tài)綁定執(zhí)行的正確性、類簇協(xié)同完成系統(tǒng)功能的正確性等測試用例可由多種方案結(jié)合生成如根據(jù)類的繼承關(guān)系圖來縱向檢查類, 根據(jù)對象之間方法的相互作用來橫向檢查類的關(guān)系圖15面向?qū)ο蟮南到y(tǒng)測試（續(xù)）系統(tǒng)測試: 系統(tǒng)測試是對所有類和主程序構(gòu)成的整個系統(tǒng)進(jìn)行整體測試, 以驗證軟件系統(tǒng)的正確性和性能指標(biāo)等滿足需求規(guī)格說明書和任務(wù)書所指定的要求它與傳統(tǒng)的系統(tǒng)測試一樣, 包括功能測試、性能測試、余量測試等, 可套用傳統(tǒng)的系統(tǒng)測試方法測試用例可從對象行為模型和作為面向?qū)ο蠓治龅氖录鲌D中導(dǎo)出16面向?qū)ο?/p>

11、軟件回歸測試面向?qū)ο筌浖械幕貧w測試不再作為測試的一個獨立的階段, 而是以增量方式進(jìn)行的對象系統(tǒng)中的交互, 既發(fā)生在類內(nèi)的方法間又發(fā)生在多個類之間類A與類B的交互是通過:(1) B的實例變量作為參數(shù)傳給類A 的某方法 這時, 類B的改變必然導(dǎo)致對類A 的方法的回歸測試, 如果類A的方法又與其它方法發(fā)生交互, 這些方法及其類必須都進(jìn)行回歸測試(2) 類A的實例是類B表示的一部分 這時,B的所有對類A中變量進(jìn)行引用的方法必須進(jìn)行回歸測試 在這兩種情況下, 測試依賴集可用來確定情況(1) 中所有與方法A的交互集; 對象的數(shù)據(jù)依賴集可用來確定情況(1)和(2)中所有必須重新測試的類和方法對面向?qū)ο筌浖?/p>

12、的修改主要有: 不修改對象屬性, 只對方法進(jìn)行修改該對象以及系統(tǒng)中所有與該對象發(fā)生交互的對象都要進(jìn)行完全新的測試。通常, 這種測試代價是很高的 修改對象屬性 17面向?qū)ο筌浖y試總結(jié)面向?qū)ο鬁y試的整體目標(biāo)以最小的工作量發(fā)現(xiàn)最多的錯誤和傳統(tǒng)軟件測試的目標(biāo)是一致的，但是OO測試的策略和戰(zhàn)術(shù)有很大不同測試的視角擴(kuò)大到包括復(fù)審分析和設(shè)計模型，此外，測試的焦點從過程構(gòu)件(模塊)移向了類不論是傳統(tǒng)的測試方法還是面向?qū)ο蟮臏y試方法，都應(yīng)該遵循下列的原則： 應(yīng)當(dāng)把“盡早和不斷地測試”作為開發(fā)者的座右銘程序員應(yīng)該避免檢查自己的程序，測試工作應(yīng)由獨立的專業(yè)的軟件測試機(jī)構(gòu)來完成設(shè)計測試用例時，應(yīng)該考慮到合法的輸入和不合法的輸入，以及各種邊界條件，特殊情況下要制造極端狀態(tài)和意外狀態(tài)，比如網(wǎng)絡(luò)異常中斷、電源斷電等情況一定要注意測試中的錯誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習(xí)慣有很大關(guān)系對測試錯誤結(jié)果一定要有一個確認(rèn)的過程。一般有A測試出來的錯誤，一定要有一個B來確認(rèn)，嚴(yán)重的錯誤可以召開評審會進(jìn)行討論和分析制定嚴(yán)格的測試計劃，并把測試時間安排得盡量寬松，不要希望在極短的時間內(nèi)完成一個高水平的測試回歸測試的關(guān)聯(lián)性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現(xiàn)的現(xiàn)象并不少見妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)