軟件測試系列培訓之單元測試+幻燈片1.ppt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20、情況下進行測試。,單元測試(Unit Test),對于程序員來說，如果養(yǎng)成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高質量的代碼，而且還能提高編程水平。 在一種傳統(tǒng)的結構化編程語言中，比如C，要進行測試的單元一般是函數(shù)或子過程。在象C+這樣的面向對象的語言中，要進行測試的基本單元是類。對Ada語言來說，開發(fā)人員可以選擇是在獨立的過程和函數(shù)，還是在Ada包的級別上進行單元測試。單元測試的原則同樣被擴展到第四代語言(4GL)的開發(fā)中，在這里基本單元被典型地劃分為一個菜單或顯示界面。,單元測試(Unit Test),單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發(fā)過程中使用，單元測試必須

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

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

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

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

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

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

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

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

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

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

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

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

33、其他好處 1：減少程序的Bug,要減少軟件中的錯誤數(shù)目，方法之一就是擁有一個專業(yè)的測試組，其工作就是盡一切可能使軟件崩潰。不幸的是，如果擁有測試組，那么即使是經驗豐富的開發(fā)人員，也會傾向于花費較少的時間來保證代碼的可靠性。 軟件界有一句俗語：“開發(fā)人員不應該測試他們自己的代碼”。這是因為開發(fā)人員對自己的代碼了如指掌，他們很清楚如何采用適當?shù)姆椒▽Υa進行測試。盡管這句俗語很有道理，但卻忽略了非常重要的一點 - 如果開發(fā)人員不對自己的代碼進行測試，又如何知道代碼能否按照預期的方式運行？ 簡單說來，他們根本無從得知。開發(fā)人員編寫那種運行不正?；蛑辉谀承┣闆r下運行正常的代碼是一個嚴重的問題。他們通常

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

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

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

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

38、還會發(fā)現(xiàn)一些很容易發(fā)現(xiàn)而在集成測試和系統(tǒng)測試很難發(fā)現(xià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ù)上升的，這就是我們要盡可能早的排除盡可能多的bug來減少后期成本的因素之一。,重要性 4：產品質量,單元測試的好與壞直接影響到產品的質量，可能就是由

39、于代碼中的某一個小錯誤就導致了整個產品的質量降低一個指標，或者導致更嚴重的后果，如果我們做好了單元測試這種情況是可以完全避免的。 綜上所述，單元測試是構筑產品質量的基石，我們不要因為節(jié)約單元測試的時間不做單元測試或隨便做而讓我們在后期浪費太多的不值得的時間，我們也不愿意因為由于節(jié)約那些時間導致開發(fā)出來的整個產品失敗或重來！,四、 C/C+單元測試問答,為什么要進行單元測試? 由誰進行測試？開發(fā)部門還是測試部門？ 由測試部門進行單元測試為什么成本昂貴？ 由開發(fā)部門進行單元測試能保證測試效果嗎？ 邊編碼邊測試會影響編碼進度嗎？ 實施單元測試需要改變開發(fā)流程嗎？ 單元測試測試哪些代碼？ 實際工作中，

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

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

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

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

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

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

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

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

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

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

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

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

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

53、測試員如何測試。如果測試出現(xiàn)問題，則測試工具會加重問題。在實現(xià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 Jte

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

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

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

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

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

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