軟件測試系列培訓(xùn)之單元測試+1

1、軟件測試系列培訓(xùn)一單元測試 劉東升 2007-04浙 江 XXXX集 成 控 制 股 份 有 限 公 司現(xiàn)象投入太多的精力，找 bug，而新的代碼仍然會出現(xiàn)類似 bug； 寫完代碼，心里沒底，是否有大量 bug 等待自己； 新修改的代碼不知道是否影響其他局部代碼； 由于牽扯太多，導(dǎo)致不敢進(jìn)行修改代碼；. 主要內(nèi)容軟件測試根本理論單元測試根本理論為什么要進(jìn)行單元測試 C/C+單元測試問答 單元測試工具如何實施單元測試討論一、軟件測試根本理論目的：對軟件測試有個整體認(rèn)識軟件測試軟件測試分類軟件開發(fā)全過程檢測及測試自動化 V模型與X模型 TDD Test-Driven Development什么是軟

2、件測試？ 在軟件投入運(yùn)行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。軟件測試的概念： 軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程?；蛘哒f，軟件測試是根據(jù)軟件開發(fā)各個階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計一批測試用例即輸入數(shù)據(jù)及其預(yù)期結(jié)果，并利用這些測試用例去執(zhí)行程序，以發(fā)現(xiàn)程序錯誤的過程。 測試的目的測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤； 一個好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤； 一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試也可以這樣說，測試的目標(biāo)是以較少的用例、時間和人力找出軟件中潛在的各種錯誤和缺陷，以確保系統(tǒng)的質(zhì)量一個被人忽略的軟件測試目的是：測試可以

3、幫助發(fā)現(xiàn)當(dāng)前開發(fā)工作所采用的軟件過程也是一個“軟件的缺陷，以便進(jìn)行改進(jìn)。首先，測試并不僅僅是為了要找出錯誤。分析錯誤產(chǎn)生的原因和錯誤在開發(fā)的哪一個階段產(chǎn)生，具有非常重要的意義。 通過分析錯誤產(chǎn)生于哪一個開發(fā)階段、而又在哪一個階段被發(fā)現(xiàn)，我們可以判斷從錯誤的產(chǎn)生到錯誤的發(fā)現(xiàn)，跨越了多少個開發(fā)階段。軟件開發(fā)的一條重要原那么是盡早發(fā)現(xiàn)與修正錯誤。正確分析與利用測試的結(jié)果，我們可以非常有效地進(jìn)行軟件過程改進(jìn)軟件測試原那么 2-1完全測試程序是不可能的 輸入量太大 輸出結(jié)果太多 軟件實現(xiàn)途徑太多 軟件說明書沒有客觀標(biāo)準(zhǔn)。從不同角度看，軟件缺陷的標(biāo)準(zhǔn)不同。軟件測試原那么 2-2 軟件測試是有風(fēng)險的行為 測

4、試無法顯示潛伏的軟件缺陷找到的軟件缺陷越多，就說明軟件缺陷越多 并非所有軟件缺陷都能修復(fù)軟件測試一項講究條理的技術(shù)專業(yè) 軟件測試分類從是否需要執(zhí)行被測軟件的角度，可分為：靜態(tài)測試動態(tài)測試從測試是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實現(xiàn)算法的角度來看，可分為 ：白盒測試黑盒測試軟件測試方法靜態(tài)和動態(tài)靜態(tài)檢查確保系統(tǒng)按照組織的標(biāo)準(zhǔn)和過程運(yùn)行，主要依賴于評審和非運(yùn)行的手段來檢查。通常包括需求評審、設(shè)計評審、代碼走查和代碼檢查。動態(tài)檢查在生命周期中進(jìn)行測試運(yùn)行。通常包括單元測試、集成測試、系統(tǒng)測試、用戶的驗收測試。 靜態(tài)測試審查 (Inspection) 軟件的一種根本測試方法，它以一系列典型問題為依據(jù)進(jìn)行檢測

5、。走查 (Walkthrough) 一對一的審查，比審查更加仔細(xì)?；貞?Review) 以發(fā)現(xiàn)軟件中存在的錯誤和缺陷為目的的一種軟件測試方法，它是在軟件證實執(zhí)行之前完成。靜態(tài)和動態(tài)測試進(jìn)行結(jié)構(gòu)和功能測試測試階段執(zhí)行人靜態(tài)校驗動態(tài)校驗可行性評審開發(fā)人員，用戶需求評審開發(fā)人員，用戶設(shè)計評審開發(fā)人員單元測試開發(fā)人員集成測試開發(fā)人員，用戶系統(tǒng)測試開發(fā)人員在用戶的協(xié)助下完成驗收測試用戶測試技術(shù)黑盒測試黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試，它是在產(chǎn)品所應(yīng)具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能翻開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者在程序接口進(jìn)

6、行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息如數(shù)據(jù)庫或文件的完整性。 “黑盒測試著眼于程序外部結(jié)構(gòu)、不考慮內(nèi)部邏輯結(jié)構(gòu)、針對軟件界面和軟件功能進(jìn)行測試?！昂诤蟹ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進(jìn)行測試。 它不僅應(yīng)用于開發(fā)階段的測試，更重要的是在產(chǎn)品測試階段及維護(hù)階段必不可少。主要用于軟件確認(rèn)測試。 黑盒測試方法主要有：等價類劃分 邊值分析因果圖錯誤推測 白盒測試白

7、盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能。使用被測單元內(nèi)部如何工作的信息，允許測試人員對程序內(nèi)部邏輯結(jié)構(gòu)及有關(guān)信息來設(shè)計和選擇測試用例，對程序的邏輯路徑進(jìn)行測試?；谝粋€應(yīng)用代碼的內(nèi)部邏輯知識，測試是基于覆蓋全部代碼、分支、路徑、條件。 白盒測試的主要方法邏輯驅(qū)動測試根本路徑測試 主要用于軟件驗證。 使用程序設(shè)計的控制結(jié)構(gòu)導(dǎo)出測試用例。 邏輯驅(qū)動測試：主要是測試覆蓋率，以程序內(nèi)在邏輯結(jié)構(gòu)為根底的測試。包括以下6種類型：語句

8、覆蓋判斷覆蓋條件覆蓋判定-條件覆蓋條件組合覆蓋路徑測試白盒測試的主要目的保證一個模塊中的所有獨立路徑至少被執(zhí)行一次；對所有的邏輯值均需要測試真、假兩個分支；在上下邊界及可操作范圍內(nèi)運(yùn)行所有循環(huán)；檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性。概念語句覆蓋：語句覆蓋就是設(shè)計假設(shè)干個測試用例，運(yùn)行被測試程序，使得每一條可執(zhí)行語句至少執(zhí)行一次；判定覆蓋也稱為分支覆蓋：設(shè)計假設(shè)干個測試用例，運(yùn)行所測程序，使程序中每個判斷的取真分支和取假分支至少執(zhí)行一次；條件覆蓋：設(shè)計足夠多的測試用例，運(yùn)行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執(zhí)行一次；判定-條件覆蓋：設(shè)計足夠多的測試用例，運(yùn)行所測程序，使程序中每個判

9、斷的每個條件的所有可能取值至少執(zhí)行一次，并且每個可能的判斷結(jié)果也至少執(zhí)行一次，換句話說，即是要求各個判斷的所有可能的條件取值組合至少執(zhí)行一次；條件組合測試：設(shè)計足夠多的測試用例，運(yùn)行所測程序，使程序中每個判斷的所有可能的條件取值組合至少執(zhí)行一次；路徑測試：設(shè)計足夠多的測試用例，運(yùn)行所測程序，要覆蓋程序中所有可能的路徑。 軟件開發(fā)全過程檢測及測試自動化單元測試unit test 由編程的開發(fā)人員自行方案與完成的，針對單個或相關(guān)聯(lián)的一組程序單元的測試。 組裝測試inegration test 方案于設(shè)計階段，由開發(fā)人員與測試人員合作完成的，針對結(jié)合起來的不同單元以及它們的接口的測試。系統(tǒng)測試sys

10、tem test ：可認(rèn)為包括“可用性與圖形用戶界面測試 測試整個系統(tǒng)，以證實它滿足要求所規(guī)定的功能、質(zhì)量和性能等方面的特性。 回歸測試regression test ： 用于驗證改變了的系統(tǒng)或其組件仍然保持應(yīng)有的特性。 驗收測試acceptance test ： 測試整個系統(tǒng)，以保證其到達(dá)可以交付使用的狀態(tài)。 V模型V模型單元測試、集成測試、系統(tǒng)測試、驗收測試。是“從小到大、“由內(nèi)至外、“循序漸進(jìn)的測試過程，表達(dá)了“分而治之的思想。 單元測試的粒度最小，一般由開發(fā)小組采用白盒方式來測試，主要測試單元是否符合“設(shè)計。 集成測試界于單元測試和系統(tǒng)測試之間，起到“橋梁作用，一般由開發(fā)小組采用白盒加

11、黑盒的方式來測試，既要驗證“設(shè)計又要驗證“需求。 V模型系統(tǒng)測試的粒度最大，一般由獨立測試小組采用黑盒方式來測試，主要測試系統(tǒng)是否符合“需求規(guī)格說明書。 驗收測試與系統(tǒng)測試非常相似，主要區(qū)別是測試人員不同，驗收測試由用戶執(zhí)行。 測試內(nèi)容測試內(nèi)容一般包含接口與路徑測試。 功能測試、健壯性測試、性能測試、用戶界面測試、平安性測試、壓力測試、可靠性測試、安裝/反安裝測試 測試階段對應(yīng)表測試階段 主要依據(jù) 測試人員、測試方式 主要測試內(nèi)容 單元測試系統(tǒng)設(shè)計文檔由開發(fā)小組執(zhí)行白盒測試 接口測試、路徑測試 集成測試系統(tǒng)設(shè)計文檔需求文檔由開發(fā)小組執(zhí)行白盒測試和黑盒測試 接口測試、路徑測試功能測試、性能測試

12、系統(tǒng)測試需求文檔由獨立測試小組執(zhí)行黑盒測試 功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試 驗收測試需求文檔由用戶執(zhí)行黑盒測試 接口與路徑測試 3-1接口測試：數(shù)據(jù)一般通過接口輸入和輸出，接口測試一般是白盒測試的第一步。 輸入?yún)?shù)有“典型值、“邊界值、“異常值 輸出包括函數(shù)的返回值和輸出參數(shù)。 實際輸出與期望的輸出不一致，那么說明程序有錯誤。 一個函數(shù)體內(nèi)的語句可能只有十幾條，但邏輯路徑可能有成千上萬條。所以應(yīng)該根據(jù)經(jīng)驗選擇關(guān)鍵的路徑測試。 接口與路徑測試 3-2路徑測試的檢查表數(shù)據(jù)類型、變量值、邏輯判斷、循環(huán)、內(nèi)存管理、文件I/O、錯誤處理

13、預(yù)防一些重要的路徑?jīng)]有被測試的措施有：觀察是否有程序語句從來沒有被執(zhí)行過。要特別留意函數(shù)體內(nèi)的錯誤處理程序塊。 接口與路徑測試 3-3接口與路徑測試用例的參考模板功能測試 3-1 功能測試的根本方法是構(gòu)造一些合理輸入在需求范圍之內(nèi)，檢查輸出是否與期望的相同。如果兩者不一致，即說明功能有誤。難點在于如何構(gòu)造有效的輸入。功能測試 3-2功能測試的測試方法：等價劃分法和邊界值分析法。 等價劃分是指把輸入空間劃分為幾個“等價區(qū)間，在每個“等價區(qū)間中只需要測試一個典型值就可以了。等價劃分法來源于人們的直覺與經(jīng)驗，可令測試事半功倍。 “缺陷遺漏在角落里，聚集在邊界上。邊界值測試法是對等價劃分法的補(bǔ)充。如果

14、A和B是輸入空間的邊界值，那么除了典型值外還要用A和B作為測試用例。 功能測試 3-3功能測試用例的參考模板性能測試 3-1性能測試即測試軟件處理事務(wù)的速度，一是為了檢驗性能是否符合需求，二是為了得到某些性能數(shù)據(jù)供人們參考。 絕對值考慮：如數(shù)據(jù)送輸速率是每秒多少比特。 “相對值考慮：如某個軟件比另一個軟件快多少倍。性能測試中考慮運(yùn)行環(huán)境的影響：例如網(wǎng)絡(luò)環(huán)境、計算機(jī)主頻，總線結(jié)構(gòu)和外部設(shè)備都可能影響軟件的運(yùn)行速度。 性能測試 3-2性能測試的一些本卷須知：應(yīng)當(dāng)編寫一段程序用于計算時間以及相關(guān)數(shù)據(jù)。 應(yīng)當(dāng)測試軟件在標(biāo)準(zhǔn)配置和最低配置下的性能。 應(yīng)當(dāng)關(guān)閉那些消耗內(nèi)存、占用CPU的其它應(yīng)用軟件如殺毒軟

15、件。 應(yīng)當(dāng)分檔記錄。例如傳輸文件的容量從100K到1M可以分成假設(shè)干等級。 同一種輸入情況在不同的時間可能得到不同的性能數(shù)據(jù)，可以取其平均值。 性能測試 3-3性能測試用例的參考模板壓力測試 2-1壓力測試也叫負(fù)荷測試，即獲取系統(tǒng)能正常運(yùn)行的極限狀態(tài)。壓力測試的主要任務(wù)是：構(gòu)造正確的輸入，使勁折騰系統(tǒng)卻讓它剛好不癱瘓。 壓力測試的一個變種是敏感測試。在某種情況下，微小的輸入變動會導(dǎo)致系統(tǒng)的表現(xiàn)如性能發(fā)生急劇的變化。壓力測試 2-2壓力測試用例的參考模板其他測試內(nèi)容健壯性測試用戶界面測試信息平安測試可靠性測試安裝和反安裝測試問題1：有了“黑盒測試為什么還要“白盒測試？問題2：由于單元測試要寫測試

16、驅(qū)動程序，非常麻煩，能否等到整個系統(tǒng)全部開發(fā)完后，再集中精力進(jìn)行一次性地單元測試呢？ 問題3：如果每個單元都通過了測試，把它們集成一起難道會有什么不妥嗎？集成測試是否多此一舉？測試常見問題 2-1測試常見問題 2-2問題4：在集成測試的時候，已經(jīng)對一些子系統(tǒng)進(jìn)行了功能測試、性能測試等等，那么在系統(tǒng)測試時能否跳過相同內(nèi)容的測試? 問題5：既然系統(tǒng)測試與驗收測試的內(nèi)容幾乎是相同的，為什么還要驗收測試？問題6：能否將系統(tǒng)測試和驗收測試“合二為一？ 總結(jié) 2-1測試可以將測試描述為一個運(yùn)行程序以發(fā)現(xiàn)錯誤的過程。軟件測試的準(zhǔn)那么:不完全測試、風(fēng)險測試、無法顯示潛伏錯誤、發(fā)現(xiàn)錯誤成線性增長、缺陷不能完全修

17、復(fù)、測試有條理規(guī)程測試的方法:黑盒/白盒、靜態(tài)/動態(tài)軟件測試的各個階段：單元測試、集成測試、系統(tǒng)測試、驗收測試總結(jié) 2-2測試的內(nèi)容包括：接口/路徑測試、功能測試、性能測試、壓力測試、可靠性測試、平安性測試、用戶界面測試、安裝/反安裝測試X模型測試驅(qū)動開發(fā)TDD, Test-Driven Development 測試驅(qū)動開發(fā)以測試作為開發(fā)過程的中心，它要求在編寫任何代碼之前，首先編寫用于定義產(chǎn)品代碼行為的測試，而編寫的產(chǎn)品代碼又以使測試通過為目標(biāo)。測試驅(qū)動開發(fā)要求測試可以完全自動地運(yùn)行，在代碼進(jìn)行重構(gòu)前必須運(yùn)行測試。TDD根本做法 1. 寫一個測試程序。 2. 讓程序編譯通過。 3. 運(yùn)行測試

18、程序，發(fā)現(xiàn)不能運(yùn)行。 4. 讓測試程序可以運(yùn)行。 5. 消除重復(fù)設(shè)計，優(yōu)化設(shè)計結(jié)構(gòu)。 測試產(chǎn)品說明書對于產(chǎn)品說明書的制定是個很重要的設(shè)計階段，產(chǎn)品說明書的質(zhì)量會直接影響到整個產(chǎn)品開發(fā)。測試產(chǎn)品說明書屬于靜態(tài)黑盒子測試。 常用測試用語測試用例測試用例：編寫用于輸入輸入的實際數(shù)制和預(yù)期結(jié)果。測試用例還明確指出使用具體測試用例產(chǎn)生的測試程序的任何限制 。使用目的： 測試用例應(yīng)該設(shè)計為能夠快速容易地發(fā)現(xiàn)盡可能多的錯誤。 應(yīng)該通過使用和產(chǎn)生正確和錯誤的輸入和輸出來“檢驗程序。 其目標(biāo)是要使用合理范圍內(nèi)的條件，盡可能全面地測試所有模塊乃至整個系統(tǒng)。測試與調(diào)試什么是缺陷缺陷：最終產(chǎn)品同用戶的期望不一致缺陷的

19、分類錯誤遺漏超出需求的局部缺陷未觸發(fā)VS.錯誤應(yīng)首先解決測試與調(diào)試調(diào)試的準(zhǔn)那么調(diào)試的方法：歸納法、演繹法和回溯法。常用調(diào)試技術(shù)使用診斷輸出語句 (diagnostic output statement)、快照轉(zhuǎn)儲 (snapshot dump) 以及跟蹤指令的斷點 (instruction-dependent breakpoint)。 二、單元測試根本理論什么是單元測試(Unit Test)什么時候測試？為什么要進(jìn)行單元測試 C/C+單元測試問答摘要 單元測試(Unit Test)工廠在組裝一臺電視機(jī)之前，會對每個元件都進(jìn)行測試，這，就是單元測試。臨時單元測試：代碼覆蓋率要超過70%都很困難充

20、分的單元測試：提高軟件質(zhì)量，降低開發(fā)本錢的必由之路。單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動，在單元測試活動中，軟件的獨立單元將在與程序的其他局部相隔離的情況下進(jìn)行測試。單元測試(Unit Test)對于程序員來說，如果養(yǎng)成了對自己寫的代碼進(jìn)行單元測試的習(xí)慣，不但可以寫出高質(zhì)量的代碼，而且還能提高編程水平。在一種傳統(tǒng)的結(jié)構(gòu)化編程語言中，比方C，要進(jìn)行測試的單元一般是函數(shù)或子過程。在象C+這樣的面向?qū)ο蟮恼Z言中，要進(jìn)行測試的根本單元是類。對Ada語言來說，開發(fā)人員可以選擇是在獨立的過程和函數(shù)，還是在Ada包的級別上進(jìn)行單元測試。單元測試的原那么同樣被擴(kuò)展到第四代語言(4GL)的開發(fā)中

21、，在這里根本單元被典型地劃分為一個菜單或顯示界面。單元測試(Unit Test)單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發(fā)過程中使用，單元測試必須是可重復(fù)的，無論是在軟件修改，或是移植到新的運(yùn)行環(huán)境的過程中。因此，所有的測試都必須在整個軟件系統(tǒng)的生命周期中進(jìn)行維護(hù)。 三、為什么要 進(jìn)行單元測試一些流行的誤解-反調(diào)論證 其他好處 單元測試的重要性 反證1：單元測試?yán)速M了太多的時間一旦編碼完成，開發(fā)人員總是會迫切希望進(jìn)行軟件的集成工作，這樣他們就能夠看到實際的系統(tǒng)開始啟開工作了。 這在外表上看來是一項明顯的進(jìn)步，而象單元測試這樣的活動也許會被看作是通往這個階段點的道路上的障礙， 推遲了

22、對整個系統(tǒng)進(jìn)行聯(lián)調(diào)這種真正有意思的工作啟動的時間。反證1：單元測試?yán)速M了太多的時間在這種開發(fā)步驟中，真實意義上的進(jìn)步被外表上的進(jìn)步取代了。系統(tǒng)能夠正常工作的可能性是很小的，更多的情況是充滿了各式各樣的Bug。在實踐中，這樣一種開發(fā)步驟常常會導(dǎo)致這樣的結(jié)果：軟件甚至無法運(yùn)行。更進(jìn)一步的結(jié)果是大量的時間將被花費在跟蹤那些包含在獨立單元里的簡單的Bug上面，在個別情況下，這些Bug也許是瑣碎和微缺乏道的，但是總的來說，他們會導(dǎo)致在軟件集成為一個系統(tǒng)時增加額外的工期， 而且當(dāng)這個系統(tǒng)投入使用時也無法確保它能夠可靠運(yùn)行。 反證1：單元測試?yán)速M了太多的時間在實踐工作中，進(jìn)行了完整方案的單元測試和編寫實際的

23、代碼所花費的精力大致上是相同的。一旦完成了這些單元測試工作，很多Bug將被糾正，在確信他們手頭擁有穩(wěn)定可靠的部件的情況下，開發(fā)人員能夠進(jìn)行更高效的系統(tǒng)集成工作。這才是真實意義上的進(jìn)步，所以說完整方案下的單元測試是對時間的更高效的利用。而調(diào)試人員的不受控和散漫的工作方式只會花費更多的時間而取得很少的好處。使用AdaTEST和Cantata這樣的支持工具可以使單元測試更加簡單和有效。但這不是必須的，單元測試即使是在沒有工具支持的情況下也是一項非常有意義的活動。反證2：僅僅證明代碼做了什么 這是那些沒有首先為每個單元編寫一個詳細(xì)的規(guī)格說明而直接跳到編碼階段的開發(fā)人員提出的一條普遍的抱怨， 當(dāng)編碼完成

24、以后并且面臨代碼測試任務(wù)的時候，他們就閱讀這些代碼并找出它實際上做了什么，把他們的測試工作基于已經(jīng)寫好的代碼的根底上。當(dāng)然，他們無法證明任何事情。所有的這些測試工作能夠說明的事情就是編譯器工作正常。是的，他們也許能夠抓住(希望能夠)罕見的編譯器Bug，但是他們能夠做的僅僅是這些。反證2：僅僅證明代碼做了什么 如果他們首先寫好一個詳細(xì)的規(guī)格說明，測試能夠以規(guī)格說明為根底。代碼就能夠針對它的規(guī)格說明，而不是針對自身進(jìn)行測試。這樣的測試仍然能夠抓住編譯器的Bug，同時也能找到更多的編碼錯誤，甚至是一些規(guī)格說明中的錯誤。好的規(guī)格說明可以使測試的質(zhì)量更高，所以最后的結(jié)論是高質(zhì)量的測試需要高質(zhì)量的規(guī)格說明

25、。 反證2：僅僅證明代碼做了什么 在實踐中會出現(xiàn)這樣的情況： 一個開發(fā)人員要面對測試一個單元時只給出單元的代碼而沒有規(guī)格說明這樣吃力不討好的任務(wù)。你怎樣做才會有更多的收獲，而不僅僅是發(fā)現(xiàn)編譯器的Bug？第一步是理解這個單元原本要做什么， - 不是它實際上做了什么。 比較有效的方法是倒推出一個概要的規(guī)格說明。這個過程的主要輸入條件是要閱讀那些程序代碼和注釋， 主要針對這個單元， 及調(diào)用它和被它調(diào)用的相關(guān)代碼。畫出流程圖是非常有幫助的，你可以用手工或使用某種工具。 可以組織對這個概要規(guī)格說明的走讀(Review)，以確保對這個單元的說明沒有根本的錯誤， 有了這種最小程度的代碼深層說明，就可以用它來

26、設(shè)計單元測試了。 反證3：我是個很棒的程序員， 我是不是可以不進(jìn)行單元測試？ 在每個開發(fā)組織中都至少有一個這樣的開發(fā)人員，他非常擅長于編程，他們開發(fā)的軟件總是在第一時間就可以正常運(yùn)行，因此不需要進(jìn)行測試。你是否經(jīng)常聽到這樣的借口？在真實世界里，每個人都會犯錯誤。即使某個開發(fā)人員可以抱著這種態(tài)度在很少的一些簡單的程序中應(yīng)付過去。 但真正的軟件系統(tǒng)是非常復(fù)雜的。真正的軟件系統(tǒng)不可以寄希望于沒有進(jìn)行廣泛的測試和Bug修改正程就可以正常工作。編碼不是一個可以一次性通過的過程。在真實世界中，軟件產(chǎn)品必須進(jìn)行維護(hù)以對操作需求的改變作出反響， 并且要對最初的開發(fā)工作遺留下來的Bug進(jìn)行修改。你希望依靠那些原

27、始作者進(jìn)行修改嗎？ 這些制造出這些未經(jīng)測試的原始代碼的資深專家們還會繼續(xù)在其他地方制造這樣的代碼。在開發(fā)人員做出修改后進(jìn)行可重復(fù)的單元測試可以防止產(chǎn)生那些令人不快的負(fù)作用。 反證4：不管怎樣， 集成測試將會抓住所有的Bug ？ 我們已經(jīng)在前面的討論中從一個側(cè)面對這個問題進(jìn)行了局部的闡述。這個論點不成立的原因在于規(guī)模越大的代碼集成意味著復(fù)雜性就越高。如果軟件的單元沒有事先進(jìn)行測試，開發(fā)人員很可能會花費大量的時間僅僅是為了使軟件能夠運(yùn)行，而任何實際的測試方案都無法執(zhí)行。一旦軟件可以運(yùn)行了，開發(fā)人員又要面對這樣的問題： 在考慮軟件全局復(fù)雜性的前提下對每個單元進(jìn)行全面的測試。 這是一件非常困難的事情，

28、甚至在創(chuàng)造一種單元調(diào)用的測試條件的時候，要全面的考慮單元的被調(diào)用時的各種入口參數(shù)。在軟件集成階段，對單元功能全面測試的復(fù)雜程度遠(yuǎn)遠(yuǎn)的超過獨立進(jìn)行的單元測試過程。最后的結(jié)果是測試將無法到達(dá)它所應(yīng)該有的全面性。一些缺陷將被遺漏，并且很多Bug將被忽略過去。讓我們類比一下，假設(shè)我們要清洗一臺已經(jīng)完全裝配好的食物加工機(jī)器!無論你噴了多少水和清潔劑，一些食物的小碎片還是會粘在機(jī)器的死角位置，只有任其腐爛并等待以后再想方法。但我們換個角度想想，如果這臺機(jī)器是拆開的， 這些死角也許就不存在或者更容易接觸到了，并且每一局部都可以毫不費力的進(jìn)行清洗。 反證5：它的本錢效率不高一個特定的開發(fā)組織或軟件應(yīng)用系統(tǒng)的測

29、試水平取決于對那些未發(fā)現(xiàn)的Bug的潛在后果的重視程度。這種后果的嚴(yán)重程度可以從一個Bug引起的小小的不便到發(fā)生屢次的死機(jī)的情況。這種后果可能常常會被軟件的開發(fā)人員所無視(但是用戶可不會這樣)，這種情況會長期的損害這些向用戶提交帶有Bug的軟件的開發(fā)組織的信譽(yù)，并且會導(dǎo)致對未來的市場產(chǎn)生負(fù)面的影響。相反地，一個可靠的軟件系統(tǒng)的良好的聲譽(yù)將有助于一個開發(fā)組織獲取未來的市場。 很多研究成果說明，無論什么時候作出修改都要進(jìn)行完整的回歸測試，在生命周期中盡早地對軟件產(chǎn)品進(jìn)行測試將使效率和質(zhì)量得到最好的保證。Bug發(fā)現(xiàn)的越晚，修改它所需的費用就越高，因此從經(jīng)濟(jì)角度來看， 應(yīng)該盡可能早的查找和修改Bug。在

30、修改費用變的過高之前，單元測試是一個在早期抓住Bug的時機(jī)。相比后階段的測試，單元測試的創(chuàng)立更簡單，維護(hù)更容易，并且可以更方便的進(jìn)行重復(fù)。從全程的費用來考慮， 相比起那些復(fù)雜且曠日持久的集成測試，或是不穩(wěn)定的軟件系統(tǒng)來說，單元測試所需的費用是很低的。 反證5：它的本錢效率不高摘自(Capers Jones，McGraw-Hill 1991)，它列出了準(zhǔn)備測試，執(zhí)行測試，和修改缺陷所花費的時間(以一個功能點為基準(zhǔn))，這些數(shù)據(jù)顯示單元測試的本錢效率大約是集成測試的兩倍 系統(tǒng)測試的三倍。 反證5：它的本錢效率不高(術(shù)語域測試(Field test)意思是在軟件投入使用以后，針對某個領(lǐng)域所作的所有測試

31、活動)這個圖表并不表示開發(fā)人員不應(yīng)該進(jìn)行后階段的測試活動，這次測試活動仍然是必須的。它的真正意思是盡可能早的排除盡可能多的Bug可以減少后階段測試的費用。其他的一些圖表顯示高達(dá)50%的維護(hù)工作量被花在那些總是會有的Bug的修改上面。如果這些Bug在開發(fā)階段被排除掉的話，這些工作量就可以節(jié)省下來。當(dāng)考慮到軟件維護(hù)費用可能會比最初的開發(fā)費用高出數(shù)倍的時候，這種潛在的對50%軟件維護(hù)費用的節(jié)省將對整個軟件生命周期費用產(chǎn)生重大的影響。 反證 結(jié)論 經(jīng)驗說明一個盡責(zé)的單元測試方法將會在軟件開發(fā)的某個階段發(fā)現(xiàn)很多的Bug，并且修改它們的本錢也很低。在軟件開發(fā)的后期階段，Bug的發(fā)現(xiàn)并修改將會變得更加困難，

32、并要消耗大量的時間和開發(fā)費用。無論什么時候作出修改都要進(jìn)行完整的回歸測試，在生命周期中盡早地對軟件產(chǎn)品進(jìn)行測試將使效率和質(zhì)量得到最好的保證。 在提供了經(jīng)過測試的單元的情況下，系統(tǒng)集成過程將會大大地簡化。開發(fā)人員可以將精力集中在單元之間的交互作用和全局的功能實現(xiàn)上，而不是陷入充滿很多Bug的單元之中不能自拔。使測試工作的效力發(fā)揮到最大化的關(guān)鍵在于選擇正確的測試策略，這其中包含了完全的單元測試的概念，以及對測試過程的良好的管理，還有適當(dāng)?shù)厥褂孟驛daTEST和Cantata這樣的工具來支持測試過程。這些活動可以產(chǎn)生這樣的結(jié)果：在花費更低的開發(fā)費用的情況下得到更穩(wěn)定的軟件。更進(jìn)一步的好處是簡化了維護(hù)

33、過程并降低了生命周期的費用。有效的單元測試是推行全局質(zhì)量文化的一局部，而這種質(zhì)量文化將會為軟件開發(fā)者帶來無限的商機(jī)。 其他好處 1：減少程序的Bug 要減少軟件中的錯誤數(shù)目，方法之一就是擁有一個專業(yè)的測試組，其工作就是盡一切可能使軟件崩潰。不幸的是，如果擁有測試組，那么即使是經(jīng)驗豐富的開發(fā)人員，也會傾向于花費較少的時間來保證代碼的可靠性。 軟件界有一句俗語：“開發(fā)人員不應(yīng)該測試他們自己的代碼。這是因為開發(fā)人員對自己的代碼了如指掌，他們很清楚如何采用適當(dāng)?shù)姆椒▽Υa進(jìn)行測試。盡管這句俗語很有道理，但卻忽略了非常重要的一點 - 如果開發(fā)人員不對自己的代碼進(jìn)行測試，又如何知道代碼能否按照預(yù)期的方式運(yùn)

34、行？ 簡單說來，他們根本無從得知。開發(fā)人員編寫那種運(yùn)行不正常或只在某些情況下運(yùn)行正常的代碼是一個嚴(yán)重的問題。他們通常只測試代碼能否在很少的情況下正常運(yùn)行，而不是驗證代碼能夠在所有情況下均正常運(yùn)行。 其他好處 2：提高開發(fā)速度 在實踐工作中，進(jìn)行了完整方案的單元測試和編寫實際的代碼所花費的精力大致上是相同的。一旦完成了這些單元測試工作，很多Bug將被糾正，在確信他們手頭擁有穩(wěn)定可靠的部件的情況下，開發(fā)人員能夠進(jìn)行更高效的系統(tǒng)集成工作。這才是真實意義上的進(jìn)步，所以說完整方案下的單元測試是對時間的更高效的利用。而調(diào)試人員的不受控和散漫的工作方式只會花費更多的時間而取得很少的好處。經(jīng)驗說明一個盡責(zé)的單

35、元測試方法將會在軟件開發(fā)的某個階段發(fā)現(xiàn)很多的Bug，并且修改它們的本錢也很低。在軟件開發(fā)的后期階段，Bug的發(fā)現(xiàn)并修改將會變得更加困難，并要消耗大量的時間和開發(fā)費用。無論什么時候作出修改都要進(jìn)行完整的回歸測試，在生命周期中盡早地對軟件產(chǎn)品進(jìn)行測試將使效率和質(zhì)量得到最好的保證。 在提供了經(jīng)過測試的單元的情況下，系統(tǒng)集成過程將會大大地簡化。開發(fā)人員可以將精力集中在單元之間的交互作用和全局的功能實現(xiàn)上，而不是陷入充滿很多Bug的單元之中不能自拔。其他好處 3：使程序代碼更整潔，優(yōu)化程序的設(shè)計 只有自動的單元測試程序失敗時，我們才會去重寫代碼，在測試驅(qū)動開發(fā)中，要求我們對程序不停的重構(gòu)，通過重構(gòu)，我們

36、可以優(yōu)化程序的結(jié)構(gòu)設(shè)計，消除程序中潛在的錯誤。同時，為了能夠使自己的程序可以很方便的進(jìn)行測試，開發(fā)人員就需要很好地考慮程序的設(shè)計，極限編程的方法說可以不需要設(shè)計就開始編碼，但實際上，它在編寫代碼的過程中每時每刻都為了方便的進(jìn)行和通過測試而在優(yōu)化自己的設(shè)計。它實際上是把開始階段很大很抽象的設(shè)計分散到你編寫的每個方法中。因此他們會說好設(shè)計最后會自然而然的出現(xiàn)。 其他好處 4：編寫單元測試代碼的過程實際上就是設(shè)計程序的過程 在編寫單元測試代碼時，我們實際上是在思考我們的程序根據(jù)預(yù)期會返回什么結(jié)果，它實際上就是程序設(shè)計的過程。而通過重構(gòu)過程，我們可以對這些設(shè)計進(jìn)行很好的優(yōu)化。 單元測試的重要性 單元測

37、試是軟件測試的根底，因此單元測試的效果會直接影響到軟件的后期測試，最終在很大程度上影響到產(chǎn)品的質(zhì)量。時間方面測試效果測試本錢產(chǎn)品質(zhì)量重要性 1：時間方面 如果認(rèn)真的做好了單元測試，在系統(tǒng)集成聯(lián)調(diào)時非常順利，因此會節(jié)約很多時間，反之那些由于因為時間原因不做單元測試或隨便做做的那么在集成時總會遇到那些本應(yīng)該在單元測試就能發(fā)現(xiàn)的問題，而這種問題在集成時遇到往往很難讓開發(fā)人員預(yù)料到，最后在苦苦尋覓中才發(fā)現(xiàn)這是個很低級的錯誤而在悔恨自己時已經(jīng)浪費了很多時間，這種時間上的浪費一點都不值得，正所謂得不償失。重要性 2：測試效果根據(jù)以往的測試經(jīng)驗來看，單元測試的效果是非常明顯的，首先它是測試階段的根底，做好了

38、單元測試，在做后期的集成測試和系統(tǒng)測試時就很順利。其次在單元測試過程中能發(fā)現(xiàn)一些很深層次的問題，同時還會發(fā)現(xiàn)一些很容易發(fā)現(xiàn)而在集成測試和系統(tǒng)測試很難發(fā)現(xiàn)的問題。再次單元測試關(guān)注的范圍也特殊，它不僅僅是證明這些代碼做了什么，最重要的是代碼是如何做的，是否做了它該做的事情而沒有做不該做的事情。重要性 3：測試本錢在單元測試時某些問題就很容易發(fā)現(xiàn)，如果在后期的測試中發(fā)現(xiàn)問題所花的本錢將成倍數(shù)上升。比方在單元測試時發(fā)現(xiàn)1個問題需要1個小時，那么在集成測試時發(fā)現(xiàn)該問題需要2個小時，在系統(tǒng)測試時發(fā)現(xiàn)那么需要3個小時，同理還有定位問題和解決問題的費用也是成倍數(shù)上升的，這就是我們要盡可能早的排除盡可能多的bu

39、g來減少后期本錢的因素之一。重要性 4：產(chǎn)品質(zhì)量單元測試的好與壞直接影響到產(chǎn)品的質(zhì)量，可能就是由于代碼中的某一個小錯誤就導(dǎo)致了整個產(chǎn)品的質(zhì)量降低一個指標(biāo)，或者導(dǎo)致更嚴(yán)重的后果，如果我們做好了單元測試這種情況是可以完全防止的。綜上所述，單元測試是構(gòu)筑產(chǎn)品質(zhì)量的基石，我們不要因為節(jié)約單元測試的時間不做單元測試或隨便做而讓我們在后期浪費太多的不值得的時間，我們也不愿意因為由于節(jié)約那些時間導(dǎo)致開發(fā)出來的整個產(chǎn)品失敗或重來！四、 C/C+單元測試問答為什么要進(jìn)行單元測試?由誰進(jìn)行測試？開發(fā)部門還是測試部門？由測試部門進(jìn)行單元測試為什么本錢昂貴？由開發(fā)部門進(jìn)行單元測試能保證測試效果嗎？ 邊編碼邊測試會影響

40、編碼進(jìn)度嗎？實施單元測試需要改變開發(fā)流程嗎？ 單元測試測試哪些代碼？實際工作中，單元測試能實現(xiàn)什么程度的測試覆蓋？ 單元測試如何改進(jìn)工程代碼的整體結(jié)構(gòu)？我希望依賴全自動的工具來完成單元測試，這一想法現(xiàn)實嗎？如果由開發(fā)部門實施單元測試，那么測試部門要做哪些工作？為什么要進(jìn)行單元測試?單元測試保證局部代碼的質(zhì)量單元測試改進(jìn)工程代碼的整體結(jié)構(gòu)單元測試降低測試、維護(hù)升級的本錢單元測試使開發(fā)過程適應(yīng)頻繁變化的需求單元測試有助于提升程序員的能力由誰進(jìn)行測試？開發(fā)部門/測試部門？應(yīng)該由開發(fā)部門進(jìn)行單元測試！由測試部門進(jìn)行單元測試的問題：代價高，人手缺乏，耽誤了測試部門對其他測試的準(zhǔn)備工作。由開發(fā)部門進(jìn)行單元

41、測試的問題：擔(dān)憂影響開發(fā)進(jìn)度，程序員不習(xí)慣做單元測試，測試自己編寫的代碼，難于保證測試的效果。無論由哪個部門做單元測試，都要面對一些問題，但開發(fā)部門所面對的問題可以借助工具來解決，而由測試部門進(jìn)行單元測試，要么無法真正實施，要么代價昂貴。 由測試部門來單元測試本錢昂貴？需屢次重復(fù)理解程序反復(fù)溝通需要大量時間本錢不利于發(fā)揮單元測試對代碼結(jié)構(gòu)的約束機(jī)制耽誤測試部門對其他測試的準(zhǔn)備工作即使測試部門人手充裕，僅僅從效益來考慮，也不應(yīng)該由測試部門進(jìn)行單元測試。如果測試部門本來就人力不充裕(進(jìn)行單元測試的人員需具備編碼能力)，勉強(qiáng)由測試部門進(jìn)行單元測試，結(jié)果往往是-沒有結(jié)果。由開發(fā)部門進(jìn)行單元測試能保證測

42、試效果嗎？程序員測試自己編寫的代碼，往往只考慮“正常狀況，這當(dāng)然會影響測試效果。但如果所用的單元測試工具能夠統(tǒng)計各種白盒覆蓋率，就能檢查測試效果。當(dāng)然，只做到這一點還是不夠的，因為白盒覆蓋具有逾后逾難的特點，到達(dá)一定的覆蓋率后，覆蓋率的提升會很困難。如果測試工具功能足夠強(qiáng)大，能提供工具幫助用戶快速地設(shè)計測試用例，到達(dá)完整的白盒覆蓋，那么測試效果就能得到完全的保證。實際上，如果沒有充分的統(tǒng)計數(shù)據(jù)，沒有到達(dá)足夠的測試完整性，那么由誰做單元測試，效果都不能保證。邊編碼邊測試會影響編碼進(jìn)度嗎？ 傳統(tǒng)的單元測試是很費時費力的工作，主要時間消耗在于：編寫測試代碼、設(shè)計測試用例，如果開發(fā)工具能自動生成測試代

43、碼，并且具有快速設(shè)計測試用例的功能，那么測試費時就很少；另一方面，如果測試工具還能提供數(shù)據(jù)，幫助程序員整理編程思路、快速發(fā)現(xiàn)錯誤，更高效地調(diào)試，那么就能大量提高開發(fā)效率，抵銷測試所消耗的時間，不但不會影響編碼進(jìn)度，甚至加快編碼進(jìn)度。實施單元測試需要改變開發(fā)流程嗎？邊開發(fā)邊測試，單元測試是編碼行為而不是測試行為，測試代碼看作是工程代碼的一局部，程序員提交產(chǎn)品代碼時也要提交測試代碼和測試報告，其他流程可以不作任何改變。另一方面，在充分單元測試的根底上，由于具有高質(zhì)量的局部代碼，良好的整體代碼結(jié)構(gòu)，保證了代碼的可擴(kuò)展性和可復(fù)用性，同時，自動回歸測試支持對代碼的頻繁修改而不用擔(dān)憂引入新的錯誤，因此，開

44、發(fā)流程自然會變得敏捷，可以適應(yīng)頻繁變化的需求，使系統(tǒng)分析、架構(gòu)設(shè)計和后期測試的壓力減輕，自然而有效地改進(jìn)了開發(fā)流程。單元測試測試哪些代碼？單元測試通常不測試很簡單的代碼，一般也不測試“邊界代碼。很簡單的代碼容易理解，例如Get/Set函數(shù)，這里解釋一下“邊界代碼。“邊界代碼是指用于與外部系統(tǒng)交互的代碼，例如用于處理用戶界面的代碼。數(shù)據(jù)庫、文件、網(wǎng)絡(luò)都可以看作是外部系統(tǒng)，用于讀寫數(shù)據(jù)庫或文件、或訪問網(wǎng)絡(luò)的代碼也可以看作是“邊界代碼，這類代碼應(yīng)該獨立出來，可以進(jìn)行單元測試，但對這些代碼的單元測試通常不能自動驗證預(yù)期輸出，而是需要人工觀察。編程時，不要把普通代碼與“邊界代碼混在一起，例如，不要把各種

45、運(yùn)算直接寫在界面類中，做到了這一點，絕大多數(shù)代碼都可以進(jìn)行單元測試。實際工作中，單元測試能實現(xiàn)什么程度的測試覆蓋？單元測試的最低要求是100%語句覆蓋，這個覆蓋率還是不夠的，最好實現(xiàn)多種覆蓋的組全，比較理想的覆蓋率組合是：100%的語句、條件、分支、路徑覆蓋，另外，測試工具最好還能自動生成邊界測試用例捕捉未處理特殊輸入形成的錯誤。在到達(dá)這種覆蓋之后，殘留的編碼錯誤可以幾乎說沒有了設(shè)計方面的錯誤除外，這些屬于集成或系統(tǒng)測試的范疇。單元測試如何改進(jìn)工程代碼的整體結(jié)構(gòu)？具有良好整體結(jié)構(gòu)的代碼，應(yīng)該符合“低耦合的特性，即具有“可測性。測試不具有“可測性的代碼時一般會產(chǎn)生編譯錯誤，或者需要打樁才能測試，

46、從而將問題暴露出來。發(fā)現(xiàn)問題后，重構(gòu)代碼、消除不當(dāng)耦合一般不難，這種簡單的重構(gòu)將有效地改進(jìn)代碼的整體結(jié)構(gòu)。我希望依賴全自動的工具來完成單元測試，這一想法現(xiàn)實嗎？完全自動化是一個美妙的愿望，但由于單元測試的根本特性，完全自動化的單元測試是不現(xiàn)實的。與其他不同，單元測試是“隔離的測試，要求代碼具有可測性，一個工程甚至一個文件中，難免會有些影響可測性的代碼，編譯到這些代碼時常常會產(chǎn)生編譯錯誤，因此，全自動的單元測試工具往往只能測試小局部代碼，即使使用某種技術(shù)手段屏蔽掉編譯錯誤，也得不償失，因為同時也屏蔽掉了改進(jìn)代碼整體結(jié)構(gòu)的珍貴時機(jī)。如果采用自底向上的方式，一個一個文件測試，測試一個文件前，先將該文

47、件參加測試工程并編譯，沒有編譯錯誤時再測試，這樣可以及時發(fā)現(xiàn)并消除不當(dāng)耦合，使代碼具有可測性，這種非全自動的方式，可以測試絕大多數(shù)代碼，也保證了代碼具有良好的整體結(jié)構(gòu)。另一方面，主要由測試工具自動生成測試用例來進(jìn)行測試往往沒有實際意義，因為測試工具無法自動了解程序的功能，因此，自動測試用例通常只能發(fā)現(xiàn)異常之類的極端錯誤，大多數(shù)一般錯誤都是無法發(fā)現(xiàn)的。測試工具最重要的不是自動生成測試用例，而是能提供快速建立和編輯測試用例的工具。如果由開發(fā)部門實施單元測試，那么測試部門要做哪些工作？推動、組織單元測試的實施。單元測試既然叫做“測試，開發(fā)部門常常認(rèn)識不到其重要性和必要性，需要由測試部門推動和協(xié)助組織

48、實施。制定單元測試標(biāo)準(zhǔn)，培訓(xùn)單元測試技術(shù)。檢查、審核單元測試結(jié)果，保證單元測試的有效性。五、單元測試工具測試工具的分類和選擇 Parasoft Compuware Rational AutomatedQA AQTime xUnit系列 Visual Studio 2005 Visual Unit 測試工具的分類和選擇 白盒測試工具靜態(tài)測試工具動態(tài)測試工具黑盒測試工具功能測試工具性能測試工具測試管理工具 其他測試工具測試工具的選擇白盒測試工具白盒測試工具一般是針對代碼進(jìn)行測試，測試中發(fā)現(xiàn)的缺陷可以定位到代碼級靜態(tài)測試工具直接對代碼進(jìn)行分析，不需要運(yùn)行代碼，也不需要對代碼編譯鏈接，生成可執(zhí)行文件。

49、靜態(tài)測試工具一般是對代碼進(jìn)行語法掃描，找出不符合編碼標(biāo)準(zhǔn)的地方，根據(jù)某種質(zhì)量模型評價代碼的質(zhì)量，生成系統(tǒng)的調(diào)用關(guān)系圖等。動態(tài)測試工具與靜態(tài)測試工具不同，動態(tài)測試工具的一般采用“插樁的方式，向代碼生成的可執(zhí)行文件中插入一些監(jiān)測代碼，用來統(tǒng)計程序運(yùn)行時的數(shù)據(jù)。其與靜態(tài)測試工具最大的不同就是動態(tài)測試工具要求被測系統(tǒng)實際運(yùn)行。 黑盒測試工具黑盒測試工具適用于黑盒測試的場合，黑盒測試工具包括功能測試工具和性能測試工具。黑盒測試工具的一般原理是利用腳本的錄制(Record)/回放(Playback)，模擬用戶的操作，然后將被測系統(tǒng)的輸出記錄下來同預(yù)先給定的標(biāo)準(zhǔn)結(jié)果比較。黑盒測試工具可以大大減輕黑盒測試的工

50、作量，在迭代開發(fā)的過程中，能夠很好地進(jìn)行回歸測試。黑盒測試工具的代表有Rational公司的TeamTest、Robot，Compuware公司的QACenter，另外，專用于性能測試的工具包括有Radview公司的WebLoad、Microsoft公司的WebStress等工具。 測試管理工具測試管理工具用于對測試進(jìn)行管理。內(nèi)容：對測試方案、測試用例、測試實施進(jìn)行管理，對缺陷的跟蹤管理。測試管理工具的代表有Rational公司的Test Manager、Compureware公司的TrackRecord，Mercury的TestDirector和Quality Center等軟件。測試工具的

51、選擇功能根本的功能 報表功能 測試工具的集成能力 操作系統(tǒng)和開發(fā)工具的兼容性 價格連續(xù)性和一致性：全盤考慮，分階段、逐步的引入測試工具 測試工具引入中的誤區(qū)分析沒有考慮到公司的實際情況，盲目引入測試工具 專題分析，引入哪些測試工具？沒有進(jìn)行有效的測試工具的培訓(xùn)測試工具的培訓(xùn)是一個長期的過程系列的培訓(xùn)和交流 沒有形成一個良好的使用測試工具的環(huán)境 沒有能夠形成一種機(jī)制讓測試工具真正能夠發(fā)揮作用 良好的測試工具使用環(huán)境 約束機(jī)制開發(fā)流程 例如，單元測試是由開發(fā)人員完成，如果沒有流程來標(biāo)準(zhǔn)開發(fā)人員的行為，在工程進(jìn)度壓力比較大的情況下，開發(fā)人員很可能就會有意識地不使用測試工具，來逃避問題。在這種情況下，

52、就必須形成一種有約束力的機(jī)制來強(qiáng)制對測試工具的使用。 某公司的一種比較好的方式：將測試工具的使用明確定義進(jìn)公司的開發(fā)流程。在開發(fā)流程中明確說明，在工程里程碑提交的文檔中必須包括測試工具生成的報告，該報告中的數(shù)據(jù)是決定工程是否合格的依據(jù)。根據(jù)公司的實際情況，在提交集成測試時需要提交DevPartner工具生成的測試覆蓋率報告、Logiscope生成的代碼質(zhì)量報告，并且要求單元測試的代碼覆蓋率必須到達(dá)80%以上，代碼質(zhì)量評價必須在Fair以上。 測試工具并不是策略測試工具并不能教測試員如何測試。如果測試出現(xiàn)問題，那么測試工具會加重問題。在實現(xiàn)測試過程自動化之前，應(yīng)首先解決測試過程中的問題。有些測試

53、工具帶有測試策略的建議。但是這種建議很少能夠描述得很清楚，并不能針對具體情況，而且往往過于強(qiáng)調(diào)他們那種自動化測試的重要性。工具是輔助性的，關(guān)鍵還是靠人的思想和行為！ Parasoft Parasoft Jtest 代碼分析和動態(tài)類、組件測試Parasoft C+Test代碼分析和動態(tài)測試Parasoft .TEST代碼分析和動態(tài)測試Parasoft Insure+ 實時性能監(jiān)控以及分析優(yōu)化Parasoft CodeWizard代碼靜態(tài)分析Parasoft Jtest是第一個自動化Java單元測試工具。Jtest自動測試任何Java類或部件，而不需要您寫一個測試用例、驅(qū)動程序或樁函數(shù)。只要點擊一

54、個按鈕，Jtest自動測試代碼構(gòu)造白盒測試、測試代碼功能性黑盒測試、維護(hù)代碼完整性回歸測試和靜態(tài)分析編程標(biāo)準(zhǔn)執(zhí)行和指標(biāo)度量。不需要復(fù)雜的設(shè)置，Jtest能夠立即使用并指出問題。如果您使用“按合同設(shè)計技術(shù)在代碼中參加描述信息，Jtest能夠自動建立和執(zhí)行測試用例驗證一個類的功能是否符合其功能描述。Jcontract Java 實時性能監(jiān)控以及分析優(yōu)化 Parasoft C+Test 單元測試和靜態(tài)分析工具，自動測試C和C類別、功能或組件，而無需編寫單個測試實例、測試驅(qū)動程序或樁調(diào)用。只需點擊按鈕，C+Test即會采用業(yè)內(nèi)編碼標(biāo)準(zhǔn)執(zhí)行代碼的靜態(tài)分析，測試代碼構(gòu)造白盒測試，測試代碼功能性黑盒測試，并

55、保持代碼完整性回歸測試。Parasoft .TEST 單元測試和靜態(tài)分析工具，自動測試寫在Microsoft?.NET框架的類別，而無需編寫單個測試場景或樁調(diào)用。只需點擊按鈕，.TEST即會在.NET源代碼上自動執(zhí)行完整系列的靜態(tài)和動態(tài)測試。.TEST RuleWizard性能通過圖形化表達(dá)希望.TEST在自動編碼標(biāo)準(zhǔn)執(zhí)行過程中查找的模式，支持設(shè)計定制的編碼標(biāo)準(zhǔn)。 Parasoft Insure+ 一個自動化的內(nèi)存錯誤、內(nèi)存泄漏的精確檢測工具。Insure+能夠可視化實時內(nèi)存操作，準(zhǔn)確檢測出內(nèi)存泄漏產(chǎn)生的根源。Insure+還能執(zhí)行覆蓋性分析，清楚地指示那些代碼已經(jīng)測試過。將Insure+集成

56、到您的開發(fā)環(huán)境中，能夠極大地減少調(diào)試時間并有效地防止錯誤。 Parasoft CodeWizard 高級C/C+源代碼分析工具，采用三百種以上行業(yè)相關(guān)的編碼準(zhǔn)那么，自動識別編譯器未檢測到的危險的編碼構(gòu)造。CodeWizard可以容易地通過RuleWizard性能，創(chuàng)立新定制的準(zhǔn)那么，或者抑制用于定制分析的準(zhǔn)那么。日常使用CodeWizard，可簡化代碼檢查，并使代碼更具可讀性和可維護(hù)性。 Compuware白盒測試工具集BoundsChecker C+,Delphi API和OLE錯誤檢查、指針和泄露錯誤檢查、內(nèi)存錯誤檢查 TrueTime C+,Java,Visual Basic 代碼運(yùn)行效

57、率檢查、組件性能的分析 FailSafe Visual Basic 自動錯誤處理和恢復(fù)系統(tǒng) Jcheck M$ Visual J+ 圖形化的純種和事件分析工具 TrueCoverage C+,Java,Visual Basic 函數(shù)調(diào)用次數(shù)、所占比率統(tǒng)計以及穩(wěn)定性跟蹤 SmartCheck Visual Basic 函數(shù)調(diào)用次數(shù)、所占比率統(tǒng)計以及穩(wěn)定性跟蹤 CodeReview Visual Basic 自動源代碼分析工具Compuware DevPartner Studio針對軟件開發(fā)小組使用 Microsoft Visual C+，Microsoft Visual Basic，Java,A

58、SP 或 HTML 設(shè)計的一套緊密配合的調(diào)試，測試和管理工具。該產(chǎn)品結(jié)合了強(qiáng)大的錯誤檢測，性能分析，覆蓋率分析，需求管理，測試和發(fā)布工具與全面的工程跟蹤，錯誤管理，任務(wù)管理和自動的工作流程。DevPartner Studio Enterprise Edition 通過提高軟件生產(chǎn)率,提高代碼質(zhì)量，支持工作流以及通訊標(biāo)準(zhǔn)讓你對軟件工程有更多的控制權(quán)。Win下最好的輔助調(diào)試工具。能夠幫你檢查內(nèi)存泄漏，GDI泄漏，內(nèi)存覆蓋，數(shù)組越界，系統(tǒng)API調(diào)用參數(shù)是否適宜。還能profile，對你的程序的運(yùn)行時間進(jìn)行分析，每個函數(shù)占用多少運(yùn)行時間，每一行占用多少運(yùn)行時間，幫你找出時間的瓶頸。 Rational

59、Rational PurifyRational QuantifyRational PureCoverageIBM Rational PurifyPlusRational Purify面向VC, VB或者Java開發(fā)的測試Visual C/C+ 和Java代碼中與內(nèi)存有關(guān)的錯誤，確保整個應(yīng)用程序的質(zhì)量和可靠性。在查找典型的Visual C/C+程序中的傳統(tǒng)內(nèi)存訪問錯誤，以及Java中與垃圾內(nèi)存收集相關(guān)的錯誤方面，Rational Purify可以大顯身手。Rational Robot的回歸測試與Rational Purify結(jié)合使用完成可靠性測試。 Rational Quantify面向VC、V

60、B 或者Java開發(fā)的測試性能瓶頸檢測工具，它可以自動檢測出影響程序段執(zhí)行速度的程序性能瓶頸，提供參數(shù)分析表等等直觀表格。幫助分析影響程序短執(zhí)行速度的關(guān)鍵局部。 Rational PureCoverage面向VC、VB或者Java開發(fā)的測試覆蓋程度檢測工具，它可以自動檢測你的測試完整性和那些無法到達(dá)的局部。作為一個質(zhì)量控制工程，可以使用PureCoverage在每一個測試階段生產(chǎn)詳盡的測試覆蓋程度報告。 IBM Rational PurifyPlus一套完整的運(yùn)行時分析工具，旨在提升應(yīng)用的可靠性和性能。包括Purify、Quantify、PureCoverage。AutomatedQA AQT