軟件測試面向?qū)ο鬁y試技術(shù)

一、面向?qū)ο鬁y試概述1.傳統(tǒng)的軟件開發(fā)存在的問題（1）軟件重用性差（2）軟件可維護(hù)性差（3）開發(fā)出的軟件不易滿足用戶需求第一頁第二頁，共59頁。一、面向?qū)ο鬁y試概述2、面向?qū)ο蠹夹g(shù)基本概念（1）對象（2）對象的狀態(tài)和行為（3）類（4）類的結(jié)構(gòu)（類間關(guān)系）（5）消息和方法第二頁第三頁，共59頁。一、面向?qū)ο鬁y試概述

我們生活在一個對象的世界里，每個對象有一定的屬性，把屬性相同的對象進(jìn)行歸納就形成類例如：家具就可以看作類，其主要的屬性有價格、尺寸、重量、位置和顏色等無論我們談?wù)撟雷?、椅子還是沙發(fā)、衣櫥，這些屬性總是可用的，因為它們都是家具而繼承了為類定義的所有屬性。除了屬性之外，每個對象可以被一系列不同的方式操縱，它可以被買賣、移動、修改(如漆上不同的顏色)。這些操作或方法將改變對象的一個或多個屬性。類的合法操作可以和對象的定義聯(lián)系在一起，并且被類的所有實例繼承。第三頁第四頁，共59頁。一、面向?qū)ο鬁y試概述面向?qū)ο筇卣鳎?）對象唯一性（2）分類性（3）繼承性（4）多態(tài)性第四頁第五頁，共59頁。一、面向?qū)ο鬁y試概述面向?qū)ο笠兀?）抽象（2）封裝（3）共享第五頁第六頁，共59頁。面向?qū)ο筌浖_發(fā)方法與傳統(tǒng)的軟件開發(fā)方法的區(qū)別：（1）調(diào)查、分析系統(tǒng)需求，建立一個全面、合理、統(tǒng)一的模型。（2）對象設(shè)計。（3）程序?qū)崿F(xiàn)。第六頁第七頁，共59頁。面向?qū)ο筌浖_發(fā)過程面向?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)測試。第七頁第八頁，共59頁。面向?qū)ο鬁y試在傳統(tǒng)的面向過程程序中，對于函數(shù) y=Function(x);只需要考慮一個函數(shù)（Function()）的行為特點，在面向?qū)ο蟪绦蛑校悴坏貌煌瑫r考慮基類函數(shù)（Base::Function()）的行為和繼承類函數(shù)（Derived::Function()）的行為。面向?qū)ο蟪绦虻慕Y(jié)構(gòu)不再是傳統(tǒng)的功能模塊結(jié)構(gòu)，作為一個整體，原有集成測試所要求的逐步將開發(fā)的模塊搭建在一起進(jìn)行測試的方法已不可能。第八頁第九頁，共59頁。面向?qū)ο鬁y試面向?qū)ο筌浖γ總€開發(fā)階段都有不同以往的要求和結(jié)果，已經(jīng)不可能用功能細(xì)化的觀點來檢測面向?qū)ο蠓治龊驮O(shè)計的結(jié)果。針對面向?qū)ο筌浖拈_發(fā)特點，應(yīng)該有一種新的測試模型。第九頁第十頁，共59頁。二、面向?qū)ο竽Ｐ?/p>

OOAOODOOPOOATestOODTestOOPTestOOUnitTestOOIntegrateTestOOSystemTestOOATest：面向?qū)ο蠓治龅臏y試，OODTest：面向?qū)ο笤O(shè)計的測試，OOPTest：面向?qū)ο缶幊痰臏y試；OOUnitTest：面向?qū)ο髥卧獪y試，OOIntegrateTest：面向?qū)ο蠹蓽y試，OOSystemTest：面向?qū)ο笙到y(tǒng)測試。第十頁第十一頁，共59頁。二、面向?qū)ο竽Ｐ蚈OATest和OODTest:是對分析和設(shè)計結(jié)果的測試，主要是對分析設(shè)計生成的文檔進(jìn)行，是軟件開發(fā)前期的關(guān)鍵性測試；OOPTest:主要針對編程風(fēng)格和程序代碼實現(xiàn)進(jìn)行測試看，其測試內(nèi)容主要在面向?qū)ο髥卧兔嫦驅(qū)ο蠹蓽y試中體現(xiàn)；OOUnitTest:對程序內(nèi)部具體單一的功能模塊的測試。主要是對類的測試。

OOIntegrateTest:主要對系統(tǒng)內(nèi)部相互服務(wù)進(jìn)行測試，如方法間的相互作用，類間的消息傳遞等。OOSystemTest:是面向?qū)ο鬁y試的最后階段的測試，主要以用戶需求為測試標(biāo)準(zhǔn)，借鑒OOA及其測試結(jié)果。第十一頁第十二頁，共59頁。二、面向?qū)ο竽Ｐ蚈OA：將問題空間中實現(xiàn)的功能進(jìn)行抽象，問題空間中的實例抽象為對象，用對象的結(jié)構(gòu)反映問題空間的復(fù)雜關(guān)系，用屬性和服務(wù)表示實例的特殊性和行為OOD：建立類結(jié)構(gòu)或進(jìn)一步構(gòu)造類庫，實現(xiàn)分析結(jié)果對問題空間的抽象。OOP：軟件的計算機實現(xiàn)。第十二頁第十三頁，共59頁。三、面向?qū)ο蠓治龊驮O(shè)計的測試OOATest和OODTest:是對分析和設(shè)計結(jié)果的測試，主要是對分析設(shè)計生成的文檔進(jìn)行，是軟件開發(fā)前期的關(guān)鍵性測試； OOA直接映射問題空間，全面地在問題空間中實現(xiàn)功能的現(xiàn)實抽象化。OOA必須回答：（1）為完成用戶要求，系統(tǒng)應(yīng)提供哪些功能（2）系統(tǒng)應(yīng)由哪些對象構(gòu)成（3）每個對象應(yīng)有哪些屬性和服務(wù)（4）對象間應(yīng)有怎樣的聯(lián)系第十三頁第十四頁，共59頁。三、面向?qū)ο蠓治龊驮O(shè)計的測試面向?qū)ο笤O(shè)計（OOD）采用“造型的觀點”，以O(shè)OA為基礎(chǔ)歸納出類，并建立類結(jié)構(gòu)或進(jìn)一步構(gòu)造成類庫，實現(xiàn)分析結(jié)果對問題空間的抽象。OOD歸納的類，可以是對象簡單的延續(xù)，可以是不同對象的相同或相似的服務(wù)。由此可見，OOD不是在OOA上的另一思維方式的大動干戈，而是OOA的進(jìn)一步細(xì)化和更高層的抽象。面向?qū)ο笤O(shè)計（OOD）是以O(shè)OA歸納出的類為基礎(chǔ)，建立類結(jié)構(gòu)甚至進(jìn)一步構(gòu)造成類庫，實現(xiàn)分析結(jié)果對問題空間的抽象。第十四頁第十五頁，共59頁。三、面向?qū)ο蠓治龊驮O(shè)計的測試對認(rèn)定的對象的測試

OOA（面向?qū)ο蠓治觯┲姓J(rèn)定的對象是對問題空間中的結(jié)構(gòu)、其他系統(tǒng)、設(shè)備、被記憶的事件、系統(tǒng)涉及的人員等實際實例的抽象。對它的測試可以從如下方面考慮：認(rèn)定的對象是否全面，其名稱應(yīng)該盡量準(zhǔn)確、適用，是否問題空間中所涉及到的實例都反映在認(rèn)定的抽象對象中。認(rèn)定的對象是否具有多個屬性。只有一個屬性的對象通常應(yīng)看作其他對象的屬性而不是抽象為獨立的對象對認(rèn)定為同一對象的實例是否有共同的、區(qū)別于其他實例的共同屬性，是否提供或需要相同的服務(wù)如果系統(tǒng)沒有必要始終保持對象代表的實例信息，提供或者得到關(guān)于它的服務(wù)，認(rèn)定的對象也無必要。第十五頁第十六頁，共59頁。三、面向?qū)ο蠓治龊驮O(shè)計的測試對認(rèn)定的結(jié)構(gòu)的測試

認(rèn)定的結(jié)構(gòu)指的是多種對象的組織方式，用來反映問題空間中的復(fù)雜實例和復(fù)雜關(guān)系。認(rèn)定的分類結(jié)構(gòu)測試要點：處于高層的對象，是否在問題空間中含有不同于下一層對象的特殊可能性，即是否能派生出下一層對象。處于同一低層的對象，是否能抽象出在現(xiàn)實中有意義的更一般的上層對象。對所有認(rèn)定的對象，是否能在問題空間內(nèi)向上層抽象出在現(xiàn)實中有意義的對象。高層的對象的特性是否完全體現(xiàn)下層的共性，低層的對象是否有高層特性基礎(chǔ)上的特殊性。第十六頁第十七頁，共59頁。三、面向?qū)ο蠓治龊驮O(shè)計的測試對構(gòu)造的類層次結(jié)構(gòu)的測試

為了能充分發(fā)揮面向?qū)ο罄^承共享特性，OOD（面向?qū)ο笤O(shè)計）的類層次結(jié)構(gòu)通?；贠OA中產(chǎn)生的分類結(jié)構(gòu)的原則來組織，著重體現(xiàn)父類和子類間的一般性和特殊性。在當(dāng)前的問題空間，對類層次結(jié)構(gòu)的主要要求是能在解空間構(gòu)造實現(xiàn)全部功能的結(jié)構(gòu)框架。為此測試要注意如下幾個方面：類層次結(jié)構(gòu)是否涵蓋了所有定義的類；是否能體現(xiàn)OOA中所定義的實例關(guān)聯(lián)、消息關(guān)聯(lián)；子類是否具有父類沒有的新特性；子類間的共同特性是否完全在父類中得以體現(xiàn)。第十七頁第十八頁，共59頁。五、面向?qū)ο缶幊痰臏y試典型的面向?qū)ο蟪绦蚓哂欣^承、封裝和多態(tài)的新特性，這使得傳統(tǒng)的測試策略必須有所改變。封裝是對數(shù)據(jù)的隱藏，外界只能通過被提供的操作來訪問或修改數(shù)據(jù)，這樣降低了數(shù)據(jù)被任意修改和讀寫的可能性，降低了傳統(tǒng)程序中對數(shù)據(jù)非法操作的測試。繼承是面向?qū)ο蟪绦虻闹匾攸c，繼承使得代碼的重用率提高，同時也使錯誤傳播的概率提高。第十八頁第十九頁，共59頁。五、面向?qū)ο缶幊痰臏y試?yán)^承使得傳統(tǒng)測試遇見了這樣一個難題：對繼承的代碼究竟應(yīng)該怎樣測試？多態(tài)使得面向?qū)ο蟪绦驅(qū)ν獬尸F(xiàn)出強大的處理能力，但同時卻使得程序內(nèi)“同一”函數(shù)的行為復(fù)雜化，測試時不得不考慮不同類型具體執(zhí)行的代碼和產(chǎn)生的行為。第十九頁第二十頁，共59頁。面向?qū)ο蟪绦蚴前压δ艿膶崿F(xiàn)分布在類中。能正確實現(xiàn)功能的類，通過消息傳遞來協(xié)同實現(xiàn)設(shè)計要求的功能。正是這種面向?qū)ο蟪绦蝻L(fēng)格，將出現(xiàn)的錯誤能精確的確定在某一具體的類。因此，在面向?qū)ο缶幊蹋∣OP）階段，忽略類功能實現(xiàn)的細(xì)則，將測試的目光集中在類功能的實現(xiàn)和相應(yīng)的面向?qū)ο蟪绦蝻L(fēng)格，主要體現(xiàn)為以下兩個方面（假設(shè)編程使用C++語言）：

☆數(shù)據(jù)成員是否滿足數(shù)據(jù)封裝的要求

☆類是否實現(xiàn)了要求的功能第二十頁第二十一頁，共59頁。六、面向?qū)ο蟮膯卧獪y試傳統(tǒng)的單元測試是針對程序的函數(shù)、過程或完成某一定功能的程序塊。沿用單元測試的概念，實際測試類成員函數(shù)。一些傳統(tǒng)的測試方法在面向?qū)ο蟮膯卧獪y試中都可以使用。如等價類劃分法，因果圖法，邊值分析法，邏輯覆蓋法，路徑分析法，等等，單元測試一般建議由程序員完成。第二十一頁第二十二頁，共59頁。六、面向?qū)ο蟮膯卧獪y試面向?qū)ο蟮膯卧獪y試的對象是軟件設(shè)計的最小單位—類。單元測試的依據(jù)是詳細(xì)設(shè)計，單元測試應(yīng)對類中所有重要的屬性和方法設(shè)計測試用例，以發(fā)現(xiàn)類內(nèi)部的錯誤。單元測試多采用白盒測試技術(shù)，系統(tǒng)內(nèi)多個類都可以并行進(jìn)行測試。沿用單元測試概念，實際測試類成員函數(shù)。一些傳統(tǒng)的測試方法在面向?qū)ο蟮膯卧獪y試中都可以使用，如等價類劃分、邊界值分析、因果圖、邏輯覆蓋、路徑分析法等。第二十二頁第二十三頁，共59頁。1、單元測試的內(nèi)容面向?qū)ο蟮膯卧褪穷?，單元測試實際測試的就是對類的測試。類測試的目的主要確保一個類的代碼能夠完全滿足類的說明所描述的要求。第二十三頁第二十四頁，共59頁。2、單元測試開始的時間單元測試開始的時間一般在完全說明了這個類，并且準(zhǔn)備對其編碼后不久。單元測試開始時要制定一個測試計劃。在反復(fù)迭代的過程中，類的實現(xiàn)和說明在進(jìn)程中可能會發(fā)生變化，所以應(yīng)該在軟件的其他部件使用該類之前對類進(jìn)行測試，同時還有必要執(zhí)行回歸測試。第二十四頁第二十五頁，共59頁。3、單元測試的人員由另一個類的開發(fā)人員編寫測試計劃，由該類的開發(fā)人員完成測試，避免對類說明的錯誤理解第二十五頁第二十六頁，共59頁。4、單元測試方法單元測試的方法有代碼檢查和執(zhí)行測試用例。在某些情況下，用代碼檢查代替基于執(zhí)行的測試方法是可行的，但是，代碼檢查也存在以下兩個不利之處：代碼檢查容易受人為因素影響代碼檢查在回歸測試方面明顯需要更多的工作量第二十六頁第二十七頁，共59頁。類測試按順序分為以下三部分：基于屬性的測試：類中所有屬性的設(shè)置和訪問的測試?；诜?wù)的測試：測試類中的每個方法。基于狀態(tài)的測試：除了類的每個操作要進(jìn)行測試，類的行為也要進(jìn)行測試，所有能引起狀態(tài)變化的事件都要模擬到。類的行為通常可用狀態(tài)圖來描述，在利用狀態(tài)圖進(jìn)行類測試時，可考慮覆蓋所有狀態(tài)、狀態(tài)遷移等覆蓋標(biāo)準(zhǔn)，也可考慮從初始狀態(tài)到終止?fàn)顟B(tài)的所有遷移路徑的覆蓋。第二十七頁第二十八頁，共59頁。5、方法的測試在測試類的功能實現(xiàn)時，應(yīng)該首先保證類成員函數(shù)的正確性。測試時主要考慮封裝在類中的一個方法對數(shù)據(jù)進(jìn)行的操作，可以采用傳統(tǒng)的模塊測試方法，通過向所在對象發(fā)消息來執(zhí)行，它的執(zhí)行與狀態(tài)有關(guān)。傳統(tǒng)的針對模塊的設(shè)計測試用例的技術(shù)，如等價劃分、邊界值分析、因果圖、邏輯覆蓋、路徑覆蓋等方法，仍然可以作為測試類中每個方法的主要技術(shù)。第二十八頁第二十九頁，共59頁。在面向?qū)ο蟮南到y(tǒng)中的方法，是通過消息來驅(qū)動執(zhí)行的，要測試類中的方法，必須用一個驅(qū)動程序?qū)Ρ粶y方法發(fā)送一條消息以驅(qū)動其執(zhí)行，如果被測模塊或方法中調(diào)用了其他模塊或方法，則需要設(shè)計一個模擬被調(diào)子程序功能的存根程序，驅(qū)動程序、存根程序及被測模塊或方法組成一個獨立的可執(zhí)行單元。第二十九頁第三十頁，共59頁。在面向?qū)ο筌浖?，在保證單個方法功能正確的基礎(chǔ)上，還應(yīng)該處理好測試方法之間的協(xié)助關(guān)系。為了提高方法的重用性，設(shè)計方法的一個準(zhǔn)則是提高方法的內(nèi)聚，即在一個方法中只完成單個功能。對于繼承過來的方法，也要加以測試。運行測試用例的時候，必須提供能夠?qū)嵗臉额?，以及起?qū)動器作用的“主程序”類，來提供和分析測試用例。第三十頁第三十一頁，共59頁。6、測試程度可以根據(jù)已經(jīng)測試了多少類的實現(xiàn)和多少類的說明來衡量測試的充分性。通常需要將這兩者都考慮到，希望測試到操作和狀態(tài)轉(zhuǎn)換的各種組合情況。一個對象能維持自己的狀態(tài)，而狀態(tài)一般來說也會影響操作的含義。第三十一頁第三十二頁，共59頁。類層次的分割測試這種測試可以減少用完全相同的方式檢查類測試用例的數(shù)目。這很像傳統(tǒng)軟件測試中的等價類劃分測試。分割測試又可分三種：基于狀態(tài)的分割，按類操作是否改變類的狀態(tài)來分割（歸類）；基于屬性的分割，按類操作所用到的屬性來分割（歸類）；基于類型的分割，按完成的功能分割（歸類）。第三十二頁第三十三頁，共59頁。舉例一個銀行類Account：屬性：balance（賬戶余額）和creditLimit（透支額）其操作有：open（）打開賬戶、setup（）建立、deposit（）存款、withdraw（）取錢、balance（）查詢余額、summarize（）操作清單、creaditLimit（）透支限額close（）關(guān)閉賬戶第三十三頁第三十四頁，共59頁。舉例基于狀態(tài)劃分就是根據(jù)它們改變類狀態(tài)的能力對類操作進(jìn)行劃分?？紤]Account類，狀態(tài)操作包括deposit（）、withdraw（），非狀態(tài)操作包括balance（）、summarize（）、creaditLimit（）。將給不狀態(tài)的操作和不改變狀態(tài)的操作分別進(jìn)行測試。因此：測試用例a：open→setup→deposit→deposit→withdraw→withdraw→close測試用例b：open→setup→deposit→summrize→creaditLimit→balance→withdraw→close第三十四頁第三十五頁，共59頁。舉例基于屬性劃分就是根據(jù)它們所使用的屬性進(jìn)行劃分。對于類Account，屬性balance和creaditLimit用于定義劃分。操作可分為三類（1）使用creditLimit的操作；（2）修改creditLimit的操作；（3）既不使用也不修改creditLimit的操作。然后為每個劃分設(shè)計測試用例?；陬悇e的劃分就是根據(jù)每個操作所完成一般功能進(jìn)行劃分類操作。例如Account類操作可以劃分初始化操作——open（）、setup（）,計算操作——deposit（）、withdraw（），查詢操作——balance（）、summarize（）、creadLimit（）及關(guān)閉操作close（）。第三十五頁第三十六頁，共59頁。七、面向?qū)ο蟮募蓽y試對于面向?qū)ο蟪绦颍嗷フ{(diào)用的功能是散布在程序的不同類中，類通過消息相互作用申請和提供服務(wù)。把一組相互有影響的類看作一個整體稱為類簇。類簇的測試主要依據(jù)系統(tǒng)中相關(guān)類的層次關(guān)系，檢查類之間相互作用的正確性，即檢查各相關(guān)類之間消息連接的合法性、子類的繼承性與父類的一致性、動態(tài)綁定執(zhí)行的正確性、類簇協(xié)同完成系統(tǒng)功能的正確性等。面向?qū)ο蟮募蓽y試能夠檢測出相對獨立的單元測試無法檢測出的那些類相互作用時才會產(chǎn)生的錯誤。第三十六頁第三十七頁，共59頁?；趩卧獪y試對成員函數(shù)行為正確性的保證，集成測試只關(guān)注于系統(tǒng)的結(jié)構(gòu)和內(nèi)部的相互作用。面向?qū)ο蟮募蓽y試可以分成兩步進(jìn)行：先進(jìn)行靜態(tài)測試，再進(jìn)行動態(tài)測試。七、面向?qū)ο蟮募蓽y試第三十七頁第三十八頁，共59頁。靜態(tài)測試主要針對程序的結(jié)構(gòu)進(jìn)行，檢測程序結(jié)構(gòu)是否符合設(shè)計要求?，F(xiàn)在流行的一些測試軟件都能提供一種稱為“可逆性工程”的功能，即通過原程序得到類關(guān)系圖和函數(shù)功能調(diào)用關(guān)系圖。通過“可逆性工程”得到的結(jié)果與OOD的結(jié)果相互比較，檢測程序結(jié)構(gòu)和實現(xiàn)上是否有缺陷，通過這種方法檢測OOP是否達(dá)到了OOD的要求。第三十八頁第三十九頁，共59頁。動態(tài)測試設(shè)計測試用例時，通常需要功能調(diào)用結(jié)構(gòu)圖、類關(guān)系圖或者實體關(guān)系圖為參考，確定不需要被重復(fù)測試的部分，從而優(yōu)化測試用例，減少測試工作量，使得進(jìn)行的測試能夠達(dá)到一定覆蓋標(biāo)準(zhǔn)。測試所要達(dá)到的覆蓋標(biāo)準(zhǔn)：達(dá)到類所有的服務(wù)要求或服務(wù)提供的一定覆蓋率；依據(jù)類間傳遞的消息，達(dá)到對所有執(zhí)行線程的一定覆蓋率；達(dá)到類的所有狀態(tài)的一定覆蓋率等。同時也可以考慮使用現(xiàn)有的一些測試工具來得到程序代碼執(zhí)行的覆蓋率。第三十九頁第四十頁，共59頁。面向?qū)ο蠹蓽y試的測試策略其測試有兩種不同策略：基于類間協(xié)作關(guān)系的橫向測試基于類間繼承關(guān)系的縱向測試。第四十頁第四十一頁，共59頁。1、基于類間協(xié)作關(guān)系的橫向測試由系統(tǒng)的一個輸入事件為起點，對其觸發(fā)的一組類進(jìn)行測試，執(zhí)行相應(yīng)的操作/消息處理路徑，最后終止于某一輸出事件。應(yīng)用回歸測試對以測試過的類集再重新執(zhí)行一次，以保證加入新類時不會產(chǎn)生意外的結(jié)果第四十一頁第四十二頁，共59頁。第四十二頁第四十三頁，共59頁。第四十三頁第四十四頁，共59頁。2、基于類間繼承關(guān)系的縱向測試首先通過測試獨立的類來開始構(gòu)造系統(tǒng)，在獨立類測試完成后，進(jìn)行下一層繼承獨立類的類的測試，這個依賴類層次的測試序列一直循環(huán)執(zhí)行到構(gòu)造完整個系統(tǒng)為止。集成測試在面向?qū)ο笙到y(tǒng)中屬于應(yīng)用生命周期的一個階段，可在兩個層次上進(jìn)行：對一個新類進(jìn)行測試，并測試在定義中所涉及的那些類的集成。將各部件集合在一起組成完整的系統(tǒng)進(jìn)行測試。第四十四頁第四十五頁，共59頁。類與子類的測試假設(shè)類D是類C的子類，類C已進(jìn)行了充分的測試第四十五頁第四十六頁，共59頁。分層與增量

派生類D是C的子類，那么所有的用于C的基于規(guī)范的測試用例也都適用于D。術(shù)語“繼承的測試用例”來代表從父類測試用例中選取出來的、用于子類的測試用例?？梢酝ㄟ^增量變化分析來確定繼承的測試用例中哪些在測試子類時必須執(zhí)行、哪些可以不執(zhí)行。

合理的分析，有利于找出更有價值的測試用例。第四十六頁第四十七頁，共59頁。分層與增量

-測試用例選擇

D的接口中添加新的操作，并且有可能是D中的一個新方法實現(xiàn)的新操作。新操作引入了新的功能/代碼，這些都需要測試。在D中改變那些在C中聲明的操作規(guī)范，需要為操作添加新的基于規(guī)范的測試用例。附加的測試用例提供了符合其前置條件的新輸入，并且對由任何加強了的后置條件導(dǎo)致的新的期望結(jié)果進(jìn)行檢查。在D中覆蓋那些在C中實現(xiàn)了某個操作并且被D繼承了的方法，可以復(fù)用于該方法的所有繼承來的基于規(guī)范的測試用例。在D中添加新的實例變量來實現(xiàn)更多的狀態(tài)和/或?qū)傩?，最有可能與新的操作和/或重載方法中代碼有關(guān)，而且關(guān)系到對測試的處理。在D中改變類常量。類常量累計成每個測試用例的附加的后置條件。第四十七頁第四十八頁，共59頁。注：設(shè)計測試用例時，不但要設(shè)計確認(rèn)類功能滿足的輸入，還應(yīng)該有意識的設(shè)計一些被禁止的例子，確認(rèn)類是否有不合法的行為產(chǎn)生，如發(fā)送與類狀態(tài)不相適應(yīng)的消息，要求不相適應(yīng)的服務(wù)等。根據(jù)具體情況，動態(tài)的集成測試，有時也可以通過系統(tǒng)測試完成。第四十八頁第四十九頁，共59頁。八、面向?qū)ο蟮南到y(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)。第四十九頁第五十頁，共59頁。具體測試內(nèi)容包括：功能測試：測試是否滿足開發(fā)要求，是否能夠提供設(shè)計所描述的功能，是否用戶的需求都得到滿足。強度測試：測試系統(tǒng)的能力最高實際限度。性能測試：測試軟件的運行性能。安全測試：驗證安裝在系統(tǒng)內(nèi)的保護(hù)機構(gòu)確實能夠?qū)ο到y(tǒng)進(jìn)行保護(hù)，使之不受各種非常的干擾。容錯性測試可用性測試：安裝/卸載測試（install/uninstalltest）等等。第