黑盒測試和白盒測試的區(qū)別

黑盒測試和白盒測試的區(qū)別軟件測試方法軟件測試方法：白盒測試、黑盒測試、灰盒測試、靜態(tài)測試、動(dòng)態(tài)測試白盒測試：是一種測試用例設(shè)計(jì)方法，在這里盒子指的是被測試的軟件，白盒，顧名思義即盒子是可視的，你可以清楚盒子內(nèi)部的東西以及里面是如何運(yùn)作的，因此白盒測試需要你對(duì)系統(tǒng)內(nèi)部的結(jié)構(gòu)和工作原理有一個(gè)清楚的了解，并且基于這個(gè)知識(shí)來設(shè)計(jì)你的用例。白盒測試技術(shù)一般可被分為靜態(tài)分析和動(dòng)態(tài)分析兩類技術(shù)。靜態(tài)分析主要有：控制流分析技術(shù)、數(shù)據(jù)流分析技術(shù)、信息流分析技術(shù)。動(dòng)態(tài)分析主要有：邏輯覆蓋率測試（分支測試、路徑測試等），程序插裝等。白盒測試優(yōu)點(diǎn):迫使測試人員去仔細(xì)的思考軟件的實(shí)現(xiàn);可以檢測代碼中的每條分支和路徑；揭示隱藏在代碼中的錯(cuò)誤；對(duì)代碼的測試比較徹底；最優(yōu)化。白盒測試缺點(diǎn)：昂貴;無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯(cuò)誤;不驗(yàn)證規(guī)格的正確性。黑盒測試又叫功能測試，這是因?yàn)樵诤诤袦y試中主要關(guān)注被測軟件的功能實(shí)現(xiàn)，而不是內(nèi)部邏輯。在黑盒測試中，被測對(duì)象的內(nèi)部結(jié)構(gòu)，運(yùn)作情況對(duì)測試人員是不可見的，測試人員對(duì)被測產(chǎn)品的驗(yàn)證主要是根據(jù)其規(guī)格，驗(yàn)證其與規(guī)格的一致性。在絕大多數(shù)沒有用戶參與的黑盒測試中，最常見的測試有：功能性測試、容量測試、安全性測試、負(fù)載測試、恢復(fù)性測試、標(biāo)桿測試、穩(wěn)定性測試、可靠性測試等?；液袦y試：白盒測試和黑盒測試往往不是決然分開的，一般在白盒測試中交叉使用黑盒測試的方法，在黑盒測試中交叉使用白盒測試的方法?；液袦y試就是這類界于白盒測試和黑盒測試之間的測試。最常見的灰盒測試是集成測試。靜態(tài)測試：是一種不通過執(zhí)行程序而進(jìn)行測試的技術(shù)。它的關(guān)鍵功能是檢查軟件的表示和描述是否一致，沒有沖突或者沒有歧義。動(dòng)態(tài)測試：包含了程序在受控的環(huán)境下使用特定的期望結(jié)果進(jìn)行正式的運(yùn)行。它顯示了一個(gè)系統(tǒng)在檢查狀態(tài)下是正確還是不正確。單元測試屬于白盒測試范疇；集成測試屬于灰盒測試范疇；系統(tǒng)測試屬于黑盒測試范疇。單元測試概念：單元測試（UnitTesting）是對(duì)軟件基本組成單元進(jìn)行的測試，如函數(shù)或是一個(gè)類的方法。這里的單元，就是軟件設(shè)計(jì)的最小單位。單元測試的兩個(gè)步驟：人工靜態(tài)檢查法與動(dòng)態(tài)執(zhí)行跟蹤法。人工靜態(tài)檢查是測試的第一步，這個(gè)階段工作主要是保證代碼算法的邏輯正確性（盡量通過人工檢查發(fā)現(xiàn)代碼的邏輯錯(cuò)誤）、清晰性、規(guī)范性、一致性、算法高效性，并盡可能的發(fā)現(xiàn)程序中沒有發(fā)現(xiàn)的錯(cuò)誤。第二步是通過設(shè)計(jì)測試用例，執(zhí)行待測程序來跟蹤比較實(shí)際結(jié)果與預(yù)期結(jié)果來發(fā)現(xiàn)錯(cuò)誤。人工檢查：（1）、檢查算法的邏輯正確性：確定所編寫的代碼算法、數(shù)據(jù)結(jié)構(gòu)定義（如：隊(duì)列、堆棧等）是否實(shí)現(xiàn)了模塊或方法所要求的功能。、模塊接口的正確性檢查：確定形式參數(shù)個(gè)數(shù)、數(shù)據(jù)類型、順序是否正確；確定返回值類型及返回值的正確性。、輸入?yún)?shù)有沒有作正確性檢查：如果沒有作正確性檢查，確定該參數(shù)是否的確無需做參數(shù)正確性檢查，否則請(qǐng)?zhí)砑由蠀?shù)的正確性檢查。、調(diào)用其他方法接口的正確性：檢查實(shí)參類型正確與否、傳入的參數(shù)值正確與否、個(gè)數(shù)正確與否，特別是具有多態(tài)的方法。返回值正確與否，有沒有誤解返回值所表示的意思。最好對(duì)每個(gè)被調(diào)用的方法的返回值用顯示代碼作正確性檢查，如果被調(diào)用方法出現(xiàn)異?；蝈e(cuò)誤程序應(yīng)該給予反饋，并添加適當(dāng)?shù)某鲥e(cuò)處理代碼。、出錯(cuò)處理：模塊代碼要求能預(yù)見出錯(cuò)的條件，并設(shè)置適當(dāng)?shù)某鲥e(cuò)處理，以便一旦程序出錯(cuò)時(shí)，能對(duì)出錯(cuò)程序重做安排，保證其邏輯的正確性，這種出錯(cuò)處理應(yīng)當(dāng)是模塊功能的一部分。若出現(xiàn)下列情況之一，則表明模塊的錯(cuò)誤處理功能包含有錯(cuò)誤或缺陷：出錯(cuò)的描述難以理解；出錯(cuò)的描述不足以對(duì)錯(cuò)誤定位，不足以確定出錯(cuò)的原因；顯示的錯(cuò)誤信息與實(shí)際的錯(cuò)誤原因不符；對(duì)錯(cuò)誤條件的處理不正確；在對(duì)錯(cuò)誤進(jìn)行處理之前，錯(cuò)誤條件已經(jīng)引起系統(tǒng)的干預(yù)等。、保證表達(dá)式、SQL語句的正確性：檢查所編寫的SQL語句的語法、邏輯的正確性。對(duì)表達(dá)式應(yīng)該保證不含二義性，對(duì)于容易產(chǎn)生歧義的表達(dá)式或運(yùn)算符優(yōu)先級(jí)(如：<、=、>、&&、||、++、--等)可以采用擴(kuò)號(hào)'、()〃運(yùn)算符避免二義性，這樣一方面能夠保證代碼的正確可靠，同時(shí)也能夠提高代碼的可讀性。、檢查常量或全局變量使用的正確性：確定所使用的常量或全局變量的取值和數(shù)值、數(shù)據(jù)類型；保證常量每次引用同它的取值、數(shù)值和類型的一致性。、表示符定義的規(guī)范一致性：保證變量命名能夠見名知意，并且簡潔但不宜過長或過短、規(guī)范、容易記憶、最好能夠拼讀。并盡量保證用相同的表示符代表相同功能，不要將不同的功能用相同的表示符表示；更不要用相同的表示符代表不同的功能意義。、程序風(fēng)格的一致性、規(guī)范性：代碼必須能保證符合企業(yè)規(guī)范，保證所有成員的代碼風(fēng)格一致、規(guī)范、工整。例如對(duì)數(shù)組做循環(huán)，不要一會(huì)兒采用下標(biāo)變量從下到上的方式(如:for(i=0;i++;i<10))，一會(huì)兒又采用從上到下的方式(如:for(i=10;i--;i>0))；應(yīng)該盡量采用統(tǒng)一的方式，或則統(tǒng)一從下到上，或則統(tǒng)一從上到下。建議采用for循環(huán)和While循環(huán)，不要采用do{}while循環(huán)等。、檢查程序中使用到的神秘?cái)?shù)字是否采用了表示符定義：神秘的數(shù)字包括各種常數(shù)、數(shù)組的大小、字符位置、變換因子以及程序中出現(xiàn)的其他以文字形式寫出的數(shù)值。在程序源代碼里，一個(gè)具有原本形式的數(shù)對(duì)其本身的重要性或作用沒提供任何指示性信息，它們也導(dǎo)致程序難以理解和修改。對(duì)于這類神秘?cái)?shù)字必須采用相應(yīng)的標(biāo)量來表示；如果該數(shù)字在整個(gè)系統(tǒng)中都可能使用到務(wù)必將它定義為全局常量;如果該神秘?cái)?shù)字在一個(gè)類中使用可將其定義為類的屬性(Attribute)，如果該神秘?cái)?shù)字只在一個(gè)方法中出現(xiàn)務(wù)必將其定義為局部變量或常量。、檢查代碼是否可以優(yōu)化、算法效率是否最高：如：SQL語句是否可以優(yōu)化，是否可以用1條SQL語句代替程序中的多條SQL語句的功能，循環(huán)是否必要，循環(huán)中的語句是否可以抽出到循環(huán)之外等。、檢查您的程序是否清晰簡潔容易理解：注意：冗長的程序并不一定不是清晰的。（13）、檢查方法內(nèi)部注釋是否完整：是否清晰簡潔；是否正確的反映了代碼的功能，錯(cuò)誤的注釋比沒有注釋更糟；是否做了多余的注釋；對(duì)于簡單的一看就懂的代碼沒有必要注釋。（14）、檢查注釋文檔是否完整：對(duì)包、類、屬性、方法功能、參數(shù)、返回值的注釋是否正確且容易理解；是否會(huì)落了或多了某個(gè)參數(shù)的注釋，參數(shù)類型是否正確，參數(shù)的限定值是否正確。特別是對(duì)于形式參數(shù)與返回值中關(guān)于神秘?cái)?shù)值的注釋，如：類型參數(shù)應(yīng)該指出1.代表什么，2.代表什么，3.代表什么等。對(duì)于返回結(jié)果集（ResultSet）的注釋，應(yīng)該注釋結(jié)果集中包含那些字段及字段類型、字段順序等。動(dòng)態(tài)執(zhí)行跟蹤：動(dòng)態(tài)執(zhí)行測試通常分為黑盒測試與白盒測試。對(duì)于單元測試來說主要應(yīng)該采用白盒測試法對(duì)每個(gè)模塊的內(nèi)部作跟蹤檢查測試。對(duì)于單元白盒測試，應(yīng)該對(duì)程序模塊進(jìn)行如下檢查：（1）、對(duì)模塊內(nèi)所有獨(dú)立的執(zhí)行路徑至少測試一次；（2）、對(duì)所有的邏輯判定，取''真〃與''假〃的兩種情況都至少執(zhí)行一次；（3）、在循環(huán)的邊界和運(yùn)行界限內(nèi)執(zhí)行循環(huán)體；（4）、測試內(nèi)部數(shù)據(jù)的有效性等等。單元測試的目的：在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種錯(cuò)誤，主要是基于白盒測試。單元測試的目的主要有3方面：驗(yàn)證單元代碼和詳細(xì)設(shè)計(jì)文檔的一致性；跟蹤詳細(xì)設(shè)計(jì)文檔中設(shè)計(jì)的實(shí)現(xiàn)，發(fā)現(xiàn)詳細(xì)設(shè)計(jì)文檔中存在的錯(cuò)誤；發(fā)現(xiàn)在編碼過程中引入的錯(cuò)誤。單元的常見錯(cuò)誤：（1）、單元接口；（2）、局部數(shù)據(jù)結(jié)構(gòu)；（3）、獨(dú)立路徑；（4）、出錯(cuò)處理；（5）、邊界條件。單元測試策略：有三種，獨(dú)立的單元測試策略，自頂向下的單元測試策略和自底向上的單元測試策略。獨(dú)立的測試策略：不考慮每個(gè)模塊與其他模塊之間的關(guān)系，為每個(gè)模塊設(shè)計(jì)樁模塊和驅(qū)動(dòng)模塊。每個(gè)模塊進(jìn)行獨(dú)立的單元測試。自頂向下的測試策略：先對(duì)最頂層的單元進(jìn)行測試，把頂層所調(diào)用的單元做成樁模塊。其次對(duì)第二層進(jìn)行測試，使用上面已測試的單元做驅(qū)動(dòng)模塊。如此類推直到測試完所有模塊。自底向上測試：先對(duì)模塊調(diào)用層次圖上最低層的模塊進(jìn)行單元測試，模擬調(diào)用該模塊的模塊做驅(qū)動(dòng)模塊。然后再對(duì)上面一層做單元測試，用下面已被測試過的模塊做樁模塊。依次類推，直到測試完所有模塊。單元測試過程：計(jì)劃（測什么）、設(shè)計(jì)（測試方案、策略）、實(shí)現(xiàn)（寫測試用例、代碼）、執(zhí)行（測試報(bào)告）四個(gè)階段。單元測試的原則：（1）、對(duì)全新的代碼或修改過的代碼進(jìn)行單元測試；（2）、單元測試根據(jù)單元測試計(jì)劃和方案進(jìn)行，排除測試的隨意性；（3）、必須保證單元測試計(jì)劃、單元測試方案、單元測試用例等經(jīng)過評(píng)審；（4）、當(dāng)測試用例的測試結(jié)果與預(yù)期結(jié)果不一致時(shí)，單元測試的執(zhí)行人員需如實(shí)記錄實(shí)際的測試結(jié)果；（5）、只有當(dāng)測試計(jì)劃中的結(jié)束標(biāo)準(zhǔn)達(dá)到時(shí)，單元測試才能結(jié)束；（6）、對(duì)被測試單元需達(dá)到的一定的代碼覆蓋率要求。測試用例1.簡介：測試用例（TestCase）是為某個(gè)特殊目標(biāo)而編制的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測試某個(gè)程序路徑或核實(shí)是否滿足某個(gè)特定需求。也指對(duì)一項(xiàng)特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和策略。內(nèi)容包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等，并形成文檔。不同類別的軟件，測試用例是不同的。概述：測試用例構(gòu)成了設(shè)計(jì)和制定測試過程的基礎(chǔ)。測試的'深度〃與測試用例的數(shù)量成比例。由于每個(gè)測試用例反映不同的場景、條件或經(jīng)由產(chǎn)品的事件流，因而，隨著測試用例數(shù)量的增加，你對(duì)產(chǎn)品質(zhì)量和測試流程也就越有信心。判斷測試是否完全的一個(gè)主要評(píng)測方法是基于需求的覆蓋，而這又是以確定、實(shí)施和/或執(zhí)行的測試用例的數(shù)量為依據(jù)的。測試工作量與測試用例的數(shù)量成比例。最佳方案是為每個(gè)測試需求至少編制兩個(gè)測試用例。一個(gè)測試用例用于證明該需求已經(jīng)滿足，通常稱作正面測試用例。另一個(gè)測試用例反映某個(gè)無法接受、反?；蛞馔獾臈l件或數(shù)據(jù)，用于論證只有在所需條件下才能夠滿足該需求，這個(gè)測試用例稱作負(fù)面測試用例。設(shè)計(jì)方法：、白盒技術(shù)：白盒測試是結(jié)構(gòu)測試，所以被測對(duì)象基本上是源程序，以程序的內(nèi)部邏輯為基礎(chǔ)設(shè)計(jì)測試用例。白盒測試的測試用例設(shè)計(jì)：一般采用邏輯覆蓋法和基本路徑法進(jìn)行設(shè)計(jì)。邏輯覆蓋是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的測試用例設(shè)計(jì)技術(shù)，這一方法要求測試人員對(duì)程序的邏輯結(jié)構(gòu)有清楚的了解。邏輯覆蓋可分為：語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋與路徑覆蓋。語句覆蓋：在測試時(shí)，首先設(shè)計(jì)若干個(gè)測試用例，然后運(yùn)行被測程序，使程序中的每個(gè)可執(zhí)行語句至少執(zhí)行一次。判定覆蓋法：在測試時(shí)，首先設(shè)計(jì)若干個(gè)測試用例，然后運(yùn)行被測程序，使得程序中的每個(gè)判斷的取真分支和取假分支至少經(jīng)歷一次，即判斷的真假值均曾被滿足。條件覆蓋法：在測試時(shí)，首先設(shè)計(jì)若干個(gè)測試用例，然后運(yùn)行被測程序，要使每個(gè)判斷中每個(gè)條件的可能取值至少滿足一次。判定條件覆蓋法：在測試時(shí)，首先設(shè)計(jì)若干個(gè)測試用例，然后運(yùn)行被測程序，使得判斷中每個(gè)條件的所有可能至少出現(xiàn)一次，并且每個(gè)判斷本身的判定結(jié)果至少出現(xiàn)一次。路徑覆蓋法：在測試時(shí)，首先設(shè)計(jì)若干個(gè)測試用例，然后運(yùn)行被測程序，要求覆蓋程序中所有可能的路徑?；韭窂礁采w法：是在程序控制流圖的基礎(chǔ)上，通過分析控制結(jié)構(gòu)的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，設(shè)計(jì)測試用例的方法。該方法把覆蓋的路徑數(shù)壓縮到一定限度內(nèi)，程序中的循環(huán)體最多只執(zhí)行一次。設(shè)計(jì)出的測試用例要保證在測試中，程序的每一個(gè)可執(zhí)行語句至少執(zhí)行一次。循環(huán)路徑測試：基本路徑覆蓋法將循環(huán)限制在最多一次，這樣雖然大大降低了需要覆蓋的路徑的條數(shù)，但對(duì)循環(huán)的測試卻不充分了，因此還需要對(duì)循環(huán)路徑進(jìn)行測試。循環(huán)路徑測試包含，簡單循環(huán)的測試和嵌套循環(huán)的測試。每一種覆蓋方法都有其優(yōu)缺點(diǎn)。通常在設(shè)計(jì)測試用例時(shí)應(yīng)該根據(jù)代碼模塊的復(fù)雜度，選擇覆蓋方法。一般的代碼的復(fù)雜度與測試用例設(shè)計(jì)的復(fù)雜度成正比。因此，設(shè)計(jì)人員必須做到模塊或方法功能的單一性、高內(nèi)聚性，使得方法或函數(shù)代碼盡可能的簡單；這樣將可大大提高測試用例設(shè)計(jì)的容易度，提高測試用例的覆蓋程度?；韭窂綔y試法是在程序控制流圖的基礎(chǔ)上，通過分析控制構(gòu)造的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，從而設(shè)計(jì)測試用例的方法。設(shè)計(jì)出的測試用例要保證在測試中程序的每個(gè)可執(zhí)行語句至少執(zhí)行一次?；韭窂綔y試法包括以下5個(gè)方面：（1）、程序的控制流圖：描述程序控制流的一種圖示方法；（2）、程序環(huán)境復(fù)雜性：McCabe復(fù)雜性度量；從程序的環(huán)路復(fù)雜性可導(dǎo)出程序基本路徑集合中的獨(dú)立路徑條數(shù)，這是確定程序中每個(gè)可執(zhí)行語句至少執(zhí)行依次所必須的測試用例數(shù)目的上界；（3）、導(dǎo)出測試用例；（4）、準(zhǔn)備測試用例，確?；韭窂郊械拿恳粭l路徑的執(zhí)行；（5）、圖形矩陣：是在基本路徑測試中起輔助作用的軟件工具，利用它可以實(shí)現(xiàn)自動(dòng)地確定一個(gè)基本路徑集。另外，對(duì)于測試用例的選擇除了滿足所選擇的覆蓋程度（或覆蓋標(biāo)準(zhǔn)）外還需要盡可能的采用邊界值分析法、錯(cuò)誤推測法等常用地設(shè)計(jì)方法。采用邊界值分析法設(shè)計(jì)合理的輸入條件與不合理的輸入條件;條件邊界測試用例應(yīng)該包括輸入?yún)?shù)的邊界與條件邊界（if,while，for，switch,SQLWhere子句等）。錯(cuò)誤推測法，列舉出程序中所有可能的錯(cuò)誤和容易發(fā)生錯(cuò)誤的特殊情況，根據(jù)它們選擇測試用例；在編碼、單元測試階段可以發(fā)現(xiàn)很多常見的錯(cuò)誤和疑似錯(cuò)誤，對(duì)于這些錯(cuò)誤應(yīng)該作重點(diǎn)測試，并設(shè)計(jì)相應(yīng)的測試用例。（2）、黑盒技術(shù)：等價(jià)劃分類、邊界值分析、錯(cuò)誤推測、因果圖、綜合策略測試類設(shè)計(jì)：一個(gè)模塊或一個(gè)方法（Method）并不是一個(gè)獨(dú)立的程序，在考慮測試它時(shí)要同時(shí)考慮它和外界的聯(lián)系，用些輔助模塊去模擬與所測模塊相聯(lián)系的其他模塊。這些輔助模塊分為兩種：（1）、驅(qū)動(dòng)模塊（driver）:相當(dāng)于所測模塊的主程序。它接收測試數(shù)據(jù)，把這些數(shù)據(jù)傳送給所測模塊，最后再輸出實(shí)際測試結(jié)果；（2）、樁模塊（stub）:用于代替所測模塊調(diào)用的子模塊。樁模塊可以做少量的數(shù)據(jù)操作，不需要把子模塊所有功能都帶進(jìn)來，但不容許什么事情也不做。打樁：一般在做單元或集成測試時(shí)，如果某個(gè)程序單元的某條語句，需要調(diào)用的一個(gè)外部函數(shù)還沒有設(shè)計(jì)、編碼、調(diào)試完成的話，可以只讓它簡單地返回幾個(gè)支持測試用例的值就可以了，這種狀態(tài)的外部函數(shù)一般就叫做''打樁〃。所測模塊與它相關(guān)的驅(qū)動(dòng)模塊及樁模塊共同構(gòu)成了一個(gè)'測試環(huán)境氣驅(qū)動(dòng)模塊和樁模塊的編寫會(huì)給測試帶來額外的開銷。因?yàn)樗鼈冊(cè)谲浖桓稌r(shí)并不作為產(chǎn)品的一部分一同交付，而且它們的編寫需要一定的工作量。特別是樁模塊，不能只簡單地給出''曾經(jīng)進(jìn)入〃的信息。為了能夠正確的測試軟件，樁模塊可能需要模擬實(shí)際子模塊的功能，這樣樁模塊的建立就不是很輕松了。編寫樁模塊是困難費(fèi)時(shí)的，其實(shí)也是完全可以避免編寫樁模塊的；只需在項(xiàng)目進(jìn)度管理時(shí)將實(shí)際樁模塊的代碼編寫工作安排在被測模塊前編寫即可。而且這樣可以提高測試工作的效率，提高實(shí)際樁模塊的測試頻率從而更有效的保證產(chǎn)品的質(zhì)量。但是，為了保證能夠向上一層級(jí)提供穩(wěn)定可靠的實(shí)際樁模塊，為后續(xù)模塊測試打下良好的基礎(chǔ)，驅(qū)動(dòng)模塊還是必不可少的。對(duì)于每一個(gè)包或子系統(tǒng)我們可以根據(jù)所編寫的測試用例來編寫一個(gè)測試模塊類來做驅(qū)動(dòng)模塊，用于測試包中所有的待測試模塊。而最好不要在每個(gè)類中用一個(gè)測試函數(shù)的方法，來測試跟蹤類中所有的方法。這樣的好處在于：（1）、能夠同時(shí)測試包中所有的方法或模塊，也可以方便的測試跟蹤指定的模塊或方法；（2）、能夠聯(lián)合使用所有測試用例對(duì)同一段代碼執(zhí)行測試，發(fā)現(xiàn)問題；（3）、便以回歸測試，當(dāng)某個(gè)模塊作了修改之后，只要執(zhí)行測試類就可以執(zhí)行所有被測的模塊或方法。這樣不但能夠方便得檢查、跟蹤所修改的代碼，而且能夠檢查出修改對(duì)包內(nèi)相關(guān)模塊或方法所造成的影響，使修改引進(jìn)的錯(cuò)誤得以及時(shí)發(fā)現(xiàn)；（4）、復(fù)用測試方法，使測試單元保持持久性，并可以用既有的測試來編寫相關(guān)測試；（5）、將測試代碼與產(chǎn)品代碼分開，使代碼更清晰、簡潔；提高測試代碼與被測代碼的可維護(hù)性。跟蹤調(diào)試：跟蹤調(diào)試不但是深入測試代碼的最佳方法，而且也是程序調(diào)試發(fā)現(xiàn)錯(cuò)誤根源的有利工具。測試類設(shè)計(jì)完成后，最好能借助代碼排錯(cuò)工具來跟蹤調(diào)試待測代碼段以深入的檢查代碼的邏輯錯(cuò)誤。現(xiàn)有的代碼開發(fā)工具（如:JBuilder）一般都集成了這類排錯(cuò)工具。排錯(cuò)工具一般由執(zhí)行控制程序、執(zhí)行狀態(tài)查詢程序、跟蹤程序組成。執(zhí)行控制程序包括斷點(diǎn)定義、斷點(diǎn)撤銷、單步執(zhí)行、斷點(diǎn)執(zhí)行、條件執(zhí)行等功能。執(zhí)行狀態(tài)查詢程序包括寄存器、堆棧狀態(tài)、變量、代碼等與程序相關(guān)的各種狀態(tài)信息的查詢。跟蹤程序用以跟蹤程序執(zhí)行過程中所經(jīng)歷的事件序列（如：分支、子程序調(diào)用等）。程序員可通過對(duì)程序執(zhí)行過程中各種狀態(tài)的判別進(jìn)行程序錯(cuò)誤的識(shí)別、定位及改正。對(duì)于模塊的單元跟蹤調(diào)試最好能夠做到：每次修改被測模塊后，都將所有測試用例跟蹤執(zhí)行一遍以排除所有可能出現(xiàn)或引進(jìn)的錯(cuò)誤。在時(shí)間有限的情況下也必須調(diào)用驅(qū)動(dòng)模塊對(duì)所有的測試用例執(zhí)行一次，并對(duì)出現(xiàn)錯(cuò)誤或異常的測試用例跟蹤執(zhí)行一次，以發(fā)現(xiàn)問題的根源。排錯(cuò)過程往往是一個(gè)艱苦的過程，特別是那種算法復(fù)雜、調(diào)用子模塊較多的模塊，對(duì)于錯(cuò)誤的定位來說并不是件容易的事情。盡管排錯(cuò)不是一門好學(xué)的技術(shù)（有時(shí)人們更愿意稱之為藝術(shù)），但還是有若干行之有效的方法和策略，下面介紹幾種排錯(cuò)時(shí)應(yīng)該采用的方法策略：（1）、斷點(diǎn)設(shè)置，設(shè)置斷點(diǎn)對(duì)源程序?qū)嵭袛帱c(diǎn)跟蹤將能夠大大提高排錯(cuò)的效率。通常斷點(diǎn)的設(shè)置除了根據(jù)經(jīng)驗(yàn)與錯(cuò)誤信息來設(shè)置外，還應(yīng)重點(diǎn)考慮以下幾種類行的語句：A、函數(shù)調(diào)用語句。子函數(shù)的調(diào)用語句是測試的重點(diǎn)，一方面由于在調(diào)用子函數(shù)時(shí)可能引起接口引用錯(cuò)誤，另一方面可能是子函數(shù)本身的錯(cuò)誤；B、判定轉(zhuǎn)移/循環(huán)語句。判定語句常常會(huì)由于邊界值與比較優(yōu)先級(jí)等問題引起錯(cuò)誤或失效而作出錯(cuò)誤的轉(zhuǎn)移。因此，對(duì)于判定轉(zhuǎn)穢循環(huán)語句也是一個(gè)重要的測試點(diǎn)；C、SQL語句。對(duì)于數(shù)據(jù)庫的應(yīng)用程序來說，SQL語句常常會(huì)在模塊中占比較重要的業(yè)務(wù)邏輯，而且比較復(fù)雜。因此，它也屬于比較容易出現(xiàn)錯(cuò)誤的語句；D、復(fù)雜算法段。出錯(cuò)的概率常與算法的復(fù)雜度成正比。所以越復(fù)雜的算法越需要作重點(diǎn)跟蹤，如遞歸、回朔等算法。（2）、可疑變量查看，在跟蹤執(zhí)行狀態(tài)下當(dāng)程序停止在某條語句時(shí)可查看變量的當(dāng)前值和對(duì)象的當(dāng)前屬性。通過對(duì)比這些變量當(dāng)前值與預(yù)期值可以輕松的定位程序問題根源；（3）、SQL語句執(zhí)行檢查，在跟蹤執(zhí)行或運(yùn)行狀態(tài)下將疑似錯(cuò)誤的SQL語句打印出來，重新在數(shù)據(jù)庫SQL查詢分析器（如：OracleSQLPlus）中跟蹤執(zhí)行可以較高效的檢查糾正SQL語句錯(cuò)誤；（4）、注意群集現(xiàn)象，經(jīng)驗(yàn)表明測試后程序中殘存的錯(cuò)誤數(shù)目與該程序中已發(fā)現(xiàn)的錯(cuò)誤數(shù)目或檢錯(cuò)率成正比。根據(jù)這個(gè)規(guī)律，應(yīng)當(dāng)對(duì)錯(cuò)誤群集的程序段進(jìn)行重點(diǎn)測試，以提高測試投資