需求分析---瞭解熟悉業務，分析需求測試點

1. 確認功能(業務功能，輔助功能，資料約束，易用性需求，編輯約束，引數需求，許可權需求，效能約束）
2. 場景分析（考慮場景呼叫者和系統內部各個場景之間聯絡）
3. 挖掘隱性需求（常用業務流程以及各分支）

測試計劃

1. 編寫目的

• 此文件根據專案需求文件，制定測試策略、評估測試風險，確定所需的資源，並對測試的工作量進行估計，進行人員和進度安排，並且列出測試專案的可交付元素。

2. 參考文件

• 詳細設計文件，設計原型

3. 測試概要

1. 測試目標

通過測試，達到以下目標：

• 測試已實現的產品是否達到設計的要求，包括：各個功能點是否以實現，業務流程是否正確。
• 產品規定的操作和系統執行穩定。
  Bug數和缺陷率控制在可接收的範圍之內，遺留BUG一般不超過所有BUG的10%

2. 測試範圍

-列出測試最終需要交付的功能模組列表

3. 測試人力資源

4. 測試環境：伺服器環境，終端環境，網路環境

5. bug管理工具

4. 測試規範

• 開始測試標準：程式碼編譯通過，軟體可以爭取安裝執行，實現功能與產品設計出人，冒煙測試通過
• 中斷測試標準：安裝無法正確完成，程式程式碼編譯不通過，系統服務異常，發現阻塞功能的bug

5. bug規範

• 致命，嚴重，一般，建議

6. 測試策略

• 冒煙測試：依據開發提測時間變動
• 第一輪功能測試：執行測試用例，包括邊界值測試，相容性測試，易用性測試，使用者- - 介面測試，安全性測試
• 第二輪功能測試：bug複測及功能驗證
• 迴歸測試：全面迴歸測試
• 效能測試：需確認具體效能測試方案和工具
• 釋出測試
• 測試報告總結

7. 測試風險

• 測試本身（測試時間/測試技術/開發進度延誤/難以修復缺陷/其它原因）

8. 測試輸出文件

• 測試計劃
• 測試用例
• 測試bug單
• 測試報告

測試用例

測試需求分析和業務流程分析

1. 設計方法（重要）

等價類劃分法

依據需求將輸入（特殊情況下會考慮輸出）劃分為若干個等價類，從等價類中選出一個測試用例，如果這個測試用 例測試通過，則認為所代表的等價類測試通過，這樣就可以用較少的測試用例達到儘量多的功能覆蓋，解決了不能窮舉測試的問題。

有效等價類：符合規格說明，對程式來說有意義的資料集合。

無效等價類：不符合需求規格說明的。

舉個例子：輸入5-15個大寫字母

（將測試的範圍劃分成幾個互不相交的子集）
有效等價類：5-15個大寫字母
無效等價類：小於5或大於15的大寫字母、數字、特殊字元、小寫字母。

1. 原則：

2. 確定了輸入條件取值範圍或值的個數，可以劃分出1個有效等價類和2個無效等價類。
   例如：輸入學生成績，輸入域為[0,100]，有效等價類為[0,100]，無效等價類為(-∞，0)和(100,+∞)

3. 輸入條件規定了輸入值的集合，例如條件中規定了“必須如何”的絕對條件，可以確定1個有效等價類和1個對立無效等價類。
   例如：規定輸入為正整數，有效等價類為所有正整數，無效等價類為所有非正整數

4. 輸入條件的資料型別為布林型別，可以確定1個有效等價類和1個無效等價類，有效等價類為true，無效等價類為false。

5. 規定了輸入資料的一組值，假定n個，程式要對這n組值分別處理，可以劃分出n個有效等價類和1個無效等價類。
   例如：規定輸入資料只能為中文，英文或阿拉伯文，則這三種分別為3個有效等價類，除這3種以外的任何字元集合為1個無效等價類

6. 在規定了輸入資料必須遵守規則的情況下，可劃分出1個遵守規則的有效等價類和若干個從不同角度違反規則的無效等價類。

7. 若已劃分出的等價類中各元素在程式中的處理方式不同，則應再將該等價類進一步劃分為更小的等價類。

邊界值分析法

針對輸入輸出邊界值進行測試的一種黑盒測試方法。

通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。

舉個例子：

（選出的測試用例，應選取正好等於、剛剛大於、剛剛小於邊界的值）
1.輸入框長度為1-11：取邊界值：0，1，2，10，11，12
2.運動員的參賽專案為1-3項：取邊界值：0項，1項，2項，3項，4項

註冊郵箱的軟體需求為例子：

使用者名稱要求長度為6-15位
邊界值上的點：5，6，7，14，15，16
在實際的測試過程中，會將等價類和邊界值結合起來使用，所以最終確認的用例設計為：5，6，7，10，14，15，16

因果圖法

表示輸入和輸出關係的一種邏輯圖.使用場景：當需求有多個輸入時候，並且需求的輸出和輸入相關，我們就用因果圖法。

• 恆等：如果原因為真，那麼結果必定為真。
• 與：只有兩個原因都為真，結果才為真。
• 或：只要有一個原因為真，結果就為真。
• 非：原因為假，結果為真

因果圖設計測試用例的步驟：

• 分析所有輸入輸出的可能
• 找出輸入和輸出之間的對應關係
• 畫出因果圖
• 把因果圖轉為判定表
• 把判定表對應到每一個測試用例

判定表法（適合於邏輯判斷複雜的場景，通過窮舉條件獲得結果，對結果再進行優化合並，會得到一個判斷清晰的策略）

場景法

場景法多個功能點組合在一起形成事件流，根據不同的事件觸發，形成不同的場景。

銀行取款例子：

插卡–>輸入密碼–>輸入取款金額–>取款–>退卡
基本流：沒有異常事件發生的條件下的場景
備選流：發生異常情況下的場景
輸入錯誤密碼：第一次輸錯，第二次輸對。
第二次、第三次密碼都輸錯，吞卡，賬戶凍結。
當輸入金額大於銀行餘額，會提示“餘額不足”。
取款操作過慢，吞卡。

正交實驗法

   正交實驗設計是研究多因素多水平的一種設計方法。根據正交性，由試驗因素的全部水平組合中挑選出部分有代表性的點進行試驗，通過對這部分試驗結果的分析瞭解全面試驗的情況，找出最優的水平組合。

• 因素（Factor）：在一項試驗中，凡欲考察的變數稱為因素（變數 ）
• 水平（位級）（Level）：在試驗範圍內，因素被考察的值稱為水平（變數的取值 ）
• 因素數(Factors)：正交表中列的個數，用C代表。
• 水平數(Levels)：任何單個因素能夠取得的值的最大個數。
• 行數：L= N（CT）= （水平數 - 1）* 因素數 + 1。

正交法設計測試用例的步驟：（在各因素互相獨立的情況下，設計出一種特殊的表格，找出能以少數替代全面的測試用例）

• 有哪些因素（變數）
• 每個因素有哪幾個水平（變數的取值）
• 選擇一個合適的正交表
• 把變數的值對映到表中
• 把每一行的各因素水平的組合作為一個測試用例
• 加上你認為可疑且沒有在表中出現的用例組

以使用者用郵箱註冊為例子

1. 因素：姓名，郵箱，密碼，確認密碼，驗證碼
2. 水平：填寫，不填寫
3. 表中的因素數=5
   表中每個因素的水平數=2(填寫或不填寫)
   正交表的行數：((水平數-1)*因素數）+1
   正交表的列數：因素數

功能圖法

錯誤推測法

錯誤猜測法是經驗豐富的測試人員喜歡使用的一種測試方法。錯誤猜測法只適用於其他測試用例設計法，設計完測試用例之後，進行測試用例的補充。

（在測試程式時，人們可以根據經驗或直覺推測程式中可能存在的各種錯誤）

• 基於經驗和直覺，找出程式中你認為可能出現的錯誤，有針對性地設計測試用例。
• 經驗可能來自於在對某項業務的測試較多，也可以來自於售後使用者的反饋意見
• 從故障管理庫中整理bug。

經驗豐富的測試人員喜歡的一種測試方法
基於經驗和直覺，找出程式中可能出現的錯誤，有針對的設計測試用例

案例分析：

還是以註冊為例子，重點關注
①姓名中的特殊字元
②密碼校驗中的大小寫
③密碼傳送是否明文

還有其它測試大綱法和狀態遷移法等

2. 測試用例八要素：

• 用例編號，測試專案，測試標題，重要級別，預置條件，測試輸入，操作步驟，預期輸出

  1. 用例編號（規則：由字元和數字組成的字串，具有唯一性，易識別性）
  2. 測試專案（對應測試用例編號中的測試子項名 系統測試
  3. 測試標題（體現測試出發點關注點以及測試用例期盼的測試結果）
  4. 重要級別、優先級別（重要級別一般分為高中低 ）
  5. 預置條件：測試用例在執行時需要滿足一些前提條件，環境的設定
  6. 測試輸入（測試執行中需要加工的外部資訊，避免用描述性語言，要具體，根據測試用例具體情況，有手工輸入，檔案，資料庫記錄）
  7. 操作步驟：執行當前用例需要經過的操作步驟，需要明確的給出每一個步驟的描述
  8. 預期輸出：需要判斷測試物件是否正常工作

測試執行

1. 測試環境搭建

• 測試環境：硬體環境，軟體環境

• 硬體環境：測試必須的伺服器，客戶端，網路連線裝置，以及印表機/掃描器等輔助硬體裝置構成的環境

• 軟體環境：被測軟體執行的作業系統，資料庫以及其它應用軟體構成的環境

• 搭建測試環境的準備工作：

  • 安裝工具：虛擬機器
  • 虛擬機器優點：執行在主機上

2. 執行測試用例

• 根據測試用例優先順序來執行測試用例

3. 測試執行流程：

• 冒煙測試-迭代測試（先功能後效能，迴歸測試）-釋出測試
• 注：對應測試產出對應測試報告和bug清單，並將bug提到缺陷管理庫裡

測試文件

1. 測試報告

• 測試結論（是否達到釋出標準，是否可釋出）
• 已知風險、未知風險
• 測試時間，測試人員（測試起止時間）
• 測試環境，測試裝置（用到哪些測試收集，客戶端環境，瀏覽器）
• 需求大綱（當前這個版本，包含哪些需求點）
• Bug資料分析（從多個維度分析：bug等級分佈，遺留bug分析，bug型別分佈。模組bug分佈，bug啟用次數分析）
• 測試總結（從測試角度，對版本存在的問題，提出建議）

2. bug清單報告

• 分析統計bug迭代生命週期
• bug迭代修復情況（折線圖）
• 未關閉bug按嚴重等級或狀態統計（扇形圖）

另附：

最好配帶截圖圖片和log日誌

bug描述：（重要）

1. bug標題（問題描述）
2. bug測試環境（所屬版本，所屬模組）
3. bug優先順序
4. bug型別
5. 可重複性（是否好復現）
6. 操作步驟（通過對什麼樣的操作，進行了什麼 樣的步驟）
7. 預期結果
8. 實際結果