第二章 軟件測試策略

第二章

軟件測試策略授課教師：

鄭煒第二章軟件測試策略2.1軟件開發(fā)過程及模型2.1.1軟件開發(fā)過程2.1.2軟件開發(fā)模型2.2軟件測試過程2.2.1測試計(jì)劃和控制2.2.2測試分析和設(shè)計(jì)2.2.3測試實(shí)現(xiàn)和執(zhí)行2.2.4測試出口準(zhǔn)則的評估和報(bào)告2.2.5測試活動(dòng)結(jié)束第二章軟件測試策略2.3軟件測試與軟件開發(fā)的關(guān)系2.3.1軟件測試在軟件開發(fā)中的作用2.3.2軟件測試與軟件開發(fā)各階段的關(guān)系2.3.3常見軟件測試模型2.4黑盒測試和白盒測試2.4.1黑盒測試2.4.2白盒測試2.4.3黑盒測試與白盒測試的比較2.1.1軟件開發(fā)過程軟件開發(fā)過程對于整個(gè)軟件工程來說是十分重要的，軟件測試也是基于軟件開發(fā)完成的。正規(guī)的軟件開發(fā)過程可以分為8個(gè)部分：

可行性研究、需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、實(shí)現(xiàn)、集成測試、確認(rèn)測試，以及使用與維護(hù)。2.1.2軟件開發(fā)模型（1）瀑布模型

1970年，溫斯頓·羅伊斯（WinstonRoyce）提出了著名的“瀑布模型”，直到20世紀(jì)80年代早期，它一直是唯一被廣泛采用的軟件開發(fā)模型。瀑布模型將軟件生命周期劃分為制訂計(jì)劃、需求分析、軟件設(shè)計(jì)、程序編寫、軟件測試和運(yùn)行維護(hù)6個(gè)基本活動(dòng)，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落，如圖2-1所示。2.1.2軟件開發(fā)模型（1）瀑布模型

瀑布模型強(qiáng)調(diào)文檔的作用，并要求每個(gè)階段都要仔細(xì)驗(yàn)證。但是，這種模型的線性過程太理想化，已不再適合現(xiàn)代的軟件開發(fā)模式，幾乎被業(yè)界拋棄。其主要問題有以下3個(gè)方面。①各個(gè)階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量。②由于開發(fā)模型是線性的，用戶只有等到整個(gè)過程的末期才能見到開發(fā)成果，從而增加了開發(fā)的風(fēng)險(xiǎn)。③早期的錯(cuò)誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn)，進(jìn)而帶來嚴(yán)重的后果。2.1.2軟件開發(fā)模型（2）快速原型模型

快速原型模型首先根據(jù)需求分析進(jìn)行原型開發(fā)，即建造一個(gè)快速原型，實(shí)現(xiàn)客戶或未來的用戶與系統(tǒng)的交互，然后用戶或客戶對原型進(jìn)行評價(jià)，進(jìn)一步細(xì)化待開發(fā)軟件的需求，如圖2-2所示。通過逐步調(diào)整原型使其滿足客戶的要求，開發(fā)人員最終確定客戶的真正需求是什么；最后在快速原型的基礎(chǔ)上開發(fā)客戶滿意的軟件產(chǎn)品。2.1.2軟件開發(fā)模型（2）快速原型模型

顯然，快速原型模型可以克服瀑布模型的缺點(diǎn)，減少由于軟件需求不明確帶來的開發(fā)風(fēng)險(xiǎn)，具有顯著的效果?？焖僭湍Ｐ偷年P(guān)鍵在于盡可能快速地建造出軟件原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，原型系統(tǒng)的內(nèi)部結(jié)構(gòu)并不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。2.1.2軟件開發(fā)模型（3）增量模型

增量模型又稱演化模型，如圖2-3所示。2.1.2軟件開發(fā)模型（3）增量模型

在增量模型中，軟件被作為一系列的增量構(gòu)件來設(shè)計(jì)、實(shí)現(xiàn)、集成和測試，每一個(gè)構(gòu)件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構(gòu)成的。增量模型在各個(gè)階段并不交付一個(gè)可運(yùn)行的完整產(chǎn)品，而是交付滿足客戶需求的一個(gè)子集的可運(yùn)行產(chǎn)品。整個(gè)產(chǎn)品被分解成若干個(gè)構(gòu)件，開發(fā)人員逐個(gè)構(gòu)件地交付產(chǎn)品，這樣做的好處是軟件開發(fā)可以較好地適應(yīng)變化，客戶可以不斷地看到所開發(fā)的軟件，從而降低開發(fā)風(fēng)險(xiǎn)。2.1.2軟件開發(fā)模型（3）增量模型

但是，增量模型也存在以下缺陷。①由于各個(gè)構(gòu)件是逐漸并入已有的軟件體系結(jié)構(gòu)中的，所以加入的構(gòu)件必須不破壞已構(gòu)造好的系統(tǒng)部分，這需要軟件具備開放式的體系結(jié)構(gòu)。②在開發(fā)過程中，需求的變化是不可避免的。增量模型適應(yīng)變化的能力大大優(yōu)于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性。在使用增量模型時(shí)，第1個(gè)增量往往是實(shí)現(xiàn)基本需求的核心產(chǎn)品。核心產(chǎn)品交付用戶使用后，經(jīng)過評價(jià)形成下一個(gè)增量的開發(fā)計(jì)劃，它包括對核心產(chǎn)品的修改和一些新功能的發(fā)布。這個(gè)過程在每個(gè)增量發(fā)布后不斷重復(fù)，直到產(chǎn)生最終的完善產(chǎn)品。2.1.2軟件開發(fā)模型（4）螺旋模型

1988年，巴利·玻姆（BarryBoehm）正式發(fā)表了軟件系統(tǒng)開發(fā)的“螺旋模型”，它將瀑布模型和快速原型模型結(jié)合起來，強(qiáng)調(diào)了其他模型所忽視的風(fēng)險(xiǎn)分析，特別適合于大型復(fù)雜的系統(tǒng)。螺旋模型沿著螺旋線進(jìn)行若干次迭代，圖2-4所示的螺旋模型的4個(gè)象限分別代表了制訂計(jì)劃、風(fēng)險(xiǎn)分析、實(shí)施工程和客戶評估4個(gè)活動(dòng)。

2.1.2軟件開發(fā)模型（4）螺旋模型

螺旋模型也有一定的限制條件，具體如下。①螺旋模型強(qiáng)調(diào)風(fēng)險(xiǎn)分析，但要求許多客戶接受和相信這種分析，并做出相關(guān)反應(yīng)是不容易的，因此，這種模型往往適應(yīng)于內(nèi)部的大規(guī)模軟件開發(fā)。②如果執(zhí)行風(fēng)險(xiǎn)分析會(huì)大大影響項(xiàng)目的利潤，那么進(jìn)行風(fēng)險(xiǎn)分析將毫無意義，因此，螺旋模型只適合于大規(guī)模軟件項(xiàng)目。③軟件開發(fā)人員應(yīng)該擅長尋找可能的風(fēng)險(xiǎn)，準(zhǔn)確地分析風(fēng)險(xiǎn)，否則將會(huì)帶來更大的風(fēng)險(xiǎn)。2.1.2軟件開發(fā)模型第二章軟件測試策略2.1軟件開發(fā)過程及模型2.2軟件測試過程2.2.1測試計(jì)劃和控制2.2.2測試分析和設(shè)計(jì)2.2.3測試實(shí)現(xiàn)和執(zhí)行2.2.4測試出口準(zhǔn)則的評估和報(bào)告2.2.5測試活動(dòng)結(jié)束2.2.1測試計(jì)劃和控制

測試作為貫穿整個(gè)軟件開發(fā)過程的活動(dòng)，需要有一份完善且周詳?shù)臏y試計(jì)劃作為指導(dǎo)。測試計(jì)劃是整個(gè)測試過程的路由圖，在需求活動(dòng)一開始時(shí)，相關(guān)人員就需要著手進(jìn)行測試計(jì)劃的編寫了。形成一份完整、詳細(xì)的測試文檔需經(jīng)過計(jì)劃、準(zhǔn)備、檢查、修改和繼續(xù)5個(gè)步驟。測試計(jì)劃主要的任務(wù)就是確定測試策略，它定義了項(xiàng)目的測試目標(biāo)和實(shí)現(xiàn)方法。2.2.1測試計(jì)劃和控制

測試強(qiáng)度很大程度上取決于使用哪種測試工具，需要達(dá)到哪一個(gè)級別的測試覆蓋率，涉及源代碼的測試覆蓋率常用作測試出口準(zhǔn)則之一。因?yàn)檐浖?xiàng)目經(jīng)常是在苛刻的時(shí)間壓力下完成的，所以需要在計(jì)劃過程中考慮這個(gè)問題，合理分配時(shí)間，保證軟件的最重要部分優(yōu)先級最高，最先被測試，以免由于時(shí)間上的限制而無法執(zhí)行已經(jīng)計(jì)劃好的測試。

測試計(jì)劃完成后，測試過程就進(jìn)入了測試用例的設(shè)計(jì)和測試腳本的開發(fā)階段。測試用例的規(guī)格說明分為兩步進(jìn)行：首先要定義邏輯測試用例，然后選擇實(shí)際輸入，將邏輯測試用例轉(zhuǎn)換成具體測試用例。2.2.2測試分析和設(shè)計(jì)測試用例設(shè)計(jì)的方法和管理

每個(gè)測試用例都必須描述其初始狀況，即前置條件：測試用例要清楚定義需要什么樣的環(huán)境條件，以及必須滿足的其他條件，此外，還需要提前定義期望得到哪些結(jié)果和行為。結(jié)果包括輸出、全局化數(shù)據(jù)和狀態(tài)的變更，以及執(zhí)行測試用例后的其他任何結(jié)果。而常見的編寫測試用例的方法有等價(jià)類劃分、邊界值分析、因果圖、錯(cuò)誤推測法、狀態(tài)遷移圖、流程分析法、正交驗(yàn)證法等。2.2.2測試分析和設(shè)計(jì)測試腳本的開發(fā)

要進(jìn)行測試腳本的開發(fā)，首先需要設(shè)立測試腳本的開發(fā)環(huán)境，安裝測試工具，設(shè)置管理服務(wù)器和具有代理的客戶端，建立項(xiàng)目的共享路徑和目錄，并能連接到腳本存儲(chǔ)庫和被測軟件等。然后執(zhí)行錄制測試的初始化過程、獨(dú)立模塊過程、導(dǎo)航過程和其他操作過程，結(jié)合已經(jīng)建立的測試用例，將錄制的測試腳本進(jìn)行組織、調(diào)試和修改，構(gòu)造成一個(gè)有效的測試腳本體系，并建立外部數(shù)據(jù)集合。但測試腳本的開發(fā)也存在一些常見的問題，如測試腳本很亂、測試腳本與測試需求或測試策略沒有對應(yīng)性、測試腳本不可重用、測試過程被作為一個(gè)編程任務(wù)來執(zhí)行導(dǎo)致腳本可移植性差等。這些問題應(yīng)該盡量避免，設(shè)計(jì)好腳本的結(jié)構(gòu)、模塊化、參數(shù)傳遞、基礎(chǔ)函數(shù)等方面。2.2.3測試實(shí)現(xiàn)和執(zhí)行

測試用例的設(shè)計(jì)和測試腳本的開發(fā)完成之后，就可以開始執(zhí)行測試了。測試的執(zhí)行有手工測試和自動(dòng)化測試兩種。

手工測試是在合適的環(huán)境下，按照測試用例的條件、步驟要求，準(zhǔn)備測試數(shù)據(jù)，對系統(tǒng)進(jìn)行操作，比較實(shí)際結(jié)果和測試用例所描述的期望結(jié)果，以確定系統(tǒng)是否正常運(yùn)行；而自動(dòng)化測試是使用測試工具運(yùn)行測試腳本，從而得到測試結(jié)果。自動(dòng)化測試的管理相對比較容易，測試工具會(huì)完整執(zhí)行測試腳本，而且可以自動(dòng)記錄測試結(jié)果。2.2.4測試出口準(zhǔn)則的評估和報(bào)告判斷測試終結(jié)

測試出口準(zhǔn)則的評估是檢驗(yàn)測試對象是否符合預(yù)先定義的一組測試目標(biāo)和出口準(zhǔn)則的活動(dòng)。測試出口準(zhǔn)則的評估可能產(chǎn)生下列結(jié)果：測試結(jié)果滿足所有出口準(zhǔn)則，可以正常結(jié)束測試；要求執(zhí)行一些附加測試用例；測試出口準(zhǔn)則要求過高，需要對測試出口準(zhǔn)則進(jìn)行修改。

2.2.4測試出口準(zhǔn)則的評估和報(bào)告判斷測試終結(jié)執(zhí)行完所有測試用例后再對比測試出口準(zhǔn)則，如果發(fā)現(xiàn)還有一個(gè)，甚至多個(gè)條件沒有被滿足，那么就需要執(zhí)行進(jìn)一步的測試，或是思考測試出口準(zhǔn)則是否合理、是否需要修改。此時(shí)如果測試人員要增加新的測試用例，需要考慮新加的測試用例是否符合測試用例準(zhǔn)則；否則，額外的測試用例只會(huì)增加工作量，對測試沒有起到任何幫助。測試過程中，有時(shí)可能會(huì)出現(xiàn)測試對象本身問題導(dǎo)致定義的測試出口準(zhǔn)則無法滿足的情況。2.2.4測試出口準(zhǔn)則的評估和報(bào)告測試終結(jié)的其他標(biāo)準(zhǔn)

除測試覆蓋率以外，測試出口準(zhǔn)則還可以包括其他條目，例如，失效發(fā)現(xiàn)率，也叫軟件缺陷發(fā)現(xiàn)百分比。它是由單位時(shí)間內(nèi)新發(fā)現(xiàn)的失效個(gè)數(shù)的平均值計(jì)算來的。如果失效發(fā)現(xiàn)率降低到設(shè)定的閾值以下，就表明不再需要更多的測試，測試工作可以結(jié)束了。根據(jù)失效發(fā)現(xiàn)率評估測試出口準(zhǔn)則時(shí)還應(yīng)考慮失效的嚴(yán)重程度，對失效進(jìn)行分類并區(qū)別對待。測試開銷

在實(shí)際測試過程中，能夠結(jié)束測試還要考慮時(shí)間與成本方面的因素。如果測試人員由于這些因素不得不停止測試工作，很可能是在資源分配階段中沒有做好相應(yīng)的工作，或者對測試某個(gè)活動(dòng)的工作量做出了一個(gè)誤判，導(dǎo)致后期的時(shí)間或成本短缺。2.2.5測試活動(dòng)結(jié)束

測試的全部完成，并不意味著測試過程的結(jié)束。在測試過程的最后，有可能會(huì)遺漏一些應(yīng)當(dāng)被完成的活動(dòng)。例如，測試人員在測試的最后應(yīng)該分析并且整理在測試工作中積累的經(jīng)驗(yàn)，以便在以后的項(xiàng)目中使用。測試人員測試時(shí)還應(yīng)注意在不同活動(dòng)中觀察到的計(jì)劃和執(zhí)行的背離以及可能引起這些背離的原因。在測試的最后階段，測試人員需要編寫測試或質(zhì)量報(bào)告，還需要記錄項(xiàng)目的一些重要信息。例如，一些應(yīng)該記錄的信息有：軟件系統(tǒng)是何時(shí)發(fā)布的、測試工作是何時(shí)完成或者結(jié)束的、軟件何時(shí)抵達(dá)一個(gè)里程碑或者完成一個(gè)版本的維護(hù)更新等。此外，除測試報(bào)告或質(zhì)量報(bào)告的寫作之外，還要對測試計(jì)劃、測試設(shè)計(jì)和測試執(zhí)行等進(jìn)行檢查分析，完成項(xiàng)目總結(jié)并編寫項(xiàng)目總結(jié)報(bào)告。第二章軟件測試策略2.1軟件開發(fā)過程及模型2.2軟件測試過程2.3軟件測試與軟件開發(fā)的關(guān)系2.3.1軟件測試在軟件開發(fā)中的作用2.3.2軟件測試與軟件開發(fā)各階段的關(guān)系2.3.3常見軟件測試模型2.3.1軟件測試在軟件開發(fā)中的作用項(xiàng)目規(guī)劃階段：負(fù)責(zé)監(jiān)控整個(gè)測試過程。需求分析階段：確定測試需求分析，即確定在項(xiàng)目中需要測試什么，同時(shí)制訂系統(tǒng)測試計(jì)劃。概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)階段：制訂集成測試計(jì)劃和單元測試計(jì)劃。程序編寫階段：開發(fā)相應(yīng)的測試代碼和測試腳本。測試階段：實(shí)施測試，并提交相應(yīng)的測試報(bào)告。測試在開發(fā)各階段的作用如下：2.3.2軟件測試與軟件開發(fā)各階段的關(guān)系軟件測試與軟件開發(fā)各階段的關(guān)系如圖2-6所示。2.3.3常見軟件測試模型V模型

V模型是軟件開發(fā)瀑布模型的變種，主要反映了測試活動(dòng)分析與設(shè)計(jì)的關(guān)系，如圖2-7所示。2.3.3常見軟件測試模型V模型

V模型描述了基本的開發(fā)過程和測試行為。它不僅包含保證源代碼正確性的低層測試，而且包含滿足用戶系統(tǒng)要求的高層測試。圖2-7箭頭方向?yàn)闀r(shí)間方向，從左至右分別是開發(fā)的各階段與測試的各階段。V

模型非常明確地標(biāo)注了測試過程中存在的不同級別，并使測試的每個(gè)階段都與開發(fā)的階段相對應(yīng)。但

V

模型也存在著一定的局限，它不能發(fā)現(xiàn)需求分析等前期階段產(chǎn)生的錯(cuò)誤，直到編碼完成之后才進(jìn)行測試，因此早期出現(xiàn)的錯(cuò)誤不能及時(shí)暴露。此外，V

模型只是對程序進(jìn)行測試，早期的需求、設(shè)計(jì)環(huán)節(jié)并沒有涵蓋其中，也為后來的測試埋下了隱患。2.3.3常見軟件測試模型W模型

W模型如圖2-8所示2.3.3常見軟件測試模型W模型

W模型是由V模型自然演化發(fā)展而來的，它強(qiáng)調(diào)了測試應(yīng)貫通于整個(gè)開發(fā)過程，而且測試的對象還包括了需求、功能與設(shè)計(jì)等。在W模型中，可以認(rèn)為測試與開發(fā)是同步進(jìn)行的，這樣可以使開發(fā)過程中的問題及早地暴露出來。同時(shí)W模型強(qiáng)調(diào)了測試計(jì)劃等工作的先行和對系統(tǒng)需求、系統(tǒng)設(shè)計(jì)的測試。

但W模型仍存在著較為明顯的問題，因?yàn)樗鼘㈤_發(fā)活動(dòng)認(rèn)定為從需求開始到編碼結(jié)束的串行活動(dòng)，只有在上一活動(dòng)結(jié)束后才能開始下一步的行動(dòng)，無法支持需要迭代、自發(fā)性以及變更調(diào)整的項(xiàng)目。2.3.3常見軟件測試模型H模型

H

模型將測試活動(dòng)從開發(fā)流程中完全獨(dú)立出來了，清晰地表現(xiàn)了測試準(zhǔn)備活動(dòng)與測試執(zhí)行活動(dòng)，如圖2-9所示；測試流程僅演示了整個(gè)生產(chǎn)周期中某個(gè)層次上的一次測試“微循環(huán)”，而圖2-9中的其他流程可以是任意開發(fā)流程。一旦測試條件成熟，準(zhǔn)備活動(dòng)完成后，就可以執(zhí)行測試活動(dòng)了。2.3.3常見軟件測試模型H模型

H模型強(qiáng)調(diào)軟件測試是一個(gè)獨(dú)立的流程，它需要“盡早準(zhǔn)備，盡早執(zhí)行”。軟件測試貫穿于產(chǎn)品的整個(gè)生命周期，可以與其他流程并發(fā)進(jìn)行。但是H模型的缺點(diǎn)在于它太過于抽象化，測試人員應(yīng)該重點(diǎn)理解其中的意義，并以此來指導(dǎo)實(shí)際測試工作，而模型本身并無太多可執(zhí)行的意義。2.3.3常見軟件測試模型X模型

X模型如圖2-10所示2.3.3常見軟件測試模型X模型

X模型左邊描述的是針對單獨(dú)程序片段所進(jìn)行的相互分離的編碼和測試，如圖2-10左邊所示，然后頻繁地交接，再通過集成最終合成為可執(zhí)行的程序，如圖2-10右上方所示，而且可執(zhí)行程序還需要進(jìn)行測試，已經(jīng)通過集成測試的成品可以進(jìn)行封版并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。同時(shí)，X模型還定位了探索性測試，如圖2-10右下方所示，這是不進(jìn)行實(shí)現(xiàn)計(jì)劃的特殊類型測試，例如，“我就這么測一下，結(jié)果會(huì)怎么樣”。

作為探索性測試，X模型能夠幫助有經(jīng)驗(yàn)的測試人員在測試計(jì)劃之外發(fā)現(xiàn)更多的軟件錯(cuò)誤，但也存在一定的弊端：它有可能對測試造成人力、物力和財(cái)力的浪費(fèi)，同時(shí)也對測試人員的熟練程度要求比較高。2.3.3常見軟件測試模型前置測試模型

前置測試模型將開發(fā)和測試的聲明周期整合在一起，如圖2-11所示。2.3.3常見軟件測試模型前置測試模型

前置測試模型表示了項(xiàng)目聲明周期從開始到結(jié)束之間的關(guān)鍵行為。它對每個(gè)交付內(nèi)容進(jìn)行測試（圖2-11中的橢圓框表示了其他一些要測試的對象），在設(shè)計(jì)階段制訂測試計(jì)劃和進(jìn)行測試設(shè)計(jì)，讓驗(yàn)收測試和技術(shù)測試保持相互獨(dú)立。總之，它是一個(gè)將測試和開發(fā)緊密結(jié)合的模型。前置測試模型能給開發(fā)人員、測試人員、項(xiàng)目經(jīng)理和用戶等帶來很多不同于傳統(tǒng)方法的內(nèi)在的價(jià)值。與以前的測試模型中很少劃分優(yōu)先級所不同的是，前置測試模型用較低的成本及早發(fā)現(xiàn)錯(cuò)誤，并且充分強(qiáng)調(diào)了測試對確保系統(tǒng)的高質(zhì)量的重要意義。它不僅能節(jié)省時(shí)間，而且能減少那些令開發(fā)人員十分厭惡的重復(fù)工作。2.3.3常見軟件測試模型

這些測試模型中，V

模型強(qiáng)調(diào)了在整個(gè)軟件項(xiàng)目開發(fā)中需要經(jīng)歷的若干個(gè)測試級別，但是它沒有明確指出應(yīng)該對軟件的需求、設(shè)計(jì)進(jìn)行測試。在這一點(diǎn)上，W模型給出了補(bǔ)充，但是與V模型一樣沒有專門針對測試進(jìn)行流程說明。隨著軟件測試的不斷發(fā)展，第三方測試已經(jīng)獨(dú)立出來的時(shí)候，H

模型就得到了相應(yīng)的體現(xiàn)，它表現(xiàn)為測試獨(dú)立。X

模型和前置測試模型又在此基礎(chǔ)上增加了許多不確定因素的處理情況，這就對應(yīng)了在實(shí)際的項(xiàng)目中經(jīng)常發(fā)生變更的情況。

在實(shí)際的項(xiàng)目中，要合理應(yīng)用這些測試模型的優(yōu)點(diǎn)。例如，在W模型下，合理運(yùn)用H模型的思想進(jìn)行獨(dú)立的測試，或者在前置測試模型中，參考X模型的一個(gè)程序片段也需要相關(guān)的集成測試的理論等，將測試與開發(fā)緊密結(jié)合，尋找最適合的測試方案。第二章軟件測試策略2.1軟件開發(fā)過程及模型2.2軟件測試過程2.3軟件測試與軟件開發(fā)的關(guān)系2.4黑盒測試和白盒測試2.4.1黑盒測試2.4.2白盒測試2.4.3黑盒測試與白盒測試的比較2.4.1黑盒測試黑盒測試黑盒測試也稱功能測試，通過測試來檢測每個(gè)功能是否能夠正常使用。在測試中，把程序看作一個(gè)不能打開的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下對程序進(jìn)行測試。它只檢查程序功能是否能按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮茌斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。2.4.1黑盒測試黑盒測試有兩個(gè)重要的優(yōu)點(diǎn)黑盒測試與軟件的具體實(shí)現(xiàn)方式無關(guān)，因此軟件實(shí)現(xiàn)方式如果發(fā)生了變更、修改但功能測試不變，仍可以使用原來的測試用例。在進(jìn)行軟件開發(fā)的同時(shí)，也可以進(jìn)行軟件黑盒測試用例的設(shè)計(jì)，這樣可以節(jié)省一部分時(shí)間成本，減少總開發(fā)時(shí)間。常見的黑盒測試方法有等價(jià)類劃分、邊界值設(shè)計(jì)、因果圖分析和正交試驗(yàn)法等2.4.1黑盒測試黑盒測試的常用工具QACenterQACenter主要包括功能測試工具QARun、性能測試工具QALoad、應(yīng)用可用性管理工具EcoTools和應(yīng)用性能優(yōu)化工具EcoScope。WinRunnerWinRunner

是一種企業(yè)級的功能測試工具能夠有效地幫助測試人員對復(fù)雜的企業(yè)級應(yīng)用的不同發(fā)布版本進(jìn)行測試，提高測試人員的工作效率和質(zhì)量，確?？缙脚_的、復(fù)雜的企業(yè)級應(yīng)用無故障發(fā)布及長期穩(wěn)定運(yùn)行。WinRunner

具有以下幾個(gè)顯著的功能：創(chuàng)建測試、插入檢查點(diǎn)、檢驗(yàn)數(shù)據(jù)、增強(qiáng)測試、運(yùn)行測試、分析結(jié)果與維護(hù)測試。2.4.2白盒測試白盒測試白盒測試又稱結(jié)構(gòu)測試、透明盒測試、邏輯驅(qū)動(dòng)測試或基于代碼的測試。白盒測試是一種測試用例設(shè)計(jì)方法，盒子指的是被測試的軟件。對于白盒測試來說，“盒子”是可視的，測試人員可以看到盒子內(nèi)部的東西并且了解程序的運(yùn)作過程。白盒測試需全面了解程序內(nèi)部邏輯結(jié)構(gòu)，對所有邏輯路徑進(jìn)行測試。白盒測試是窮舉路徑測試，測試人員必須了解程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯出手，從而得出測試數(shù)據(jù)。2.4.2白盒測試在白盒測試的使用流程中，必須遵從以下規(guī)則一個(gè)模塊中的所有獨(dú)立路徑都需至少得到一次測試。所有邏輯值的真與假情況都需要被測試到。為了保證程序結(jié)構(gòu)的有效性，需要檢查程序的內(nèi)部邏輯結(jié)構(gòu)。在程序的上、下邊界與可操作范圍內(nèi)都能保證循環(huán)的順利運(yùn)行。2.4.2白盒測試

白盒測試的工具JtestJtest是一個(gè)代碼分析和動(dòng)態(tài)類、組件測試工具，是一個(gè)集成的、易于使用和自動(dòng)化的Java單元測試工具。它可以增強(qiáng)代碼的穩(wěn)定性，防止軟件錯(cuò)誤。JcontractJcontract用于系統(tǒng)級驗(yàn)證或測試部件是否正確工作并被正確使用。Jcontract是一個(gè)獨(dú)立工具，在功能上是Jtest的補(bǔ)充。可以用Jcontract插裝按DbC（DesignbyContract）注解的Java代碼。當(dāng)將類或部件組裝成系統(tǒng)時(shí)，Jcontract在運(yùn)行時(shí)監(jiān)視并報(bào)告錯(cuò)用和功能性問題。Jcontract可幫助開發(fā)人員有效地考核類或部件的系統(tǒng)級行為。2.4.2白盒測試白盒測試的工具C++TestC++Test

可以幫助開發(fā)人員防止軟件錯(cuò)誤，保證代碼的健全性、可靠性、可維護(hù)性和可移