一、 靜態(tài)測試方法和動態(tài)測試方法靜態(tài)方法靜態(tài)方法的主要特征是在用計算機測試源程序時，計算機并不真正運行被測試的程序。這說明靜態(tài)方法一方面要利用計算機作為對被測程序進行特性分析的工具，它與人工測試有著根本的區(qū)別；另一方面，它并不真正運行被測程序，只進行特性分析，這是和動態(tài)方法不同的。因此，靜態(tài)方法常稱為“分析”，靜態(tài)分析是對被測程序進行特性分析的一些方法的總稱。靜態(tài)分析并不等同于編譯系統(tǒng)，編譯系統(tǒng)雖然能發(fā)現(xiàn)某些程序錯誤，但這些錯誤遠非軟件中存在的大部分錯誤，靜態(tài)分析的查錯和分析功能是編譯程序所不能代替的。動態(tài)方法動態(tài)方法的主要特征是計算機必須真正運行被測試的程序，通過輸入測試用例對其運行情況（輸入/輸出的對應(yīng)關(guān)系）進行分析。二、 黑盒測試方法和白盒測試方法1） 測試規(guī)劃基于產(chǎn)品的功能，目的是檢查程序各功能是否實現(xiàn)，并檢查其中的錯誤。這種測試方法稱為黑盒測試（Black-boxTesting）02） 測試規(guī)劃基于產(chǎn)品的內(nèi)部結(jié)構(gòu)來規(guī)劃測試，檢查內(nèi)部操作是否按規(guī)定執(zhí)行，軟件各部分功能是否得到充分使用。這種測試稱為白盒測試（White-boxTesting）o黑盒測試又稱功能測試、數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明的測試是一種從用戶觀點出發(fā)的測試。用這種方法進行測試時，把被測程序當做一個黑盒，在不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性、測試者只知道該程序輸入和輸出之間的關(guān)系或程序功能的情況下，依靠能夠反映這一關(guān)系和程序功能需求規(guī)格的說明書，來確定測試用例和推斷測試結(jié)果的正確性。軟件的黑盒測試一般被用來確認軟件功能的正確性和可操作性。白盒測試又稱結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序的測試。它依賴于對程序細節(jié)的嚴密檢驗，針對特定條件和循環(huán)集設(shè)計測試用例，對軟件的邏輯路徑進行測試。在程序的不同點檢驗程序的狀態(tài)，來判定其實際情況是否和預(yù)期的狀態(tài)相一致。軟件的白盒測試一般用來分析程序的內(nèi)部結(jié)構(gòu)?？梢哉f，黑合法和白盒法是從完全不同的起點出發(fā)的，并且這兩個出發(fā)點在某種程度上是完全對立的，反映了測試思路的兩個極端情況。這兩類方法在長期的軟件測試實踐中已經(jīng)被證明是有效和實用的。一般地說，在進行單元測試時通常采用白盒測試，而在確認測試或系統(tǒng)測試中大都采用黑盒測試。白黑測試最為常見的程序結(jié)構(gòu)覆蓋有：1） 語句覆蓋：它要求被測程序的每一可執(zhí)行語句在測試中盡可能都檢驗過，這是最弱的邏輯覆蓋準則。2） 分支覆蓋或判斷覆蓋：要求程序中所有判定的分支盡可能得到檢驗。3） 條件覆蓋：當判定式中含有多個條件時，要求每個條件的取值均得到檢驗。4） 判斷/條件覆蓋：同時考慮條件的組合值及判定結(jié)果的檢驗。5） 路徑覆蓋：只考慮對程序路徑的全面檢驗。為取得被測程序的覆蓋情況，最為常用的辦法是在測試前對被測程序進行預(yù)處理。預(yù)處理的主要工作是在其重要的控制點插入“探測器”一一程序插裝。必須說明，無論哪種測試覆蓋，即使其覆蓋率達到百分之百，也不能保證把所有隱藏的程序欠缺都揭露出來。三、黑盒測試方法和白盒測試方法的對黑盒法白盒法規(guī)劃方面針對功能的測試針對結(jié)構(gòu)的測試優(yōu)勢方面能確保從用戶使用的角度出發(fā)進行測試能夠?qū)Τ绦騼?nèi)部的特定部位進行覆蓋測試欠缺方面無法測試程序內(nèi)部特定部位如果規(guī)格說明有誤，則無法發(fā)現(xiàn)問題無法檢驗程序的外部特性無法對未實現(xiàn)規(guī)格說明的程序內(nèi)部欠缺部分進行測試應(yīng)用舉例邊界值分析法等價類劃分法基于圖的測試比較測試語句覆蓋判斷覆蓋條件覆蓋判斷/條件覆蓋基本路徑覆蓋循環(huán)覆蓋模塊接口測試軟件測試過程軟件測試過程按測試的先后次序可分為5個步驟：單元測試、集成測試、確認測試和系統(tǒng)測試，最后進行驗收測試。1） 單元測試：分別完成每個單元的測試任務(wù)，以確保每個模塊能正常工作。單元測試大量地采用了白盒測試方法，盡可能地發(fā)現(xiàn)模塊內(nèi)部的程序錯誤。2） 集成測試：把已測試過的模塊組裝起來，進行集成測試。其目的在于檢驗與軟件設(shè)計相關(guān)的程序結(jié)構(gòu)問題。這時較多地采用黑盒測試方法來設(shè)計測試用例。3） 確認測試：完成集成測試以后，要對開發(fā)工作初期制定的確認準則進行檢驗。確認測試是檢驗所開發(fā)的軟件能否滿足所有功能和性能需求的最后手段，通常均采用黑盒測試法。4） 系統(tǒng)測試：完成確認測試以后，給出的應(yīng)該是合格的軟件產(chǎn)品，但為檢驗它能否與系統(tǒng)的其他部分（如硬件、數(shù)據(jù)庫及操作人員）協(xié)調(diào)工作，需要進行系統(tǒng)測試，嚴格地說，系統(tǒng)測試已超出了軟件工程的范圍。5） 驗收測試：檢驗軟件產(chǎn)品質(zhì)量的最后一道工序是驗收測試。與前面討論的各種測試活動的不同之處主要在于它突出了客戶的作用，同時軟件開發(fā)人員也應(yīng)有一定程度的參與。總的來說，軟件測試階段的輸入信息包括兩類:1）軟件配置：這是測試的對象，包括需求說明書、設(shè)計說明書和被測的源程序等。2）測試配置：包括測試計劃、測試步驟、測試用例（測試數(shù)據(jù)）以及具體實施測試的測試程序、測試工具等。一、單元測試軟件單元測試是要檢驗程序最小單位（模塊）有無錯誤，它是在編碼完成后必須進行的測試工作。一般由開發(fā)人員本身來完成，因而單元測試通常被視做編碼步驟的附屬品。單元測試大多從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例，即采用白盒測試方法，多個程序模塊可以并行地獨立開展測試工作。1、單元測試的主要任務(wù)單元測試是針對每個程序模塊，解決5個方面的問題：模塊接口、局部數(shù)據(jù)結(jié)構(gòu)、邊界條件、獨立的路徑和錯誤處理。模塊接口對模塊接口的測試，是檢查進出程序單元的數(shù)據(jù)流是否正確。對模塊接口數(shù)據(jù)流的測試必須在任何其他測試之前進行，因為如果不能確保數(shù)據(jù)正確地輸入和輸出的話，所有的測試都是沒有意義的。針對模塊接口測試應(yīng)進行的檢查，主要涉及如下方面的內(nèi)容：1） 模塊接受的輸入?yún)?shù)個數(shù)與模塊的變量個數(shù)是否一致。2） 參數(shù)與變量的屬性是否匹配。3） 參數(shù)與變量所使用的單位是否一致。4） 給另一被調(diào)用模塊的變量個數(shù)與參數(shù)個數(shù)是否相同。5） 傳送給另一被調(diào)用模塊的變量屬性與參數(shù)屬性是否匹配。6） 傳送給另一被調(diào)用模塊的變量，其單位是否與參數(shù)的單位一致。7） 調(diào)用內(nèi)部函數(shù)時，變量的個數(shù)、屬性和次序是否正確。8） 在模塊有多個入口的情況下，是否有引用與當前入口無關(guān)的參數(shù)。9） 是否會修改只是作為輸入值的變量。10） 出現(xiàn)全局變量時，這些變量是否在所有引用它們的模塊中都有相同的定義。11） 有沒有把常數(shù)當做變量來傳送。12） 文件屬性是否正確。13）文件打開語句的格式是否正確。14） 格式說明與輸入、輸出語句給出的信息是否一致。15） 緩沖區(qū)的大小是否與記錄的大小匹配。16） 是否所有的文件在使用前均已打開了。17） 對文件結(jié)束條件的判斷和處理是否正確。18） 對輸入、輸出錯誤的處理是否正確。19） 有沒有輸出信息的正文錯誤。局部數(shù)據(jù)結(jié)構(gòu)在模塊工作過程中，必須測試其內(nèi)部的數(shù)據(jù)能否保持完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式相互關(guān)系不發(fā)生錯誤。應(yīng)該說，模塊的局部數(shù)據(jù)結(jié)構(gòu)是經(jīng)常發(fā)現(xiàn)錯誤的錯誤源，對于局部數(shù)據(jù)結(jié)構(gòu)應(yīng)該在單元測試中注意發(fā)現(xiàn)以下幾類錯誤：1） 不正確的或不一致的類型說明。2） 錯誤的初始化或默認值。3） 錯誤的變量名，如拼寫錯誤或縮寫錯誤。4） 不相容的數(shù)據(jù)類型。5） 下溢、上溢或者地址錯誤。除了局部數(shù)據(jù)結(jié)構(gòu)外，在單元測試中還應(yīng)弄清楚全程數(shù)據(jù)對模塊的影響。路徑測試在單元測試中，最主要的測試是針對路徑的測試。測試用例必須能夠發(fā)現(xiàn)由于計算錯誤、不正確的判斷或不正常的控制流而產(chǎn)生的錯誤。常見的錯誤有：1） 誤解的或不正確的算術(shù)優(yōu)先級。2） 混合模式的運算。3） 錯誤的初始化。4） 精確度不夠精確。5） 表達式的不正確符號表示。針對判定和條件覆蓋，測試用例還要能夠發(fā)現(xiàn)如下錯誤：1）同數(shù)據(jù)類型的比較。2）不正確的邏輯操作或優(yōu)先級。3） 應(yīng)當相等的地方由于精確度的錯誤而不能相等。4） 不正確的判定或不正確的變量。5） 不正常的或不存在的循環(huán)終止。6） 當遇到分支循環(huán)時不能退出。7） 不適當?shù)匦薷难h(huán)變量。邊界條件實踐表明，軟件常常在邊界地區(qū)發(fā)生問題。例如，處理n維數(shù)組的第n個元素時很容易出錯，循環(huán)執(zhí)行到最后一次執(zhí)行循環(huán)體時也可能出錯。邊界測試是單元測試的最后一步，是非常重要的，必須采用邊值分析方法來設(shè)計測試用例，仔細地測試為限制數(shù)據(jù)處理而設(shè)置的邊界處，看模塊是否能夠正常工作。出錯處理測試出錯處理的要點是模塊在工作中發(fā)生了錯誤，其中的出錯處理設(shè)施是否有效。程序運行中出現(xiàn)異常現(xiàn)象并不奇怪，良好的設(shè)計應(yīng)該預(yù)先估計到投入運行后可能發(fā)生的錯

誤，并給相應(yīng)的處理措施，使得用戶不至于素手無策。檢驗程序中出錯處理可能面對的情況有:1） 對運行發(fā)生的錯誤描述得難以理解。2） 所報告的錯誤與實際遇到的錯誤不一致。3） 出錯后，在錯誤處理之前就引起了系統(tǒng)干預(yù)。4） 例外條件的處理不正確。5） 提供的錯誤信息不足，以致無法找到出錯的原因。用戶對這5個方面的錯誤會非常的敏感，因此，如何設(shè)計測試用例，使得模塊測試能夠高效率地發(fā)現(xiàn)其中的錯誤，就成為軟件測試過程中非常重要的問題。單元測試的執(zhí)行過程一般情況下，單元測試常常是和代碼編寫工作同時進行的，在完成了程序編寫、復(fù)查和語法正確性驗證后，就應(yīng)進行單元測試用例設(shè)計。在對每個模塊進行單元測試時，不能完全忽視它們和周圍模塊的相互聯(lián)系。為模擬這一聯(lián)系，在進行單元測試時，需設(shè)置若干輔助測試模塊。輔助模塊有兩種，一種是驅(qū)動模塊（Driver），用以模擬被測模塊的上級模塊。驅(qū)動模塊在單元測試中接受測試數(shù)據(jù)，把相關(guān)的數(shù)據(jù)傳送給被測模塊，啟動被測模塊，并打印出相應(yīng)的結(jié)果。另一種是樁模塊（Stub），用以模擬被測模塊工作過程中所調(diào)用的模塊。樁模塊由被測模塊調(diào)用，它們一般只進行很少的數(shù)據(jù)處理，例如打印入口和返回，以便于檢驗被測模塊與其下級模塊的接口。集成測試集成測試（IntegratedTesting）階段是指每個模塊完成單元測試以后，需要按照設(shè)計時確定的結(jié)構(gòu)圖，把它們連接起來，進行集成測試。很多實際的例子表明，軟件的一些模塊能夠單獨地工作，但并不能保證連接之后也肯定能正常工作。程序在某些局部反映不出的問題，在全局上很可能暴露出來，影響軟件功能的實現(xiàn)。集成測試包括兩種不同的方法：非增式測試和增式測試。確認測試確認測試的準則軟件確認要通過一系列證明軟件功能和需求一致的黑盒測試來完成。在需求規(guī)格說明書中可能作了原則性規(guī)定，但在測試階段需要更詳細、更具體的測試規(guī)格說明書（TestSpecification）作進一步說明，列出要進行的測試種類，并定義為發(fā)現(xiàn)與需求不一致的錯誤而使用詳細測試用例的測試過程。經(jīng)過確認測試，應(yīng)該為已開發(fā)的軟件給出結(jié)論性評價：1） 經(jīng)過檢驗的軟件功能、性能及其他要求均已滿足需求規(guī)格說明書的規(guī)定，因而可被認為是合格的軟件。2） 經(jīng)過檢驗發(fā)現(xiàn)與需求說明書有相當?shù)钠x，得到一個各項缺陷清單。對于這種情況，往往很難在交付期之前把發(fā)現(xiàn)的問題糾正過來。這就需要開發(fā)部門與用戶進行協(xié)商，找出解決的辦法。配置審查的內(nèi)容確認過程的重要環(huán)節(jié)就是配置審查工作。其目的在于確保已開發(fā)軟件的所有文件資料均已編寫齊全，并得到分類編目，足以支持投入運行以后的軟件維護工作。這些文件資料包括用戶所需資料（如用戶手冊、操作手冊）、設(shè)計資料（如設(shè)計說明書等）、源程序以及測試資料（如測試說明書、測試報告等）。配置審查（ConfigurationReview）有時也稱配置審計（ConfigurationAudit）0系統(tǒng)測試軟件只是整個計算機系統(tǒng)中的一個組成部分，因此，在軟件開發(fā)完成以后，最終還要和系統(tǒng)中的其他部分（硬件、信息）集成起來，在投入運行以前要完成系統(tǒng)測試，以保證各組成部分不僅能單獨地受到檢驗，而且在系統(tǒng)各部分協(xié)調(diào)工作的環(huán)境下也能正常工作。盡管每一個檢驗有著特定的目標，然而，所有的檢測工作都要驗證系統(tǒng)中每個部分均已得到正確的集成，并能完成指定的功能。下面我們對幾種系統(tǒng)測試方法進行簡要的介紹。恢復(fù)測試方法許多計算機系統(tǒng)一旦出現(xiàn)錯誤，就必須在一定時間內(nèi)從錯誤中恢復(fù)過來，然后繼續(xù)運行?；謴?fù)測試是通過各種手段，強制性地使軟件出錯，而不能正常工作，進而檢驗系統(tǒng)的恢復(fù)能力。如果系統(tǒng)恢復(fù)是自動的（系統(tǒng)本身完成），則應(yīng)檢驗：重新初始化、檢驗點設(shè)置機構(gòu)、數(shù)據(jù)恢復(fù)以及重新啟動是否正確。如果這一恢復(fù)需要人為干預(yù)，則應(yīng)考慮平均修復(fù)時間是否在限定的范圍以內(nèi)。安全測試方法安全測試的目的在于驗證安裝在系統(tǒng)內(nèi)的保護機制能否在實際中保護系統(tǒng)且不受非法侵入，不受各種非法的干擾。系統(tǒng)的安全測試要設(shè)置一些測試用例試圖突破系統(tǒng)的安全保密措施，檢驗系統(tǒng)是否有安全保密的漏洞。強度測試方法強度測試需要在反常數(shù)量、頻率或資源的方式下運行系統(tǒng)，以檢驗系統(tǒng)能力的最高實際限度。比如：1） 如果正常的中斷平均頻率為每秒5次，強度測試設(shè)計為每秒50次中斷。2） 把輸入數(shù)據(jù)的量提高一個數(shù)量級來測試輸入功能會如何響應(yīng)。3） 若某系統(tǒng)正常運行可支持20個終端并行工作，強度測試則檢驗100個終端并行工作的情況。4） 執(zhí)行需要大量內(nèi)存或其他資源的測試實例。性能測試方法性能測試用來測試軟件在集成系統(tǒng)中的運行性能，特別是針對實時系統(tǒng)嵌入的系統(tǒng)。性能測試可以在測試過程的任意階段進行，但只有當整個系統(tǒng)的所有成分都集成到一起后，才能檢查一個系統(tǒng)的真正性能。這種測試常常與強度測試結(jié)合起來進行。為了記錄性能，需要在系統(tǒng)中安裝必要的量測儀表或者為度量性能而設(shè)置的軟件（或程序段）。驗收測試驗收測試是檢驗軟產(chǎn)品質(zhì)量的最后一道工序。與前面討論的各種測試活動的不同之處主要在于它突出了客戶的作用，同時軟件開發(fā)人員也應(yīng)有一定程度的參與。如何組織好驗收測試并不是一件容易的事。本節(jié)只是對驗收測試的任務(wù)、目標以及驗收測試的組織管理給出簡要的闡述。驗收測試的內(nèi)容軟件驗收測試應(yīng)完成的工作包括：1） 明確驗收項目，規(guī)定驗收測試通過的標準。2） 確定測試方法。3） 決定驗收測試的組織機構(gòu)和可利用的資源。4） 選定驗收測試結(jié)果分析方法。5） 指定驗收測試計劃并進行評審。6） 設(shè)計驗收測試所用測試用例。7） 審查驗收測試準備工作。8）執(zhí)行驗收測試。9）分析測試結(jié)果。10）闡明驗收測試結(jié)論，決定通過驗收或是拒絕。驗收測試計劃可能包括的檢驗方面有以下一些：1） 功能測試（例如，完整的工資計算過程）。2） 逆向測試（例如，檢驗不符合要求數(shù)據(jù)而引起出錯的恢復(fù)能力）。3） 特殊情況（例如，極限測試、不存在路徑的測試）。4） 文檔檢查。5） 強度測試（例如，大批量數(shù)據(jù)或最多用戶同時使用）。6） 恢復(fù)測試（例如，硬件故障或用戶不良數(shù)據(jù)引起的一些情況）。7） 可維護性評價。8） 用戶操作測試（如啟動、退出系統(tǒng)）。9） 用戶友好型檢驗。10） 安全測試。軟件驗