1 基本理論

整理資料時(shí)發(fā)現(xiàn)以前給兄弟們灌輸?shù)膯卧獪y試的一些基本知識(shí)，放在這里供大家參考。里面參考了網(wǎng)上 很多朋友的資料，這里沒一一列出，一并謝過。ppt轉(zhuǎn)的，比較亂，ppt已經(jīng)上傳到個(gè)人資源的，需要的可以去下載看看。不知道怎么搞的，ppt轉(zhuǎn)成 word格式是正確的，word里粘貼到這里，在編輯方式下也是對的，可是瀏覽文章時(shí)就亂七八糟了。只有在記事本里中轉(zhuǎn)了一下，喪失了很多排版上的信息。

現(xiàn)象

• 投入太多的精力，找 bug，而新的代碼仍然會(huì)出現(xiàn)類似 bug；
• 寫完代碼，心里沒底，是否有大量 bug 等待自己；
• 新修改的代碼不知道是否影響其他部分代碼；
• 由于牽扯太多，導(dǎo)致不敢進(jìn)行修改代碼；
  ...

一、軟件測試基本理論

• 目的：對軟件測試有個(gè)整體認(rèn)識(shí)
• 軟件測試
• 軟件測試分類
• 軟件開發(fā)全過程檢測及測試自動(dòng)化
• V模型與X模型
• TDD（ Test-Driven Development）

什么是軟件測試？

在軟件投入運(yùn)行前，對軟件需求分析、設(shè)計(jì)規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。

軟件測試的概念：

軟件測試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程。

或者說，軟件測試是根據(jù)軟件開發(fā)各個(gè)階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)一批測試用例（即輸入數(shù)據(jù)及其預(yù)期結(jié)果），并利用這些測試用例去執(zhí)行程序， 以發(fā)現(xiàn)程序錯(cuò)誤的過程。

測試的目的

• 測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯(cuò)誤；
• 一個(gè)好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤；
• 一個(gè)成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測試
• 也可以這樣說，測試的目標(biāo)是以較少的用例、時(shí)間和人力找出軟件中潛在的各種錯(cuò)誤和缺陷，以確保系統(tǒng)的質(zhì)量
• 一個(gè)被人忽略的軟件測試目的是：測試可以幫助發(fā)現(xiàn)當(dāng)前開發(fā)工作所采用的軟件過程（也是一個(gè)“軟件”）的缺陷，以便進(jìn)行改進(jìn)。
• 首先，測試并不僅僅是為了要找出錯(cuò)誤。分析錯(cuò)誤產(chǎn)生的原因和錯(cuò)誤在開發(fā)的哪一個(gè)階段產(chǎn)生，具有非常重要的意義。
• 通過分析錯(cuò)誤產(chǎn)生于哪一個(gè)開發(fā)階段、而又在哪一個(gè)階段被發(fā)現(xiàn)，我們可以判斷從錯(cuò)誤的產(chǎn)生到 錯(cuò)誤的發(fā)現(xiàn)，跨越了多少個(gè)開發(fā)階段。
• 軟件開發(fā)的一條重要原則是盡早發(fā)現(xiàn)與修正錯(cuò)誤。
• 正確分析與利用測試的結(jié)果，我們可以非常有效地進(jìn)行軟件過程改進(jìn)

軟件測試原則 2-1

• 完全測試程序是不可能的
  －輸入量太大
  －輸出結(jié)果太多
  －軟件實(shí)現(xiàn)途徑太多
  －軟件說明書沒有客觀標(biāo)準(zhǔn)。從不同角度看，軟件缺陷的標(biāo)準(zhǔn)不同。

軟件測試原則 2-2

• 軟件測試是有風(fēng)險(xiǎn)的行為
• 測試無法顯示潛伏的軟件缺陷
• 找到的軟件缺陷越多，就說明軟件缺陷越多
• 并非所有軟件缺陷都能修復(fù)
• 軟件測試一項(xiàng)講究條理的技術(shù)專業(yè)

軟件測試分類

從是否需要執(zhí)行被測軟件的角度，可分為：

從測試是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)算法的角度來看，可分為 ：

軟件測試方法－靜態(tài)和動(dòng)態(tài)

• 靜態(tài)檢查
  確保系統(tǒng)按照組織的標(biāo)準(zhǔn)和過程運(yùn)行，主要依賴于評審和非運(yùn)行的手段來檢查。通常包括需求評審、設(shè)計(jì)評審、代碼走查和代碼檢查。
• 動(dòng)態(tài)檢查
  在生命周期中進(jìn)行測試（運(yùn)行）。通常包括單元測試、集成測試、系統(tǒng)測試、用戶的驗(yàn)收測試。

靜態(tài)測試

• 審查 (Inspection)
  －軟件的一種基本測試方法，它以一系列典型問題為依據(jù)進(jìn)行檢測。
• 走查 (Walkthrough)
  －一對一的審查，比審查更加仔細(xì)。
• 回顧(Review)
  －以發(fā)現(xiàn)軟件中存在的錯(cuò)誤和缺陷為目的的一種軟件測試方法，它是在軟件證實(shí)執(zhí)行之前完成。

靜態(tài)和動(dòng)態(tài)測試進(jìn)行結(jié)構(gòu)和功能測試

測試技術(shù)

黑盒測試

黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動(dòng)測試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過測試來檢測每個(gè)功能是 否都能正常使用，在測試時(shí)，把程序看作一個(gè)不能打開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者在程序接口進(jìn)行測試，它只檢查程序功能 是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。

“黑盒”測試著眼于程序外部結(jié)構(gòu)、不考慮內(nèi)部邏輯結(jié)構(gòu)、針對軟件界面和軟件功能進(jìn)行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況 使用，才能以這種方法查出程序中所有的錯(cuò)誤。實(shí)際上測試情況有無窮多個(gè)，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進(jìn)行測試。

它不僅應(yīng)用于開發(fā)階段的測試，更重要的是在產(chǎn)品測試階段及維護(hù)階段必不可少。主要用于軟件確認(rèn)測試。

黑盒測試方法主要有：

• 等價(jià)類劃分
• 邊值分析
• 因果圖
• 錯(cuò)誤推測

白盒測試

白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動(dòng)測試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動(dòng)作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測 試程序，檢驗(yàn)程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能。

使用被測單元內(nèi)部如何工作的信息，允許測試人員對程序內(nèi)部邏輯結(jié)構(gòu)及有關(guān)信息來設(shè)計(jì)和選擇測試用例，對程序的邏輯路徑進(jìn)行測試。基于一個(gè)應(yīng)用代碼的內(nèi)部邏 輯知識(shí)，測試是基于覆蓋全部代碼、分支、路徑、條件。

白盒測試的主要方法

• 邏輯驅(qū)動(dòng)測試
• 基本路徑測試

主要用于軟件驗(yàn)證。

使用程序設(shè)計(jì)的控制結(jié)構(gòu)導(dǎo)出測試用例。

邏輯驅(qū)動(dòng)測試：

主要是測試覆蓋率，以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測試。包括以下6種類型：

• 語句覆蓋
• 判斷覆蓋
• 條件覆蓋
• 判定-條件覆蓋
• 條件組合覆蓋
• 路徑測試

白盒測試的主要目的

• 保證一個(gè)模塊中的所有獨(dú)立路徑至少被執(zhí)行一次；
• 對所有的邏輯值均需要測試真、假兩個(gè)分支；
• 在上下邊界及可操作范圍內(nèi)運(yùn)行所有循環(huán)；
• 檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性。

概念

• 語句覆蓋：語句覆蓋就是設(shè)計(jì)若干個(gè)測試用例，運(yùn)行被測試程序，使得每一條可執(zhí)行語句至少執(zhí)行一次；
• 判定覆蓋（也稱為分支覆蓋）：設(shè)計(jì)若干個(gè)測試用例，運(yùn)行所測程序，使程序中每個(gè)判斷的取真分支和取假分支至少執(zhí)行一次；
• 條件覆蓋：設(shè)計(jì)足夠多的測試用例，運(yùn)行所測程序，使程序中每個(gè)判斷的每個(gè)條件的每個(gè)可能取值至少執(zhí)行一次；
• 判定-條件覆蓋：設(shè)計(jì)足夠多的測試用例，運(yùn)行所測程序，使程序中每個(gè)判斷的每個(gè)條件的所有可能取值至少執(zhí)行一次，并且每個(gè)可能的判斷結(jié)果也至少執(zhí)行一次， 換句話說，即是要求各個(gè)判斷的所有可能的條件取值組合至少執(zhí)行一次；
• 條件組合測試：設(shè)計(jì)足夠多的測試用例，運(yùn)行所測程序，使程序中每個(gè)判斷的所有可能的條件取值組合至少執(zhí)行一次；
• 路徑測試：設(shè)計(jì)足夠多的測試用例，運(yùn)行所測程序，要覆蓋程序中所有可能的路徑。

軟件開發(fā)全過程檢測及測試自動(dòng)化

• 單元測試（unit test ）
  由編程的開發(fā)人員自行計(jì)劃與完成的，針對單個(gè)或相關(guān)聯(lián)的一組程序單元的測試。
• 組裝測試（inegration test ）
  計(jì)劃于設(shè)計(jì)階段，由開發(fā)人員與測試人員合作完成的，針對結(jié)合起來的不同單元以及它們的接口的測試。
• 系統(tǒng)測試（system test ）：（可認(rèn)為包括“可用性與圖形用戶界面測試”）
  測試整個(gè)系統(tǒng)，以證實(shí)它滿足要求所規(guī)定的功能、質(zhì)量和性能等方面的特性。
• 回歸測試（regression test ）：
  用于驗(yàn)證改變了的系統(tǒng)或其組件仍然保持應(yīng)有的特性。
• 驗(yàn)收測試（acceptance test ）：
  測試整個(gè)系統(tǒng)，以保證其達(dá)到可以交付使用的狀態(tài)。

V模型

V模型

• 單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試。是“從小到大”、“由內(nèi)至外”、“循序漸進(jìn)”的測試過程，體現(xiàn)了“分而治之”的思想。
• 單元測試的粒度最小，一般由開發(fā)小組采用白盒方式來測試，主要測試單元是否符合“設(shè)計(jì)”。
• 集成測試界于單元測試和系統(tǒng)測試之間，起到“橋梁作用”，一般由開發(fā)小組采用白盒加黑盒的 方式來測試，既要驗(yàn)證“設(shè)計(jì)”又要驗(yàn)證“需求”。

V模型

• 系統(tǒng)測試的粒度最大，一般由獨(dú)立測試小組采用黑盒方式來測試，主要測試系統(tǒng)是否符合“需求規(guī)格說明書”。
• 驗(yàn)收測試與系統(tǒng)測試非常相似，主要區(qū)別是測試人員不同，驗(yàn)收測試由用戶執(zhí)行。

測試內(nèi)容

• 測試內(nèi)容一般包含
• 接口與路徑測試。
• 功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝 /反安裝測試…

測試階段對應(yīng)表

接口與路徑測試 3-1

• 接口測試：數(shù)據(jù)一般通過接口輸入和輸出，接口測試一般是白盒測試的第一步。
  ― 輸入?yún)?shù)有“典型值”、“邊界值”、“異常值”
  ― 輸出包括函數(shù)的返回值和輸出參數(shù)。
  ― 實(shí)際輸出與期望的輸出不一致，那么說明程序有錯(cuò)誤。
• 一個(gè)函數(shù)體內(nèi)的語句可能只有十幾條，但邏輯路徑可能有成千上萬條。所以應(yīng)該根據(jù)經(jīng)驗(yàn)選擇關(guān) 鍵的路徑測試。

接口與路徑測試 3-2

• 路徑測試的檢查表
• －數(shù)據(jù)類型、變量值、邏輯判斷、循環(huán)、內(nèi)存管理、文件I/O、錯(cuò)誤處理
• 預(yù)防一些重要的路徑?jīng)]有被測試的措施有：
  ― 觀察是否有程序語句從來沒有被執(zhí)行過。
  ― 要特別留意函數(shù)體內(nèi)的錯(cuò)誤處理程序塊。

接口與路徑測試 3-3

• 接口與路徑測試用例的參考模板

功能測試 3-1

• 功能測試的基本方法是構(gòu)造一些合理輸入（在需求范圍之內(nèi)），檢查輸出是否與期望的相同。如果兩者不一致，即表明功能有誤。
• 難點(diǎn)在于如何構(gòu)造有效的輸入。

功能測試 3-2

• 功能測試的測試方法：等價(jià)劃分法和邊界值分析法。
  ― 等價(jià)劃分是指把輸入空間劃分為幾個(gè)“等價(jià)區(qū)間”，在每個(gè)“等價(jià)區(qū)間”中只需要測試一個(gè)典型值就可以了。等價(jià)劃分法來源于人們的直覺與經(jīng)驗(yàn)，可令測試事半功 倍。
  ― “缺陷遺漏在角落里，聚集在邊界上”。邊界值測試法是對等價(jià)劃分法的補(bǔ)充。如果A和B是輸入空間的邊界值，那么除了典型值外還要用A和B作為測試用例。

功能測試 3-3

• 功能測試用例的參考模板

性能測試 3-1

• 性能測試即測試軟件處理事務(wù)的速度，一是為了檢驗(yàn)性能是否符合需求，二是為了得到某些性能數(shù)據(jù)供人們參考。
• 絕對值考慮：如數(shù)據(jù)送輸速率是每秒多少比特。 “相對值”考慮：如某個(gè)軟件比另一個(gè)軟件快多少倍。
• 性能測試中考慮運(yùn)行環(huán)境的影響：例如網(wǎng)絡(luò)環(huán)境、計(jì)算機(jī)主頻，總線結(jié)構(gòu)和外部設(shè)備都可能影響軟件的運(yùn)行速度。

性能測試 3-2

• 性能測試的一些注意事項(xiàng)：
  ― 應(yīng)當(dāng)編寫一段程序用于計(jì)算時(shí)間以及相關(guān)數(shù)據(jù)。
  ― 應(yīng)當(dāng)測試軟件在標(biāo)準(zhǔn)配置和最低配置下的性能。
  ― 應(yīng)當(dāng)關(guān)閉那些消耗內(nèi)存、占用CPU的其它應(yīng)用軟件（如殺毒軟件）。
  ― 應(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)卻讓它剛好不癱瘓。
• 壓力測試的一個(gè)變種是敏感測試。在某種情況下，微小的輸入變動(dòng)會(huì)導(dǎo)致系統(tǒng)的表現(xiàn)（如性能） 發(fā)生急劇的變化。

壓力測試 2-2

• 壓力測試用例的參考模板

其他測試內(nèi)容

• 健壯性測試
• 用戶界面測試
• 信息安全測試
• 可靠性測試
• 安裝和反安裝測試

測試常見問題 2-1

• 問題1：有了“黑盒”測試為什么還要“白盒”測試？
• 問題2：由于單元測試要寫測試驅(qū)動(dòng)程序，非常麻煩，能否等到整個(gè)系統(tǒng)全部開發(fā)完后，再集中精力進(jìn)行一次性地單元測試呢？
• 問題3：如果每個(gè)單元都通過了測試，把它們集成一起難道會(huì)有什么不妥嗎？集成測試是否多此 一舉？

測試常見問題 2-2

• 問題4：在集成測試的時(shí)候，已經(jīng)對一些子系統(tǒng)進(jìn)行了功能測試、性能測試等等，那么在系統(tǒng)測試時(shí)能否跳過相同內(nèi)容的測試?
• 問題5：既然系統(tǒng)測試與驗(yàn)收測試的內(nèi)容幾乎是相同的，為什么還要驗(yàn)收測試？
• 問題6：能否將系統(tǒng)測試和驗(yàn)收測試“合二為一”？

總結(jié) 2-1

• 測試可以將測試描述為一個(gè)運(yùn)行程序以發(fā)現(xiàn)錯(cuò)誤的過程。
• 軟件測試的準(zhǔn)則:不完全測試、風(fēng)險(xiǎn)測試、無法顯示潛伏錯(cuò)誤、發(fā)現(xiàn)錯(cuò)誤成線性增長、缺陷不能完全修復(fù)、測試有條理規(guī)程
• 測試的方法:黑盒/白盒、靜態(tài)/動(dòng)態(tài)
• 軟件測試的各個(gè)階段：單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試

總結(jié) 2-2

• 測試的內(nèi)容包括：接口/路徑測試、功能測試、性能測試、壓力測試、可靠性測試、安全性測試、用戶界面測試、安裝/反安裝測試

X模型

測試驅(qū)動(dòng)開發(fā)

• TDD, Test-Driven Development
• 測試驅(qū)動(dòng)開發(fā)以測試作為開發(fā)過程的中心，它要求在編寫任何代碼之前，首先編寫用于定義產(chǎn)品 代碼行為的測試，而編寫的產(chǎn)品代碼又以使測試通過為目標(biāo)。測試驅(qū)動(dòng)開發(fā)要求測試可以完全自動(dòng)地運(yùn)行，在代碼進(jìn)行重構(gòu)前必須運(yùn)行測試。

TDD基本做法

• 1. 寫一個(gè)測試程序。
• 2. 讓程序編譯通過。
• 3. 運(yùn)行測試程序，發(fā)現(xiàn)不能運(yùn)行。
• 4. 讓測試程序可以運(yùn)行。
• 5. 消除重復(fù)設(shè)計(jì)，優(yōu)化設(shè)計(jì)結(jié)構(gòu)。

測試產(chǎn)品說明書

• 對于產(chǎn)品說明書的制定是個(gè)很重要的設(shè)計(jì)階段，產(chǎn)品說明書的質(zhì)量會(huì)直接影響到整個(gè)產(chǎn)品開發(fā)。
• 測試產(chǎn)品說明書屬于靜態(tài)黑盒子測試。

常用測試用語－測試用例

• 測試用例：編寫用于輸入輸入的實(shí)際數(shù)制和預(yù)期結(jié)果。測試用例還明確指出使用具體測試用例產(chǎn)生的測試程序的任何限制 。
• 使用目的：
  ― 測試用例應(yīng)該設(shè)計(jì)為能夠快速容易地發(fā)現(xiàn)盡可能多的錯(cuò)誤。
  ― 應(yīng)該通過使用和產(chǎn)生正確和錯(cuò)誤的輸入和輸出來“檢驗(yàn)”程序。
  ― 其目標(biāo)是要使用合理范圍內(nèi)的條件，盡可能全面地測試所有模塊乃至整個(gè)系統(tǒng)。

測試與調(diào)試－什么是缺陷

• 缺陷：最終產(chǎn)品同用戶的期望不一致
• 缺陷的分類
• 錯(cuò)誤
• 遺漏
• 超出需求的部分
• 缺陷（未觸發(fā)）VS.錯(cuò)誤（應(yīng)首先解決）

測試與調(diào)試－調(diào)試的準(zhǔn)則

• 調(diào)試的方法：歸納法、演繹法和回溯法。
• 常用調(diào)試技術(shù)使用診斷輸出語句 (diagnostic output statement)、快照轉(zhuǎn)儲(chǔ) (snapshot dump) 以及跟蹤指令的斷點(diǎn) (instruction-dependent breakpoint)。

二、單元測試基本理論

• 什么是單元測試(Unit Test)
• 什么時(shí)候測試？
• 為什么要進(jìn)行單元測試
• C/C++單元測試問答（摘要）

單元測試(Unit Test)

• 工廠在組裝一臺(tái)電視機(jī)之前，會(huì)對每個(gè)元件都進(jìn)行測試，這，就是單元測試。
• 臨時(shí)單元測試：代碼覆蓋率要超過70%都很困難
• 充分的單元測試：提高軟件質(zhì)量，降低開發(fā)成本的必由之路。
• 單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動(dòng)，在單元測試活動(dòng)中，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(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ā)人員可以選擇是在獨(dú)立的過程和函數(shù)，還是在Ada包的級別上進(jìn)行單元測試。單元測試的原則同樣被擴(kuò)展到第四代語言(4GL)的開發(fā)中，在這里 基本單元被典型地劃分為一個(gè)菜單或顯示界面。

單元測試(Unit Test)

• 單元測試不僅僅是作為無錯(cuò)編碼一種輔助手段在一次性的開發(fā)過程中使用，單元測試必須是可重復(fù)的，無論是在軟件修改，或是移植到新的運(yùn)行環(huán)境的過程中。因 此，所有的測試都必須在整個(gè)軟件系統(tǒng)的生命周期中進(jìn)行維護(hù)。

三、為什么要 進(jìn)行單元測試

• 一些流行的誤解--反調(diào)論證
• 其他好處
• 單元測試的重要性

反證1：單元測試?yán)速M(fèi)了太多的時(shí)間

一旦編碼完成，開發(fā)人員總是會(huì)迫切希望進(jìn)行軟件的集成工作，這樣他們就能夠看到實(shí)際的系統(tǒng)開始啟動(dòng)工作了。 這在外表上看來是一項(xiàng)明顯的進(jìn)步，而象單元測試這樣的活動(dòng)也許會(huì)被看作是通往這個(gè)階段點(diǎn)的道路上的障礙， 推遲了對整個(gè)系統(tǒng)進(jìn)行聯(lián)調(diào)這種真正有意思的工作啟動(dòng)的時(shí)間。

反證1：單元測試?yán)速M(fèi)了太多的時(shí)間

　在這種開發(fā)步驟中，真實(shí)意義上的進(jìn)步被外表上的進(jìn)步取代了。系統(tǒng)能夠正常工作的可能性是很小的，更多的情況是充滿了各式各樣的Bug。在實(shí)踐中，這樣一 種開發(fā)步驟常常會(huì)導(dǎo)致這樣的結(jié)果：軟件甚至無法運(yùn)行。更進(jìn)一步的結(jié)果是大量的時(shí)間將被花費(fèi)在跟蹤那些包含在獨(dú)立單元里的簡單的Bug上面，在個(gè)別情況下， 這些Bug也許是瑣碎和微不足道的，但是總的來說，他們會(huì)導(dǎo)致在軟件集成為一個(gè)系統(tǒng)時(shí)增加額外的工期， 而且當(dāng)這個(gè)系統(tǒng)投入使用時(shí)也無法確保它能夠可靠運(yùn)行。

反證1：單元測試?yán)速M(fèi)了太多的時(shí)間

• 在實(shí)踐工作中，進(jìn)行了完整計(jì)劃的單元測試和編寫實(shí)際的代碼所花費(fèi)的精力大致上是相同的。一旦完成了這些單元測試工作，很多Bug將被糾正，在確信他們手頭 擁有穩(wěn)定可靠的部件的情況下，開發(fā)人員能夠進(jìn)行更高效的系統(tǒng)集成工作。這才是真實(shí)意義上的進(jìn)步，所以說完整計(jì)劃下的單元測試是對時(shí)間的更高效的利用。而調(diào) 試人員的不受控和散漫的工作方式只會(huì)花費(fèi)更多的時(shí)間而取得很少的好處。
• 使用AdaTEST和Cantata這樣的支持工具可以使單元測試更加簡單和有效。但這不是必須的，單元測試即使是在沒有工具支持的情況下也是一項(xiàng)非常有 意義的活動(dòng)。

反證2：僅僅證明代碼做了什么

這是那些沒有首先為每個(gè)單元編寫一個(gè)詳細(xì)的規(guī)格說明而直接跳到編碼階段的開發(fā)人員提出的一條普遍的抱怨， 當(dāng)編碼完成以后并且面臨代碼測試任務(wù)的時(shí)候，他們就閱讀這些代碼并找出它實(shí)際上做了什么，把他們的測試工作基于已經(jīng)寫好的代碼的基礎(chǔ)上。當(dāng)然，他們無法證 明任何事情。所有的這些測試工作能夠表明的事情就是編譯器工作正常。是的，他們也許能夠抓住(希望能夠)罕見的編譯器Bug，但是他們能夠做的僅僅是這 些。

反證2：僅僅證明代碼做了什么

如果他們首先寫好一個(gè)詳細(xì)的規(guī)格說明，測試能夠以規(guī)格說明為基礎(chǔ)。代碼就能夠針對它的規(guī)格說明，而不是針對自身進(jìn)行測試。這樣的測試仍然能夠抓住編譯器的 Bug，同時(shí)也能找到更多的編碼錯(cuò)誤，甚至是一些規(guī)格說明中的錯(cuò)誤。

反證2：僅僅證明代碼做了什么

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

反證3：我是個(gè)很棒的程序員， 我是不是可以不進(jìn)行單元測試？

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

反證4：不管怎樣， 集成測試將會(huì)抓住所有的Bug ？

• 我們已經(jīng)在前面的討論中從一個(gè)側(cè)面對這個(gè)問題進(jìn)行了部分的闡述。這個(gè)論點(diǎn)不成立的原因在于規(guī)模越大的代碼集成意味著復(fù)雜性就越高。如果軟件的單元沒有事先 進(jìn)行測試，開發(fā)人員很可能會(huì)花費(fèi)大量的時(shí)間僅僅是為了使軟件能夠運(yùn)行，而任何實(shí)際的測試方案都無法執(zhí)行。
• 一旦軟件可以運(yùn)行了，開發(fā)人員又要面對這樣的問題： 在考慮軟件全局復(fù)雜性的前提下對每個(gè)單元進(jìn)行全面的測試。 這是一件非常困難的事情，甚至在創(chuàng)造一種單元調(diào)用的測試條件的時(shí)候，要全面的考慮單元的被調(diào)用時(shí)的各種入口參數(shù)。在軟件集成階段，對單元功能全面測試的復(fù) 雜程度遠(yuǎn)遠(yuǎn)的超過獨(dú)立進(jìn)行的單元測試過程。
• 最后的結(jié)果是測試將無法達(dá)到它所應(yīng)該有的全面性。一些缺陷將被遺漏，并且很多Bug將被忽略過去。
• 讓我們類比一下，假設(shè)我們要清洗一臺(tái)已經(jīng)完全裝配好的食物加工機(jī)器!無論你噴了多少水和清潔劑，一些食物的小碎片還是會(huì)粘在機(jī)器的死角位置，只有任其腐爛 并等待以后再想辦法。但我們換個(gè)角度想想，如果這臺(tái)機(jī)器是拆開的， 這些死角也許就不存在或者更容易接觸到了，并且每一部分都可以毫不費(fèi)力的進(jìn)行清洗。

反證5：它的成本效率不高

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

反證5：它的成本效率不高

• 摘自<<實(shí)用軟件度量>>(Capers Jones，McGraw-Hill 1991)，它列出了準(zhǔn)備測試，執(zhí)行測試，和修改缺陷所花費(fèi)的時(shí)間(以一個(gè)功能點(diǎn)為基準(zhǔn))，這些數(shù)據(jù)顯示單元測試的成本效率大約是集成測試的兩倍 系統(tǒng)測試的三倍。

反證5：它的成本效率不高

• (術(shù)語域測試(Field test)意思是在軟件投入使用以后，針對某個(gè)領(lǐng)域所作的所有測試活動(dòng))
• 這個(gè)圖表并不表示開發(fā)人員不應(yīng)該進(jìn)行后階段的測試活動(dòng)，這次測試活動(dòng)仍然是必須的。它的真正意思是盡可能早的排除盡可能多的Bug可以減少后階段測試的費(fèi) 用。
• 其他的一些圖表顯示高達(dá)50%的維護(hù)工作量被花在那些總是會(huì)有的Bug的修改上面。如果這些Bug在開發(fā)階段被排除掉的話，這些工作量就可以節(jié)省下來。當(dāng) 考慮到軟件維護(hù)費(fèi)用可能會(huì)比最初的開發(fā)費(fèi)用高出數(shù)倍的時(shí)候，這種潛在的對50%軟件維護(hù)費(fèi)用的節(jié)省將對整個(gè)軟件生命周期費(fèi)用產(chǎn)生重大的影響。

反證 結(jié)論

• 經(jīng)驗(yàn)表明一個(gè)盡責(zé)的單元測試方法將會(huì)在軟件開發(fā)的某個(gè)階段發(fā)現(xiàn)很多的Bug，并且修改它們的成本也很低。在軟件開發(fā)的后期階段，Bug的發(fā)現(xiàn)并修改將會(huì)變 得更加困難，并要消耗大量的時(shí)間和開發(fā)費(fèi)用。無論什么時(shí)候作出修改都要進(jìn)行完整的回歸測試，在生命周期中盡早地對軟件產(chǎn)品進(jìn)行測試將使效率和質(zhì)量得到最好 的保證。 在提供了經(jīng)過測試的單元的情況下，系統(tǒng)集成過程將會(huì)大大地簡化。開發(fā)人員可以將精力集中在單元之間的交互作用和全局的功能實(shí)現(xiàn)上，而不是陷入充滿很多 Bug的單元之中不能自拔。
• 使測試工作的效力發(fā)揮到最大化的關(guān)鍵在于選擇正確的測試策略，這其中包含了完全的單元測試的概念，以及對測試過程的良好的管理，還有適當(dāng)?shù)厥褂孟?AdaTEST和Cantata這樣的工具來支持測試過程。這些活動(dòng)可以產(chǎn)生這樣的結(jié)果：在花費(fèi)更低的開發(fā)費(fèi)用的情況下得到更穩(wěn)定的軟件。更進(jìn)一步的好處 是簡化了維護(hù)過程并降低了生命周期的費(fèi)用。有效的單元測試是推行全局質(zhì)量文化的一部分，而這種質(zhì)量文化將會(huì)為軟件開發(fā)者帶來無限的商機(jī)。

其他好處 1：減少程序的Bug

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

其他好處 2：提高開發(fā)速度

• 在實(shí)踐工作中，進(jìn)行了完整計(jì)劃的單元測試和編寫實(shí)際的代碼所花費(fèi)的精力大致上是相同的。一旦完成了這些單元測試工作，很多Bug將被糾正，在確信他們手頭 擁有穩(wěn)定可靠的部件的情況下，開發(fā)人員能夠進(jìn)行更高效的系統(tǒng)集成工作。這才是真實(shí)意義上的進(jìn)步，所以說完整計(jì)劃下的單元測試是對時(shí)間的更高效的利用。而調(diào) 試人員的不受控和散漫的工作方式只會(huì)花費(fèi)更多的時(shí)間而取得很少的好處。
• 經(jīng)驗(yàn)表明一個(gè)盡責(zé)的單元測試方法將會(huì)在軟件開發(fā)的某個(gè)階段發(fā)現(xiàn)很多的Bug，并且修改它們的成本也很低。在軟件開發(fā)的后期階段，Bug的發(fā)現(xiàn)并修改將會(huì)變 得更加困難，并要消耗大量的時(shí)間和開發(fā)費(fèi)用。無論什么時(shí)候作出修改都要進(jìn)行完整的回歸測試，在生命周期中盡早地對軟件產(chǎn)品進(jìn)行測試將使效率和質(zhì)量得到最好 的保證。 在提供了經(jīng)過測試的單元的情況下，系統(tǒng)集成過程將會(huì)大大地簡化。開發(fā)人員可以將精力集中在單元之間的交互作用和全局的功能實(shí)現(xiàn)上，而不是陷入充滿很多 Bug的單元之中不能自拔。

其他好處 3：使程序代碼更整潔，優(yōu)化程序的設(shè)計(jì)

• 只有自動(dòng)的單元測試程序失敗時(shí)，我們才會(huì)去重寫代碼，在測試驅(qū)動(dòng)開發(fā)中，要求我們對程序不停的重構(gòu)，通過重構(gòu)，我們可以優(yōu)化程序的結(jié)構(gòu)設(shè)計(jì)，消除程序中潛 在的錯(cuò)誤。同時(shí)，為了能夠使自己的程序可以很方便的進(jìn)行測試，開發(fā)人員就需要很好地考慮程序的設(shè)計(jì)，極限編程的方法說可以不需要設(shè)計(jì)就開始編碼，但實(shí)際 上，它在編寫代碼的過程中每時(shí)每刻都為了方便的進(jìn)行和通過測試而在優(yōu)化自己的設(shè)計(jì)。它實(shí)際上是把開始階段很大很抽象的設(shè)計(jì)分散到你編寫的每個(gè)方法中。因此 他們會(huì)說好設(shè)計(jì)最后會(huì)自然而然的出現(xiàn)。

其他好處 4：編寫單元測試代碼的過程實(shí)際上就是設(shè)計(jì)程序的過程

• 在編寫單元測試代碼時(shí)，我們實(shí)際上是在思考我們的程序根據(jù)預(yù)期會(huì)返回什么結(jié)果，它實(shí)際上就 是程序設(shè)計(jì)的過程。而通過重構(gòu)過程，我們可以對這些設(shè)計(jì)進(jìn)行很好的優(yōu)化。

單元測試的重要性

• 單元測試是軟件測試的基礎(chǔ)，因此單元測試的效果會(huì)直接影響到軟件的后期測試，最終在很大程度上影響到產(chǎn)品的質(zhì)量。
• 時(shí)間方面
• 測試效果
• 測試成本
• 產(chǎn)品質(zhì)量

重要性 1：時(shí)間方面

• 如果認(rèn)真的做好了單元測試，在系統(tǒng)集成聯(lián)調(diào)時(shí)非常順利，因此會(huì)節(jié)約很多時(shí)間，反之那些由于因?yàn)闀r(shí)間原因不做單元測試或隨便做做的則在集成時(shí)總會(huì)遇到那些本 應(yīng)該在單元測試就能發(fā)現(xiàn)的問題，而這種問題在集成時(shí)遇到往往很難讓開發(fā)人員預(yù)料到，最后在苦苦尋覓中才發(fā)現(xiàn)這是個(gè)很低級的錯(cuò)誤而在悔恨自己時(shí)已經(jīng)浪費(fèi)了很 多時(shí)間，這種時(shí)間上的浪費(fèi)一點(diǎn)都不值得，正所謂得不償失。

重要性 2：測試效果

• 根據(jù)以往的測試經(jīng)驗(yàn)來看，單元測試的效果是非常明顯的，首先它是測試階段的基礎(chǔ)，做好了單元測試，在做后期的集成測試和系統(tǒng)測試時(shí)就很順利。其次在單元測 試過程中能發(fā)現(xiàn)一些很深層次的問題，同時(shí)還會(huì)發(fā)現(xiàn)一些很容易發(fā)現(xiàn)而在集成測試和系統(tǒng)測試很難發(fā)現(xiàn)的問題。再次單元測試關(guān)注的范圍也特殊，它不僅僅是證明這 些代碼做了什么，最重要的是代碼是如何做的，是否做了它該做的事情而沒有做不該做的事情。

重要性 3：測試成本

• 在單元測試時(shí)某些問題就很容易發(fā)現(xiàn)，如果在后期的測試中發(fā)現(xiàn)問題所花的成本將成倍數(shù)上升。比如在單元測試時(shí)發(fā)現(xiàn)1個(gè)問題需要1個(gè)小時(shí)，則在集成測試時(shí)發(fā)現(xiàn) 該問題需要2個(gè)小時(shí)，在系統(tǒng)測試時(shí)發(fā)現(xiàn)則需要3個(gè)小時(shí)，同理還有定位問題和解決問題的費(fèi)用也是成倍數(shù)上升的，這就是我們要盡可能早的排除盡可能多的bug 來減少后期成本的因素之一。

重要性 4：產(chǎn)品質(zhì)量

• 單元測試的好與壞直接影響到產(chǎn)品的質(zhì)量，可能就是由于代碼中的某一個(gè)小錯(cuò)誤就導(dǎo)致了整個(gè)產(chǎn)品的質(zhì)量降低一個(gè)指標(biāo)，或者導(dǎo)致更嚴(yán)重的后果，如果我們做好了單 元測試這種情況是可以完全避免的。
• 綜上所述，單元測試是構(gòu)筑產(chǎn)品質(zhì)量的基石，我們不要因?yàn)楣?jié)約單元測試的時(shí)間不做單元測試或隨便做而讓我們在后期浪費(fèi)太多的不值得的時(shí)間，我們也不愿意因?yàn)?由于節(jié)約那些時(shí)間導(dǎo)致開發(fā)出來的整個(gè)產(chǎn)品失敗或重來！

四、 C/C++單元測試問答

• 為什么要進(jìn)行單元測試?
• 由誰進(jìn)行測試？開發(fā)部門還是測試部門？
• 由測試部門進(jìn)行單元測試為什么成本昂貴？
• 由開發(fā)部門進(jìn)行單元測試能保證測試效果嗎？
• 邊編碼邊測試會(huì)影響編碼進(jìn)度嗎？
• 實(shí)施單元測試需要改變開發(fā)流程嗎？
• 單元測試測試哪些代碼？
• 實(shí)際工作中，單元測試能實(shí)現(xiàn)什么程度的測試覆蓋？
• 單元測試如何改良項(xiàng)目代碼的整體結(jié)構(gòu)？
• 我希望依賴全自動(dòng)的工具來完成單元測試，這一想法現(xiàn)實(shí)嗎？
• 如果由開發(fā)部門實(shí)施單元測試，那么測試部門要做哪些工作？

為什么要進(jìn)行單元測試?

• 單元測試保證局部代碼的質(zhì)量
• 單元測試改良項(xiàng)目代碼的整體結(jié)構(gòu)
• 單元測試降低測試、維護(hù)升級的成本
• 單元測試使開發(fā)過程適應(yīng)頻繁變化的需求
• 單元測試有助于提升程序員的能力

由誰進(jìn)行測試？開發(fā)部門/測試部門？

• 應(yīng)該由開發(fā)部門進(jìn)行單元測試！
• 測試部門進(jìn)行單元測試的問題：代價(jià)高，人手不足，耽誤了測試部門對其他測試的準(zhǔn)備工作。
• 由開發(fā)部門進(jìn)行單元測試的問題：擔(dān)心影響開發(fā)進(jìn)度，程序員不習(xí)慣做單元測試，測試自己編寫的代碼，難于保證測試的效果。
• 無論由哪個(gè)部門做單元測試，都要面對一些問題，但開發(fā)部門所面對的問題可以借助工具來解決，而由測試部門進(jìn)行單元測試，要么無法真正實(shí)施，要么代價(jià)昂貴。

由測試部門來單元測試成本昂貴？

• 需多次重復(fù)理解程序
• 反復(fù)溝通需要大量時(shí)間成本
• 不利于發(fā)揮單元測試對代碼結(jié)構(gòu)的約束機(jī)制
• 耽誤測試部門對其他測試的準(zhǔn)備工作
• 即使測試部門人手充裕，僅僅從效益來考慮，也不應(yīng)該由測試部門進(jìn)行單元測試。如果測試部門本來就人力不充裕(進(jìn)行單元測試的人員需具備編碼能力)，勉強(qiáng)由 測試部門進(jìn)行單元測試，結(jié)果往往是----沒有結(jié)果。

由開發(fā)部門進(jìn)行單元測試能保證測試效果嗎？

• 程序員測試自己編寫的代碼，往往只考慮“正常狀況”，這當(dāng)然會(huì)影響測試效果。但如果所用的單元測試工具能夠統(tǒng)計(jì)各種白盒覆蓋率，就能檢查測試效果。當(dāng)然， 只做到這一點(diǎn)還是不夠的，因?yàn)榘缀懈采w具有逾后逾難的特點(diǎn)，達(dá)到一定的覆蓋率后，覆蓋率的提升會(huì)很困難。如果測試工具功能足夠強(qiáng)大，能提供工具幫助用戶快 速地設(shè)計(jì)測試用例，達(dá)到完整的白盒覆蓋，那么測試效果就能得到完全的保證。
• 實(shí)際上，如果沒有充分的統(tǒng)計(jì)數(shù)據(jù)，沒有達(dá)到足夠的測試完整性，那么由誰做單元測試，效果都不能保證。

邊編碼邊測試會(huì)影響編碼進(jìn)度嗎？

• 傳統(tǒng)的單元測試是很費(fèi)時(shí)費(fèi)力的工作，主要時(shí)間消耗在于：編寫測試代碼、設(shè)計(jì)測試用例，如果開發(fā)工具能自動(dòng)生成測試代碼，并且具有快速設(shè)計(jì)測試用例的功能， 那么測試費(fèi)時(shí)就很少；另一方面，如果測試工具還能提供數(shù)據(jù)，幫助程序員整理編程思路、快速發(fā)現(xiàn)錯(cuò)誤，更高效地調(diào)試，那么就能大量提高開發(fā)效率，抵銷測試所 消耗的時(shí)間，不但不會(huì)影響編碼進(jìn)度，甚至加快編碼進(jìn)度。

實(shí)施單元測試需要改變開發(fā)流程嗎？

• 邊開發(fā)邊測試，單元測試是編碼行為而不是測試行為，測試代碼看作是項(xiàng)目代碼的一部分，程序員提交產(chǎn)品代碼時(shí)也要提交測試代碼和測試報(bào)告，其他流程可以不作 任何改變。
• 另一方面，在充分單元測試的基礎(chǔ)上，由于具有高質(zhì)量的局部代碼，良好的整體代碼結(jié)構(gòu)，保證了代碼的可擴(kuò)展性和可復(fù)用性，同時(shí)，自動(dòng)回歸測試支持對代碼的頻 繁修改而不用擔(dān)心引入新的錯(cuò)誤，因此，開發(fā)流程自然會(huì)變得敏捷，可以適應(yīng)頻繁變化的需求，使系統(tǒng)分析、架構(gòu)設(shè)計(jì)和后期測試的壓力減輕，自然而有效地改進(jìn)了 開發(fā)流程。

單元測試測試哪些代碼？

• 單元測試通常不測試很簡單的代碼，一般也不測試“邊界代碼”。很簡單的代碼容易理解，例如Get/Set函數(shù)，這里解釋一下“邊界代碼”。“邊界代碼”是 指用于與外部系統(tǒng)交互的代碼，例如用于處理用戶界面的代碼。數(shù)據(jù)庫、文件、網(wǎng)絡(luò)都可以看作是外部系統(tǒng)，用于讀寫數(shù)據(jù)庫或文件、或訪問網(wǎng)絡(luò)的代碼也可以看作 是“邊界代碼”，這類代碼應(yīng)該獨(dú)立出來，可以進(jìn)行單元測試，但對這些代碼的單元測試通常不能自動(dòng)驗(yàn)證預(yù)期輸出，而是需要人工察看。編程時(shí)，不要把普通代碼 與“邊界代碼”混在一起，例如，不要把各種運(yùn)算直接寫在界面類中，做到了這一點(diǎn)，絕大多數(shù)代碼都可以進(jìn)行單元測試。
  實(shí)際工作中，單元測試能實(shí)現(xiàn)什么程度的測試覆蓋？
• 單元測試的最低要求是100%語句覆蓋，這個(gè)覆蓋率還是不夠的，最好實(shí)現(xiàn)多種覆蓋的組全，比較理想的覆蓋率組合是：100%的語句、條件、分支、路徑覆 蓋，另外，測試工具最好還能自動(dòng)生成邊界測試用例捕捉未處理特殊輸入形成的錯(cuò)誤。在達(dá)到這種覆蓋之后，殘留的編碼錯(cuò)誤可以幾乎說沒有了（設(shè)計(jì)方面的錯(cuò)誤除 外，這些屬于集成或系統(tǒng)測試的范疇）。

單元測試如何改良項(xiàng)目代碼的整體結(jié)構(gòu)？

• 具有良好整體結(jié)構(gòu)的代碼，應(yīng)該符合“低耦合”的特性，即具有“可測性”。測試不具有“可測性”的代碼時(shí)一般會(huì)產(chǎn)生編譯錯(cuò)誤，或者需要打樁才能測試，從而將 問題暴露出來。發(fā)現(xiàn)問題后，重構(gòu)代碼、消除不當(dāng)耦合一般不難，這種簡單的重構(gòu)將有效地改良代碼的整體結(jié)構(gòu)。
  我希望依賴全自動(dòng)的工具來完成單元測試，這一想法現(xiàn)實(shí)嗎？
• 完全自動(dòng)化是一個(gè)美妙的愿望，但由于單元測試的基本特性，完全自動(dòng)化的單元測試是不現(xiàn)實(shí)的。
• 與其他不同，單元測試是“隔離”的測試，要求代碼具有可測性，一個(gè)項(xiàng)目甚至一個(gè)文件中，難免會(huì)有些影響可測性的代碼，編譯到這些代碼時(shí)常常會(huì)產(chǎn)生編譯錯(cuò) 誤，因此，全自動(dòng)的單元測試工具往往只能測試小部分代碼，即使使用某種技術(shù)手段屏蔽掉編譯錯(cuò)誤，也得不償失，因?yàn)橥瑫r(shí)也屏蔽掉了改良代碼整體結(jié)構(gòu)的寶貴機(jī) 會(huì)。如果采用自底向上的方式，一個(gè)一個(gè)文件測試，測試一個(gè)文件前，先將該文件加入測試工程并編譯，沒有編譯錯(cuò)誤時(shí)再測試，這樣可以及時(shí)發(fā)現(xiàn)并消除不當(dāng)耦 合，使代碼具有可測性，這種非全自動(dòng)的方式，可以測試絕大多數(shù)代碼，也保證了代碼具有良好的整體結(jié)構(gòu)。
• 另一方面，主要由測試工具自動(dòng)生成測試用例來進(jìn)行測試往往沒有實(shí)際意義，因?yàn)闇y試工具無法自動(dòng)了解程序的功能，因此，自動(dòng)測試用例通常只能發(fā)現(xiàn)異常之類的 極端錯(cuò)誤，大多數(shù)一般錯(cuò)誤都是無法發(fā)現(xiàn)的。測試工具最重要的不是自動(dòng)生成測試用例，而是能提供快速建立和編輯測試用例的工具。

如果由開發(fā)部門實(shí)施單元測試，那么測試部門要做哪些工作？

• 推動(dòng)、組織單元測試的實(shí)施。單元測試既然叫做“測試”，開發(fā)部門常常認(rèn)識(shí)不到其重要性和必要性，需要由測試部門推動(dòng)和協(xié)助組織實(shí)施。
• 制定單元測試規(guī)范，培訓(xùn)單元測試技術(shù)。
• 檢查、審核單元測試結(jié)果，保證單元測試的有效性。

五、單元測試工具

• 測試工具的分類和選擇
• Parasoft
• Compuware
• Rational
• AutomatedQA AQTime
• xUnit系列
• Visual Studio 2005
• Visual Unit

測試工具的分類和選擇

• 白盒測試工具
• 靜態(tài)測試工具
• 動(dòng)態(tài)測試工具
• 黑盒測試工具
• 功能測試工具
• 性能測試工具
• 測試管理工具
• 其他測試工具
• 測試工具的選擇

白盒測試工具

• 白盒測試工具一般是針對代碼進(jìn)行測試，測試中發(fā)現(xiàn)的缺陷可以定位到代碼級
• 靜態(tài)測試工具直接對代碼進(jìn)行分析，不需要運(yùn)行代碼，也不需要對代碼編譯鏈接，生成可執(zhí)行文件。靜態(tài)測試工具一般是對代碼進(jìn)行語法掃描，找出不符合編碼規(guī)范 的地方，根據(jù)某種質(zhì)量模型評價(jià)代碼的質(zhì)量，生成系統(tǒng)的調(diào)用關(guān)系圖等。
• 動(dòng)態(tài)測試工具與靜態(tài)測試工具不同，動(dòng)態(tài)測試工具的一般采用“插樁”的方式，向代碼生成的可執(zhí)行文件中插入一些監(jiān)測代碼，用來統(tǒng)計(jì)程序運(yùn)行時(shí)的數(shù)據(jù)。其與靜 態(tài)測試工具最大的不同就是動(dòng)態(tài)測試工具要求被測系統(tǒng)實(shí)際運(yùn)行。

黑盒測試工具

• 黑盒測試工具適用于黑盒測試的場合，黑盒測試工具包括功能測試工具和性能測試工具。
• 黑盒測試工具的一般原理是利用腳本的錄制(Record)/回放(Playback)，模擬用戶的操作，然后將被測系統(tǒng)的輸出記錄下來同預(yù)先給定的標(biāo)準(zhǔn)結(jié) 果比較。黑盒測試工具可以大大減輕黑盒測試的工作量，在迭代開發(fā)的過程中，能夠很好地進(jìn)行回歸測試。
• 黑盒測試工具的代表有Rational公司的TeamTest、Robot，Compuware公司的QACenter，另外，專用于性能測試的工具包括 有Radview公司的WebLoad、Microsoft公司的WebStress等工具。

測試管理工具

• 測試管理工具用于對測試進(jìn)行管理。
• 內(nèi)容：對測試計(jì)劃、測試用例、測試實(shí)施進(jìn)行管理，對缺陷的跟蹤管理。
• 測試管理工具的代表有Rational公司的Test Manager、Compureware公司的TrackRecord，Mercury的TestDirector和Quality Center等軟件。

測試工具的選擇

• 功能
• 基本的功能
• 報(bào)表功能
• 測試工具的集成能力
• 操作系統(tǒng)和開發(fā)工具的兼容性
• 價(jià)格
• 連續(xù)性和一致性：
• 全盤考慮，分階段、逐步的引入測試工具

測試工具引入中的誤區(qū)分析

• 沒有考慮到公司的實(shí)際情況，盲目引入測試工具

專題分析，引入哪些測試工具？

• 沒有進(jìn)行有效的測試工具的培訓(xùn)

測試工具的培訓(xùn)是一個(gè)長期的過程

系列的培訓(xùn)和交流

• 沒有形成一個(gè)良好的使用測試工具的環(huán)境

沒有能夠形成一種機(jī)制讓測試工具真正能夠發(fā)揮作用

良好的測試工具使用環(huán)境

• 約束機(jī)制

測試工具并不是策略

• 測試工具并不能教測試員如何測試。如果測試出現(xiàn)問題，則測試工具會(huì)加重問題。在實(shí)現(xiàn)測試過程自動(dòng)化之前，應(yīng)首先解決測試過程中的問題。
• 有些測試工具帶有測試策略的建議。但是這種建議很少能夠描述得很清楚，并不能針對具體情況，而且往往過于強(qiáng)調(diào)他們那種自動(dòng)化測試的重要性。
• 工具是輔助性的，關(guān)鍵還是靠人的思想和行為！

Parasoft

• Parasoft Jtest 代碼分析和動(dòng)態(tài)類、組件測試
• Parasoft C++Test代碼分析和動(dòng)態(tài)測試
• Parasoft .TEST代碼分析和動(dòng)態(tài)測試
• Parasoft Insure++ 實(shí)時(shí)性能監(jiān)控以及分析優(yōu)化
• Parasoft CodeWizard代碼靜態(tài)分析

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

Jcontract Java 實(shí)時(shí)性能監(jiān)控以及分析優(yōu)化

Parasoft C++Test

單元測試和靜態(tài)分析工具，自動(dòng)測試C和C＋＋類別、功能或組件，而無需編寫單個(gè)測試實(shí)例、測試驅(qū)動(dòng)程序或樁調(diào)用。只需點(diǎn)擊按鈕，C++Test即會(huì)采用業(yè) 內(nèi)編碼標(biāo)準(zhǔn)執(zhí)行代碼的靜態(tài)分析，測試代碼構(gòu)造（白盒測試），測試代碼功能性（黑盒測試），并保持代碼完整性（回歸測試）。

Parasoft .TEST

單元測試和靜態(tài)分析工具，自動(dòng)測試寫在Microsoft?.NET框架的類別，而無需編寫單個(gè)測試場景或樁調(diào)用。只需點(diǎn)擊按鈕，.TEST即會(huì) 在.NET源代碼上自動(dòng)執(zhí)行完整系列的靜態(tài)和動(dòng)態(tài)測試。.TEST RuleWizard性能通過圖形化表達(dá)希望.TEST在自動(dòng)編碼標(biāo)準(zhǔn)執(zhí)行過程中查找的模式，支持設(shè)計(jì)定制的編碼標(biāo)準(zhǔn)。

Parasoft Insure++

一個(gè)自動(dòng)化的內(nèi)存錯(cuò)誤、內(nèi)存泄漏的精確檢測工具。Insure++能夠可視化實(shí)時(shí)內(nèi)存操作，準(zhǔn)確檢測出內(nèi)存泄漏產(chǎn)生的根源。Insure++還能執(zhí)行覆蓋 性分析，清楚地指示那些代碼已經(jīng)測試過。將Insure++集成到您的開發(fā)環(huán)境中，能夠極大地減少調(diào)試時(shí)間并有效地防止錯(cuò)誤。

Parasoft CodeWizard

高級C/C++源代碼分析工具，采用三百種以上行業(yè)相關(guān)的編碼準(zhǔn)則，自動(dòng)識(shí)別編譯器未檢測到的危險(xiǎn)的編碼構(gòu)造。CodeWizard可以容易地通過 RuleWizard性能，創(chuàng)建新定制的準(zhǔn)則，或者抑制用于定制分析的準(zhǔn)則。日常使用CodeWizard，可簡化代碼檢查，并使代碼更具可讀性和可維護(hù) 性。

Compuware白盒測試工具集

• http://www.compuware.com
• BoundsChecker 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)源代碼分析工具

Compuware DevPartner Studio

針對軟件開發(fā)小組使用 Microsoft Visual C++，Microsoft Visual Basic，Java,ASP 或 HTML 設(shè)計(jì)的一套緊密配合的調(diào)試，測試和管理工具。該產(chǎn)品結(jié)合了強(qiáng)大的錯(cuò)誤檢測，性能分析，覆蓋率分析，需求管理，測試和發(fā)布工具與全面的工程跟蹤，錯(cuò)誤管理， 任務(wù)管理和自動(dòng)的工作流程。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) 行時(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開發(fā)的測試Visual C/C++ 和Java代碼中與內(nèi)存有關(guān)的錯(cuò)誤，確保整個(gè)應(yīng)用程序的質(zhì)量和可靠性。在查找典型的Visual C/C++程序中的傳統(tǒng)內(nèi)存訪問錯(cuò)誤，以及Java中與垃圾內(nèi)存收集相關(guān)的錯(cuò)誤方面，Rational Purify可以大顯身手。Rational Robot的回歸測試與Rational Purify結(jié)合使用完成可靠性測試。

網(wǎng)址：http://www-306.ibm.com/software/rational/

Rational Quantify

面向VC、VB 或者Java開發(fā)的測試性能瓶頸檢測工具，它可以自動(dòng)檢測出影響程序段執(zhí)行速度的程序性能瓶頸，提供參數(shù)分析表等等直觀表格。幫助分析影響程序短執(zhí)行速度 的關(guān)鍵部分。

網(wǎng)址：http://www-306.ibm.com/software/rational

Rational PureCoverage

面向VC、VB或者Java開發(fā)的測試覆蓋程度檢測工具，它可以自動(dòng)檢測你的測試完整性和那些無法達(dá)到的部分。作為一個(gè)質(zhì)量控制工程，可以使用 PureCoverage在每一個(gè)測試階段生產(chǎn)詳盡的測試覆蓋程度報(bào)告。

網(wǎng)址：http://www-306.ibm.com/software/rational/

IBM Rational PurifyPlus

一套完整的運(yùn)行時(shí)分析工具，旨在提升應(yīng)用的可靠性和性能。包括Purify、Quantify、PureCoverage。

AutomatedQA AQTime

AutomatedQA AQTime是軟件項(xiàng)目的測試工具，能實(shí)時(shí)/靜態(tài)地分析軟件的執(zhí)行效率和代碼性能，發(fā)現(xiàn)軟件項(xiàng)目客戶端和服務(wù)器段的瓶頸所在、內(nèi)存泄漏、消耗資源的代碼及 未經(jīng)驗(yàn)證的算法。能夠分析Delphi/BCB/VC/VB/GCC等工具開發(fā)的軟件產(chǎn)品，此外，它有專門For VS.NET的版本。AQTime是專業(yè)Windows開發(fā)者在開發(fā)過程中消除臆測的完全方案，使開發(fā)者在完成項(xiàng)目時(shí)開發(fā)出堅(jiān)如磐石的程序。通過 AQTime無可匹敵的報(bào)告系統(tǒng)和測試分析架構(gòu)，開發(fā)這不僅可以得知其項(xiàng)目中確實(shí)存在bug和瓶頸，而且會(huì)知道具體到哪個(gè)模塊、類、線程、代碼行出了問 題，從而快速消除錯(cuò)誤。

性能架構(gòu)和內(nèi)存分配調(diào)試器，適于Win32和.NET互聯(lián)程序。該工具可以集成到Microsoft Visual Studio .NET中，也可單獨(dú)使用。通過AQtime 4，您不僅可以發(fā)現(xiàn)程序瓶頸，還可以查找瓶頸來源。

AQtime 4是AutomatedQA的獲獎(jiǎng)產(chǎn)品performance profiling和memory debugging工具集的下一代替換產(chǎn)品，支持Microsoft, Borland, Intel, Compaq 和 GNU編譯器。新版本結(jié)合了旗艦產(chǎn)品Aqtime和AQtime for .NET的所有優(yōu)勢，前者主要面向Win32應(yīng)用程序性能分析，而后者則是第一個(gè)Microsoft .NET平臺(tái)的性能和內(nèi)存分配架構(gòu)工具。

如同其先前產(chǎn)品一樣，AQtime 4可以為.NET和Win32程序生成全面細(xì)致的報(bào)告，從而幫助您輕松隔離并排除代碼中含有的性能問題和內(nèi)存/資源泄露問題。

xUnit系列

目前的最流行的單元測試工具是xUnit系列框架，常用的根據(jù)語言不同分為JUnit（java），CppUnit（C++），DUnit （Delphi ），NUnit（.net），PhpUnit（Php ）等等。該測試框架的第一個(gè)和最杰出的應(yīng)用就是由Erich Gamma （《設(shè)計(jì)模式》的作者）和Kent Beck（XP（Extreme Programming）的創(chuàng)始人 ）提供的開放源代碼的JUnit。

xUnit系列

• Aunit Ada http://www.libre.act-europe.fr
• CppUnit C++ http://cppunit.sourceforge.net
• ComUnit VB,COM http://comunit.sourceforge.net
• Dunit Delphi http://dunit.sourceforge.net
• DotUnit .Net http://dotunit.sourceforge.net
• HttpUnit Web http://c2.com/cgi/wiki?HttpUnit
• HtmlUnit Web http://htmlunit.sourceforge.net
• Jtest Java http://www.junit.org
• JsUnit(Hieatt) Javas cript 1.4以上 http://www.jsunit.net
• PhpUnit Php http://phpunit.sourceforge.net
• PerlUnit Perl http://perlunit.sourceforge.net
• XmlUnit Xml http://xmlunit.sourceforge.net

CppUnit測試觀念

測試的結(jié)果是程序直接監(jiān)測的，而不是“通過人眼對屏幕上的輸出結(jié)果的觀測”。

cppunit并不推薦屏幕輸出，或者寫可視化的測試單元

測試的過程是自動(dòng)化的，不需要人工的干預(yù)

cppunit推薦用大量典型測試數(shù)據(jù)進(jìn)行回歸的方式

測試用例是安全可控的。如果一個(gè)測試用例錯(cuò)誤或者發(fā)生了異常，那么應(yīng)該記錄這個(gè)錯(cuò)誤，并且去執(zhí)行下一個(gè)用例，而不應(yīng)該停下來。cppunit測試框架保證 了這一點(diǎn)。

單元測試是頻繁發(fā)生的，每天都進(jìn)行。

由于測試案例的自動(dòng)化，故此，在你的模塊發(fā)生了重要改變時(shí)（特別是設(shè)計(jì)上的重大變化/重構(gòu)時(shí)）， 你都應(yīng)該馬上運(yùn)行一遍所有的測試程序，以確認(rèn)你的代碼沒有引入預(yù)期（或曾經(jīng)出現(xiàn)過）的bug。你可以在準(zhǔn)備吃飯的時(shí)候，啟動(dòng)單元測試程序進(jìn)行回歸。

單元測試的目的是產(chǎn)生高質(zhì)量的單元（模塊）。從而減少系統(tǒng)集成（包括系統(tǒng)集成測試）的代價(jià)。

Visual Studio 2005

Team版的VS2005里面包含了完整的Test功能,具體有:Unit Test,WebTest和LoadTest.這一整套的測試基本涵蓋了軟件開發(fā)會(huì)使用到的測試功能.

我這里先從單元測試開始介紹(Unit Test).說起單元測試,很多使用.net進(jìn)行開發(fā)的人員也許馬上就想起了NUnit,實(shí)際上它是個(gè)很好的工具,在VS2005出來之前,我也一直使 用.不過現(xiàn)在VS2005已經(jīng)提供了與NUnit一樣,甚至還要強(qiáng)大的功能,我們又有什么理由不使用呢?

微軟因該說是很好的領(lǐng)會(huì)和貫徹了這個(gè)中國的經(jīng)典儒家思想。Borland的Together好，.Net2005中就集成了了class designer,雖然說功能還不是很強(qiáng)大，同樣，在單元測試成為軟件開發(fā)中必不可少的環(huán)節(jié)而Nunit好評如潮的時(shí)，.Net2005中也加入了自己的 單元測試組件。

Visual Studio 2005

自動(dòng)代碼生成，是現(xiàn)代的開發(fā)環(huán)境追求的目標(biāo)之一，而visual stutio無疑是走在了業(yè)界的最前列。在.net 2005中可以在右鍵菜單中選擇unit test，而后針對該類的方法的單元測試的框架便自動(dòng)生成，為開發(fā)者提供了很大的便利。
Visual Studio 2005
Visual Studio 2005

Visual Unit

• 國產(chǎn)的單元測試工具，據(jù)說申請了多項(xiàng)專利，擁有一批創(chuàng)新的技術(shù)。
• VU目前版本適用于C++語言。
• 黑盒方面，可以輕松完成功能測試、邊界測試、速度測試，
• 白盒方面，可以輕松完成語句覆蓋、條件覆蓋、分支覆蓋、路徑覆蓋。這種空前的測試完整性，使代碼中的缺陷無所循形。

六、如何實(shí)施單元測試

• 學(xué)習(xí)基本理論
• 評估&選擇單元測試軟件
• 選擇范圍：靜態(tài)分析、動(dòng)態(tài)分析、測試程序框架
• 開發(fā)平臺(tái)：
• VC6.0?VS2005
• QNX

單元測試系列講座

• 基本理論
• CppUnit

七、討論

2 CppUnit Framework

一、背景

• CppUnit 是個(gè)基于 LGPL 的開源項(xiàng)目，最初版本移植自 JUnit，是一個(gè)非常優(yōu)秀的開源測試框架。
• CppUnit 和 JUnit 一樣主要思想來源于極限編程（XProgramming）。
• 主要功能就是對單元測試進(jìn)行管理，并可進(jìn)行自動(dòng)化測試。
• “現(xiàn)象” ? 就應(yīng)該學(xué)習(xí)使用這種技術(shù)

二、感性認(rèn)識(shí)

• CppUnit安裝與使用方法
• VC6
• VS2005
• QNX
• CppUnit快速入門

CppUnit VC6.0安裝

• 重要參考：INSTALL-WIN32.txt
• 解壓cppunit-1.12.0.tar.gz
• Building:---------
  * Open the src/CppUnitLibraries.dsw workspace in VC++.
  * In the 'Build' menu, select 'Batch Build...'
  * In the batch build dialog, select all projects and press the build button.
  * The resulting libraries can be found in the lib/ directory.
• 注意：直接編譯會(huì)有錯(cuò)誤

CppUnit VC6.0安裝

• 注冊插件
• At the current time, the only supported WIN32 platform is
• Microsoft Visual C++. You must have VC++ 6.0 at least.
• Quick Steps to compile & run a sample using the GUI TestRunner:
  - Open examples/examples.dsw in VC++ (contains all the samples).
• VC7 will ask you if you want to convert, anwser 'yes to all'.
  - Make HostApp the Active project
  - Compile
  - For Visual Studio 6 only:
  - in VC++, Tools/Customize.../Add-ins and macro files/Browse...
  - select the file lib/TestRunnerDSPlugIn.dll and press ok to register
• the add-ins (double-click on failure = open file in VC++).
  - Run the project

CppUnit VC 設(shè)置

• “Projects/Settings.../C++/C++ Language”頁選中“Enable RTTI ”
  RTTI---Run-Time Type Information
• 在“Projects/Settings.../C++/Code Generation”頁選擇“Use run-time library”中的內(nèi)容：
  Release版, 選擇"Mulithreaded DLL".
  Debug版, 選擇 "Debug Multihreaded DLL".
• Project Settings/Post-Build step增加： $(TargetPath)

CppUnit VS2005安裝

• 1、 Open examples/examples.dsw in VC++ (contains all the samples).
  VC7 will ask you if you want to convert, anwser 'yes to all'.
• 2、解決方案上右鍵，批量編譯，選擇全部，編譯
• 3、錯(cuò)誤：
  #import "libid:80cc9f66-e7d8-4ddd-85b6-d9e6cd0e93e2" version
  ("7.0") lcid("0") raw_interfaces_only named_guids
  改為：
  #import "libid:80cc9f66-e7d8-4ddd-85b6-d9e6cd0e93e2" version
  ("8.0") lcid("0") raw_interfaces_only named_guids
• 4、d:/cppunit-1.12.0/cppunit-1.12.0/src/msvc6/dsplugin/stdafx.h
  (12) : fatal error C1189: #error : This add-in is for VC++ 6.0
  ?only.
  不用處理

CppUnit VS2005 向?qū)?/p>

• 0. 下載 CPPUnitProjectWizard
• 1. 復(fù)制文件
  CPPUnitProjectWizard.vsdir - 為向?qū)?br /> CPPUnitProjectWizard.vsz - 讓VS8知道從哪里找到向?qū)?br /> 到您的Visual Studio 8安裝目錄下的 VSProjects 文件夾中
• 2. 把整個(gè)CPPUnitProjectWizard解決方案文件夾復(fù)制到您的Visual Studio 8安裝目錄下的VCWizards文件夾中。
  比如，我放在c:/Program Files/Microsoft Visual Studio 8/VC/VCWizards/CPPUnitProjectWizard/CPPUnitProjectWizard
  或者，也可以放在你想放置的其它地方，然后編譯CPPUnitProjectWizard.vsz，定義參數(shù) ABSOLUTE_PATH
  Param="ABSOLUTE_PATH = c:/Program Files/Microsoft Visual Studio 8/VC/VCWizards/CPPUnitProjectWizard/CPPUnitProjectWizard"
• 3. 該項(xiàng)目需要定義環(huán)境變量 CPPUNITDIR
  比如，我的環(huán)境變量 %CPPUNITDIR% = D:/cppunit-1.12.0
  最后，修改 環(huán)境變量 %PATH%,在PATH路徑中，增加 %CPPUNITDIR%/lib，以便程序加載時(shí)能找到 cppunit_dll.dll
• 4. 在開發(fā)環(huán)境中，設(shè)置好Include/Lib路徑
  %CPPUNITDIR%/Include
  %CPPUNITDIR%/LIB

CppUnit QNX

• 參考工程模板
• 修改buildcfg.bat
• Qnx的安裝環(huán)境設(shè)置
• QNXDISK：qnx安裝在的分區(qū)
• SUNYPRJPATH：工程根路徑
• 調(diào)用build.bat編譯
• 舉例說明

CppUnit快速入門

• CppUnit本身的測試
• Example0--快速入門

三、基本理論

• 什么是 UnitTest Framework
• 什么是 CppUnit
• CppUnit 架構(gòu)
• 產(chǎn)品代碼與測試代碼關(guān)系
• Unit Test與 TDD（測試驅(qū)動(dòng)開發(fā)）
• CppUnit的原理

什么是UnitTest Framework

單元測試框架是編寫和運(yùn)行單元測試的軟件工具，用來構(gòu)建測試、運(yùn)行測試、報(bào)告測試結(jié)果

unit test famework 的歷史以及 CppUnit
JUnit -> xUnit（含CppUnit ）

xUnit 家族

Junit - The reference implementation of xUnit
CppUnit - The C++ port of JUnit
NUnit - The xUnit for .NET
PyUnit - The Python version of xUnit
MinUnit - minimal but functional C Languages unit test framework
XmlUnit – for XML contents

什么是 CppUnit

CppUnit是個(gè)基于 LGPL 的開源項(xiàng)目，最初版本移植自 JUnit ，是一個(gè)非常優(yōu)秀的開源測試框架。CppUnit和 JUnit 一樣主要思想來源于極限編程（XProgramming）。主要功能就是對單元測試進(jìn)行管理，并可進(jìn)行自動(dòng)化測試。
CppUnit 架構(gòu)--- namespace
CppUnit 架構(gòu)--- key classes
CppUnit 架構(gòu)--- classes to collect test results
CppUnit 架構(gòu)--- outputter classes for printing test results

產(chǎn)品代碼與測試代碼關(guān)系

產(chǎn)品代碼和測試代碼的目錄結(jié)構(gòu)示意圖

產(chǎn)品代碼與測試代碼關(guān)系

產(chǎn)品代碼與測試框架關(guān)系示意圖

Unit Test與 TDD（測試驅(qū)動(dòng)開發(fā)）

• 測試驅(qū)動(dòng)開發(fā)精髓
• TDD循環(huán)
  “Test twice, code once” - 測試兩次，編碼一次。
• 測試驅(qū)動(dòng)開發(fā)的原則

測試驅(qū)動(dòng)開發(fā)精髓

• 維護(hù)詳盡的程序員編寫的測試程序組
• 除非有相關(guān)的測試，否則代碼不應(yīng)被加入產(chǎn)品（“極限編程”，因?yàn)闇y試是重要的，所以對幾乎所有代碼都要有測試）
• 測試先行
• 測試決定你需要寫的代碼

TDD循環(huán)

“Test twice, code once”

• 編寫新代碼的測試，查看是否失敗
• 編寫新代碼，以最簡方式實(shí)現(xiàn)
• 再次測試是否成功，重構(gòu)代碼

測試驅(qū)動(dòng)開發(fā)的原則

• 先寫測試代碼，然后編寫符合測試的代碼。至少做到完成部分代碼后，完成對應(yīng)的測試代碼；
• 測試代碼不需要覆蓋所有的細(xì)節(jié)，但應(yīng)該對所有主要的功能和可能出錯(cuò)的地方有相應(yīng)的測試用 例；
• 發(fā)現(xiàn) bug，首先編寫對應(yīng)的測試用例，然后進(jìn)行調(diào)試；
• 不斷總結(jié)出現(xiàn) bug 的原因，對其他代碼編寫相應(yīng)測試用例；
• 每次編寫完成代碼，運(yùn)行所有以前的測試用例，驗(yàn)證對以前代碼影響，把這種影響盡早消除；
• 不斷維護(hù)測試代碼，保證代碼變動(dòng)后通過所有測試；
• 在編碼前：他可以強(qiáng)迫你對需求進(jìn)行詳細(xì)的分析。
• 在編碼時(shí)：他可以使你對over coding保持警覺。
• 在重構(gòu)時(shí)：可以確保新的設(shè)計(jì)能夠兼容舊版本的功能。
• 在團(tuán)隊(duì)開發(fā)時(shí)：可以確保自己的單元是無誤的。

CppUnit的原理

• Test
• TestFixture
• TestCase
• TestSuite
• ASSERT

CppUnit的原理--- Test

• //Test.h
• 測試類的抽象基類
• 規(guī)定了所有測試類都應(yīng)該具有的行為
• 對應(yīng)于Composite Pattern中的Component

CppUnit的原理--- TestFixture

• //TestFixture.h
• 一個(gè)或一組測試用例的測試對象被稱為 Fixture
• Fixture就是被測試的目標(biāo)
• 為一組相關(guān)的測試提供運(yùn)行所需的公用環(huán)境
• 抽象類，用于包裝測試類使之具有setUp方法和tearDown方法。

CppUnit的原理--- TestCase

• //TestCase.h，TestCase.cpp
• 多重繼承：
• TestCase : public TestLeaf, public TestFixture
• TestLeaf: public Test
• TestCase ：對這個(gè) Fixture 的某個(gè)功能、某個(gè)可能出錯(cuò)的流程編寫測試代碼，這樣對某個(gè)方面完整的測試被稱為TestCase（測試用例）

CppUnit的原理--- TestCase步驟

• 對 fixture 進(jìn)行初始化，及其他初始化操作，比如：生成一組被測試的對象，初始化值；（ setUp ()）
• 按照要測試的某個(gè)功能或者某個(gè)流程對 fixture 進(jìn)行操作；
• 驗(yàn)證結(jié)果是否正確；
  對 fixture 的及其他的資源釋放等清理工作 （ tearDown()）

運(yùn)行時(shí) CppUnit 會(huì)自動(dòng)為每個(gè)測試用例函數(shù)運(yùn)行 setUp，之后運(yùn)行 tearDown，這樣測試用例之間就沒有交叉影響

CppUnit的原理--- TestCase注意點(diǎn)

• 可以自動(dòng)執(zhí)行，不用人手操作。
• 自動(dòng)返回測試結(jié)果。
• 絕對的獨(dú)立，不能與其他TestCase有任何聯(lián)系。就算測試同一個(gè)函數(shù)的不同功能也需要分開。每個(gè)TestCase可以說是一個(gè)孤島。
• 例如
  CppUnit的原理--- TestCase例子
  CppUnit的原理--- ASSERT
• CPPUNIT_ASSERT(condition)：判斷condition的值是否為 真，如果為假則生成錯(cuò)誤信息。
• CPPUNIT_ASSERT_MESSAGE(message, condition)：與CPPUNIT_ASSERT類似，但結(jié)果為假時(shí)報(bào)告messsage信息。
• CPPUNIT_FAIL(message)：直接報(bào)告messsage錯(cuò)誤信息。
• CPPUNIT_ASSERT_EQUAL(expected, actual)：判斷expected和actual的值是否相等，如果不等輸出錯(cuò)誤信息。
• CPPUNIT_ASSERT_EQUAL_MESSAGE(message, expected, actual)：與CPPUNIT_ASSERT_EQUAL類似，但斷言失敗時(shí)輸出message信息。
• CPPUNIT_ASSERT_DOUBLES_EQUAL(expected, actual, delta)：判斷expected與actual的偏差是否小于delta，用于浮點(diǎn)數(shù)比較。
• CPPUNIT_ASSERT_THROW(expression, ExceptionType)：判斷執(zhí)行表達(dá)式expression后是否拋出ExceptionType異常。
• CPPUNIT_ASSERT_NO_THROW(expression)：斷言執(zhí)行表達(dá)式expression后無異常拋出。

四、 核心內(nèi)容

• 測試對象（Test，TestFixture，...）
  用于開發(fā)測試用例，以及對測試用例進(jìn)行組織管理
• 測試結(jié)果（TestResult）
  處理測試用例執(zhí)行結(jié)果， Observer Pattern
• 測試結(jié)果監(jiān)聽者（TestListener）
  TestListener作為TestResult的觀察者，擔(dān)任實(shí)際的結(jié)果處理角色
• 結(jié)果輸出（Outputter）
  將結(jié)果進(jìn)行輸出，可以制定不同的輸出格式
• 對象工廠（TestFactory）
  用于創(chuàng)建測試對象，對測試用例進(jìn)行自動(dòng)化管理
• 測試執(zhí)行體（TestRunner）
  用于運(yùn)行一個(gè)測試
  核心內(nèi)容 ---Test
• 所有測試對象的基類
• CppUnit采用樹形結(jié)構(gòu)來組織管理測試對象,類似于目錄樹

組合設(shè)計(jì)模式（Composite Pattern），Test的兩個(gè)直接子類TestLeaf和TestComposite分別表示“測試樹”中的葉節(jié)點(diǎn)和非葉節(jié)點(diǎn)，其中 TestComposite主要起組織管理的作用，就像目錄樹中的文件夾，而TestLeaf才是最終具有執(zhí)行能力的測試對象，就像目錄樹中的文件。

Test最重要的一個(gè)公共接口為：
virtual void run(TestResult *result) = 0;
其作用為執(zhí)行測試對象，將結(jié)果提交給result。

在實(shí)際應(yīng)用中，一般不會(huì)直接使用Test、TestComposite以及TestLeaf，除非要重新定制某些機(jī)制。

核心內(nèi)容 ---TestFixture

用于維護(hù)一組測試用例的上下文環(huán)境

在實(shí)際應(yīng)用中，經(jīng)常會(huì)開發(fā)一組測試用例來對某個(gè)類的接口加以測試，而這些測試用例很可能具有相同 的初始化和清理代碼。為此，CppUnit引入TestFixture來實(shí)現(xiàn)這一機(jī)制。

TestFixture具有以下兩個(gè)接口，分別用于處理測試環(huán)境的初始化與清理工作：
virtual void setUp();
virtual void tearDown();

核心內(nèi)容 ---TestCase

測試用例，從名字上就可以看出來，它便是單元測試的執(zhí)行對象。
TestCase從Test和TestFixture多繼承而來，通過把Test::run制定成模板函數(shù)（Template Method）而將兩個(gè)父類的操作融合在一起

這里要提到的是函數(shù)runTest，它是TestCase定義的一個(gè)接口，原型如下：
virtual void runTest();

用戶需從TestCase派生出子類并實(shí)現(xiàn)runTest以開發(fā)自己所需的測試用例。

核心內(nèi)容 ---TestSuit

測試包，按照樹形結(jié)構(gòu)管理測試用例

TestSuit是TestComposite的一個(gè)實(shí)現(xiàn)，它采用vector來管理子測試對象（Test），從而形成遞歸的樹形結(jié)構(gòu)。

核心內(nèi)容 --- TestCaller

TestCase適配器（Adapter），它將成員函數(shù)轉(zhuǎn)換成測試用例

雖然可以從TestCase派生自己的測試類，但從TestCase類的定義可以看出，它只能支持一個(gè)測試用例，這對于測試代碼的組織和維護(hù)很不方便，尤 其是那些有共同上下文環(huán)境的一組測試。為此，CppUnit提供了TestCaller以解決這個(gè)問題

TestCaller是一個(gè)模板類，它以實(shí)現(xiàn)了TestFixture接口的類為模板參數(shù)，將目標(biāo)類中某個(gè)符合runTest原型的測試方法適配成 TestCase的子類。

在實(shí)際應(yīng)用中，大多采用TestFixture和TestCaller相組合的方式,詳見后面的 例子

核心內(nèi)容 ---TestResult和TestListener

處理測試信息和結(jié)果

TestResult和TestListener采用了觀察者模式，TestResult維護(hù)一 個(gè)注冊表，用于管理向其登記過的TestListener，當(dāng)TestResult收到測試對象（Test）的測試信息時(shí)，再一一分發(fā)給它所管轄的 TestListener。這一設(shè)計(jì)有助于實(shí)現(xiàn)對同一測試的多種處理方式。

核心內(nèi)容 ---TestFactory

測試工廠

輔助類，通過借助一系列宏定義讓測試用例的組織管理變得自動(dòng)化。參見后面的例子

核心內(nèi)容 --- TestRunner

用于執(zhí)行測試用例

TestRunner將待執(zhí)行的測試對象管理起來，然后供用戶調(diào)用。其接口為：
virtual void addTest( Test *test ); virtual void run( TestResult &controller, const std::string &testPath = "" );

這也是一個(gè)輔助類，需注意的是，通過addTest添加到TestRunner中的測試對象必須 是通過new動(dòng)態(tài)創(chuàng)建的，用戶不能刪除這個(gè)對象，因?yàn)門estRunner將自行管理測試對象的生命期
??核心內(nèi)容 ---例1
??核心內(nèi)容 ---例1
??核心內(nèi)容 ---例1
??核心內(nèi)容 ---例2
??核心內(nèi)容 ---例2
??核心內(nèi)容 ---例2
??核心內(nèi)容 ---例3
??核心內(nèi)容 ---例3
??核心內(nèi)容 ---例3

五、三個(gè)例子分析

六、CppUnit源碼解讀

• 參考“CppUnit源碼解讀.doc”

七、討論