《軟件工程與開發(fā)技術(shù)》課件第14章

第14章面向?qū)ο鬁y試基礎(chǔ)

14.1面向?qū)ο蟮膯卧獪y試14.2面向?qū)ο蟮募蓽y試14.3面向?qū)ο蟮拇_認(rèn)測試與系統(tǒng)測試14.4設(shè)計(jì)測試用例14.5小結(jié)

14.1面向?qū)ο蟮膯卧獪y試

在面向?qū)ο蟮能浖_發(fā)中，“封裝”導(dǎo)致了類和對象的定義特點(diǎn)，這意味著類和類的實(shí)例(對象)包裝了屬性(數(shù)據(jù))和處理這些數(shù)據(jù)的操作(也稱為方法或服務(wù))。軟件的核心是“對象”，不像傳統(tǒng)軟件開發(fā)中的“單元”(或者說單元的概念改變了)。也就是說，封裝起來的類和對象是最小的可測試單元。一個類可以包含一組不同的操作，而一個特定的操作也可能定義在一組不同的類中。因此，面向?qū)ο蟮能浖卧獪y試與傳統(tǒng)測試方法不一樣，它的含義發(fā)生了很大變化。面向?qū)ο筌浖膯卧獪y試不是獨(dú)立地測試單個操作，而是把所有操作都看成類的一部分，全面地測試類和對象所封裝的屬性和操縱這些屬性的操作整體。具體地說，在面向?qū)ο蟮膯卧獪y試中不僅要發(fā)現(xiàn)類的所有操作中存在的問題，還要考查一個類與其他的類協(xié)同工作時可能出現(xiàn)的錯誤?，F(xiàn)以實(shí)例說明：在一個類層次中，操作A在超類中定義并被一組子類繼承，每個子類都可使用操作A，但是A要調(diào)用子類中定義的操作并處理子類的私有屬性。由于在不同的子類中使用操作A的環(huán)境有所不同，因此有必要在每個子類的語境中測試操作A。這就是說，當(dāng)測試面向?qū)ο筌浖r，傳統(tǒng)的單元測試方法是不完備的，我們不能再獨(dú)立地對操作A進(jìn)行測試。 14.2面向?qū)ο蟮募蓽y試

1．基于線程的測試(Thread_basedTesting)

基于線程的測試把響應(yīng)系統(tǒng)的一個輸入或一個事件所需要的一組類集成起來進(jìn)行測試。應(yīng)當(dāng)分別集成并測試每個線程，同時為了避免產(chǎn)生副作用再進(jìn)行回歸測試。該測試需要基于系統(tǒng)的動態(tài)模型。

2．基于使用的測試(Use_basedTesting)

基于使用的測試首先測試幾乎不使用服務(wù)器類的那些類(稱為獨(dú)立類)；接著測試使用獨(dú)立類的最下層的類(稱為依賴類)；然后，對根據(jù)依賴類的使用關(guān)系，從下到上一個層次一個層次地持續(xù)進(jìn)行測試，直至把整個軟件系統(tǒng)測試完為止。

除了上述兩種測試方法，還有一種集群測試法，是面向?qū)ο筌浖蓽y試的一個步驟。為了檢查一群相互協(xié)作的類，用精心設(shè)計(jì)的測試用例，力圖發(fā)現(xiàn)協(xié)作錯誤，即集群測試。通過研究對象模型可以確定協(xié)作類。

為減少測試工作的工作量，在進(jìn)行集成測試時，可參考類關(guān)系圖或?qū)嶓w關(guān)系圖，確定不需要被重復(fù)測試的部分，從而優(yōu)化測試用例，使測試能夠達(dá)到一定的標(biāo)準(zhǔn)。14.3面向?qū)ο蟮拇_認(rèn)測試與系統(tǒng)測試

通過對軟件的單元測試和集成測試，僅能確認(rèn)軟件開發(fā)的功能是正確的，不能確認(rèn)在實(shí)際運(yùn)行時，它是否滿足用戶要求，是否大量存在與實(shí)際使用條件下的各種應(yīng)用相矛盾的錯誤。為此在完成上述測試活動后，還必須經(jīng)過規(guī)范的確認(rèn)測試和系統(tǒng)測試。

面向?qū)ο筌浖拇_認(rèn)測試或系統(tǒng)測試與傳統(tǒng)的確認(rèn)測試一樣，通過設(shè)計(jì)測試用例，主要檢查用戶界面和用戶可識別的輸出，不再考慮類之間相互連接的細(xì)節(jié)。測試人員應(yīng)該認(rèn)真研究動態(tài)模型和描述系統(tǒng)行為的腳本，為系統(tǒng)的輸入信息設(shè)計(jì)出錯處理的通路，模擬錯誤的數(shù)據(jù)和軟件界面可能發(fā)生的錯誤，設(shè)計(jì)出合理的測試用例。

14.4設(shè)計(jì)測試用例

14.4.1測試用例概述

類似于用例(UseCase)的定義，測試用例(TestCase)是為實(shí)現(xiàn)某個特殊目標(biāo)(驗(yàn)證或者找錯)而執(zhí)行系統(tǒng)的過程。它包括精心設(shè)計(jì)的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測試某個程序功能或者路徑是否滿足特定需求。

測試用例包括對特定的軟件產(chǎn)品進(jìn)行測試的任務(wù)描述，體現(xiàn)測試方案、方法、技術(shù)和策略，其內(nèi)容包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等，并形成文檔。測試用例是針對軟件產(chǎn)品的功能、業(yè)務(wù)規(guī)則和業(yè)務(wù)處理所設(shè)計(jì)的測試方案。對軟件的每個特定功能或運(yùn)行操作路徑的測試構(gòu)成了一個個測試用例。不同類別的軟件，測試用例的策略、方法和側(cè)重點(diǎn)都是不同的。例如，企業(yè)信息管理類軟件，其需求不確定或者變化較為頻繁，通常的策略是把測試數(shù)據(jù)和測試腳本從測試用例中劃分出來，以供重用。

目前，面向?qū)ο筌浖臏y試用例的設(shè)計(jì)方法還處于研究、發(fā)展階段。1993年，Berard提出了指導(dǎo)面向?qū)ο蟮能浖y試用例設(shè)計(jì)的方法，要點(diǎn)如下：

(1)每一個測試用例都要有一個唯一的標(biāo)識，并與被測試的一個或幾個類相關(guān)聯(lián)起來。

(2)每個測試用例都要陳述測試目的。

(3)對每個測試用例要有相應(yīng)的測試步驟，包括被測對象的特定狀態(tài)、所使用的消息和操作、可能產(chǎn)生的錯誤及測試需要的外部環(huán)境。

(4)與傳統(tǒng)軟件測試(測試用例的設(shè)計(jì)由軟件的輸入—處理—輸出或單個模塊的算法細(xì)節(jié)驅(qū)動)不同，面向?qū)ο鬁y試關(guān)注于設(shè)計(jì)適當(dāng)?shù)牟僮餍蛄幸詸z查類的狀態(tài)。測試用例分為基于黑盒的測試用例和基于白盒的測試用例。前者也叫做基于系統(tǒng)外部需求的測試用例，主要根據(jù)需求分析階段的用例規(guī)格描述和其他需求進(jìn)行設(shè)計(jì)，只觀察系統(tǒng)的外觀表現(xiàn)是否滿足預(yù)期要求；后者又稱為基于系統(tǒng)內(nèi)部結(jié)構(gòu)的測試用例，主要依據(jù)分析設(shè)計(jì)階段的邏輯和物理模型，如類圖和順序圖以及代碼設(shè)計(jì)測試用例，旨在測試軟件功能執(zhí)行過程中對象的交互過程，包括消息、響應(yīng)以及各個程序路徑等。14.4.2面向?qū)ο蟾拍顚y試用例設(shè)計(jì)的影響

封裝性和繼承性是類的重要特性，這為面向?qū)ο蟮能浖_發(fā)帶來很多好處，同時它又為面向?qū)ο蟮能浖y試帶來負(fù)面影響。

類的屬性和操作是被封裝的，而測試需要了解對象的詳細(xì)狀態(tài)。同時，當(dāng)改變數(shù)據(jù)成員的結(jié)構(gòu)時，要測試是否影響了類的對外接口，是否導(dǎo)致相應(yīng)的外界必須改動。例如，強(qiáng)制的類型轉(zhuǎn)換會破壞數(shù)據(jù)的封裝性。請看下面的這段程序：classHd{

inta=1;

char*h=“Hd”;}

classVb{

public:intb=2;

char*v="Vb";}

Hdp;

Vb*q=(Vb*)&p;

這樣，p的私有數(shù)據(jù)成員a可以通過q被隨意訪問，破壞了類Vb的封裝性。…此外，繼承不會減少對子類的測試，相反，會使測試過程更加復(fù)雜化。因此，繼承也給測試用例的設(shè)計(jì)帶來負(fù)面影響。當(dāng)父類與子類的環(huán)境不同時，父類的測試用例對子類沒有什么使用價值，必須為子類設(shè)計(jì)新的測試用例。

在設(shè)計(jì)面向?qū)ο蟮臏y試用例時應(yīng)注意以下三點(diǎn)：

(1)繼承的成員函數(shù)需要測試。對于在父類中已經(jīng)測試過的成員函數(shù)，根據(jù)具體情況仍需在子類中重新測試。一般在下述兩種情況下要對成員函數(shù)重新進(jìn)行測試：

①繼承的成員函數(shù)在子類中有所改動。

②成員函數(shù)調(diào)用了改動過的成員函數(shù)。

(2)子類的測試用例可以參照父類。例如，有兩個不同的成員函數(shù)的定義如下：

father::B()中定義為

if(value<0)message("less");

elseif(value==0)message("equal");

elsemessage("more");

son::B()中定義為

if(value<0)message("less");

elseif(value==0)message("Itisequal");

else{message("more");

if(value==99)message("Luck");}

在原有的測試上，對son::B()的測試只需做如下改動：將value=0的測試結(jié)果期望改動，并增加value==99這一條件的測試。

(3)設(shè)計(jì)測試用例時，不但要設(shè)計(jì)確認(rèn)類功能滿足的輸入，而且還應(yīng)有意識地設(shè)計(jì)一些被禁止的例子，確認(rèn)類是否有不合法的行為產(chǎn)生。14.4.3類測試用例設(shè)計(jì)

1．基于故障的測試用例設(shè)計(jì)

基于故障的測試(Fault_basedTesting)與傳統(tǒng)的錯誤推測法類似，通過對面向?qū)ο蠓治龌蛎嫦驅(qū)ο笤O(shè)計(jì)模型的分析，首先推測軟件中可能有的錯誤，然后設(shè)計(jì)出最可能發(fā)現(xiàn)這些錯誤的測試用例。例如，軟件工程師經(jīng)常在問題的邊界處犯錯誤，因此，在測試(計(jì)算平方根)操作(該操作在輸入為負(fù)數(shù)時返回出錯信息)時，應(yīng)該著重檢查邊界情況：一個接近零的負(fù)數(shù)和零本身。其中，“零本身”用于檢查程序員是否犯了如下錯誤：

(1)把語句if(x＞＝0)calculate=sqr(x)；誤寫成if(x＞0)calculate=sqr(x)；。

(2)程序中將if(strncmp(str1,str2,strlen(str1)))誤寫成if(strncmp(str1,str2,strlen(str2)))，那么如果在測試用例中使用的數(shù)據(jù)str1和str2長度相同，就無法檢測出錯誤。

為了推測出軟件中可能有的錯誤，測試人員應(yīng)該認(rèn)真研究分析模型和設(shè)計(jì)模型，還得依靠測試人員的經(jīng)驗(yàn)和直覺。如果推測得比較準(zhǔn)確，則使用基于故障的測試方法能夠用較少的工作量發(fā)現(xiàn)大量錯誤,否則不然。

2．基于用例的測試用例設(shè)計(jì)

基于故障的測試用例有一個很突出的缺點(diǎn)，當(dāng)功能描述是錯誤的或子系統(tǒng)間的交互存在錯誤時，基于故障的測試用例就無法發(fā)現(xiàn)錯誤。

基于用例的測試用例更關(guān)心的是用戶想做什么，而不是軟件想做什么。通過用例獲取用戶要完成的功能，并以此為依據(jù)設(shè)計(jì)所涉及的各個類的測試用例。更具體地說，先搞清楚用戶想實(shí)現(xiàn)哪些功能，然后去尋找完成這些功能，需要哪些類參與，從功能出發(fā)，對所確定的這些類及其子類分別設(shè)計(jì)類測試用例。用例實(shí)現(xiàn)涉及到的類在動態(tài)模型，尤其是順序圖或通信圖中可以得到充分的展現(xiàn)，因此基于用例的測試用例設(shè)計(jì)應(yīng)該好好地研究、分析和設(shè)計(jì)模型中的動態(tài)模型。14.4.4類間測試用例設(shè)計(jì)

1．多個類的劃分測試方法

多個類的劃分測試方法有三種，即基于狀態(tài)的劃分、基于屬性的劃分和基于功能的劃分。根據(jù)類操作改變類狀態(tài)的能力來劃分類操作，稱為基于狀態(tài)的劃分法；根據(jù)類操作使用的屬性來劃分類操作，稱為基于屬性的劃分法；根據(jù)類操作所完成的功能來劃分類操作，稱為基于功能的劃分法。另外，多類測試還應(yīng)該包括那些通過發(fā)送給協(xié)作類的消息而被調(diào)用的操作。根據(jù)與特定類的接口來劃分類操作也是一種可用的劃分測試方法。

2．從行為模型導(dǎo)出測試用例

動態(tài)行為模型由幾個狀態(tài)轉(zhuǎn)換圖組成的。根據(jù)類的狀態(tài)圖，可以設(shè)計(jì)出測試該類以及類間動態(tài)行為的測試用例。同時，為了保證該類的所有行為都能被測試，還可以利用狀態(tài)圖設(shè)計(jì)更多測試用例。14.4.5測試用例設(shè)計(jì)舉例

1．基于用例(UseCase)的測試用例設(shè)計(jì)

用于功能性測試的測試用例來源于測試目標(biāo)的用例。應(yīng)該為每個用例場景編制測試用例。用例場景要通過描述流經(jīng)用例的路徑來確定。這個流經(jīng)過程要從用例開始到結(jié)束，遍歷其中所有基本流和備選流。

例如，圖14.1中經(jīng)過用例的每條不同路徑反映了基本流和備選流，用箭頭來表示。基本流用黑直線來表示，是經(jīng)過用例的最簡單的路徑。每個備選流自基本流開始，之后，備選流會在某個特定條件下執(zhí)行。備選流可能會重新加入基本流中(備選流1和備選流3)，還可能起源于另一個備選流(備選流2)，或者終止用例而不再重新加入某個流(備選流2和備選流4)。圖14.1用例的執(zhí)行路徑(基本路徑和備選路徑)

根據(jù)上述每個場景可以生成測試用例，生成每個場景的測試用例是通過確定某個特定條件來完成的。這個特定條件將導(dǎo)致特定用例場景的執(zhí)行。例如，假定圖14.1描述的用例對備選流3規(guī)定為：“如果在上述步驟2[輸入提款金額]中輸入的金額超出當(dāng)前賬戶余額，則出現(xiàn)此事件流。系統(tǒng)將顯示一則警告消息，之后重新加入基本流，再次執(zhí)行上述步驟2

[輸入提款金額]，此時銀行客戶可以輸入新的提款金額?！睋?jù)此，可以開始確定需要用來執(zhí)行備選流3的測試用例，如表14.2所示。

2．基于白盒技術(shù)的單元測試的測試用例設(shè)計(jì)

從理論上來講，白盒測試應(yīng)該測試程序每一條可能的路徑。在所有簡單的單元內(nèi)實(shí)現(xiàn)這樣的目標(biāo)是不切實(shí)際的。作為最基本的測試，應(yīng)將每個決策(Decision)到?jīng)Q策路徑(DD路徑)測試至少一次，這樣可確保將所有語句至少執(zhí)行一次。決策通常是指if語句，而DD路徑是兩個決策之間的路徑。要達(dá)到這種程度的測試覆蓋，測試用例應(yīng)確保：

(1)每個if語言的布爾表達(dá)式的求值結(jié)果為true和false。例如，表達(dá)式(a<3)or(b>4)的求值結(jié)果為true/false的四種組合，即滿足條件覆蓋。

(2)每一個循環(huán)至少要執(zhí)行零次、一次和一次以上。

(3)可使用代碼覆蓋工具來確定白盒測試未測試到的代碼，另外在進(jìn)行白盒測試的同時應(yīng)進(jìn)行可靠性測試。

例如，假設(shè)對類SetofPrime中