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

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

3、保系統(tǒng)的質(zhì)量 一個(gè)被人忽略的軟件測(cè)試目的是：測(cè)試可以幫助發(fā)現(xiàn)當(dāng)前開(kāi)發(fā)工作所采用的軟件過(guò)程（也是一個(gè)“軟件”）的缺陷，以便進(jìn)行改進(jìn)。 首先，測(cè)試并不僅僅是為了要找出錯(cuò)誤。分析錯(cuò)誤產(chǎn)生的原因和錯(cuò)誤在開(kāi)發(fā)的哪一個(gè)階段產(chǎn)生，具有非常重要的意義。 通過(guò)分析錯(cuò)誤產(chǎn)生于哪一個(gè)開(kāi)發(fā)階段、而又在哪一個(gè)階段被發(fā)現(xiàn)，我們可以判斷從錯(cuò)誤的產(chǎn)生到錯(cuò)誤的發(fā)現(xiàn)，跨越了多少個(gè)開(kāi)發(fā)階段。 軟件開(kāi)發(fā)的一條重要原則是盡早發(fā)現(xiàn)與修正錯(cuò)誤。 正確分析與利用測(cè)試的結(jié)果，我們可以非常有效地進(jìn)行軟件過(guò)程改進(jìn),軟件測(cè)試原則 2-1,完全測(cè)試程序是不可能的 輸入量太大 輸出結(jié)果太多 軟件實(shí)現(xiàn)途徑太多 軟件說(shuō)明書(shū)沒(méi)有客觀標(biāo)準(zhǔn)。從不同角度看，軟件缺

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

5、態(tài)測(cè)試,審查 (Inspection) 軟件的一種基本測(cè)試方法，它以一系列典型問(wèn)題為依據(jù)進(jìn)行檢測(cè)。 走查 (Walkthrough) 一對(duì)一的審查，比審查更加仔細(xì)。 回顧(Review) 以發(fā)現(xiàn)軟件中存在的錯(cuò)誤和缺陷為目的的一種軟件測(cè)試方法，它是在軟件證實(shí)執(zhí)行之前完成。,靜態(tài)和動(dòng)態(tài)測(cè)試進(jìn)行結(jié)構(gòu)和功能測(cè)試,測(cè)試技術(shù),黑盒測(cè)試,黑盒測(cè)試也稱(chēng)功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過(guò)測(cè)試來(lái)檢測(cè)每個(gè)功能是否都能正常使用，在測(cè)試時(shí)，把程序看作一個(gè)不能打開(kāi)的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測(cè)試者在程序接口進(jìn)行測(cè)試，它只檢查程序功能是否按照需求規(guī)格說(shuō)明書(shū)的規(guī)定正常使用，程

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

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

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

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

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

11、間，起到“橋梁作用”，一般由開(kāi)發(fā)小組采用白盒加黑盒的方式來(lái)測(cè)試，既要驗(yàn)證“設(shè)計(jì)”又要驗(yàn)證“需求”。,V模型,系統(tǒng)測(cè)試的粒度最大，一般由獨(dú)立測(cè)試小組采用黑盒方式來(lái)測(cè)試，主要測(cè)試系統(tǒng)是否符合“需求規(guī)格說(shuō)明書(shū)”。 驗(yàn)收測(cè)試與系統(tǒng)測(cè)試非常相似，主要區(qū)別是測(cè)試人員不同，驗(yàn)收測(cè)試由用戶(hù)執(zhí)行。,測(cè)試內(nèi)容,測(cè)試內(nèi)容一般包含 接口與路徑測(cè)試。 功能測(cè)試、健壯性測(cè)試、性能測(cè)試、用戶(hù)界面測(cè)試、安全性測(cè)試、壓力測(cè)試、可靠性測(cè)試、安裝/反安裝測(cè)試,測(cè)試階段對(duì)應(yīng)表,接口與路徑測(cè)試 3-1,接口測(cè)試：數(shù)據(jù)一般通過(guò)接口輸入和輸出，接口測(cè)試一般是白盒測(cè)試的第一步。 輸入?yún)?shù)有“典型值”、“邊界值”、“異常值” 輸出包括函數(shù)的返

12、回值和輸出參數(shù)。 實(shí)際輸出與期望的輸出不一致，那么說(shuō)明程序有錯(cuò)誤。 一個(gè)函數(shù)體內(nèi)的語(yǔ)句可能只有十幾條，但邏輯路徑可能有成千上萬(wàn)條。所以應(yīng)該根據(jù)經(jīng)驗(yàn)選擇關(guān)鍵的路徑測(cè)試。,接口與路徑測(cè)試 3-2,路徑測(cè)試的檢查表 數(shù)據(jù)類(lèi)型、變量值、邏輯判斷、循環(huán)、內(nèi)存管理、文件I/O、錯(cuò)誤處理 預(yù)防一些重要的路徑?jīng)]有被測(cè)試的措施有： 觀察是否有程序語(yǔ)句從來(lái)沒(méi)有被執(zhí)行過(guò)。 要特別留意函數(shù)體內(nèi)的錯(cuò)誤處理程序塊。,接口與路徑測(cè)試 3-3,接口與路徑測(cè)試用例的參考模板,功能測(cè)試 3-1,功能測(cè)試的基本方法是構(gòu)造一些合理輸入（在需求范圍之內(nèi)），檢查輸出是否與期望的相同。如果兩者不一致，即表明功能有誤。 難點(diǎn)在于如何構(gòu)造有效

13、的輸入。,功能測(cè)試 3-2,功能測(cè)試的測(cè)試方法：等價(jià)劃分法和邊界值分析法。 等價(jià)劃分是指把輸入空間劃分為幾個(gè)“等價(jià)區(qū)間”，在每個(gè)“等價(jià)區(qū)間”中只需要測(cè)試一個(gè)典型值就可以了。等價(jià)劃分法來(lái)源于人們的直覺(jué)與經(jīng)驗(yàn)，可令測(cè)試事半功倍。 “缺陷遺漏在角落里，聚集在邊界上”。邊界值測(cè)試法是對(duì)等價(jià)劃分法的補(bǔ)充。如果A和B是輸入空間的邊界值，那么除了典型值外還要用A和B作為測(cè)試用例。,功能測(cè)試 3-3,功能測(cè)試用例的參考模板,性能測(cè)試 3-1,性能測(cè)試即測(cè)試軟件處理事務(wù)的速度，一是為了檢驗(yàn)性能是否符合需求，二是為了得到某些性能數(shù)據(jù)供人們參考。 絕對(duì)值考慮：如數(shù)據(jù)送輸速率是每秒多少比特。 “相對(duì)值”考慮：如某個(gè)軟

14、件比另一個(gè)軟件快多少倍。 性能測(cè)試中考慮運(yùn)行環(huán)境的影響：例如網(wǎng)絡(luò)環(huán)境、計(jì)算機(jī)主頻，總線結(jié)構(gòu)和外部設(shè)備都可能影響軟件的運(yùn)行速度。,性能測(cè)試 3-2,性能測(cè)試的一些注意事項(xiàng)： 應(yīng)當(dāng)編寫(xiě)一段程序用于計(jì)算時(shí)間以及相關(guān)數(shù)據(jù)。 應(yīng)當(dāng)測(cè)試軟件在標(biāo)準(zhǔn)配置和最低配置下的性能。 應(yīng)當(dāng)關(guān)閉那些消耗內(nèi)存、占用CPU的其它應(yīng)用軟件（如殺毒軟件）。 應(yīng)當(dāng)分檔記錄。例如傳輸文件的容量從100K到1M可以分成若干等級(jí)。 同一種輸入情況在不同的時(shí)間可能得到不同的性能數(shù)據(jù)，可以取其平均值。,性能測(cè)試 3-3,性能測(cè)試用例的參考模板,壓力測(cè)試 2-1,壓力測(cè)試也叫負(fù)荷測(cè)試，即獲取系統(tǒng)能正常運(yùn)行的極限狀態(tài)。 壓力測(cè)試的主要任務(wù)是：構(gòu)

15、造正確的輸入，使勁折騰系統(tǒng)卻讓它剛好不癱瘓。 壓力測(cè)試的一個(gè)變種是敏感測(cè)試。在某種情況下，微小的輸入變動(dòng)會(huì)導(dǎo)致系統(tǒng)的表現(xiàn)（如性能）發(fā)生急劇的變化。,壓力測(cè)試 2-2,壓力測(cè)試用例的參考模板,其他測(cè)試內(nèi)容,健壯性測(cè)試 用戶(hù)界面測(cè)試 信息安全測(cè)試 可靠性測(cè)試 安裝和反安裝測(cè)試,問(wèn)題1：有了“黑盒”測(cè)試為什么還要“白盒”測(cè)試？ 問(wèn)題2：由于單元測(cè)試要寫(xiě)測(cè)試驅(qū)動(dòng)程序，非常麻煩，能否等到整個(gè)系統(tǒng)全部開(kāi)發(fā)完后，再集中精力進(jìn)行一次性地單元測(cè)試呢？ 問(wèn)題3：如果每個(gè)單元都通過(guò)了測(cè)試，把它們集成一起難道會(huì)有什么不妥嗎？集成測(cè)試是否多此一舉？,測(cè)試常見(jiàn)問(wèn)題 2-1,測(cè)試常見(jiàn)問(wèn)題 2-2,問(wèn)題4：在集成測(cè)試的時(shí)候，

16、已經(jīng)對(duì)一些子系統(tǒng)進(jìn)行了功能測(cè)試、性能測(cè)試等等，那么在系統(tǒng)測(cè)試時(shí)能否跳過(guò)相同內(nèi)容的測(cè)試? 問(wèn)題5：既然系統(tǒng)測(cè)試與驗(yàn)收測(cè)試的內(nèi)容幾乎是相同的，為什么還要驗(yàn)收測(cè)試？ 問(wèn)題6：能否將系統(tǒng)測(cè)試和驗(yàn)收測(cè)試“合二為一”？,總結(jié) 2-1,測(cè)試可以將測(cè)試描述為一個(gè)運(yùn)行程序以發(fā)現(xiàn)錯(cuò)誤的過(guò)程。 軟件測(cè)試的準(zhǔn)則:不完全測(cè)試、風(fēng)險(xiǎn)測(cè)試、無(wú)法顯示潛伏錯(cuò)誤、發(fā)現(xiàn)錯(cuò)誤成線性增長(zhǎng)、缺陷不能完全修復(fù)、測(cè)試有條理規(guī)程 測(cè)試的方法:黑盒/白盒、靜態(tài)/動(dòng)態(tài) 軟件測(cè)試的各個(gè)階段：?jiǎn)卧獪y(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試,總結(jié) 2-2,測(cè)試的內(nèi)容包括：接口/路徑測(cè)試、功能測(cè)試、性能測(cè)試、壓力測(cè)試、可靠性測(cè)試、安全性測(cè)試、用戶(hù)界面測(cè)試、安裝/

17、反安裝測(cè)試,X模型,測(cè)試驅(qū)動(dòng)開(kāi)發(fā),TDD, Test-Driven Development 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)以測(cè)試作為開(kāi)發(fā)過(guò)程的中心，它要求在編寫(xiě)任何代碼之前，首先編寫(xiě)用于定義產(chǎn)品代碼行為的測(cè)試，而編寫(xiě)的產(chǎn)品代碼又以使測(cè)試通過(guò)為目標(biāo)。測(cè)試驅(qū)動(dòng)開(kāi)發(fā)要求測(cè)試可以完全自動(dòng)地運(yùn)行，在代碼進(jìn)行重構(gòu)前必須運(yùn)行測(cè)試。,TDD基本做法,1. 寫(xiě)一個(gè)測(cè)試程序。 2. 讓程序編譯通過(guò)。 3. 運(yùn)行測(cè)試程序，發(fā)現(xiàn)不能運(yùn)行。 4. 讓測(cè)試程序可以運(yùn)行。 5. 消除重復(fù)設(shè)計(jì)，優(yōu)化設(shè)計(jì)結(jié)構(gòu)。,測(cè)試產(chǎn)品說(shuō)明書(shū),對(duì)于產(chǎn)品說(shuō)明書(shū)的制定是個(gè)很重要的設(shè)計(jì)階段，產(chǎn)品說(shuō)明書(shū)的質(zhì)量會(huì)直接影響到整個(gè)產(chǎn)品開(kāi)發(fā)。 測(cè)試產(chǎn)品說(shuō)明書(shū)屬于靜態(tài)黑盒子測(cè)試

18、。,常用測(cè)試用語(yǔ)測(cè)試用例,測(cè)試用例：編寫(xiě)用于輸入輸入的實(shí)際數(shù)制和預(yù)期結(jié)果。測(cè)試用例還明確指出使用具體測(cè)試用例產(chǎn)生的測(cè)試程序的任何限制 。 使用目的： 測(cè)試用例應(yīng)該設(shè)計(jì)為能夠快速容易地發(fā)現(xiàn)盡可能多的錯(cuò)誤。 應(yīng)該通過(guò)使用和產(chǎn)生正確和錯(cuò)誤的輸入和輸出來(lái)“檢驗(yàn)”程序。 其目標(biāo)是要使用合理范圍內(nèi)的條件，盡可能全面地測(cè)試所有模塊乃至整個(gè)系統(tǒng)。,測(cè)試與調(diào)試什么是缺陷,缺陷：最終產(chǎn)品同用戶(hù)的期望不一致 缺陷的分類(lèi) 錯(cuò)誤 遺漏 超出需求的部分 缺陷（未觸發(fā)）VS.錯(cuò)誤（應(yīng)首先解決）,測(cè)試與調(diào)試調(diào)試的準(zhǔn)則,調(diào)試的方法：歸納法、演繹法和回溯法。 常用調(diào)試技術(shù)使用診斷輸出語(yǔ)句 (diagnostic output s

19、tatement)、快照轉(zhuǎn)儲(chǔ) (snapshot dump) 以及跟蹤指令的斷點(diǎn) (instruction-dependent breakpoint)。,二、單元測(cè)試基本理論,什么是單元測(cè)試(Unit Test) 什么時(shí)候測(cè)試？ 為什么要進(jìn)行單元測(cè)試 C/C+單元測(cè)試問(wèn)答（摘要）,單元測(cè)試(Unit Test),工廠在組裝一臺(tái)電視機(jī)之前，會(huì)對(duì)每個(gè)元件都進(jìn)行測(cè)試，這，就是單元測(cè)試。 臨時(shí)單元測(cè)試：代碼覆蓋率要超過(guò)70%都很困難 充分的單元測(cè)試：提高軟件質(zhì)量，降低開(kāi)發(fā)成本的必由之路。 單元測(cè)試是在軟件開(kāi)發(fā)過(guò)程中要進(jìn)行的最低級(jí)別的測(cè)試活動(dòng)，在單元測(cè)試活動(dòng)中，軟件的獨(dú)立單元將在與程序的其他部分相隔離的

20、情況下進(jìn)行測(cè)試。,單元測(cè)試(Unit Test),對(duì)于程序員來(lái)說(shuō)，如果養(yǎng)成了對(duì)自己寫(xiě)的代碼進(jìn)行單元測(cè)試的習(xí)慣，不但可以寫(xiě)出高質(zhì)量的代碼，而且還能提高編程水平。 在一種傳統(tǒng)的結(jié)構(gòu)化編程語(yǔ)言中，比如C，要進(jìn)行測(cè)試的單元一般是函數(shù)或子過(guò)程。在象C+這樣的面向?qū)ο蟮恼Z(yǔ)言中，要進(jìn)行測(cè)試的基本單元是類(lèi)。對(duì)Ada語(yǔ)言來(lái)說(shuō)，開(kāi)發(fā)人員可以選擇是在獨(dú)立的過(guò)程和函數(shù)，還是在Ada包的級(jí)別上進(jìn)行單元測(cè)試。單元測(cè)試的原則同樣被擴(kuò)展到第四代語(yǔ)言(4GL)的開(kāi)發(fā)中，在這里基本單元被典型地劃分為一個(gè)菜單或顯示界面。,單元測(cè)試(Unit Test),單元測(cè)試不僅僅是作為無(wú)錯(cuò)編碼一種輔助手段在一次性的開(kāi)發(fā)過(guò)程中使用，單元測(cè)試必須

21、是可重復(fù)的，無(wú)論是在軟件修改，或是移植到新的運(yùn)行環(huán)境的過(guò)程中。因此，所有的測(cè)試都必須在整個(gè)軟件系統(tǒng)的生命周期中進(jìn)行維護(hù)。,三、為什么要 進(jìn)行單元測(cè)試,一些流行的誤解-反調(diào)論證 其他好處 單元測(cè)試的重要性,反證1：?jiǎn)卧獪y(cè)試?yán)速M(fèi)了太多的時(shí)間,一旦編碼完成，開(kāi)發(fā)人員總是會(huì)迫切希望進(jìn)行軟件的集成工作，這樣他們就能夠看到實(shí)際的系統(tǒng)開(kāi)始啟動(dòng)工作了。 這在外表上看來(lái)是一項(xiàng)明顯的進(jìn)步，而象單元測(cè)試這樣的活動(dòng)也許會(huì)被看作是通往這個(gè)階段點(diǎn)的道路上的障礙， 推遲了對(duì)整個(gè)系統(tǒng)進(jìn)行聯(lián)調(diào)這種真正有意思的工作啟動(dòng)的時(shí)間。,反證1：?jiǎn)卧獪y(cè)試?yán)速M(fèi)了太多的時(shí)間,在這種開(kāi)發(fā)步驟中，真實(shí)意義上的進(jìn)步被外表上的進(jìn)步取代了。系統(tǒng)能夠正常

22、工作的可能性是很小的，更多的情況是充滿(mǎn)了各式各樣的Bug。在實(shí)踐中，這樣一種開(kāi)發(fā)步驟常常會(huì)導(dǎo)致這樣的結(jié)果：軟件甚至無(wú)法運(yùn)行。更進(jìn)一步的結(jié)果是大量的時(shí)間將被花費(fèi)在跟蹤那些包含在獨(dú)立單元里的簡(jiǎn)單的Bug上面，在個(gè)別情況下，這些Bug也許是瑣碎和微不足道的，但是總的來(lái)說(shuō)，他們會(huì)導(dǎo)致在軟件集成為一個(gè)系統(tǒng)時(shí)增加額外的工期， 而且當(dāng)這個(gè)系統(tǒng)投入使用時(shí)也無(wú)法確保它能夠可靠運(yùn)行。,反證1：?jiǎn)卧獪y(cè)試?yán)速M(fèi)了太多的時(shí)間,在實(shí)踐工作中，進(jìn)行了完整計(jì)劃的單元測(cè)試和編寫(xiě)實(shí)際的代碼所花費(fèi)的精力大致上是相同的。一旦完成了這些單元測(cè)試工作，很多Bug將被糾正，在確信他們手頭擁有穩(wěn)定可靠的部件的情況下，開(kāi)發(fā)人員能夠進(jìn)行更高效的系

23、統(tǒng)集成工作。這才是真實(shí)意義上的進(jìn)步，所以說(shuō)完整計(jì)劃下的單元測(cè)試是對(duì)時(shí)間的更高效的利用。而調(diào)試人員的不受控和散漫的工作方式只會(huì)花費(fèi)更多的時(shí)間而取得很少的好處。 使用AdaTEST和Cantata這樣的支持工具可以使單元測(cè)試更加簡(jiǎn)單和有效。但這不是必須的，單元測(cè)試即使是在沒(méi)有工具支持的情況下也是一項(xiàng)非常有意義的活動(dòng)。,反證2：僅僅證明代碼做了什么,這是那些沒(méi)有首先為每個(gè)單元編寫(xiě)一個(gè)詳細(xì)的規(guī)格說(shuō)明而直接跳到編碼階段的開(kāi)發(fā)人員提出的一條普遍的抱怨， 當(dāng)編碼完成以后并且面臨代碼測(cè)試任務(wù)的時(shí)候，他們就閱讀這些代碼并找出它實(shí)際上做了什么，把他們的測(cè)試工作基于已經(jīng)寫(xiě)好的代碼的基礎(chǔ)上。當(dāng)然，他們無(wú)法證明任何事情

24、。所有的這些測(cè)試工作能夠表明的事情就是編譯器工作正常。是的，他們也許能夠抓住(希望能夠)罕見(jiàn)的編譯器Bug，但是他們能夠做的僅僅是這些。,反證2：僅僅證明代碼做了什么,如果他們首先寫(xiě)好一個(gè)詳細(xì)的規(guī)格說(shuō)明，測(cè)試能夠以規(guī)格說(shuō)明為基礎(chǔ)。代碼就能夠針對(duì)它的規(guī)格說(shuō)明，而不是針對(duì)自身進(jìn)行測(cè)試。這樣的測(cè)試仍然能夠抓住編譯器的Bug，同時(shí)也能找到更多的編碼錯(cuò)誤，甚至是一些規(guī)格說(shuō)明中的錯(cuò)誤。好的規(guī)格說(shuō)明可以使測(cè)試的質(zhì)量更高，所以最后的結(jié)論是高質(zhì)量的測(cè)試需要高質(zhì)量的規(guī)格說(shuō)明。,反證2：僅僅證明代碼做了什么,在實(shí)踐中會(huì)出現(xiàn)這樣的情況： 一個(gè)開(kāi)發(fā)人員要面對(duì)測(cè)試一個(gè)單元時(shí)只給出單元的代碼而沒(méi)有規(guī)格說(shuō)明這樣吃力不討好的任

25、務(wù)。你怎樣做才會(huì)有更多的收獲，而不僅僅是發(fā)現(xiàn)編譯器的Bug？第一步是理解這個(gè)單元原本要做什么， - 不是它實(shí)際上做了什么。 比較有效的方法是倒推出一個(gè)概要的規(guī)格說(shuō)明。這個(gè)過(guò)程的主要輸入條件是要閱讀那些程序代碼和注釋?zhuān)?主要針對(duì)這個(gè)單元， 及調(diào)用它和被它調(diào)用的相關(guān)代碼。畫(huà)出流程圖是非常有幫助的，你可以用手工或使用某種工具。 可以組織對(duì)這個(gè)概要規(guī)格說(shuō)明的走讀(Review)，以確保對(duì)這個(gè)單元的說(shuō)明沒(méi)有基本的錯(cuò)誤， 有了這種最小程度的代碼深層說(shuō)明，就可以用它來(lái)設(shè)計(jì)單元測(cè)試了。,反證3：我是個(gè)很棒的程序員， 我是不是可以不進(jìn)行單元測(cè)試？,在每個(gè)開(kāi)發(fā)組織中都至少有一個(gè)這樣的開(kāi)發(fā)人員，他非常擅長(zhǎng)于編程，他

26、們開(kāi)發(fā)的軟件總是在第一時(shí)間就可以正常運(yùn)行，因此不需要進(jìn)行測(cè)試。你是否經(jīng)常聽(tīng)到這樣的借口？ 在真實(shí)世界里，每個(gè)人都會(huì)犯錯(cuò)誤。即使某個(gè)開(kāi)發(fā)人員可以抱著這種態(tài)度在很少的一些簡(jiǎn)單的程序中應(yīng)付過(guò)去。 但真正的軟件系統(tǒng)是非常復(fù)雜的。真正的軟件系統(tǒng)不可以寄希望于沒(méi)有進(jìn)行廣泛的測(cè)試和Bug修改過(guò)程就可以正常工作。 編碼不是一個(gè)可以一次性通過(guò)的過(guò)程。在真實(shí)世界中，軟件產(chǎn)品必須進(jìn)行維護(hù)以對(duì)操作需求的改變作出反應(yīng)， 并且要對(duì)最初的開(kāi)發(fā)工作遺留下來(lái)的Bug進(jìn)行修改。你希望依靠那些原始作者進(jìn)行修改嗎？ 這些制造出這些未經(jīng)測(cè)試的原始代碼的資深專(zhuān)家們還會(huì)繼續(xù)在其他地方制造這樣的代碼。在開(kāi)發(fā)人員做出修改后進(jìn)行可重復(fù)的單元測(cè)試

27、可以避免產(chǎn)生那些令人不快的負(fù)作用。,反證4：不管怎樣， 集成測(cè)試將會(huì)抓住所有的Bug ？,我們已經(jīng)在前面的討論中從一個(gè)側(cè)面對(duì)這個(gè)問(wèn)題進(jìn)行了部分的闡述。這個(gè)論點(diǎn)不成立的原因在于規(guī)模越大的代碼集成意味著復(fù)雜性就越高。如果軟件的單元沒(méi)有事先進(jìn)行測(cè)試，開(kāi)發(fā)人員很可能會(huì)花費(fèi)大量的時(shí)間僅僅是為了使軟件能夠運(yùn)行，而任何實(shí)際的測(cè)試方案都無(wú)法執(zhí)行。 一旦軟件可以運(yùn)行了，開(kāi)發(fā)人員又要面對(duì)這樣的問(wèn)題： 在考慮軟件全局復(fù)雜性的前提下對(duì)每個(gè)單元進(jìn)行全面的測(cè)試。 這是一件非常困難的事情，甚至在創(chuàng)造一種單元調(diào)用的測(cè)試條件的時(shí)候，要全面的考慮單元的被調(diào)用時(shí)的各種入口參數(shù)。在軟件集成階段，對(duì)單元功能全面測(cè)試的復(fù)雜程度遠(yuǎn)遠(yuǎn)的超過(guò)

28、獨(dú)立進(jìn)行的單元測(cè)試過(guò)程。 最后的結(jié)果是測(cè)試將無(wú)法達(dá)到它所應(yīng)該有的全面性。一些缺陷將被遺漏，并且很多Bug將被忽略過(guò)去。 讓我們類(lèi)比一下，假設(shè)我們要清洗一臺(tái)已經(jīng)完全裝配好的食物加工機(jī)器!無(wú)論你噴了多少水和清潔劑，一些食物的小碎片還是會(huì)粘在機(jī)器的死角位置，只有任其腐爛并等待以后再想辦法。但我們換個(gè)角度想想，如果這臺(tái)機(jī)器是拆開(kāi)的， 這些死角也許就不存在或者更容易接觸到了，并且每一部分都可以毫不費(fèi)力的進(jìn)行清洗。,反證5：它的成本效率不高,一個(gè)特定的開(kāi)發(fā)組織或軟件應(yīng)用系統(tǒng)的測(cè)試水平取決于對(duì)那些未發(fā)現(xiàn)的Bug的潛在后果的重視程度。這種后果的嚴(yán)重程度可以從一個(gè)Bug引起的小小的不便到發(fā)生多次的死機(jī)的情況。這

29、種后果可能常常會(huì)被軟件的開(kāi)發(fā)人員所忽視(但是用戶(hù)可不會(huì)這樣)，這種情況會(huì)長(zhǎng)期的損害這些向用戶(hù)提交帶有Bug的軟件的開(kāi)發(fā)組織的信譽(yù)，并且會(huì)導(dǎo)致對(duì)未來(lái)的市場(chǎng)產(chǎn)生負(fù)面的影響。相反地，一個(gè)可靠的軟件系統(tǒng)的良好的聲譽(yù)將有助于一個(gè)開(kāi)發(fā)組織獲取未來(lái)的市場(chǎng)。 很多研究成果表明，無(wú)論什么時(shí)候作出修改都要進(jìn)行完整的回歸測(cè)試，在生命周期中盡早地對(duì)軟件產(chǎn)品進(jìn)行測(cè)試將使效率和質(zhì)量得到最好的保證。Bug發(fā)現(xiàn)的越晚，修改它所需的費(fèi)用就越高，因此從經(jīng)濟(jì)角度來(lái)看， 應(yīng)該盡可能早的查找和修改Bug。在修改費(fèi)用變的過(guò)高之前，單元測(cè)試是一個(gè)在早期抓住Bug的機(jī)會(huì)。 相比后階段的測(cè)試，單元測(cè)試的創(chuàng)建更簡(jiǎn)單，維護(hù)更容易，并且可以更方便的

30、進(jìn)行重復(fù)。從全程的費(fèi)用來(lái)考慮， 相比起那些復(fù)雜且曠日持久的集成測(cè)試，或是不穩(wěn)定的軟件系統(tǒng)來(lái)說(shuō)，單元測(cè)試所需的費(fèi)用是很低的。,反證5：它的成本效率不高,摘自(Capers Jones，McGraw-Hill 1991)，它列出了準(zhǔn)備測(cè)試，執(zhí)行測(cè)試，和修改缺陷所花費(fèi)的時(shí)間(以一個(gè)功能點(diǎn)為基準(zhǔn))，這些數(shù)據(jù)顯示單元測(cè)試的成本效率大約是集成測(cè)試的兩倍 系統(tǒng)測(cè)試的三倍。,反證5：它的成本效率不高,(術(shù)語(yǔ)域測(cè)試(Field test)意思是在軟件投入使用以后，針對(duì)某個(gè)領(lǐng)域所作的所有測(cè)試活動(dòng)) 這個(gè)圖表并不表示開(kāi)發(fā)人員不應(yīng)該進(jìn)行后階段的測(cè)試活動(dòng)，這次測(cè)試活動(dòng)仍然是必須的。它的真正意思是盡可能早的排除盡可能多的

31、Bug可以減少后階段測(cè)試的費(fèi)用。 其他的一些圖表顯示高達(dá)50%的維護(hù)工作量被花在那些總是會(huì)有的Bug的修改上面。如果這些Bug在開(kāi)發(fā)階段被排除掉的話，這些工作量就可以節(jié)省下來(lái)。當(dāng)考慮到軟件維護(hù)費(fèi)用可能會(huì)比最初的開(kāi)發(fā)費(fèi)用高出數(shù)倍的時(shí)候，這種潛在的對(duì)50%軟件維護(hù)費(fèi)用的節(jié)省將對(duì)整個(gè)軟件生命周期費(fèi)用產(chǎn)生重大的影響。,反證 結(jié)論,經(jīng)驗(yàn)表明一個(gè)盡責(zé)的單元測(cè)試方法將會(huì)在軟件開(kāi)發(fā)的某個(gè)階段發(fā)現(xiàn)很多的Bug，并且修改它們的成本也很低。在軟件開(kāi)發(fā)的后期階段，Bug的發(fā)現(xiàn)并修改將會(huì)變得更加困難，并要消耗大量的時(shí)間和開(kāi)發(fā)費(fèi)用。無(wú)論什么時(shí)候作出修改都要進(jìn)行完整的回歸測(cè)試，在生命周期中盡早地對(duì)軟件產(chǎn)品進(jìn)行測(cè)試將使效率和

32、質(zhì)量得到最好的保證。 在提供了經(jīng)過(guò)測(cè)試的單元的情況下，系統(tǒng)集成過(guò)程將會(huì)大大地簡(jiǎn)化。開(kāi)發(fā)人員可以將精力集中在單元之間的交互作用和全局的功能實(shí)現(xiàn)上，而不是陷入充滿(mǎn)很多Bug的單元之中不能自拔。 使測(cè)試工作的效力發(fā)揮到最大化的關(guān)鍵在于選擇正確的測(cè)試策略，這其中包含了完全的單元測(cè)試的概念，以及對(duì)測(cè)試過(guò)程的良好的管理，還有適當(dāng)?shù)厥褂孟驛daTEST和Cantata這樣的工具來(lái)支持測(cè)試過(guò)程。這些活動(dòng)可以產(chǎn)生這樣的結(jié)果：在花費(fèi)更低的開(kāi)發(fā)費(fèi)用的情況下得到更穩(wěn)定的軟件。更進(jìn)一步的好處是簡(jiǎn)化了維護(hù)過(guò)程并降低了生命周期的費(fèi)用。有效的單元測(cè)試是推行全局質(zhì)量文化的一部分，而這種質(zhì)量文化將會(huì)為軟件開(kāi)發(fā)者帶來(lái)無(wú)限的商機(jī)。,

33、其他好處 1：減少程序的Bug,要減少軟件中的錯(cuò)誤數(shù)目，方法之一就是擁有一個(gè)專(zhuān)業(yè)的測(cè)試組，其工作就是盡一切可能使軟件崩潰。不幸的是，如果擁有測(cè)試組，那么即使是經(jīng)驗(yàn)豐富的開(kāi)發(fā)人員，也會(huì)傾向于花費(fèi)較少的時(shí)間來(lái)保證代碼的可靠性。 軟件界有一句俗語(yǔ)：“開(kāi)發(fā)人員不應(yīng)該測(cè)試他們自己的代碼”。這是因?yàn)殚_(kāi)發(fā)人員對(duì)自己的代碼了如指掌，他們很清楚如何采用適當(dāng)?shù)姆椒▽?duì)代碼進(jìn)行測(cè)試。盡管這句俗語(yǔ)很有道理，但卻忽略了非常重要的一點(diǎn) - 如果開(kāi)發(fā)人員不對(duì)自己的代碼進(jìn)行測(cè)試，又如何知道代碼能否按照預(yù)期的方式運(yùn)行？ 簡(jiǎn)單說(shuō)來(lái)，他們根本無(wú)從得知。開(kāi)發(fā)人員編寫(xiě)那種運(yùn)行不正常或只在某些情況下運(yùn)行正常的代碼是一個(gè)嚴(yán)重的問(wèn)題。他們通常

34、只測(cè)試代碼能否在很少的情況下正常運(yùn)行，而不是驗(yàn)證代碼能夠在所有情況下均正常運(yùn)行。,其他好處 2：提高開(kāi)發(fā)速度,在實(shí)踐工作中，進(jìn)行了完整計(jì)劃的單元測(cè)試和編寫(xiě)實(shí)際的代碼所花費(fèi)的精力大致上是相同的。一旦完成了這些單元測(cè)試工作，很多Bug將被糾正，在確信他們手頭擁有穩(wěn)定可靠的部件的情況下，開(kāi)發(fā)人員能夠進(jìn)行更高效的系統(tǒng)集成工作。這才是真實(shí)意義上的進(jìn)步，所以說(shuō)完整計(jì)劃下的單元測(cè)試是對(duì)時(shí)間的更高效的利用。而調(diào)試人員的不受控和散漫的工作方式只會(huì)花費(fèi)更多的時(shí)間而取得很少的好處。 經(jīng)驗(yàn)表明一個(gè)盡責(zé)的單元測(cè)試方法將會(huì)在軟件開(kāi)發(fā)的某個(gè)階段發(fā)現(xiàn)很多的Bug，并且修改它們的成本也很低。在軟件開(kāi)發(fā)的后期階段，Bug的發(fā)現(xiàn)并

35、修改將會(huì)變得更加困難，并要消耗大量的時(shí)間和開(kāi)發(fā)費(fèi)用。無(wú)論什么時(shí)候作出修改都要進(jìn)行完整的回歸測(cè)試，在生命周期中盡早地對(duì)軟件產(chǎn)品進(jìn)行測(cè)試將使效率和質(zhì)量得到最好的保證。 在提供了經(jīng)過(guò)測(cè)試的單元的情況下，系統(tǒng)集成過(guò)程將會(huì)大大地簡(jiǎn)化。開(kāi)發(fā)人員可以將精力集中在單元之間的交互作用和全局的功能實(shí)現(xiàn)上，而不是陷入充滿(mǎn)很多Bug的單元之中不能自拔。,其他好處 3：使程序代碼更整潔，優(yōu)化程序的設(shè)計(jì),只有自動(dòng)的單元測(cè)試程序失敗時(shí)，我們才會(huì)去重寫(xiě)代碼，在測(cè)試驅(qū)動(dòng)開(kāi)發(fā)中，要求我們對(duì)程序不停的重構(gòu)，通過(guò)重構(gòu)，我們可以?xún)?yōu)化程序的結(jié)構(gòu)設(shè)計(jì)，消除程序中潛在的錯(cuò)誤。同時(shí)，為了能夠使自己的程序可以很方便的進(jìn)行測(cè)試，開(kāi)發(fā)人員就需要很好

36、地考慮程序的設(shè)計(jì)，極限編程的方法說(shuō)可以不需要設(shè)計(jì)就開(kāi)始編碼，但實(shí)際上，它在編寫(xiě)代碼的過(guò)程中每時(shí)每刻都為了方便的進(jìn)行和通過(guò)測(cè)試而在優(yōu)化自己的設(shè)計(jì)。它實(shí)際上是把開(kāi)始階段很大很抽象的設(shè)計(jì)分散到你編寫(xiě)的每個(gè)方法中。因此他們會(huì)說(shuō)好設(shè)計(jì)最后會(huì)自然而然的出現(xiàn)。,其他好處 4：編寫(xiě)單元測(cè)試代碼的過(guò)程實(shí)際上就是設(shè)計(jì)程序的過(guò)程,在編寫(xiě)單元測(cè)試代碼時(shí)，我們實(shí)際上是在思考我們的程序根據(jù)預(yù)期會(huì)返回什么結(jié)果，它實(shí)際上就是程序設(shè)計(jì)的過(guò)程。而通過(guò)重構(gòu)過(guò)程，我們可以對(duì)這些設(shè)計(jì)進(jìn)行很好的優(yōu)化。,單元測(cè)試的重要性,單元測(cè)試是軟件測(cè)試的基礎(chǔ)，因此單元測(cè)試的效果會(huì)直接影響到軟件的后期測(cè)試，最終在很大程度上影響到產(chǎn)品的質(zhì)量。 時(shí)間方面

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

38、還會(huì)發(fā)現(xiàn)一些很容易發(fā)現(xiàn)而在集成測(cè)試和系統(tǒng)測(cè)試很難發(fā)現(xiàn)的問(wèn)題。再次單元測(cè)試關(guān)注的范圍也特殊，它不僅僅是證明這些代碼做了什么，最重要的是代碼是如何做的，是否做了它該做的事情而沒(méi)有做不該做的事情。,重要性 3：測(cè)試成本,在單元測(cè)試時(shí)某些問(wèn)題就很容易發(fā)現(xiàn)，如果在后期的測(cè)試中發(fā)現(xiàn)問(wèn)題所花的成本將成倍數(shù)上升。比如在單元測(cè)試時(shí)發(fā)現(xiàn)1個(gè)問(wèn)題需要1個(gè)小時(shí)，則在集成測(cè)試時(shí)發(fā)現(xiàn)該問(wèn)題需要2個(gè)小時(shí)，在系統(tǒng)測(cè)試時(shí)發(fā)現(xiàn)則需要3個(gè)小時(shí)，同理還有定位問(wèn)題和解決問(wèn)題的費(fèi)用也是成倍數(shù)上升的，這就是我們要盡可能早的排除盡可能多的bug來(lái)減少后期成本的因素之一。,重要性 4：產(chǎn)品質(zhì)量,單元測(cè)試的好與壞直接影響到產(chǎn)品的質(zhì)量，可能就是由

39、于代碼中的某一個(gè)小錯(cuò)誤就導(dǎo)致了整個(gè)產(chǎn)品的質(zhì)量降低一個(gè)指標(biāo)，或者導(dǎo)致更嚴(yán)重的后果，如果我們做好了單元測(cè)試這種情況是可以完全避免的。 綜上所述，單元測(cè)試是構(gòu)筑產(chǎn)品質(zhì)量的基石，我們不要因?yàn)楣?jié)約單元測(cè)試的時(shí)間不做單元測(cè)試或隨便做而讓我們?cè)诤笃诶速M(fèi)太多的不值得的時(shí)間，我們也不愿意因?yàn)橛捎诠?jié)約那些時(shí)間導(dǎo)致開(kāi)發(fā)出來(lái)的整個(gè)產(chǎn)品失敗或重來(lái)！,四、 C/C+單元測(cè)試問(wèn)答,為什么要進(jìn)行單元測(cè)試? 由誰(shuí)進(jìn)行測(cè)試？開(kāi)發(fā)部門(mén)還是測(cè)試部門(mén)？ 由測(cè)試部門(mén)進(jìn)行單元測(cè)試為什么成本昂貴？ 由開(kāi)發(fā)部門(mén)進(jìn)行單元測(cè)試能保證測(cè)試效果嗎？ 邊編碼邊測(cè)試會(huì)影響編碼進(jìn)度嗎？ 實(shí)施單元測(cè)試需要改變開(kāi)發(fā)流程嗎？ 單元測(cè)試測(cè)試哪些代碼？ 實(shí)際工作中，

40、單元測(cè)試能實(shí)現(xiàn)什么程度的測(cè)試覆蓋？ 單元測(cè)試如何改良項(xiàng)目代碼的整體結(jié)構(gòu)？ 我希望依賴(lài)全自動(dòng)的工具來(lái)完成單元測(cè)試，這一想法現(xiàn)實(shí)嗎？ 如果由開(kāi)發(fā)部門(mén)實(shí)施單元測(cè)試，那么測(cè)試部門(mén)要做哪些工作？,http:/www.KaileS,為什么要進(jìn)行單元測(cè)試?,單元測(cè)試保證局部代碼的質(zhì)量 單元測(cè)試改良項(xiàng)目代碼的整體結(jié)構(gòu) 單元測(cè)試降低測(cè)試、維護(hù)升級(jí)的成本 單元測(cè)試使開(kāi)發(fā)過(guò)程適應(yīng)頻繁變化的需求 單元測(cè)試有助于提升程序員的能力,由誰(shuí)進(jìn)行測(cè)試？開(kāi)發(fā)部門(mén)/測(cè)試部門(mén)？,應(yīng)該由開(kāi)發(fā)部門(mén)進(jìn)行單元測(cè)試！ 由測(cè)試部門(mén)進(jìn)行單元測(cè)試的問(wèn)題：代價(jià)高，人手不足，耽誤了測(cè)試部門(mén)對(duì)其他測(cè)試的準(zhǔn)備工作。 由開(kāi)發(fā)部門(mén)進(jìn)行單元測(cè)試的問(wèn)題：擔(dān)心影響開(kāi)

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

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

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

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

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

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

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

48、認(rèn)識(shí)不到其重要性和必要性，需要由測(cè)試部門(mén)推動(dòng)和協(xié)助組織實(shí)施。 制定單元測(cè)試規(guī)范，培訓(xùn)單元測(cè)試技術(shù)。 檢查、審核單元測(cè)試結(jié)果，保證單元測(cè)試的有效性。,五、單元測(cè)試工具,測(cè)試工具的分類(lèi)和選擇 Parasoft Compuware Rational AutomatedQA AQTime xUnit系列 Visual Studio 2005 Visual Unit,測(cè)試工具的分類(lèi)和選擇,白盒測(cè)試工具 靜態(tài)測(cè)試工具 動(dòng)態(tài)測(cè)試工具 黑盒測(cè)試工具 功能測(cè)試工具 性能測(cè)試工具 測(cè)試管理工具 其他測(cè)試工具 測(cè)試工具的選擇,白盒測(cè)試工具,白盒測(cè)試工具一般是針對(duì)代碼進(jìn)行測(cè)試，測(cè)試中發(fā)現(xiàn)的缺陷可以定位到代碼級(jí) 靜態(tài)測(cè)

49、試工具直接對(duì)代碼進(jìn)行分析，不需要運(yùn)行代碼，也不需要對(duì)代碼編譯鏈接，生成可執(zhí)行文件。靜態(tài)測(cè)試工具一般是對(duì)代碼進(jìn)行語(yǔ)法掃描，找出不符合編碼規(guī)范的地方，根據(jù)某種質(zhì)量模型評(píng)價(jià)代碼的質(zhì)量，生成系統(tǒng)的調(diào)用關(guān)系圖等。 動(dòng)態(tài)測(cè)試工具與靜態(tài)測(cè)試工具不同，動(dòng)態(tài)測(cè)試工具的一般采用“插樁”的方式，向代碼生成的可執(zhí)行文件中插入一些監(jiān)測(cè)代碼，用來(lái)統(tǒng)計(jì)程序運(yùn)行時(shí)的數(shù)據(jù)。其與靜態(tài)測(cè)試工具最大的不同就是動(dòng)態(tài)測(cè)試工具要求被測(cè)系統(tǒng)實(shí)際運(yùn)行。,黑盒測(cè)試工具,黑盒測(cè)試工具適用于黑盒測(cè)試的場(chǎng)合，黑盒測(cè)試工具包括功能測(cè)試工具和性能測(cè)試工具。 黑盒測(cè)試工具的一般原理是利用腳本的錄制(Record)/回放(Playback)，模擬用戶(hù)的操作，

50、然后將被測(cè)系統(tǒng)的輸出記錄下來(lái)同預(yù)先給定的標(biāo)準(zhǔn)結(jié)果比較。黑盒測(cè)試工具可以大大減輕黑盒測(cè)試的工作量，在迭代開(kāi)發(fā)的過(guò)程中，能夠很好地進(jìn)行回歸測(cè)試。 黑盒測(cè)試工具的代表有Rational公司的TeamTest、Robot，Compuware公司的QACenter，另外，專(zhuān)用于性能測(cè)試的工具包括有Radview公司的WebLoad、Microsoft公司的WebStress等工具。,測(cè)試管理工具,測(cè)試管理工具用于對(duì)測(cè)試進(jìn)行管理。 內(nèi)容：對(duì)測(cè)試計(jì)劃、測(cè)試用例、測(cè)試實(shí)施進(jìn)行管理，對(duì)缺陷的跟蹤管理。 測(cè)試管理工具的代表有Rational公司的Test Manager、Compureware公司的TrackRe

51、cord，Mercury的TestDirector和Quality Center等軟件。,測(cè)試工具的選擇,功能 基本的功能 報(bào)表功能 測(cè)試工具的集成能力 操作系統(tǒng)和開(kāi)發(fā)工具的兼容性 價(jià)格 連續(xù)性和一致性： 全盤(pán)考慮，分階段、逐步的引入測(cè)試工具,測(cè)試工具引入中的誤區(qū)分析,沒(méi)有考慮到公司的實(shí)際情況，盲目引入測(cè)試工具 專(zhuān)題分析，引入哪些測(cè)試工具？ 沒(méi)有進(jìn)行有效的測(cè)試工具的培訓(xùn) 測(cè)試工具的培訓(xùn)是一個(gè)長(zhǎng)期的過(guò)程 系列的培訓(xùn)和交流 沒(méi)有形成一個(gè)良好的使用測(cè)試工具的環(huán)境 沒(méi)有能夠形成一種機(jī)制讓測(cè)試工具真正能夠發(fā)揮作用,良好的測(cè)試工具使用環(huán)境,約束機(jī)制,開(kāi)發(fā)流程,例如，單元測(cè)試是由開(kāi)發(fā)人員完成，如果沒(méi)有流程來(lái)

52、規(guī)范開(kāi)發(fā)人員的行為，在項(xiàng)目進(jìn)度壓力比較大的情況下，開(kāi)發(fā)人員很可能就會(huì)有意識(shí)地不使用測(cè)試工具，來(lái)逃避問(wèn)題。在這種情況下，就必須形成一種有約束力的機(jī)制來(lái)強(qiáng)制對(duì)測(cè)試工具的使用。,某公司的一種比較好的方式：將測(cè)試工具的使用明確定義進(jìn)公司的開(kāi)發(fā)流程。在開(kāi)發(fā)流程中明確說(shuō)明，在項(xiàng)目里程碑提交的文檔中必須包括測(cè)試工具生成的報(bào)告，該報(bào)告中的數(shù)據(jù)是決定項(xiàng)目是否合格的依據(jù)。根據(jù)公司的實(shí)際情況，在提交集成測(cè)試時(shí)需要提交DevPartner工具生成的測(cè)試覆蓋率報(bào)告、Logiscope生成的代碼質(zhì)量報(bào)告，并且要求單元測(cè)試的代碼覆蓋率必須達(dá)到80%以上，代碼質(zhì)量評(píng)價(jià)必須在Fair以上。,測(cè)試工具并不是策略,測(cè)試工具并不能教

53、測(cè)試員如何測(cè)試。如果測(cè)試出現(xiàn)問(wèn)題，則測(cè)試工具會(huì)加重問(wèn)題。在實(shí)現(xiàn)測(cè)試過(guò)程自動(dòng)化之前，應(yīng)首先解決測(cè)試過(guò)程中的問(wèn)題。 有些測(cè)試工具帶有測(cè)試策略的建議。但是這種建議很少能夠描述得很清楚，并不能針對(duì)具體情況，而且往往過(guò)于強(qiáng)調(diào)他們那種自動(dòng)化測(cè)試的重要性。 工具是輔助性的，關(guān)鍵還是靠人的思想和行為！,Parasoft,Parasoft Jtest 代碼分析和動(dòng)態(tài)類(lèi)、組件測(cè)試 Parasoft C+Test代碼分析和動(dòng)態(tài)測(cè)試 Parasoft .TEST代碼分析和動(dòng)態(tài)測(cè)試 Parasoft Insure+ 實(shí)時(shí)性能監(jiān)控以及分析優(yōu)化 Parasoft CodeWizard代碼靜態(tài)分析 ,Parasoft Jte

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

55、需編寫(xiě)單個(gè)測(cè)試實(shí)例、測(cè)試驅(qū)動(dòng)程序或樁調(diào)用。只需點(diǎn)擊按鈕，C+Test即會(huì)采用業(yè)內(nèi)編碼標(biāo)準(zhǔn)執(zhí)行代碼的靜態(tài)分析，測(cè)試代碼構(gòu)造（白盒測(cè)試），測(cè)試代碼功能性（黑盒測(cè)試），并保持代碼完整性（回歸測(cè)試）。,Parasoft .TEST,單元測(cè)試和靜態(tài)分析工具，自動(dòng)測(cè)試寫(xiě)在Microsoft?.NET框架的類(lèi)別，而無(wú)需編寫(xiě)單個(gè)測(cè)試場(chǎng)景或樁調(diào)用。只需點(diǎn)擊按鈕，.TEST即會(huì)在.NET源代碼上自動(dòng)執(zhí)行完整系列的靜態(tài)和動(dòng)態(tài)測(cè)試。.TEST RuleWizard性能通過(guò)圖形化表達(dá)希望.TEST在自動(dòng)編碼標(biāo)準(zhǔn)執(zhí)行過(guò)程中查找的模式，支持設(shè)計(jì)定制的編碼標(biāo)準(zhǔn)。,Parasoft Insure+,一個(gè)自動(dòng)化的內(nèi)存錯(cuò)誤、內(nèi)存泄

56、漏的精確檢測(cè)工具。Insure+能夠可視化實(shí)時(shí)內(nèi)存操作，準(zhǔn)確檢測(cè)出內(nèi)存泄漏產(chǎn)生的根源。Insure+還能執(zhí)行覆蓋性分析，清楚地指示那些代碼已經(jīng)測(cè)試過(guò)。將Insure+集成到您的開(kāi)發(fā)環(huán)境中，能夠極大地減少調(diào)試時(shí)間并有效地防止錯(cuò)誤。,Parasoft CodeWizard,高級(jí)C/C+源代碼分析工具，采用三百種以上行業(yè)相關(guān)的編碼準(zhǔn)則，自動(dòng)識(shí)別編譯器未檢測(cè)到的危險(xiǎn)的編碼構(gòu)造。CodeWizard可以容易地通過(guò)RuleWizard性能，創(chuàng)建新定制的準(zhǔn)則，或者抑制用于定制分析的準(zhǔn)則。日常使用CodeWizard，可簡(jiǎn)化代碼檢查，并使代碼更具可讀性和可維護(hù)性。,Compuware白盒測(cè)試工具集, Boun

57、dsChecker C+,Delphi API和OLE錯(cuò)誤檢查、指針和泄露錯(cuò)誤檢查、內(nèi)存錯(cuò)誤檢查 TrueTime C+,Java,Visual Basic 代碼運(yùn)行效率檢查、組件性能的分析 FailSafe Visual Basic 自動(dòng)錯(cuò)誤處理和恢復(fù)系統(tǒng) Jcheck M$ Visual J+ 圖形化的純種和事件分析工具 TrueCoverage C+,Java,Visual Basic 函數(shù)調(diào)用次數(shù)、所占比率統(tǒng)計(jì)以及穩(wěn)定性跟蹤 SmartCheck Visual Basic 函數(shù)調(diào)用次數(shù)、所占比率統(tǒng)計(jì)以及穩(wěn)定性跟蹤 CodeReview Visual Basic 自動(dòng)源代碼分析工具,Co

58、mpuware DevPartner Studio,針對(duì)軟件開(kāi)發(fā)小組使用 Microsoft Visual C+，Microsoft Visual Basic，Java,ASP 或 HTML 設(shè)計(jì)的一套緊密配合的調(diào)試，測(cè)試和管理工具。該產(chǎn)品結(jié)合了強(qiáng)大的錯(cuò)誤檢測(cè)，性能分析，覆蓋率分析，需求管理，測(cè)試和發(fā)布工具與全面的工程跟蹤，錯(cuò)誤管理，任務(wù)管理和自動(dòng)的工作流程。DevPartner Studio Enterprise Edition 通過(guò)提高軟件生產(chǎn)率,提高代碼質(zhì)量，支持工作流以及通訊標(biāo)準(zhǔn)讓你對(duì)軟件工程有更多的控制權(quán)。 Win下最好的輔助調(diào)試工具。能夠幫你檢查內(nèi)存泄漏，GDI泄漏，內(nèi)存覆蓋，數(shù)組

59、越界，系統(tǒng)API調(diào)用參數(shù)是否合適。還能profile，對(duì)你的程序的運(yùn)行時(shí)間進(jìn)行分析，每個(gè)函數(shù)占用多少運(yùn)行時(shí)間，每一行占用多少運(yùn)行時(shí)間，幫你找出時(shí)間的瓶頸。,Rational,Rational Purify Rational Quantify Rational PureCoverage IBM Rational PurifyPlus,Rational Purify,面向VC, VB或者Java開(kāi)發(fā)的測(cè)試Visual C/C+ 和Java代碼中與內(nèi)存有關(guān)的錯(cuò)誤，確保整個(gè)應(yīng)用程序的質(zhì)量和可靠性。在查找典型的Visual C/C+程序中的傳統(tǒng)內(nèi)存訪問(wèn)錯(cuò)誤，以及Java中與垃圾內(nèi)存收集相關(guān)的錯(cuò)誤方面，Rational Purify可以大顯身手。Rational Robot的回歸測(cè)試與Rational Purify結(jié)合使用完成可靠性測(cè)試。 網(wǎng)址：,Rational Quantify,面向VC、VB 或者Java開(kāi)發(fā)的測(cè)試性能瓶頸檢測(cè)工具，它可以自動(dòng)檢測(cè)出影響程序段執(zhí)行速度的程序性能瓶頸，提供參數(shù)分析表等等直觀表格。幫助分析影響程序短執(zhí)行速度的關(guān)鍵部分。 網(wǎng)址：,Rational PureCoverage,面向VC、VB或者Java開(kāi)發(fā)的測(cè)試覆蓋程度檢測(cè)工具，它可以自動(dòng)檢測(cè)你的測(cè)試完整性和那些無(wú)法達(dá)到的