一. 軟件測試方法
1. 軟件測試方法：白盒測試、黑盒測試、灰盒測試、靜態測試、動態測試
2. 白盒測試：是一種測試用例設計方法，在這裏盒子指的是被測試的軟件，白盒，顧名思義即盒子是可視的，你可以清楚盒子內部的東西以及裏面是如何運作的，因此白盒測試需要你對系統內部的結構和工作原理有一個清楚的瞭解，並且基於這個知識來設計你的用例。
白盒測試技術一般可被分爲靜態分析和動態分析兩類技術。
靜態分析主要有：控制流分析技術、數據流分析技術、信息流分析技術。
動態分析主要有：邏輯覆蓋率測試(分支測試、路徑測試等)，程序插裝等。
白盒測試優點：迫使測試人員去仔細的思考軟件的實現；可以檢測代碼中的每條分支和路徑；揭示隱藏在代碼中的錯誤；對代碼的測試比較徹底；最優化。
白盒測試缺點：昂貴；無法檢測代碼中遺漏的路徑和數據敏感性錯誤；不驗證規格的正確性。
3. 黑盒測試又叫功能測試，這是因爲在黑盒測試中主要關注被測軟件的功能實現，而不是內部邏輯。在黑盒測試中，被測對象的內部結構，運作情況對測試人員是不可見的，測試人員對被測產品的驗證主要是根據其規格，驗證其與規格的一致性。
在絕大多數沒有用戶參與的黑盒測試中，最常見的測試有：功能性測試、容量測試、安全性測試、負載測試、恢復性測試、標杆測試、穩定性測試、可靠性測試等。
4. 灰盒測試：白盒測試和黑盒測試往往不是決然分開的，一般在白盒測試中交叉使用黑盒測試的方法，在黑盒測試中交叉使用白盒測試的方法。灰盒測試就是這類界於白盒測試和黑盒測試之間的測試。
最常見的灰盒測試是集成測試。
5. 靜態測試：是一種不通過執行程序而進行測試的技術。它的關鍵功能是檢查軟件的表示和描述是否一致，沒有衝突或者沒有歧義。
6. 動態測試：包含了程序在受控的環境下使用特定的期望結果進行正式的運行。它顯示了一個系統在檢查狀態下是正確還是不正確。
單元測試屬於白盒測試範疇；集成測試屬於灰盒測試範疇；系統測試屬於黑盒測試範疇。
二. 單元測試
1. 概念：單元測試(Unit Testing)是對軟件基本組成單元進行的測試，如函數或是一個類的方法。這裏的單元，就是軟件設計的最小單位。
單元測試的兩個步驟：人工靜態檢查法與動態執行跟蹤法。
人工靜態檢查是測試的第一步，這個階段工作主要是保證代碼算法的邏輯正確性（儘量通過人工檢查發現代碼的邏輯錯誤）、清晰性、規範性、一致性、算法高效性，並儘可能的發現程序中沒有發現的錯誤。
第二步是通過設計測試用例，執行待測程序來跟蹤比較實際結果與預期結果來發現錯誤。
2. 人工檢查：
(1)、檢查算法的邏輯正確性：確定所編寫的代碼算法、數據結構定義（如：隊列、堆棧等）是否實現了模塊或方法所要求的功能。
(2)、模塊接口的正確性檢查：確定形式參數個數、數據類型、順序是否正確；確定返回值類型及返回值的正確性。
(3)、輸入參數有沒有作正確性檢查：如果沒有作正確性檢查，確定該參數是否的確無需做參數正確性檢查，否則請添加上參數的正確性檢查。
(4)、調用其他方法接口的正確性：檢查實參類型正確與否、傳入的參數值正確與否、個數正確與否，特別是具有多態的方法。返回值正確與否，有沒有誤解返回值所表示的意思。最好對每個被調用的方法的返回值用顯示代碼作正確性檢查，如果被調用方法出現異常或錯誤程序應該給予反饋，並添加適當的出錯處理代碼。
(5)、出錯處理：模塊代碼要求能預見出錯的條件，並設置適當的出錯處理，以便一旦程序出錯時，能對出錯程序重做安排，保證其邏輯的正確性，這種出錯處理應當是模塊功能的一部分。若出現下列情況之一，則表明模塊的錯誤處理功能包含有錯誤或缺陷：出錯的描述難以理解；出錯的描述不足以對錯誤定位，不足以確定出錯的原因；顯示的錯誤信息與實際的錯誤原因不符；對錯誤條件的處理不正確；在對錯誤進行處理之前，錯誤條件已經引起系統的干預等。
(6)、保證表達式、SQL語句的正確性：檢查所編寫的SQL語句的語法、邏輯的正確性。對錶達式應該保證不含二義性，對於容易產生歧義的表達式或運算符優先級（如：<、=、 >、 &&、||、 、 --等）可以採用擴號“（）”運算符避免二義性，這樣一方面能夠保證代碼的正確可靠，同時也能夠提高代碼的可讀性。
(7)、檢查常量或全局變量使用的正確性：確定所使用的常量或全局變量的取值和數值、數據類型；保證常量每次引用同它的取值、數值和類型的一致性。
(8)、表示符定義的規範一致性：保證變量命名能夠見名知意，並且簡潔但不宜過長或過短、規範、容易記憶、最好能夠拼讀。並儘量保證用相同的表示符代表相同功能，不要將不同的功能用相同的表示符表示；更不要用相同的表示符代表不同的功能意義。
(9)、程序風格的一致性、規範性：代碼必須能保證符合企業規範，保證所有成員的代碼風格一致、規範、工整。例如對數組做循環，不要一會兒採用下標變量從下到上的方式（如:for(i=0;i ;i<10)），一會兒又採用從上到下的方式(如:for(i=10;i--;i>0))；應該儘量採用統一的方式，或則統一從下到上，或則統一從上到下。建議採用for循環和While循環，不要採用do{}while循環等。
(10)、檢查程序中使用到的神祕數字是否採用了表示符定義：神祕的數字包括各種常數、數組的大小、字符位置、變換因子以及程序中出現的其他以文字形式寫出的數值。在程序源代碼裏，一個具有原本形式的數對其本身的重要性或作用沒提供任何指示性信息，它們也導致程序難以理解和修改。對於這類神祕數字必須採用相應的標量來表示；如果該數字在整個系統中都可能使用到務必將它定義爲全局常量；如果該神祕數字在一個類中使用可將其定義爲類的屬性（Attribute）,如果該神祕數字只在一個方法中出現務必將其定義爲局部變量或常量。
(11)、檢查代碼是否可以優化、算法效率是否最高：如：SQL語句是否可以優化，是否可以用1條SQL語句代替程序中的多條SQL語句的功能，循環是否必要，循環中的語句是否可以抽出到循環之外等。
(12)、檢查您的程序是否清晰簡潔容易理解：注意：冗長的程序並不一定不是清晰的。
(13)、檢查方法內部註釋是否完整：是否清晰簡潔；是否正確的反映了代碼的功能，錯誤的註釋比沒有註釋更糟；是否做了多餘的註釋；對於簡單的一看就懂的代碼沒有必要註釋。
(14)、檢查註釋文檔是否完整：對包、類、屬性、方法功能、參數、返回值的註釋是否正確且容易理解；是否會落了或多了某個參數的註釋，參數類型是否正確，參數的限定值是否正確。特別是對於形式參數與返回值中關於神祕數值的註釋，如：類型參數 應該指出 1.代表什麼，2.代表什麼，3.代表什麼等。對於返回結果集(Result Set)的註釋，應該註釋結果集中包含那些字段及字段類型、字段順序等。
3. 動態執行跟蹤：動態執行測試通常分爲黑盒測試與白盒測試。對於單元測試來說主要應該採用白盒測試法對每個模塊的內部作跟蹤檢查測試。對於單元白盒測試，應該對程序模塊進行如下檢查：(1)、對模塊內所有獨立的執行路徑至少測試一次；(2)、對所有的邏輯判定，取“真”與“假”的兩種情況都至少執行一次；(3)、在循環的邊界和運行界限內執行循環體；(4)、測試內部數據的有效性等等。
4. 單元測試的目的：在於發現各模塊內部可能存在的各種錯誤，主要是基於白盒測試。
單元測試的目的主要有3方面：驗證單元代碼和詳細設計文檔的一致性；跟蹤詳細設計文檔中設計的實現，發現詳細設計文檔中存在的錯誤；發現在編碼過程中引入的錯誤。
5. 單元的常見錯誤：(1)、單元接口；(2)、局部數據結構；(3)、獨立路徑；(4)、出錯處理；(5)、邊界條件。
6. 單元測試策略：有三種，獨立的單元測試策略，自頂向下的單元測試策略和自底向上的單元測試策略。
獨立的測試策略：不考慮每個模塊與其他模塊之間的關係，爲每個模塊設計樁模塊和驅動模塊。每個模塊進行獨立的單元測試。
自頂向下的測試策略：先對最頂層的單元進行測試，把頂層所調用的單元做成樁模塊。其次對第二層進行測試，使用上面已測試的單元做驅動模塊。如此類推直到測試完所有模塊。
自底向上測試：先對模塊調用層次圖上最低層的模塊進行單元測試，模擬調用該模塊的模塊做驅動模塊。然後再對上面一層做單元測試，用下面已被測試過的模塊做樁模塊。依次類推，直到測試完所有模塊。
7. 單元測試過程：計劃(測什麼)、設計(測試方案、策略)、實現(寫測試用例、代碼)、執行(測試報告)四個階段。
8. 單元測試的原則：(1)、對全新的代碼或修改過的代碼進行單元測試；(2)、單元測試根據單元測試計劃和方案進行，排除測試的隨意性；(3)、必須保證單元測試計劃、單元測試方案、單元測試用例等經過評審；(4)、當測試用例的測試結果與預期結果不一致時，單元測試的執行人員需如實記錄實際的測試結果；(5)、只有當測試計劃中的結束標準達到時，單元測試才能結束；(6)、對被測試單元需達到的一定的代碼覆蓋率要求。
三. 測試用例
1. 簡介：測試用例(Test Case)是爲某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或覈實是否滿足某個特定需求。也指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，並形成文檔。
不同類別的軟件，測試用例是不同的。
2. 概述：測試用例構成了設計和制定測試過程的基礎。測試的“深度”與測試用例的數量成比例。由於每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨着測試用例數量的增加，你對產品質量和測試流程也就越有信心。
判斷測試是否完全的一個主要評測方法是基於需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量爲依據的。
測試工作量與測試用例的數量成比例。最佳方案是爲每個測試需求至少編制兩個測試用例。一個測試用例用於證明該需求已經滿足，通常稱作正面測試用例。另一個測試用例反映某個無法接受、反常或意外的條件或數據，用於論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。
3. 設計方法：
(1)、白盒技術：白盒測試是結構測試，所以被測對象基本上是源程序，以程序的內部邏輯爲基礎設計測試用例。
白盒測試的測試用例設計：一般採用邏輯覆蓋法和基本路徑法進行設計。
邏輯覆蓋是以程序內部的邏輯結構爲基礎的測試用例設計技術，這一方法要求測試人員對程序的邏輯結構有清楚的瞭解。邏輯覆蓋可分爲：語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋與路徑覆蓋。
語句覆蓋：在測試時，首先設計若干個測試用例，然後運行被測程序，使程序中的每個可執行語句至少執行一次。
判定覆蓋法：在測試時，首先設計若干個測試用例，然後運行被測程序，使得程序中的每個判斷的取真分支和取假分支至少經歷一次，即判斷的真假值均曾被滿足。
條件覆蓋法：在測試時，首先設計若干個測試用例，然後運行被測程序，要使每個判斷中每個條件的可能取值至少滿足一次。
判定條件覆蓋法：在測試時，首先設計若干個測試用例，然後運行被測程序，使得判斷中每個條件的所有可能至少出現一次，並且每個判斷本身的判定結果至少出現一次。
路徑覆蓋法：在測試時，首先設計若干個測試用例，然後運行被測程序，要求覆蓋程序中所有可能的路徑。
基本路徑覆蓋法：是在程序控制流圖的基礎上，通過分析控制結構的環路複雜性，導出基本可執行路徑集合，設計測試用例的方法。該方法把覆蓋的路徑數壓縮到一定限度內，程序中的循環體最多隻執行一次。設計出的測試用例要保證在測試中，程序的每一個可執行語句至少執行一次。
循環路徑測試：基本路徑覆蓋法將循環限制在最多一次，這樣雖然大大降低了需要覆蓋的路徑的條數，但對循環的測試卻不充分了，因此還需要對循環路徑進行測試。循環路徑測試包含，簡單循環的測試和嵌套循環的測試。
每一種覆蓋方法都有其優缺點。通常在設計測試用例時應該根據代碼模塊的複雜度，選擇覆蓋方法。一般的代碼的複雜度與測試用例設計的複雜度成正比。因此，設計人員必須做到模塊或方法功能的單一性、高內聚性，使得方法或函數代碼儘可能的簡單；這樣將可大大提高測試用例設計的容易度，提高測試用例的覆蓋程度。
基本路徑測試法是在程序控制流圖的基礎上，通過分析控制構造的環路複雜性，導出基本可執行路徑集合，從而設計測試用例的方法。設計出的測試用例要保證在測試中程序的每個可執行語句至少執行一次。基本路徑測試法包括以下5個方面：(1)、程序的控制流圖：描述程序控制流的一種圖示方法；(2)、程序環境複雜性：McCabe複雜性度量；從程序的環路複雜性可導出程序基本路徑集合中的獨立路徑條數，這是確定程序中每個可執行語句至少執行依次所必須的測試用例數目的上界；(3)、導出測試用例；(4)、準備測試用例，確保基本路徑集中的每一條路徑的執行；(5)、圖形矩陣：是在基本路徑測試中起輔助作用的軟件工具，利用它可以實現自動地確定一個基本路徑集。
另外，對於測試用例的選擇除了滿足所選擇的覆蓋程度（或覆蓋標準）外還需要儘可能的採用邊界值分析法、錯誤推測法等常用地設計方法。採用邊界值分析法設計合理的輸入條件與不合理的輸入條件；條件邊界測試用例應該包括輸入參數的邊界與條件邊界（if,while，for，switch ,SQL Where子句等）。錯誤推測法，列舉出程序中所有可能的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例；在編碼、單元測試階段可以發現很多常見的錯誤和疑似錯誤，對於這些錯誤應該作重點測試，並設計相應的測試用例。
(2)、黑盒技術：等價劃分類、邊界值分析、錯誤推測、因果圖、綜合策略
4. 測試類設計：一個模塊或一個方法（Method）並不是一個獨立的程序，在考慮測試它時要同時考慮它和外界的聯繫，用些輔助模塊去模擬與所測模塊相聯繫的其他模塊。這些輔助模塊分爲兩種：
(1)、驅動模塊（driver）：相當於所測模塊的主程序。它接收測試數據，把這些數據傳送給所測模塊，最後再輸出實際測試結果；
(2)、樁模塊（stub）:用於代替所測模塊調用的子模塊。樁模塊可以做少量的數據操作，不需要把子模塊所有功能都帶進來，但不容許什麼事情也不做。
打樁：一般在做單元或集成測試時，如果某個程序單元的某條語句，需要調用的一個外部函數還沒有設計、編碼、調試完成的話，可以只讓它簡單地返回幾個支持測試用例的值就可以了，這種狀態的外部函數一般就叫做“打樁”。
所測模塊與它相關的驅動模塊及樁模塊共同構成了一個“測試環境”。
驅動模塊和樁模塊的編寫會給測試帶來額外的開銷。因爲它們在軟件交付時並不作爲產品的一部分一同交付，而且它們的編寫需要一定的工作量。特別是樁模塊，不能只簡單地給出“曾經進入”的信息。爲了能夠正確的測試軟件，樁模塊可能需要模擬實際子模塊的功能，這樣樁模塊的建立就不是很輕鬆了。
編寫樁模塊是困難費時的，其實也是完全可以避免編寫樁模塊的；只需在項目進度管理時將實際樁模塊的代碼編寫工作安排在被測模塊前編寫即可。而且這樣可以提高測試工作的效率，提高實際樁模塊的測試頻率從而更有效的保證產品的質量。但是，爲了保證能夠向上一層級提供穩定可靠的實際樁模塊，爲後續模塊測試打下良好的基礎，驅動模塊還是必不可少的。
對於每一個包或子系統我們可以根據所編寫的測試用例來編寫一個測試模塊類來做驅動模塊，用於測試包中所有的待測試模塊。而最好不要在每個類中用一個測試函數的方法，來測試跟蹤類中所有的方法。這樣的好處在於：(1)、能夠同時測試包中所有的方法或模塊，也可以方便的測試跟蹤指定的模塊或方法；(2)、能夠聯合使用所有測試用例對同一段代碼執行測試，發現問題；(3)、便以迴歸測試，當某個模塊作了修改之後，只要執行測試類就可以執行所有被測的模塊或方法。這樣不但能夠方便得檢查、跟蹤所修改的代碼，而且能夠檢查出修改對包內相關模塊或方法所造成的影響，使修改引進的錯誤得以及時發現；(4)、複用測試方法，使測試單元保持持久性，並可以用既有的測試來編寫相關測試；(5)、將測試代碼與產品代碼分開，使代碼更清晰、簡潔；提高測試代碼與被測代碼的可維護性。
5. 跟蹤調試：跟蹤調試不但是深入測試代碼的最佳方法，而且也是程序調試發現錯誤根源的有利工具。測試類設計完成後，最好能借助代碼排錯工具來跟蹤調試待測代碼段以深入的檢查代碼的邏輯錯誤。現有的代碼開發工具（如:JBuilder）一般都集成了這類排錯工具。排錯工具一般由執行控制程序、執行狀態查詢程序、跟蹤程序組成。執行控制程序包括斷點定義、斷點撤銷、單步執行、斷點執行、條件執行等功能。執行狀態查詢程序包括寄存器、堆棧狀態、變量、代碼等與程序相關的各種狀態信息的查詢。跟蹤程序用以跟蹤程序執行過程中所經歷的事件序列（如：分支、子程序調用等）。程序員可通過對程序執行過程中各種狀態的判別進行程序錯誤的識別、定位及改正。
對於模塊的單元跟蹤調試最好能夠做到：每次修改被測模塊後，都將所有測試用例跟蹤執行一遍以排除所有可能出現或引進的錯誤。在時間有限的情況下也必須調用驅動模塊對所有的測試用例執行一次，並對出現錯誤或異常的測試用例跟蹤執行一次，以發現問題的根源。
排錯過程往往是一個艱苦的過程，特別是那種算法複雜、調用子模塊較多的模塊，對於錯誤的定位來說並不是件容易的事情。儘管排錯不是一門好學的技術（有時人們更願意稱之爲藝術），但還是有若干行之有效的方法和策略，下面介紹幾種排錯時應該採用的方法策略：(1)、斷點設置，設置斷點對源程序實行斷點跟蹤將能夠大大提高排錯的效率。通常斷點的設置除了根據經驗與錯誤信息來設置外，還應重點考慮以下幾種類行的語句：A、函數調用語句。子函數的調用語句是測試的重點，一方面由於在調用子函數時可能引起接口引用錯誤，另一方面可能是子函數本身的錯誤；B、判定轉移/循環語句。判定語句常常會由於邊界值與比較優先級等問題引起錯誤或失效而作出錯誤的轉移。因此，對於判定轉移/循環語句也是一個重要的測試點；C、SQL語句。對於數據庫的應用程序來說，SQL語句常常會在模塊中佔比較重要的業務邏輯，而且比較複雜。因此，它也屬於比較容易出現錯誤的語句；D、複雜算法段。出錯的概率常與算法的複雜度成正比。所以越複雜的算法越需要作重點跟蹤，如遞歸、回朔等算法。(2)、可疑變量查看，在跟蹤執行狀態下當程序停止在某條語句時可查看變量的當前值和對象的當前屬性。通過對比這些變量當前值與預期值可以輕鬆的定位程序問題根源；(3)、SQL語句執行檢查，在跟蹤執行或運行狀態下將疑似錯誤的SQL語句打印出來，重新在數據庫SQL查詢分析器（如：Oracle SQL Plus）中跟蹤執行可以較高效的檢查糾正SQL語句錯誤；(4)、注意羣集現象，經驗表明測試後程序中殘存的錯誤數目與該程序中已發現的錯誤數目或檢錯率成正比。根據這個規律，應當對錯誤羣集的程序段進行重點測試，以提高測試投資的效益。如果發現某一代碼段似乎比其他程序模塊更多的錯誤傾向時，則應當花費較多的時間和代價測試這個程序模塊。
6. 測試用例設計的基本原則：(1)、一個好的測試用例在於能夠發現至今沒有發現的錯誤；(2)、測試用例應由測試輸入數據和與之對應的預期輸出結果這兩部分組成；(3)、在測試用例設計時，應當包含合理的輸入條件和不合理的輸入條件。
7. 測試用例的具體做法：
(1)、測試用例文檔：編寫測試用例文檔應有文檔模板，須符合內部的規範要求。
(2)、測試用例的設置：按功能設置用例、按路徑設置用例、按功能、路徑混合模式設置用例；
(3)、設計測試用例：測試用例可以分爲基本事件、備選事件和異常事件。
四. 白盒測試
1. 白盒測試一般包括以下幾項：
(1)、目的：保證程序創建的類與接口的完整與正確，以及程序模塊單獨正常運行。保證局部模塊功能完備性，運行正確性與穩定性。
(2)、測試項：所要測試的類。
(3)、測試依據：A、需求規格說明書、用例描述清單；B、設計文檔；C、編碼規範；D、開發命名標準。
(4)、通過的準則：創建的類、接口、方法、屬性應與《設計文檔》保持一致；程序的各種命名、註釋、代碼行的格式等應符合《程序開發命名標準》和《編碼規範》；程序模塊能獨立穩定運行。
(5)、測試環境配置：A、測試工具；B、軟件環境。
2. 測試步驟：
(1)、配置好測試環境；
(2)、編寫測試用例；
(3)、靜態測試、走查代碼；
(4)、動態測試；
(5)、確定問題屬性：分爲四類，錯誤、缺陷、失效、故障。
錯誤是指計算值、觀測值、測量值之間，或條件與真值之間，不符合規定的或理論上的正確值或條件。
缺陷是指與期望值或特徵值的偏差。
故障是指功能部件不能執行所要求的功能。故障可能由錯誤、缺陷或失效引起。
失效是指功能部件執行其功能的能力喪失，系統或系統部件喪失了在規定限度內執行所要求功能的能力。
(6)、確定問題類別；
(7)、填寫測試報告。
3. 白盒測試和單元測試的區別：(1)、測試目的：一個是測試程序的整體邏輯，另一個是測試程序中一個獨立的模塊；(2)、通常的執行人員不一樣：白盒一般由專門的白盒測試人員完成，單元測試一般由程序員自己完成。