常用的測試方法和測試工具.doc

_常用的測試方法一、 黑盒測試1. 黑盒測試其實是一種功能測試，主要在軟件的接口處進行。主要測試的以下幾類錯誤：是否有不正確或遺漏的功能在給出的接口處正確的輸入是否有正確的輸出是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息訪問錯誤性能上是否滿足要求是否有初始化或終止性錯誤2. 黑盒測試用例等價類劃分 等價類即輸入域的子集合,測試用例設(shè)計時應(yīng)設(shè)計出對應(yīng)的有效等價類和無效等價類邊界值 邊界值法是對等價類劃分方法的補充，主要是測試發(fā)生在輸入和輸出域邊界上的錯誤.等價類劃分和邊界值著重考慮輸入條件,但測試時還應(yīng)考慮輸入條件之間的關(guān)系，各種條件的組合情況，即因果圖因果圖 根據(jù)輸入條件間的關(guān)系生成判定表，根據(jù)判定表的每一列來設(shè)計測試用例功能圖 包括狀態(tài)遷移圖和邏輯模型二、 白盒測試1白盒測試是對軟件過程性細節(jié)做細致的檢查。主要對軟件程序模塊做以下檢查：對模塊的所有路徑至少執(zhí)行一次對模塊的所有邏輯判斷，取“真”和“假”兩種情況各執(zhí)行一次在循環(huán)邊界和運行界限內(nèi)執(zhí)行循環(huán)體測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性2白盒測試用例 1)邏輯覆蓋 語句覆蓋 分支覆蓋 對程序模塊中的每個取真分支和取假分支執(zhí)行一遍 條件覆蓋 對程序模塊中的每個判斷的每個條件執(zhí)行一遍 由于以上的測試用例都有較大的缺陷，所以一般不會使用,采用條件組合覆蓋更為合理有效 條件組合覆蓋(邏輯覆蓋的主要方法) 2)基本路徑測試用例 測試步驟：根據(jù)詳細設(shè)計或源代碼導(dǎo)出程序控制流圖 計算程序環(huán)路復(fù)雜性,即獨立路徑的數(shù)目(一條新的路徑必須包含一條新邊)生成測試用例(輔助工具：圖形矩陣)測試策略一、 單元測試1. 單元測試時主要對模塊的以下5個方面進行檢查：模塊接口局部數(shù)據(jù)結(jié)構(gòu)邊界條件獨立路徑出錯處理二、 集成測試1. 集成測試時主要要考察程序的以下幾個方面:各個模塊連接時,穿越模塊接口的數(shù)據(jù)是否會丟失一個模塊是否會對另一個模塊的功能產(chǎn)生不利的影響各個子功能組合起來,能否達到預(yù)期的父功能全局數(shù)據(jù)結(jié)構(gòu)是否有問題單個模塊的誤差累積起來,是否會被放大,從而達到不可接受的程度2. 集成測試的組織和實施中考慮的因素: 選用何種系統(tǒng)集成方法來進行集成測試 各個模塊連接的順序 模塊代碼編制和測試進度是否集成測試的順序是否一致 測試過程中是否需要有專門的硬件3. 集成測試完成的標志 成功執(zhí)行了測試計劃中規(guī)定的所有組裝測試 修正了所發(fā)現(xiàn)的錯誤 測試結(jié)果通過了專門小組的評審三、 確認測試1. 確認測試流程:進行有效性測試,即在模擬的環(huán)境下（可能是開發(fā)環(huán)境），運用黑盒測試的方法，驗證所沒軟件是否滿足需求說明書列出的需求。對于測試結(jié)果與預(yù)期結(jié)果不相符進，要提交一份問題報告。 軟件配置復(fù)查軟件配置復(fù)查的目的是保證軟件配置的所有成份都齊全，各方面的質(zhì)量都符合要求。 測試和測試 測試是一個用戶在開發(fā)環(huán)境下進行的測試，也可以是開發(fā)機構(gòu)內(nèi)部的用戶在模擬實際操作環(huán)境下進行的測試。測試是由軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試 驗收測試 驗收測試時軟件開發(fā)人員和QA人員也應(yīng)參加，由用戶參加設(shè)計測試用例，使用用戶界面輸入測試數(shù)據(jù)，并分析測試結(jié)果。四、 系統(tǒng)測試 即通過確認測試的軟作為整個系統(tǒng)中的一個元素而進行的測試。嵌入式系統(tǒng)測試方法及工具通常嵌入式系統(tǒng)對可靠性的要求比較高。嵌入式系統(tǒng)安全性的失效可能會導(dǎo)致災(zāi)難性的后果，即使是非安全性系統(tǒng)，由于大批量生產(chǎn)也會導(dǎo)致嚴重的經(jīng)濟損失。這就要求對嵌入式系統(tǒng)，包括嵌入式軟件進行嚴格的測試、確認和驗證。一般來說，軟件測試有7個基本階段，即單元或模塊測試、集成測試、外部功能測試、回歸測試、系統(tǒng)測試、驗收測試、安裝測試。嵌入式軟件測試在4個階段上進行，即模塊測試、集成測試、系統(tǒng)測試、硬件/軟件集成測試。前3個階段適用于任何軟件的測試，硬件/軟件集成測試階段是嵌入式軟件所特有的，目的是驗證嵌入式軟件與其所控制的硬件設(shè)備能否正確地交互。1. 白盒測試與黑盒測試由于嚴格的安全性和可靠性的要求，嵌入式軟件測試同非嵌入式軟件測試相比，通常要求有更高的代碼覆蓋率。對于嵌入式軟件，白盒測試一般不必在目標硬件上進行，更為實際的方式是在開發(fā)環(huán)境中通過硬件仿真進行，所以選取的測試工具應(yīng)該支持在宿主環(huán)境中的測試。因為黑盒測試與需求緊密相關(guān)，需求規(guī)格說明的質(zhì)量會直接影響測試的結(jié)果，黑盒測試只能限制在需求的范圍內(nèi)進行。在進行嵌入式軟件黑盒測試時，要把系統(tǒng)的預(yù)期用途作為重要依據(jù)，根據(jù)需求中對負載、定時、性能的要求，判斷軟件是否滿足這些需求規(guī)范。為了保證正確地測試，還須要檢驗軟硬件之間的接口。嵌入式軟件黑盒測試的一個重要方面是極限測試。在使用環(huán)境中，通常要求嵌入式軟件的失效過程要平穩(wěn)，所以，黑盒測試不僅要檢查軟件工作過程，也要檢查軟件換效過程。2、目標環(huán)境測試和宿主環(huán)境測試在嵌入式軟件測試中，常常要在基于目標的測試和基于宿主的測試之間作出折衷?；谀繕说臏y試消耗較多的經(jīng)費和時間，而基于宿主的測試代價較小，但畢竟是在模擬環(huán)境中進行的。目前的趨勢是把更多的測試轉(zhuǎn)移到宿主環(huán)境中進行，但是，目標環(huán)境的復(fù)雜性和獨特性不可能完全模擬。在兩個環(huán)境中可以出現(xiàn)不同的軟件缺陷，重要的是目標環(huán)境和宿主環(huán)境的測試內(nèi)容有所選擇。在宿主環(huán)境中，可以進行邏輯或界面的測試、以及與硬件無關(guān)的測試。在模擬或宿主環(huán)境中的測試消耗時間通常相對較少，用調(diào)試工具可以更快地完成調(diào)試和測試任務(wù)。而與定時問題有關(guān)的白盒測試、中斷測試、硬件接口測試只能在目標環(huán)境中進行。在軟件測試周期中，基于目標的測試是在較晚的“硬件/軟件集成測試”階段開始的，如果不更早地在模擬環(huán)境中進行白盒測試，而是等到“硬件/軟件集成測試”階段進行全部的白盒測試，將耗費更多的財力和人力。2. 常用的嵌入式軟件測試工具1)內(nèi)存分析工具在嵌入式系統(tǒng)中，內(nèi)存約束通常是有限的。內(nèi)存分析工具用來處理在動態(tài)內(nèi)存分配中存在的缺陷。當動態(tài)內(nèi)存被錯誤地分配后，通常難以再現(xiàn)，可能導(dǎo)致的失效難以追蹤，使用內(nèi)存分析工具可以避免這類缺陷進入功能測試階段。目前有兩類內(nèi)存分析工具軟件和硬件的?；谲浖膬?nèi)存分析工具可能會對代碼的性能造成很大影響，從而嚴重影響實時操作；基于硬件的內(nèi)存分析工具價格昂貴，而且只能在工具所限定的運行環(huán)境中使用。2)性能分析工具在嵌入式系統(tǒng)中，程序的性能通常是非常重要的。經(jīng)常會有這樣的要求，在特定時間內(nèi)處理一個中斷，或生成具有特定定時要求的一幀。開發(fā)人面臨的問題是決定應(yīng)該對哪一部分代碼進行優(yōu)化來改進性能，常常會花大量的時間去優(yōu)化那些對性能沒有任何影響的代碼。性能分析工具會提供有關(guān)的數(shù)據(jù)，說明執(zhí)行時間是如何消耗的，是什么時候消耗的，以及每個例程所用的時間。根據(jù)這些數(shù)據(jù)，確定哪些例程消耗部分執(zhí)行時間，從而可以決定如何優(yōu)化軟件，獲得更好的時間性能。對于大多數(shù)應(yīng)用來說，大部分執(zhí)行時間用在相對少量的代碼上，費時的代碼估計占所有軟件總量的5%-20%。性能分析工具不僅能指出哪些例程花費時間，而且與調(diào)試工具聯(lián)合使用可以引導(dǎo)開發(fā)人員查看需要優(yōu)化的特定函數(shù)，性能分析工具還可以引導(dǎo)開發(fā)人員發(fā)現(xiàn)在系統(tǒng)調(diào)用中存在的錯誤以及程序結(jié)構(gòu)上的缺陷。3)GUI測試工具很多嵌入式應(yīng)用帶有某種形式的圖形用戶界面進行交互，有些系統(tǒng)性能測試足根掘用戶輸入響應(yīng)時間進行的。GUI測試工具可以作為腳本工具有開發(fā)環(huán)境中運行測試用例，其功能包括對操作的記錄和回放、抓取屏幕顯示供以后分析和比較、設(shè)置和管理測試過程。很多嵌入式設(shè)備沒有GUI，但常?？梢詫η度胧皆O(shè)備進行插裝來運行GUI測試腳本，雖然這種方式可能要求對被測代碼進行更改，但是節(jié)省了功能測試和回歸測試的時間。4)覆蓋分析工具在進行白盒測試時，可以使用代碼覆蓋分析工具追蹤哪些代碼被執(zhí)行過。分析過程可以通過插裝來完成，插裝可以是在測試環(huán)境中嵌入硬件，也可以是在可執(zhí)行代碼中加入軟件，也可以是二者相結(jié)合。測試人員對結(jié)果數(shù)據(jù)加以總結(jié)，確定哪些代碼被執(zhí)行過，哪些代碼被巡漏了。覆蓋分析工具一般會提供有關(guān)功能覆蓋、分支覆蓋、條件覆蓋的信息。對于嵌入式軟件來說，代碼覆蓋分析工具可能侵入代碼的執(zhí)行，影響實時代碼的運行過程?；谟布拇a覆蓋分析工具的侵入程度要小一些，但是價格一般比較昂貴，而且限制被測代碼的數(shù)量。 嵌入式測試的十大秘訣在嵌入式軟件開發(fā)過程中，一般來說，花在測試和花在編碼的時間比為3:1(實際上可能更多)。這個比例隨著你的編程和測試水平的提高而不斷下降，但不論怎樣，軟件測試對一般人來講很重要。很多年前，一位開發(fā)人員為了對嵌入式有更深層次的理解，向Oracle詢問了這樣的一個問題:我怎么才能知道并懂得我的系統(tǒng)到底在干些什么呢?Oracle面對這個問題有些吃驚，因為在當時沒有人這么問過，而同時代的嵌入式開發(fā)人員問的最多的大都圍繞“我怎么才能使程序跑的更快”、“什么編譯器最好”等膚淺的問題。所以，面對這個不同尋常卻異乎成熟的問題，Oracle感到欣喜并認真回復(fù)了他:你的問題很有深度很成熟，因為只有不斷地去深入理解才有可能不斷地提高水平。并且Oracle為了鼓勵這位執(zhí)著的程序員，把條關(guān)于嵌入式軟件開發(fā)測試的秘訣告訴了他: 1.懂得使用工具2.盡早發(fā)現(xiàn)內(nèi)存問題3.深入理解代碼優(yōu)化4.不要讓自己大海撈針5.重現(xiàn)并隔離問題6.以退為進7.確定測試的完整性8.提高代碼質(zhì)量意味著節(jié)省時間9.發(fā)現(xiàn)它，分析它，解決它10.利用初學(xué)者的思維這十條秘訣在業(yè)界廣為流傳，使很多人受益。本文圍繞這十條秘訣展開論述。.懂得使用工具通常嵌入式系統(tǒng)對可靠性的要求比較高。嵌入式系統(tǒng)安全性的失效可能會導(dǎo)致災(zāi)難性的后果，即使是非安全性系統(tǒng)，由于大批量生產(chǎn)也會導(dǎo)致嚴重的經(jīng)濟損失。這就要求對嵌入式系統(tǒng)，包括嵌入式軟件進行嚴格的測試、確認和驗證。隨著越來越多的領(lǐng)域使用軟件和微處理器控制各種嵌入式設(shè)備，對門益復(fù)雜的嵌入式軟件進行快速有效的測試愈加顯得重要。就象修車需要工具一樣，好的程序員應(yīng)該能夠熟練運用各種軟件工具。不同的工具，有不同的使用范圍，有不同的功能。使用這些工具，你可以看到你的系統(tǒng)在干些什么，它又占用什么資源，它到底和哪些外界的東西打交道。讓你郁悶好幾天的問題可能通過某個工具就能輕松搞定，可惜你就是不知道。那么為什么那么多的人總是在折騰個半死之后才想到要用測試工具呢？原因很多，主要有兩個。一個是害怕，另一個是惰性。害怕是因為加入測試用具或測試模塊到代碼需要技巧同時有可能引入新的錯誤，所以他們總喜歡寄希望于通過不斷地修改重編譯代碼來消除bug,結(jié)果卻無濟于事。懶惰是因為他們習(xí)慣了使用printf之類的簡單測試手段。下面來介紹一些嵌入式常用的測試工具。.源碼級調(diào)試器Source-level Debugger這種調(diào)試器一般提供單步或多步調(diào)試、斷點設(shè)置、內(nèi)存檢測、變量查看等功能，是嵌入式調(diào)試最根本有效的調(diào)試方法。比如VxWorks TornadoII提供的gdb就屬于這一種。.簡單實用的打印顯示工具printfprintf或其它類似的打印顯示工具估計是最靈活最簡單的調(diào)試工具。打印代碼執(zhí)行過程中的各種變量可以讓你知道代碼執(zhí)行的情況。但是，printf對正常的代碼執(zhí)行干擾比較大(一般printf占用CPU比較長的時間)，需要慎重使用，最好設(shè)置打印開關(guān)來控制打印。.ICE或JTAG調(diào)試器In-circuit EmulatorICE是用來仿真CPU核心的設(shè)備，它可以在不干擾運算器的正常運行情況下，實時的檢測CPU的內(nèi)部工作情況。像桌面調(diào)試軟件所提供的：復(fù)雜的條件斷點、先進的實時跟蹤、性能分析和端口分析這些功能，它也都能提供。ICE一般都有一個比較特殊的CPU，稱為外合(bond-out)CPU。這是一種被打開了封裝的CPU，并且通過特殊的連接，可以訪問到CPU的內(nèi)部信號，而這些信號，在CPU被封裝時，是沒法“看到”的。當和工作站上強大的調(diào)試軟件聯(lián)合使用時，ICE就能提供你所能找到的最全面的調(diào)試功能。但ICE同樣有一些缺點：昂貴；不能全速工作；同樣，并不是所有的CPU都可以作為外合CPU的，從另一個角度說，這些外合CPU也不大可能及時的被新出的CPU所更換。JTAG(Joint Test Action Group)雖然它最初開發(fā)出來是為了監(jiān)測IC和電路連接，但是這種串行接口擴展了用途，包括對調(diào)試的支持。AD公司為Blackfin設(shè)計的Visual Dsp+就支持高速的JTAG調(diào)試。.ROM監(jiān)視器ROM Monitor ROM監(jiān)控器是一小程序，駐留在嵌入系統(tǒng)ROM中，通過串行的或網(wǎng)絡(luò)的連接和運行在工作站上的調(diào)試軟件通信。這是一種便宜的方式，當然也是最低端的技術(shù)。它除了要求一個通信端口和少量的內(nèi)存空間外，不需要其它任何專門的硬件。并提供了如下功能：下載代碼、運行控制、斷點、單步步進、以及觀察、修改寄存器和內(nèi)存。因為ROM監(jiān)控器是操作軟件的一部分，只有當你的應(yīng)用程序運行時，它才會工作。如果你想檢查CPU和應(yīng)用程序的狀態(tài)，你就必須停下應(yīng)用程序，再次進入ROM監(jiān)控器。.Data監(jiān)視器Data Monitor這種監(jiān)視器在不停止CPU運行的情況下不僅可以顯示指定變量內(nèi)容，還可以收集并以圖形形式顯示各個變量的變化過程。.OS監(jiān)視器Operating System Monitor操作系統(tǒng)監(jiān)視器可以顯示諸如任務(wù)切換、信號量收發(fā)、中斷等事件。一方面，這些監(jiān)視器能夠為你呈現(xiàn)事件之間的關(guān)系和時間聯(lián)系；另一方面，還可以提供對信號量優(yōu)先級反轉(zhuǎn)、死鎖和中斷延時等問題的診斷。.性能分析工具Profiler可以用來測試CPU到底耗在那里。profiler工具可以讓你知道系統(tǒng)的瓶頸在那里、CPU的使用率以及需要優(yōu)化的地方。.內(nèi)存測試工具Memory Teseter可以找到內(nèi)存使用的問題所在，比如內(nèi)存泄露、內(nèi)存碎片、內(nèi)存崩潰等問題。如果發(fā)現(xiàn)系統(tǒng)出現(xiàn)一些不可預(yù)知的或間歇性的問題，就應(yīng)該使用內(nèi)存測試工具測測看。.運行跟蹤器Execution Tracer可以顯示CPU執(zhí)行了哪些函數(shù)、誰在調(diào)用、參數(shù)是什么、何時調(diào)用等情況。這種工具主要用于測試代碼邏輯，可以在大量的事件中發(fā)現(xiàn)異常的那些。.覆蓋工具Coverage Tester主要顯示CPU具體執(zhí)行了那些代碼，并讓你知道那些代碼分支沒有被執(zhí)行到。這樣有助于提高代碼質(zhì)量并消除無用代碼。.GUI測試工具GUI Tester很多嵌入式應(yīng)用帶有某種形式的圖形用戶界面進行交互，有些系統(tǒng)性能測試足根掘用戶輸入響應(yīng)時間進行的。GUI測試工具可以作為腳本工具有開發(fā)環(huán)境中運行測試用例，其功能包括對操作的記錄和回放、抓取屏幕顯示供以后分析和比較、設(shè)置和管理測試過程(Rational公司的robot和Mercury的Loadrunner工具是杰出的代表)。很多嵌入式設(shè)備沒有GUI，但常?？梢詫η度胧皆O(shè)備進行插裝來運行GUI測試腳本，雖然這種方式可能要求對被測代碼進行更改，但是節(jié)省了功能測試和回歸測試的時間。.自制工具Home-made tester在嵌入式應(yīng)用中，有時候為了特定的目的，需要自行編寫一些工具來達到某種測試目的。本人曾經(jīng)編寫的視頻流錄顯工具在測試視頻會議數(shù)據(jù)流向和變化上幫了大忙,幫公司找到了幾個隱藏很深的bug。.盡早發(fā)現(xiàn)內(nèi)存問題 內(nèi)存問題危害很大，不容易排查，主要有三種類型:內(nèi)存泄露、內(nèi)存碎片和內(nèi)存崩潰。對于內(nèi)存問題態(tài)度必須要明確，那就是早發(fā)現(xiàn)早“治療”。在軟件設(shè)計中，內(nèi)存泄露的“名氣”最大，主要由于不斷分配的內(nèi)存無法及時地被釋放，久而久之，系統(tǒng)的內(nèi)存耗盡。即使細心的編程老手有時后也會遭遇內(nèi)存泄露問題。有測試過內(nèi)存泄露的朋友估計都有深刻地體驗，那就是內(nèi)存泄露問題一般隱藏很深，很難通過代碼閱讀來發(fā)現(xiàn)。有些內(nèi)存泄露甚至可能出現(xiàn)在庫當中。有可能這本身是庫中的bug，也有可能是因為程序員沒有正確理解它們的接口說明文檔造成錯用。在很多時候，大多數(shù)的內(nèi)存泄露問題無法探測，但可能表現(xiàn)為隨機的故障。程序員們往往會把這種現(xiàn)象怪罪于硬件問題。如果用戶對系統(tǒng)穩(wěn)定性不是很高，那么重啟系統(tǒng)問題也不大；但，如果用戶對系統(tǒng)穩(wěn)定很高，那么這種故障就有可能使用戶對產(chǎn)品失去信心，同時也意味著你的項目是個失敗的項目。由于內(nèi)存泄露危害巨大，現(xiàn)在已經(jīng)有許多工具來解決這個問題。這些工具通過查找沒有引用或重復(fù)使用的代碼塊、垃圾內(nèi)存收集、庫跟蹤等技術(shù)來發(fā)現(xiàn)內(nèi)存泄露的問題。每個工具都有利有弊，不過總的來說，用要比不用好?？傊?，負責(zé)的開發(fā)人員應(yīng)該去測試內(nèi)存泄露的問題，做到防患于未然。內(nèi)存碎片比內(nèi)存泄露隱藏還要深。隨著內(nèi)存的不斷分配并釋放，大塊內(nèi)存不斷分解為小塊內(nèi)存，從而形成碎片，久而久之，當需要申請大塊內(nèi)存是，有可能就會失敗。如果系統(tǒng)內(nèi)存夠大，那么堅持的時間會長一些，但最終還是逃不出分配失敗的厄運。在使用動態(tài)分配的系統(tǒng)中，內(nèi)存碎片經(jīng)常發(fā)生。目前，解決這個問題最效的方法就是使用工具通過顯示系統(tǒng)中內(nèi)存的使用情況來發(fā)現(xiàn)誰是導(dǎo)致內(nèi)存碎片的罪魁禍首，然后改進相應(yīng)的部分。由于動態(tài)內(nèi)存管理的種種問題，在嵌入式應(yīng)用中，很多公司干脆就禁用malloc/free的以絕后患。內(nèi)存崩潰是內(nèi)存使用最嚴重的結(jié)果，主要原因有數(shù)組訪問越界、寫已經(jīng)釋放的內(nèi)存、指針計算錯誤、訪問堆棧地址越界等等。這種內(nèi)存崩潰造成系統(tǒng)故障是隨機的，而且很難查找，目前提供用于排查的工具也很少?？傊?，如果要使用內(nèi)存管理單元的話，必須要小心，并嚴格遵守它們的使用規(guī)則，比如誰分配誰釋放。.深入理解代碼優(yōu)化講到系統(tǒng)穩(wěn)定性，人們更多地會想到實時性和速度，因為代碼效率對嵌入式系統(tǒng)來說太重要了。知道怎么優(yōu)化代碼是每個嵌入式軟件開發(fā)人員必須具備的技能。就象女孩子減肥一樣，起碼知道她哪個地方最需要減，才能去購買減肥藥或器材來減掉它?？梢?，代碼優(yōu)化的前提是找到真正需要優(yōu)化的地方，然后對癥下藥，優(yōu)化相應(yīng)部分的代碼。前面提到的profile(性能分析工具，一些功能齊全IDE都提供這種內(nèi)置的工具)能夠記錄各種情況比如各個任務(wù)的CPU占用率、各個任務(wù)的優(yōu)先級是否分配妥當、某個數(shù)據(jù)被拷貝了多少次、訪問磁盤多少次、是否調(diào)用了網(wǎng)絡(luò)收發(fā)的程序、測試代碼是否已經(jīng)關(guān)閉等等。但是，profile工具在分析實時系統(tǒng)性能方面還是有不夠的地方。一方面，人們使用profile工具往往是在系統(tǒng)出現(xiàn)問題即CPU耗盡之后，而profile工具本身對CPU占用較大，所以profile對這種情況很可能不起作用。根據(jù)Heisenberg效應(yīng)，任何測試手段或多或少都會改變系統(tǒng)運行，這個對profiler同樣適用！總之，提高運行效率的前提是你必須要知道CPU到底干了些什么干的怎么樣。.不要讓自己大海撈針大海撈針只是對調(diào)試的一種生動比喻。經(jīng)常聽到組里有人對自己正在調(diào)試的代碼說shit！可以理解，因為代碼不是他寫的，他有足夠的理由去shit bug百出的代碼，只要他自己不要寫出這種代碼，否則有一天同組的其它人可能同樣會shit他寫的代碼。為何會有大海撈針呢？肯定是有人把針掉到海里咯；那針為何會掉在海里呢？肯定是有人不小心或草率唄。所以當你在抱怨針那么難找的時候，你是否想過是你自己草率地丟掉的。同樣，當你調(diào)試個半死的時候，你是否想過你要好好反省一下當初為了尋求捷徑可能沒有嚴格地遵守好的編碼設(shè)計規(guī)范、沒有檢測一些假設(shè)條件或算法的正確性、沒有將一些可能存在問題的代碼打上記號呢？關(guān)于如何寫高質(zhì)量請參考林銳的高質(zhì)量c+/c編程指南或關(guān)于C的0x8本“經(jīng)書”(/u/4a317b79010004mc)。如果你確實已經(jīng)把針掉在海里是，為了防止在找到之前刺到自己，你必須要做一些防范工作，比如戴上安全手套。同樣，為了盡能地暴露和捕捉問題根源，我們可以設(shè)計比較全面的錯誤跟蹤代碼。怎么來做呢？盡可能對每個函數(shù)調(diào)用失敗作出處理，盡可能檢測每個參數(shù)輸入輸出的有效性包括指針以及檢測是否過多或過少地調(diào)用某個過程。錯誤跟蹤能夠讓你知道你大概把針掉在哪個位置。.重現(xiàn)并隔離問題如果你不是把針掉在大海了，而是掉在草堆里，那要好辦寫。因為至少我們可以把草堆分成很多塊，一塊一塊的找。對于模塊獨立的大型項目，使用隔離方法往往是對付那些隱藏極深bug的最后方法。如果問題的出現(xiàn)是間歇性的,我們有必要設(shè)法去重現(xiàn)它并記錄使其重現(xiàn)的整個過程以備在下一次可以利用這些條件去重現(xiàn)問題。如果你確信可以使用記錄的那些條件去重現(xiàn)問題，那么我們就可以著手去隔離問題。怎么隔離呢？我們可以用#ifdef把一些可能和問題無關(guān)的代碼關(guān)閉，把系統(tǒng)最小化到仍能夠重現(xiàn)問題的地步。如果還是無法定位問題所在，那么有必要打開“工具箱”了?？梢栽囍肐CE或數(shù)據(jù)監(jiān)視器去查看某個可疑變量的變化；可以使用跟蹤工具獲得函數(shù)調(diào)用的情況包括參數(shù)的傳遞；檢查內(nèi)存是否崩潰以及堆棧溢出的問題。.以退為進獵人為了不使自己在森林里迷路，他常常會在樹木上流下一些標記，以備自己將來有一天迷路時可以根據(jù)這些標記找到出路。對過去代碼的修改進行跟蹤記錄對將來出現(xiàn)問題之后的調(diào)試很有幫助。假如有一天，你最近一次修改的程序跑了很久之后忽然死掉了，那么你這時的第一反映就是我到底改動了些什么呢，因為上次修改之前是好的。那么如何檢測這次相對于上次的修改呢？沒錯，代碼控制系統(tǒng)SCS或稱版本控制系統(tǒng)VCS(Concurrent Version Control,CVS是VCS的演化版本)。將上個版本check in下來后和當前測試版本比較。比較的工具可以是SCS/VCS/CVS自帶的diff工具或其它功能更強的比較工具，比如BeyondCompare和ExamDiff。通過比較，記錄所有改動的代碼，分析所有可能導(dǎo)致問