目錄：
一、黑盒測試與白盒測試：
等價類劃分：
一、確定等價類
確定等價類是選取每一個輸入條件（通常是規格說明中的一個句子或短語）並 將其劃分爲兩個或更多的組。可以使用圖 4-3 中的表格來進行劃分。注意，我們確 定了兩類等價類：有效等價類代表對程序的有效輸入，而無效等價類代表的則是其 他任何可能的輸入條件（即不正確的輸入值）。
二、生成測試用例
第二步是使用等價類來生成測試用例，其過程如下：
1. 爲每個等價類設置一個不同的編號。
2. 編寫新的測試用例，儘可能多地覆蓋那些尚未被涵蓋的有效等價類，直到 所有的有效等價類都被測試用例所覆蓋（包含進去）。
3. 編寫新的用例，覆蓋一個且僅一個尚未被覆蓋的無效等價類，直到所有的 無效等價類都被測試用例所覆蓋。 用單個測試用例覆蓋無效等價類，是因爲某些特定的輸入錯誤檢查可能會屏蔽 或取代其他輸入錯誤檢查。舉例來說，如果規格說明規定了“請輸入書籍類型（硬 皮、軟皮或活頁）及數量（l～999 )”，代表兩個錯誤輸入的測試用例“XYZ 0”，很可能不會執行對數量的檢查，因爲程序也許會提示 “XYZ 是未知的書籍類型”，就不檢查輸入的其餘部分了。
邊界值分析：
很難提供一份如何進行邊界值分析的“詳細說明’，因爲這種方法需要一定程度的創造性，以及對問題採取一定程度的特殊處理辦法（因此，就像測試的許多其他方面一樣，這更多的是項智力工作，並非其他的什麼）。然而，我們還是給讀者提供一些通用指南：
1. 如果輸入條件規定了一個輸入值範圍，那麼應針對範圍的邊界設計測試用例，針對剛剛越界的情況設計無效輸入測試用例。舉例來說，如果輸入值的有效範圍是-1.0 至+l.0，那麼應針對-1.0、1.0、-1.001 和1.001 的情況設計測試用例。
2. 如果輸入條件規定了輸入值的數量，那麼應針對最小數量輸入值、最大數量輸入值，以及比最小數量少一個、比最大數量多一個的情況設計測試用例。舉例來說，如果某個輸入文件可容納l~255 條記錄，那麼應根據0、l、255 和256條記錄的情況設計測試用例。
3. 對每個輸出條件應用指南 1。舉例來說，如果某個程序按月計算FICA1的扣除額，且最小金額是$0.00，最大金額$1165.25，那麼應該設計測試用例來測試扣除$0.00 和$1165.25 的情況。此外，還應觀察是否可能設計出導致扣除金額爲負數或超過$1165.25 的測試用例。注意，檢查結果空間的邊界很重要，因爲輸入範圍的邊界並不總是能代表輸出範圍的邊界情況（例如，三角正弦函數sin的情況就如此）。同樣，總是產生超過輸出範圍的結果也是不大可能的，但無論如何，應該考慮這種可能性。
4. 對每個輸出條件應用指南 2。如果某個信息檢索系統根據輸入請求顯示關聯程度最高的信息摘要，而摘要的數量從未超過4 條，則應編寫測試用例，使程序顯示0 條、l 條和4 條摘要，還應設計測試用例，導致程序錯誤地顯示5 條摘要。
5. 如果程序的輸入或輸出是一個有序序列（例如順序的文件、線性列表或表格），則應特別注意該序列的第一個和最後一個元素。
6. 此外，發揮聰明才智找出其他的邊界條件。
因果圖分析：
生成測試用例時採用的過程如下：
1. 將規格說明分解爲可執行的片段。這是必須的步驟，因爲因果圖不善於處理較大的規格說明。舉例來說，當測試一個電子商務系統時，“可執行的片段”可能是指對挑選和確認購物車中的單件商品的規格說明。在測試一個Web 頁面設計時，我們可能會測試一個單獨的菜單樹，甚至是一個不太複雜的導航序列。
2. 確定規格說明中的因果關係。所謂“因”，是指一個明確的輸入條件或輸入條件的等價類。所謂“果”，是指一個輸出條件或系統轉換（輸入對程序或系統狀態的延續影響）。舉例來說，如果某個事務引起文件或數據庫記錄被修改，那麼這種改變就是一個系統轉換，而系統反饋的確認信息就是一個輸出條件。通過逐字逐句地閱讀規格說明，同時標識出描述“因”和“果”的文字或句子，就可以將“因”和“果”確定出來。因果關係一旦確定下來，每個“因”和“果”都被賦予一個惟一的編號。
3. 分析規格說明的語義內容，並將其轉換爲連接因果關係的布爾圖。這就是所謂的因果圖。
4. 給圖加上註解符號，說明由於語法或環境的限制而不能聯繫起來的“因”和“果”。
5. 通過仔細地跟蹤圖中的狀態變化情況，將因果圖轉換成一個有限項的判定表。表中的每一列代表一個測試用例。
6. 將判定表中的列轉換成測試用例。
語句覆蓋：
每條語句都執行到。
判斷覆蓋：
每個判斷都有出現真和假。
條件覆蓋：
每個條件都執行到。
條件/判定覆蓋：
每個條件都有真假出現。
組合覆蓋：
每個條件直接的組合都出現（顯然，這種測試用例數很多）
二、模塊測試與增量測試：
模塊測試（或單元測試）是對程序中的單個子程序、子程序或過程進行測試的 過程，也就是說，一開始並不是對整個程序進行測試，而是首先將注意力集中在對 構成程序的較小模塊的測試上面。
模塊測試的目的是將模塊的功能與定義模塊的功能規格說明或接口規格說明 進行比較。有自頂向下測試與自底向上測試。
什麼是驅動模塊和樁模塊：
單元本身無法構成一個切實可運行的程序系統，所以我們需要爲單元測試來開發樁模塊和驅動模塊，從而完成我們的單元測試目的，這是樁模塊和驅動模塊的作用。
驅動模塊是用來模擬被測試模塊的上一級模塊，相當於被測模塊的主程序。它接收數據，將相關數據傳送給被測模塊，啓用被測模塊，並打印出相應的結果。
樁模塊（Stub）是指模擬被測試的模塊所調用的模塊，而不是軟件產品的組成的部分。
增量測試--
1. 非增量測試所需的工作量要多一些。
2. 如果使用了增量測試，可以較早地發現模塊中與不匹配接口、不正確假設 相關的編程錯誤。
3. 因此如果使用了增量測試，調試會進行得容易一些。
4. 增量測試會將測試進行得更徹底。
5. 非增量測試所佔用的機器時間顯得少一些。
6. 模塊測試階段開始時，如果使用的是非增量測試，就會有更多的機會進行 並行操作（也就是說，所有的模塊可以同時測試）。
三、更高級測試：功能測試、系統測試、驗收測試、安裝測試
軟件開發流程：
、
舉例來說：
• 模塊測試的目的是發現程序模塊與其接口規格說明之間的不一致。
• 功能測試的目的是爲了證明程序未能符合其外部規格說明。
• 系統測試的目的是爲了證明軟件產品與其初始目標不一致。
在 這裏忽略了集成測試，因爲集成測試往往並不作爲一個獨立的測試步驟，而且在進 行增量模塊測試時，它是模塊測試的隱含部分。
總結：模塊測試主要是代碼層的白盒測試；功能測試主要是類似測試各部件功能是否與外部規格說明一致而採用的黑盒測試；系統測試主要是針對整個系統性能的測試，如強度測試與容量測試。驗收測試是驗收方處理的，安裝測試主要是測試安裝方面的功能。
四、調試：暴力法、歸納法、演繹法、回溯法、測試法
簡單地講，調試是執行一次成功的測試之後所要進行的工作。記住，所謂成功 的測試，是指它可以證明程序沒有實現預期的功能。調試是一個包含兩個步驟的過 程，從執行了一個成功的測試用例、發現了一個問題之後開始。第一步，確定程序 中可疑錯誤的準確性質和位置；第二步，修改錯誤。
五、極限測試
極限編程（XP，Extreme Programming），XP 到目前爲止還是最流行的敏捷軟件開發過程。測試在 XP 中的地位如此重要，以至於需要首先創建單元（模塊）測試和驗收測試， 然後才創建代碼庫。這種形式的測試被稱爲極限測試（XT，Extreme Testing）。
極限測試主要由兩種類型的測試組成：單元測試和 驗收測試。
XP 開發模型用 12 個核心實踐來驅動該過程。表 8-l 總結了這些實踐。簡單來 說．這 12 個核心的 XP 實踐可以歸納爲 4 個概念： 1. 聆聽客戶和其他程序員的談話。
2. 與客戶合作，開發應用程序的規格說明和測試用例。
3. 結對編碼。
4. 測試代碼庫。
常見詞彙表
