【導(dǎo)讀】如圖顯示某程序的邏輯結(jié)構(gòu)。試為它設(shè)計足夠的。蓋和條件組合覆蓋。順序型－構(gòu)成串行操作；復(fù)型結(jié)構(gòu)用選擇結(jié)構(gòu)代替，只對循環(huán)體檢驗一次。這樣，任一循環(huán)便。改造成進入循環(huán)體或不進入循環(huán)體的分支操作了?？紤]選擇型結(jié)構(gòu)。當(dāng)程序中判定多于一個時，形成的分支。當(dāng)n較大時將無法測試。完成路經(jīng)測試的理想情況時做到路徑覆蓋；可用弧序列或節(jié)點序列表示某一條具體路?；和弧b相乘，表示為ab，它表明。弧b是先后相繼的。路徑是并行關(guān)系。對路徑表達式化簡。要求：最多輸入100個值（以-999為輸入結(jié)束標。下面的程序片斷為主程序調(diào)用的求平均值的函數(shù)。數(shù)，兩者都為全局變量。確定圈復(fù)雜性度量V；確定獨立路徑集；為每個獨立路徑的執(zhí)行，設(shè)計測試用。V=17（邊）-13（節(jié)點）+2=6. 節(jié)點10，條件total>0為false，即輸入的一。組數(shù)據(jù)中沒有一個是有效值。假如最大值為maximum，如100；可如下設(shè)計一組測試用例數(shù)據(jù)，如5個數(shù)，分別

　　

【正文】 示該窗口 。 ? 2)：在主界面載入完畢后自動卸出內(nèi)存 ， 讓出所占用的 WINDOWS系統(tǒng)資源 。 ? 3)：關(guān)閉所有窗體 ， 系統(tǒng)退出后要釋放所占的所有系統(tǒng)資源 ， 除非是需要后臺運行的系統(tǒng) 。 ? 4)：盡量防止對系統(tǒng)的獨占使用 。 167。 5 界面測試考慮 ? 5)：窗口能否基于相關(guān)的輸入或菜單命令適當(dāng)?shù)卮蜷_ ？ ? 6)：窗口能否改變大小 、 移動和滾動 ？ ? 7)：窗口中的數(shù)據(jù)內(nèi)容能否使用鼠標 、 功能鍵 、 方向箭頭和鍵盤訪問 ？ ? 8)：當(dāng)被覆蓋并重調(diào)用后 ， 窗口能否正確地再生 ？ ? 9)：需要時能否使用所有窗口相關(guān)的功能 ？ ? 10)：所有窗口相關(guān)的功能是可操作的嗎 ？ ? 11)：是否有相關(guān)的下拉式菜單 、 工具條 、 滾動條 、 對話框 、 按鈕 、 圖標和其他控制可為窗口可用 ， 并適當(dāng)?shù)仫@示 ？ 167。 5 界面測試考慮 ? 12)：顯示多個窗口時 ， 窗口的名稱是否被適當(dāng)?shù)乇硎?？ ? 13)：活動窗口是否被適當(dāng)?shù)丶恿?？ ? 14)：如果使用多任務(wù) ， 是否所有的窗口被實時更新 ？ ? 15)：多次或不正確按鼠標是否會導(dǎo)致無法預(yù)料的副作用 ？ ? 16)：窗口的聲音和顏色提示和窗口的操作順序是否符合需求 ？ ? 17)：窗口是否正確地關(guān)閉？ 167。 6 面向?qū)ο蟮能浖y試概述 ? 一度實踐證明行之有效的軟件測試對面向?qū)ο蠹夹g(shù)開發(fā)的軟件多少顯得有些力不從心。尤其是面向?qū)ο蠹夹g(shù)所獨有的多態(tài)，繼承，封裝等新特點，產(chǎn)生了傳統(tǒng)語言設(shè)計所不存在的錯誤可能性，或者使得傳統(tǒng)軟件測試中的重點不再顯得突出，或者使原來測試經(jīng)驗認為和實踐證明的次要方面成為了主要問題。 167。 6 面向?qū)ο蟮能浖y試概述 ? 面向?qū)ο蟪绦虻慕Y(jié)構(gòu)不再是傳統(tǒng)的功能模塊結(jié)構(gòu)，作為一個整體，原有集成測試所要求的逐步將開發(fā)的模塊搭建在一起進行測試的方法已成為不可能。而且，面向?qū)ο筌浖仐壛藗鹘y(tǒng)的開發(fā)模式，對每個開發(fā)階段都有不同以往的要求和結(jié)果 ,已經(jīng)不可能用功能細化的觀點來檢測面向?qū)ο蠓治龊驮O(shè)計的結(jié)果。因此，傳統(tǒng)的測試模型對面向?qū)ο筌浖呀?jīng)不再適用。針對面向?qū)ο筌浖拈_發(fā)特點，應(yīng)該有一種新的測試模型。 167。 6 面向?qū)ο蟮能浖y試概述 ? 一 、 面向?qū)ο鬁y試模型 (ObjectOrientTestModel) ? 面向?qū)ο蟮拈_發(fā)模型突破了傳統(tǒng)的瀑布模型，將開發(fā)分為面向?qū)ο蠓治觯?OOA），面向?qū)ο笤O(shè)計（ OOD），和面向?qū)ο缶幊蹋?OOP）三個階段。分析階段產(chǎn)生整個問題空間的抽象描述，在此基礎(chǔ)上，進一步歸納出適用于面向?qū)ο缶幊陶Z言的類和類結(jié)構(gòu)，最后形成代碼。 167。 6 面向?qū)ο蟮能浖y試概述 ? 對認定的對象的測試 ? 對認定的結(jié)構(gòu)的測試 ? （ 1）對認定的分類結(jié)構(gòu)的測試 ? （ 2）對認定的組裝結(jié)構(gòu)的測試 ? 對認定的主題的測試 ? 對定義的屬性和實例關(guān)聯(lián)的測試 ? 對定義的服務(wù)和消息關(guān)聯(lián)的測試 167。 6 面向?qū)ο蟮能浖y試概述 ? 二 、 面向?qū)ο笤O(shè)計的測試 (OODTest) ? 通常的結(jié)構(gòu)化的設(shè)計方法，用的 是面向作業(yè)的設(shè)計方法，它把系統(tǒng)分解以后，提出一組作業(yè)，這些作業(yè)是以過程實現(xiàn)系統(tǒng)的基礎(chǔ)構(gòu)造，把問題域的分析轉(zhuǎn)化為求解域的設(shè)計，分析的結(jié)果是設(shè)計階段的輸入 167。 6 面向?qū)ο蟮能浖y試概述 ? 而面向?qū)ο笤O(shè)計（ OOD）采用 “ 造型的觀點 ” ，以 OOA為基礎(chǔ)歸納出類，并建立類結(jié)構(gòu)或進一步構(gòu)造成類庫，實現(xiàn)分析結(jié)果對問題空間的抽象。OOD歸納的類，可以是對象簡單的延續(xù)，可以是不同對象的相同或相似的服務(wù)。 ? OOD不是在 OOA上的另一思維方式的大動干戈，而是 OOA的進一步細化和更高層的抽象。所以， OOD與 OOA的界限通常是難以嚴格區(qū)分的。 OOD確定類和類結(jié)構(gòu)不僅是滿足當(dāng)前需求分析的要求，更重要的是通過重新組合或加以適當(dāng)?shù)难a充，能方便實現(xiàn)功能的重用和擴增，以不斷適應(yīng)用戶的要求。 167。 6 面向?qū)ο蟮能浖y試概述 ? 對 OOD的測試 ， 建議針對功能的實現(xiàn)和重用以及對 OOA結(jié)果的拓展 ， 從如下三方面考慮： ? ☆對認定的類的測試 ☆對構(gòu)造的類層次結(jié)構(gòu)的測試 ☆對類庫的支持的測試 167。 6 面向?qū)ο蟮能浖y試概述 ? 三 、 面向?qū)ο缶幊痰臏y試 (OOPTest) ? 典型的面向?qū)ο蟪绦蚓哂欣^承、封裝和多態(tài)的新特性，這使得傳統(tǒng)的測試策略必須有所改變。 167。 6 面向?qū)ο蟮能浖y試概述 ? 面向?qū)ο蟪绦蚴前压δ艿膶崿F(xiàn)分布在類中 。能正確實現(xiàn)功能的類 ， 通過消息傳遞來協(xié)同實現(xiàn)設(shè)計要求的功能 。 正是這種面向?qū)ο蟪绦蝻L(fēng)格 ，將出現(xiàn)的錯誤能精確的確定在某一具體的類 。 因此 ， 在面向?qū)ο缶幊?（ OOP） 階段 ， 忽略類功能實現(xiàn)的細則 ， 將測試的目光集中在類功能的實現(xiàn)和相應(yīng)的面向?qū)ο蟪绦蝻L(fēng)格 ， 主要體現(xiàn)為以下兩個方面 （ 假設(shè)編程使用 C++語言 ） 。 ? ☆數(shù)據(jù)成員是否滿足數(shù)據(jù)封裝的要求 ☆類是否實現(xiàn)了要求的功能 167。 6 面向?qū)ο蟮能浖y試概述 ? 五 、 面向?qū)ο蟮膯卧獪y試 (OOUnitTest) ? 傳統(tǒng)的單元測試是針對程序的函數(shù)、過程或完成某一定功能的程序塊。沿用單元測試的概念，實際測試類成員函數(shù)。一些傳統(tǒng)的測試方法在面向?qū)ο蟮膯卧獪y試中都可以使用。如等價類劃分法，因果圖法，邊值分析法，邏輯覆蓋法，路徑分析法，程序插裝法等等，方法的具體實現(xiàn)參見。 167。 6 面向?qū)ο蟮能浖y試概述 ? 在設(shè)計測試用例選擇輸入數(shù)據(jù)時 ， 可以基于以下兩個假設(shè)： ? （ 程序 ） 對某一類輸入中的一個數(shù)據(jù)正確執(zhí)行 ， 對同類中的其他輸入也能正確執(zhí)行 。 該假設(shè)的思想可參見 [6]中介紹的等價類劃分 。 ? （程序）對某一復(fù)雜度的輸入正確執(zhí)行，對更高復(fù)雜度的輸入也能正確執(zhí)行。例如需要選擇字符串作為輸入時，基于本假設(shè)，就無須計較于字符串的長度。除非字符串的長度是要求固定的，如 IP地址字符串。 167。 6 面向?qū)ο蟮能浖y試概述 ? 五 、 面向?qū)ο蟮募蓽y試 (OOIntegrateTest) ? 傳統(tǒng)的集成測試，是由底向上通過集成完成的功能模塊進行測試，一般可以在部分程序編譯完成的情況下進行。而對于面向?qū)ο蟪绦?，相互調(diào)用的功能是散布在程序的不同類中，類通過消息相互作用申請和提供服務(wù)。類的行為與它的狀態(tài)密切相關(guān)，狀態(tài)不僅僅是體現(xiàn)在類數(shù)據(jù)成員的值，也許還包括其他類中的狀態(tài)信息。由此可見，類相互依賴極其緊密，根本無法在編譯不完全的程序上對類進行測試。所以，面向?qū)ο蟮募蓽y試通常需要在整個程序編譯完成后進行。此外，面向?qū)ο蟪绦蚓哂袆討B(tài)特性，程序的控制流往往無法確定，因此也只能對整個編譯后的程序做基于黑盒子的集成測試。 167。 6 面向?qū)ο蟮能浖y試概述 ? 面向?qū)ο蟮募蓽y試能夠檢測出相對獨立的單元測試無法檢測出的那些類相互作用時才會產(chǎn)生的錯誤 。 基于單元測試對成員函數(shù)行為正確性的保證 ， 集成測試只關(guān)注于系統(tǒng)的結(jié)構(gòu)和內(nèi)部的相互作用 。 面向?qū)ο蟮募蓽y試可以分成兩步進行：先進行靜態(tài)測試 ， 再進行動態(tài)測試 。 167。 6 面向?qū)ο蟮能浖y試概述 ? 靜態(tài)測試主要針對程序的結(jié)構(gòu)進行，檢測程序結(jié)構(gòu)是否符合設(shè)計要求?，F(xiàn)在流行的一些測試軟件都能提供一種稱為 可逆性工程 的功能，即通過原程序得到類關(guān)系圖和函數(shù)功能調(diào)用關(guān)系圖，例如 InternationalSoftwareAutomation公司的Panorama2forWindows9 Rational公司的RoseC++Analyzer等，將 可逆性工程 得到的結(jié)果與 OOD的結(jié)果相比較，檢測程序結(jié)構(gòu)和實現(xiàn)上是否有缺陷。換句話說，通過這種方法檢測 OOP是否達到了設(shè)計要求。 167。 6 面向?qū)ο蟮能浖y試概述 ? 動態(tài)測試設(shè)計測試用例時，通常需要上述的功能調(diào)用結(jié)構(gòu)圖、類關(guān)系圖或者實體關(guān)系圖為參考，確定不需要被重復(fù)測試的部分，從而優(yōu)化測試用例，減少測試工作量，使得進行的測試能夠達到一定覆蓋標準。測試所要達到的覆蓋標準可以是：達到類所有的服務(wù)要求或服務(wù)提供的一定覆蓋率；依據(jù)類間傳遞的消息，達到對所有執(zhí)行線程的一定覆蓋率；達到類的所有狀態(tài)的一定覆蓋率等。同時也可以考慮使用現(xiàn)有的一些測試工具來得到程序代碼執(zhí)行的覆蓋率。 167。 6 面向?qū)ο蟮能浖y試概述 ? 具體設(shè)計測試用例，可參考下列步驟： ，參考 OOD分析結(jié)果，仔細出類的狀態(tài)和相應(yīng)的行為，類或成員函數(shù)間傳遞的消息，輸入或輸出的界定等。 。 關(guān)聯(lián)。 ，確認使用什么輸入激發(fā)類的狀態(tài)、使用類的服務(wù)和期望產(chǎn)生什么行為等。 167。 6 面向?qū)ο蟮能浖y試概述 ? 六、面向?qū)ο蟮南到y(tǒng)測試 (OOSystemTest) ? 系統(tǒng)測試時，應(yīng)該參考 OOA分析的結(jié)果，對應(yīng)描述的對象、屬性和各種服務(wù)，檢測軟件是否能夠完全 “ 再現(xiàn) ” 問題空間。系統(tǒng)測試不僅是檢測軟件的整體行為表現(xiàn)，從另一個側(cè)面看，也是對軟件開發(fā)設(shè)計的再確認。 ? 系統(tǒng)測試應(yīng)該盡量搭建與用戶實際使用環(huán)境相同的測試平臺，應(yīng)該保證被測系統(tǒng)的完整性，對臨時沒有的系統(tǒng)設(shè)備部件，也應(yīng)有相應(yīng)的模擬手段。