3.需求分析與測試用例設計方法

設計方法

測試點

定義: 測試時需要考慮的可測試方面，不同公司可能稱為"檢查點"或其它名稱
特點: 是需求分析的最后一個環節，用于解決"測哪里"和"怎么測"的問題
舉例說明: 如同打架時的各種招數，如直接約架、設陷阱或雇人打群架，每種方法對應一個測試點
與用例關系: 簡單的功能（如"退出"按鈕）可直接從測試點轉化為用例（如"點擊退出看軟件能否退出"）

場景法概述

核心作用: 主要用于測試系統的業務流程，驗證主要功能是否正確實現
測試時機: 拿到測試任務時應首先關注業務流程驗證
與其他方法關系: 區別于大綱法的功能拆分作用，屬于用例設計方法
方法分類: 屬于黑盒測試方法，與等價類、邊界值、決策表等方法并列

場景的定義
基本概念: 描述軟件操作的路徑（先干什么再干什么）
組成要素:
基本流: 正確的業務流程構成的操作路徑（模擬正確操作）
備選流: 導致程序出錯的操作流程（模擬錯誤操作）
應用特點: 與業務流程分析相似但不完全相同，更側重操作路徑的模擬
4. 場景法的分析步驟
第一步: 分析軟件需求，從用戶角度梳理業務流程和業務規則
第二步: 編寫基本流場景（正確流程）和備選流場景（錯誤流程）
實施要點: 需同時考慮正向和反向測試路徑，覆蓋正常和異常操作
方法論定位: 屬于用例設計的大方向規劃，不過多涉及細節實現

場景法的分析步驟

分析軟件需求: 首先，需要全面分析軟件的需求，明確軟件要實現的業務流程和業務規則。這是場景法分析的第一步，也是非常重要的一步，因為后續的所有步驟都基于這一步的理解。
寫出業務流程和業務規則: 從用戶使用情景的角度出發，詳細寫出軟件的業務流程和業務規則。這有助于我們更深入地理解軟件的使用場景，為后續的測試設計打下基礎。
寫出基本流場景和備選流場景: 在明確了業務流程和業務規則后，我們需要寫出基本流場景和備選流場景。基本流場景是軟件在正常情況下的操作流程，而備選流場景則是軟件在異常情況或特殊情況下的操作流程。通過這一步，我們可以更全面地覆蓋軟件的測試點，提高測試的質量。

描述程序的基本流及備選流

流程步驟：
- 插入銀行卡：客戶將銀行卡插入ATM機的讀卡器
- 驗證銀行卡：ATM機從銀行卡的磁條中讀取賬戶代碼，檢查是否屬于可接受的銀行卡
- 輸入密碼：ATM機要求客戶輸入密碼
- 驗證密碼：系統驗證密碼是否正確
- 進入主界面：ATM顯示可用操作選項
- 選擇取款：客戶選擇"取款"功能并輸入金額
- 系統驗證：檢查賬戶余額是否充足、總取款金額是否超限、ATM機現金是否足夠
- 完成交易：驗證通過后更新賬戶余額，出鈔并提示用戶取款
關鍵特征：
- 只包含正常操作路徑，不考慮任何異常情況
- 每個步驟都假設輸入正確且系統狀態正常
- 流程設計應聚焦軟件相關操作，排除無關行為（如"步行找ATM機"）

備選流

錯誤類型及處理：
- 銀行卡無效：系統提示錯誤信息并退卡
- 密碼錯誤：
  - 1-2次錯誤：提示重新輸入
  - 3次錯誤：直接吞卡（需單獨列為不同備選流）
- 賬戶余額不足：提示錯誤并退卡
- 超額取款：當日取款總額超限時提示錯誤并退卡
- ATM現金不足：提示錯誤并退卡
設計要點：
- 每個異常情況應作為獨立備選流處理
- 相同錯誤類型但處理方式不同（如密碼錯誤次數）需區分
- 結果描述應具體明確（如"吞卡"與"退卡"的區別）

根據基本流和備選流生成不同的場景

場景生成原則：通過分析基本流（正確流程）和備選流（錯誤流程）來構建測試場景，正確情況通常只有一種，而錯誤情況可能有多種
表格使用說明：場景分析表格可記錄在測試需求分析說明書中作為測試點，表格形式不重要，重點在于明確場景條件和預期結果
有效標識含義：表格中的"V"代表valid（有效），表示該條件需滿足正確值，但非必須標注項

場景法練習

三角形類別判斷

1. 例題

1）題目描述

題目: 輸入三個數，判斷它們能否構成三角形，以及若能構成，則進一步判斷是什么類型的三角形。

2）題目解析

審題過程:
- 首先，檢查輸入的三個數是否均為0-1000的實數。
- 然后，判斷三邊之和是否大于第三邊，若不滿足，則不能構成三角形。
- 接著，判斷三邊是否都相等，若是，則為等邊三角形。
- 再判斷兩邊是否相等，若是，則為等腰三角形。
- 判斷兩邊平方和是否等于第三邊平方，若是，則為直角三角形。
- 若以上條件都不滿足，則為普通三角形。
易錯點:
- 輸入數據不完整或不是實數時，需要提示必須輸入實數。
- 輸入范圍超過0-1000，或小數位數超過三位時，需要報錯。
- 注意區分不同類型的三角形判斷條件。

等價類劃分法

等價類劃分核心思想

代表選擇原理：類似于人民代表大會制度，將輸入數據劃分為若干區域后，每個區域選取代表性數據，該數據能等價代表該區域所有數據。
分類基礎：根據需求分析將輸入域劃分為有效等價類（符合需求規范）和無效等價類（違反需求規范）。
測試效率提升：通過代表數據減少測試用例數量，解決窮盡測試不可行的問題，如兩位數加法器中測試負99到99的范圍時無需測試所有值。

等價類劃分的步驟

第一步需求分析：明確被測對象的功能需求，如兩位數加法器要求輸入范圍為?99-99?99到999999的整數。
第二步初步分類：
- 有效等價類：符合輸入要求的數據（如000、505050）
- 無效等價類：超出范圍或格式錯誤的數據（如?100-100?100、100.5100.5100.5）
第三步細化分類：結合計算機知識進一步細分，例如：
- 邊界值附近單獨分類（?99-99?99、999999）
- 特殊字符輸入單獨分類（如"ab"）
代表值選取原則：每個等價類中選取最能體現該類特征的數據，如無效類中選取?100-100?100代表"小于?99-99?99"的無效情況。

等價類劃分練習

需求講解

核心需求：ATM取款功能測試，要求單筆取款金額最少50元，最多5000元，且必須是50的倍數
特殊說明：案例假設不考慮日累計限額（如現實中的2000元限制），僅測試單筆交易場景。

有效等價類劃分
唯一有效類：金額在區間內且為50的倍數的數值（如50、100、4950、5000）
測試要點：只需設計1個測試用例即可覆蓋全部有效情況，例如測試取款2500元
3. 無效等價類劃分
數值范圍違規：
小于下限：的值（如0、49）
大于上限：的值（如5001、10000）
倍數違規：非50倍數的數值（如51、4999）
特殊輸入：
空輸入（直接點擊取款）
字符輸入（需確認ATM鍵盤是否存在字母鍵）
設備適配原則：若實際ATM鍵盤無字母鍵，則字符輸入類可不測試

等價類劃分注意事項

考慮有效和無效等價類

測試方向：
- 正向測試（有效等價類）：驗證功能正常工作情況
- 負向測試（無效等價類）：驗證異常處理能力
數量比例：無效類用例通常遠多于有效類，比例可能達1:8甚至更高
術語對照：
- 有效等價類 ≈ 正向用例 ≈ 順向測試
- 無效等價類 ≈ 負向用例 ≈ 逆向測試

2. 注意劃分的粗細

過粗風險：
- 將本應分開的類合并（如將空輸入和字符輸入合并）
- 導致測試遺漏（如漏測邊界值4999）
過細風險：
- 過度拆分同類項（如分別測試大寫A和小寫a）
- 產生冗余測試（如測試200后又測試300）
實踐建議：
- 初學者宜稍細劃分，避免遺漏缺陷
- 經驗積累后可優化分類粒度
審查要點：需檢查劃分是否覆蓋所有需求約束條件（范圍、倍數、輸入類型等）

例題:等價類劃分法應用

有效等價類：輸入長度為4-10位字符
無效等價類：
- 長度小于4位
- 長度大于10位
劃分依據：根據輸入長度要求直接劃分，保持每個等價類內部具有相同測試特性

布爾類型等價類劃分

有效等價類：
- true（注意大小寫要求）
- false（注意大小寫要求）
無效等價類：除true/false外的所有輸入
注意事項：
- 需確認編程語言對大小寫的敏感性
- 若要求大寫，則有效類應調整為TRUE/FALSE
- 無效類可適當擴充包含大小寫混合情況

例題:組合框等價類劃分

有效等價類：
- 從下拉列表選擇現有字體
- 手動輸入存在的字體名稱
無效等價類：輸入不存在的字體名稱
測試要點：組合框同時支持選擇和輸入的特性需要分別驗證

例題:用戶名規范等價類劃分 02:40

有效等價類：
- 純字母組合（長度≤12）
- 字母開頭+數字組合（長度≤12）
無效等價類：
- 數字開頭
- 長度>12
- 空輸入（長度=0）
- 包含特殊字符
復雜需求分析：
- 必須字母開頭是核心約束條件
- 長度限制和字符類型限制需要組合驗證
- 可合并有效類為"字母開頭+字母數字組合"

例題:日期文本框等價類劃分

有效等價類（假設需求）：
- 當前/將來日期+"/"分隔符
- 當前/將來日期+"-"分隔符
- 當前/將來日期+無分隔符
無效等價類：
- 過去日期（范圍錯誤）
- 錯誤分隔符（如空格、字母）
- 日期順序錯誤（如月日年）
- 包含非數字字符
- 包含不允許的標點（如點號）
- 非法日期值（如2月30日）
- 世紀數省略（如18代替2018）
測試設計技巧：
- 需明確日期格式要求（年月日/月日年）
- 考慮不同地區的日期表示習慣
- 邊界值需結合等價類共同使用
- 無效類可衍生多種測試用例

邊界值分析法

標題字數： 0 1 40 41

標題字數 0 40 41 -1不具有可測性！

文本輸入域 0 1 255 256

分頁，首頁點上一頁，尾頁點上一頁，進行邊界值測試

決策表

輸入組合盲區：等價類劃分、邊界值等傳統測試方法未考慮輸入參數的組合情況，例如第一個數輸入正數、第二個數輸入負數的組合場景。

決策表練習

輸入輸出分析：
- 輸入1：工資制（年薪/月薪）
- 輸入2：錯誤類型（4種情況）
- 輸出：扣款比例（計算結果）
必須窮舉所有可能組合（年薪×4種錯誤情況 + 月薪×4種錯誤情況）
- 年薪制組合：
  - 不犯錯誤：0%
  - 僅普通：2%
  - 僅嚴重：6%
  - 兩種都犯：8%（2%+6%）
- 月薪制組合：
  - 不犯錯誤：0%
  - 僅普通：4%
  - 僅嚴重：8%
  - 兩種都犯：12%（4%+8%）

決策表適用范圍

決策表一般適用于多種輸入存在組合的情況。當存在多個輸入，且這些輸入之間有各種組合情況時，適合使用決策表。

局限性: 決策表可能導致用例數量爆炸。因為每個輸入可能有多種情況，當輸入數量增多時，組合情況會呈指數級增長，導致用例數量龐大。

實現均勻覆蓋策略

無效等價類應用

需求分析的步驟

收集文檔: 需求分析的第一步是收集相關的文檔資料。
研讀文檔: 在收集完文檔后，需要仔細研讀這些文檔，理解其中的內容和要求。
提出問題: 在研讀文檔的過程中，會產生很多疑問或不明確的地方，需要將這些問題提出來。
整理信息: 將提出的問題以及從文檔中獲取的信息進行整理，以便后續使用。
功能拆分: 將軟件需要實現的所有功能進行拆分，包括大功能和小功能。
信息合并: 將之前整理的信息與功能拆分的結果進行合并，形成完整的需求理解。
編寫測試點: 根據需求理解，編寫測試點，用于后續的測試工作。測試點可以綜合使用場景法、等價類邊界值、決策表和錯誤猜測等方法進行編寫。
需求評審: 需求分析的最后一步是進行評審，確保需求理解的準確性和完整性。

需求評審的質量要求

正確性: 需求必須與用戶說法一致，確保沒有錯誤的需求描述。
完備性: 需求必須完整無遺漏，避免出現需求缺失的情況。
易理解性: 需求文檔要讓其他部門和測試人員都能輕松理解，表述必須清晰明確。
一致性: 需求前后描述要一致，不同部門間的理解也要保持一致，避免出現矛盾。
可行性: 需求必須實際可行，如測試資源不足時要及時調整需求（例如公司只有一個路由器時不應影響正常業務）。
可修改性: 需求之間應保持適當關聯，修改一個需求時不應導致其他需求大面積受影響。
可測試性: 每個測試點都必須具備可執行性，這是最基本的要求。
可追溯性: 所有需求和測試點都要有明確依據，不能憑空猜測或不合情理。

測試計劃

測試計劃的定義與原則

文檔性質: 測試計劃是指導測試過程的綱領性文檔，用于統一團隊認識并規劃測試過程
核心功能: 規定測試范圍、途徑、資源和進度安排，確認測試項、被測特征、測試任務、人員安排及風險預案
IEEE定義: 敘述預定測試活動的范圍、途徑、資源及進度安排的文檔（1983年標準）
實際作用: 避免測試工作無序進行，明確各階段任務（如需求分析時長、測試順序等）

測試計劃的編寫原則

明確測試的目標，增強測試計劃的實用性
核心原則：測試計劃不是形式文檔，而是后續測試工作的指導依據，必須注重實際可操作性
指導性：測試工作的每一步都將按照計劃執行，因此計劃內容必須清晰明確
目標導向：需要清楚界定測試的具體要求和預期目標

堅持"5W"規則，明確內容與過程

What(內容)：明確測試范圍，如測試登錄功能還是注冊功能
Why(目標)：確定測試類型，如功能測試、性能測試或可用性測試
When(時機)：既指測試進度安排，也包含測試環境等前提條件準備
Where(環境)：詳細說明所需的硬件、軟件配置要求
How(方法)：規定測試采用的技術方法，如黑盒/白盒測試
Who(人員)：可額外增加的人員安排說明，實際工作中常與When合并考慮

測試計劃的主要內容

確定測試資源: 明確所需的人力資源、硬件資源和軟件資源。
工作量估算、里程碑和進度安排: 評估測試工作量，設定關鍵節點和整體時間表。
風險分析: 識別測試過程中可能遇到的風險，并制定相應的應對措施。
制定測試策略: 根據測試需求和目標，選擇合適的測試方法和技術。
編寫計劃書: 將上述內容整合成文檔，作為測試工作的指導和依據。

風險識別

風險評估和風險控制

測試策略

測試策略定義: 測試策略是描述當前測試項目的目標，以及所采用的測試方法。它宏觀地概述了測試的內容、方法、階段和類型。
包含內容:
- 測試目標和方法。
- 規定時間內要完成的測試內容。
- 軟件產品的特性或質量在哪些方面得到確認。
- 不同測試階段（單元測試、集成測試、系統測試）的測試對象、范圍和方法。
- 每個階段內所要進行的測試類型（功能測試、性能測試、壓力測試等）。

分階段的測試策略

分階段策略: 將測試分為多個階段，如單元測試、集成測試、系統測試等。
單元測試: 早期發現問題，保證代碼質量。
集成測試: 盡早地發現更多問題，準備自動化測試的BVT（Build Verification Test）。
系統測試: 驗證整個軟件系統的功能和性能。
優點: 能夠在早期發現問題，減少后期修復成本。
BVT（Build Verification Test）:
- 目的: 驗證最新軟件版本的功能是否完整，主要軟件特性是否正確實現。
- 優點: 時間短，快速反饋問題。
- 缺點: 覆蓋率較低，不能替代全面的測試。
不能忽略的測試: 安全性測試、可用性測試、配置測試和數據完整性測試。
制定更為詳細的UAT（用戶驗收測試）計劃
UAT測試計劃:
與測試腳本和培訓材料一起提供給用戶。
幫助用戶快速提高并完成任務。
包含內容:
詳細的測試步驟。
用戶驗收的標準和流程。
培訓材料和用戶指導。