第二章 軟件測試策略

第二章

軟件測試策略授課教師：

鄭煒第二章軟件測試策略2.1軟件開發(fā)過程及模型2.1.1軟件開發(fā)過程2.1.2軟件開發(fā)模型2.2軟件測試過程2.2.1測試計劃和控制2.2.2測試分析和設(shè)計2.2.3測試實現(xiàn)和執(zhí)行2.2.4測試出口準則的評估和報告2.2.5測試活動結(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ā)過程對于整個軟件工程來說是十分重要的，軟件測試也是基于軟件開發(fā)完成的。正規(guī)的軟件開發(fā)過程可以分為8個部分：

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

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

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

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

顯然，快速原型模型可以克服瀑布模型的缺點，減少由于軟件需求不明確帶來的開發(fā)風(fēng)險，具有顯著的效果?？焖僭湍Ｐ偷年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è)計、實現(xiàn)、集成和測試，每一個構(gòu)件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構(gòu)成的。增量模型在各個階段并不交付一個可運行的完整產(chǎn)品，而是交付滿足客戶需求的一個子集的可運行產(chǎn)品。整個產(chǎn)品被分解成若干個構(gòu)件，開發(fā)人員逐個構(gòu)件地交付產(chǎn)品，這樣做的好處是軟件開發(fā)可以較好地適應(yīng)變化，客戶可以不斷地看到所開發(fā)的軟件，從而降低開發(fā)風(fēng)險。2.1.2軟件開發(fā)模型（3）增量模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

V

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

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

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

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

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

H

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

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

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

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

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

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

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

這些測試模型中，V

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

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

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

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

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

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

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

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