一、測試用例的設計方法

1.基於需求的設計方法(總體設計方法)：使測試更加有效，因為她使測試專注於質量問題產生的根源。

基於需求的測試的關注點：1) 驗證需求是否正確，完整，沒有二義性，並且邏輯一致。

                                            2) 設計出充分必要的測試集，以保證設計和程式碼都能完全符合需求。

2.具體的設計方法

1) 等價類：依據需求將輸入劃分成若干個等價類。從等價類中選出一個測試時用例，如果這個測試用例通過，則認為所代表的這個等價類測試通過。

有效等價類：對於程式的規格說明書是合理的，有意義的輸入資料構成的集合。

無效等價類

2) 邊界值：對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為等價類劃分的補充。

 例如：[ 1，50 ]   0，1, 50, 51

            （1, 50 ]   1, 2, 50 ,51

            ( 1 , 50 )    1, 2, 49, 50

3) 因果圖 ：一種簡化了的邏輯圖，能直觀地表明程式輸入條件(原因)和輸出動作(結果) 之間的相互關係。特別適用於被測試程式具有多種輸入條件，程式的輸出又依賴於輸入條件的各種情況 。

3.正交排列

1)概念：是一種基於正交表的，高效的，快速，經濟的試驗。

2)目的：減少測試用例數目，用盡量少的用例覆蓋輸入的兩兩組合。

3) 因素(Factor):再一項試驗中，凡是要考察的變數。

4) 水平（位級）（level）:在試驗範圍內，因素被考察的值（變數的取值）

正交表的構成 ：

行數（Runs）:正交表中行的個數，即試驗的次數，用N代表。

因素數(Factors)：正交表中列的個數，用C代表。

水平數：任何單個因素能夠取得的值得最大個數。用T代表 。

正交表的兩條性質：

每一列中 各數字出現的次數一樣多。

任何兩列中構成的各列各有序數對出現的次數一樣多。

正交法設計測試用例的步驟：

(1)有哪些因素（變數 ）

(2)每個因素有哪幾個水平（變數的取值）

(3)選擇一個合適的正交表

(4)把變數的值對映到表中

(5)把每一行的各因素水平組合作為一個測試用例

(6)加上自己認為可疑且沒有在表中 出現的用例組合。

4.場景分析法(業務流程)：用業務流程把各個孤立的功能點串起來，為測試人員簡歷整體業務感覺，從而避免陷入功能細節忽視業務流程要點的錯誤傾向。

5.錯誤猜想法：猜想的經驗可能來自於對某項業務的測試較多，也可能來自售後使用者的反饋意見，或者從管理庫中整理bug.

二、測試用例的粒度和評價

1.粒度：指測試用例編寫的詳細程度。

2.如何評價測試用例

1)同行評審

2)使用者檢查

3) 專案組評審

三、測試分類

1.按開發階段來分

1)單元測試：是對軟體組成單元進行測試，其目的是檢驗軟體基本組成單位的正確性。測試的物件是軟體設計的最小單位：模組

2)整合測試：將程式模組採用適當的整合策略組裝起來，對系統的藉口及整合後的功能進行正確性檢測的測試工作，繼承的主要目的是檢查軟體單元之間的介面是否正確。

3)系統測試：包括對功能、效能以及軟體所執行的軟硬體換將進行測試，時間大部分在系統測試執行階段，包括迴歸測試和冒煙測試。

   迴歸測試：指修改了舊程式碼後，重新進行測試以確定修改沒有引入新的錯誤或導致其他程式碼產生錯誤。

  冒煙測試：物件是每一個新編譯的需要正式測試的軟體版本，目的是確認軟體基本功能正常，可以進行後續的正式 測試工作。

                     冒煙測試的執行者是版本編譯人員。

   注意：冒煙測試---->系統測試--->迴歸測試

4) 驗收測試：是不輸入案件之前的最後一個測試操作。它是測試技術的最後一個階段。驗收測試的目的是確保軟體準備就緒，按照專案合同，任務書，雙方約定的驗收依據文件，向軟體購買者展示軟體系統滿足原始的需求。

2.按測試實施組織劃分

 1) α測試：是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際環境下進行的測試。

    α測試的目的：評價軟體產品的FLURPS(即功能、局域化、可使用性、可靠性、效能和支援)。 

 2) β測試：是一種驗收測試。β測試由軟體的終端使用者們在一個或多個場所進行。

    α測試和β測試的區別：

3) 第三方測試：軟體評測機構獨立的進行測試。

3.按測試物件劃分

1) 效能測試：檢查系統是否滿足需求規格說明書中規定的效能。

  2)安全測試：檢查該專案的安全性。

  3) 相容性測試：指軟體之間能否很好地運作，會不會有影響，軟硬體之間能否發揮很好的效率工作。

  4)文件測試：檢查文件的正確性，完整性，一致性，易用性。

  5) 易用性測試(使用者體驗測試)：是互動的適應性，功能性和有效性的集中體現。

  6) 業務測試：測試人員把系統各個模組串接起來，模擬真實使用者的工作流程，滿足使用者需求定義的功能來測試的過程。

  7)介面測試(UI測試)：佈局是否合理，風格是否一致，位置是否符合習慣，命名是否統一等。

  8) 安裝測試

   9)記憶體洩漏測試

4.按是否檢視程式碼劃分

1)黑盒測試：即功能測試。只關心它的功能，不關心它內部實現的邏輯程式碼。

     黑盒測試包括：等價類，因果圖，邊界值，猜錯法，隨機數法，測試用例覆蓋，輸入覆蓋，輸出覆蓋。

  2) 白盒測試：即結構測試。只關心它的程式碼實現邏輯，不關心它的功能。(測試程式碼)

介面測試是白盒測試的一種。

     白盒測試包括：語句覆蓋，判定覆蓋（分支覆蓋），條件覆蓋，判定/條件覆蓋，組合覆蓋，路徑覆蓋。

  3)灰盒測試：介於黑盒測試和白盒測試之間的一種測試方法。既關心輸入輸出的正確性，又關心程式內部的情況。

灰盒測試多用於整合測試階段。

5.按測試執行方式劃分

  1)靜態測試：不通過執行被測程式本身。僅通過分析或檢查源程式的語法、結構、過程、介面來檢查程式的正確性。

  2) 動態測試：通過執行被測程式。檢查執行結果與預期結果的差異，並分析執行效率、正確性和健壯性。

6.按是否手工執行劃分

   1) 手工測試：由人一個一個的輸入用例，然後觀察結果，和機器測試相對應，屬於比較原始但是必須的一個步驟。

   2) 自動化測試：把人為測試轉化為機器執行的一種過程。

    自動化實施步驟：
    ①完成功能測試，版本基本穩定。

    ②根據專案特性，選擇合適專案的自動化工具，並搭建環境。

    ③提取手工測試的測試用例轉化為自動化測試的用例。

    ④通過工具，程式碼實現自動化的構造輸入，自動檢測輸出結果是否符合預期結果。

    ⑤生成自動化測試報告。

    ⑥持續改進，指令碼優化。

7.按測試地域劃分

   1)本地測試

   2) 國際化測試

四 、測試管理

1.測試策略：測試的大體規劃。用什麼方法，什麼工具，什麼資源來測試什麼東西。

2.需求分析的注意事項：

  1) 測試應該儘早的介入

  2) 不斷變化的需求需要及時的收集和整理。

  3) 沒有需求文件時，需要測試人員不斷的收集原始的客戶需求。

  4) 應有質疑，堅持精神，當需求不明確時，我們可以將需求追溯到終端客戶。

3.需求分析的具體方法

 1) 快速理解需求的捷徑：需求串講(主要解決的問題：需求理解的不一致)

 2) 驗證需求  （需求文件也要測試：正確性、必要性、完整性、一致性）

 3)從設計需求中提取測試需求