測試用例及黑盒測試方法

一、測試用例

1.1 基本要素

測試用例（Test Case）是為了實施測試而向被測試的系統提供的一組集合，這組集合包含：測試環境、操作步驟、測試數據、預期結果等4個主要要素。

1.1.1 測試環境

定義：測試執行所需的軟硬件配置、網絡條件、依賴服務等。
示例：
- Web 端：Chrome 瀏覽器 v115 + Windows 11 + 網絡帶寬 100Mbps
- 移動端：iPhone 14 Pro (iOS 16.5) + 4G 網絡
- 服務端：CentOS 7.9 + JDK 11 + MySQL 8.0
關鍵點：
- 明確區分測試環境類型（開發環境、測試環境、預發布環境）。
- 記錄第三方依賴（如支付接口的沙箱環境）。

1.1.2 操作步驟

定義：測試執行的詳細流程，需清晰、無歧義，確保不同測試人員執行結果一致。

示例：

1. 打開應用，點擊【登錄】按鈕。
2. 輸入用戶名 `test_user` 和密碼 `Test@123`。
3. 勾選【記住密碼】，點擊【提交】。

關鍵點：
- 步驟編號化，避免復雜長句。
- 包含前置條件（如“已注冊賬號”）和后置操作（如“清理測試數據”）。

1.1.3 測試數據

定義：測試過程中使用的輸入數據，需覆蓋有效、無效、邊界值等場景。
示例：

測試場景測試數據
有效用戶名 user_123（長度 8）
無效用戶名 admin#（含特殊字符）
邊界值用戶名 a（長度 1）
關鍵點：
- 數據需獨立維護（如通過 CSV 文件或數據庫管理），便于復用和維護。
- 敏感數據脫敏處理（如密碼用 **** 替代明文）。

測試場景	測試數據
有效用戶名	`user_123`（長度 8）
無效用戶名	`admin#`（含特殊字符）
邊界值用戶名	`a`（長度 1）

1.1.4 預期結果

定義：每個步驟執行后系統應有的正確響應，需唯一且可驗證。
示例：
- 界面響應：跳轉至首頁，顯示歡迎語“Hello, test_user”。
- 數據驗證：數據庫的 user 表中新增一條狀態為“激活”的記錄。
- 性能指標：接口響應時間 ≤ 500ms。
關鍵點：
- 避免模糊描述（如“系統正常運行”）。
- 結合自動化校驗點（如斷言數據庫字段值）。

1.2 評價標準

1.2.1 用例表達清晰，無二義性

問題案例：輸入錯誤密碼，檢查系統是否提示錯誤。
改進后：輸入密碼“123”，點擊登錄，頁面彈出提示框“密碼長度需為6-20位”。
關鍵點：
- 使用具體數值而非“錯誤值”等模糊描述。
- 明確界面元素名稱（如按鈕 ID 或文案）。

1.2.2 用例可操作性強

反例：測試支付功能是否能正常扣款（缺少步驟和驗證點）。

正例：

1. 在訂單頁選擇【支付寶支付】，點擊【立即付款】。
2. 在支付寶沙箱環境輸入賬號 `test@alipay.com` 和密碼 `123456`。
3. 預期結果：- 頁面跳轉至“支付成功”頁。- 訂單狀態更新為“已支付”。- 支付寶賬單中顯示扣款金額 100 元。

1.2.3 輸入與輸出明確

常見問題：一條用例包含多個預期結果（如“登錄成功并跳轉首頁”）。
改進方案：
- 拆分用例：TC-001 驗證登錄成功 + TC-002 驗證登錄后跳轉邏輯。
- 使用自動化腳本分離校驗點。

1.2.4 用例可維護性好

實踐建議：
- 模塊化設計：按功能模塊管理用例（如“登錄模塊”、“支付模塊”）。
- 參數化數據：將易變數據（如 URL、賬號）提取為配置文件。
- 版本關聯：用例與需求 ID 或用戶故事綁定，便于變更追蹤。

1.2.5 需求覆蓋率高

實現方法：
1. 需求拆解：將用戶需求轉化為功能點（如“支持用戶名登錄”）。
2. 映射矩陣：建立需求-用例追蹤表，確保每個需求有對應測試用例。
  
  需求 ID 需求描述關聯用例覆蓋類型
  REQ-001 用戶名長度為6-15 TC-001 ~ TC-005 功能+邊界值

需求 ID	需求描述	關聯用例	覆蓋類型
REQ-001	用戶名長度為6-15	TC-001 ~ TC-005	功能+邊界值

1.3 好處

測試用例是自動化測試的基礎

1.3.1 提高測試效率

新版本迭代時，通過歷史用例快速執行回歸測試，減少漏測風險。
利用用例步驟直接生成自動化腳本（如 Selenium 或 Postman 集合）。

1.3.2 促進團隊協作

開發人員參考測試用例理解需求驗收標準。
新人通過用例快速熟悉系統功能。

1.3.3 降低溝通成本

缺陷報告中引用用例 ID，精準定位問題場景（如“TC-005 中實際結果與預期不符”）。

二、測試用例的設計方法

2.1 基于需求設計測試用例

2.1.1 功能需求測試分析

需求規格說明書、UI設計稿、測試人員經驗

1. 業務流程測試設計：

步驟：
1. 根據需求規格說明書繪制流程圖（如泳道圖、活動圖）。
2. 識別關鍵節點（如提交訂單、支付、退款）。
3. 覆蓋正向流程和異常分支（如庫存不足、支付超時）。

示例（電商下單流程）：

正向流程：瀏覽商品 → 加入購物車 → 填寫地址 → 支付 → 訂單完成  
異常分支：  - 支付失敗 → 訂單狀態置為“待支付”  - 地址未填寫 → 彈窗提示“請填寫收貨地址”

2. UI測試設計要點：

布局驗證：
- 控件對齊方式（如左對齊、居中）。
- 響應式設計（不同屏幕分辨率下的顯示效果）。
交互細節：
- 焦點跳轉邏輯（如按 Tab 鍵切換輸入框順序）。
- 錯誤提示的即時性和明確性（如實時校驗密碼強度）。

3. 用戶體驗（易用性）測試：

測試點：
- 快捷鍵支持（如 Ctrl+C/V 復制粘貼）。
- 頁面加載時的加載動畫（避免用戶誤以為卡頓）。

2.1.2 非功能需求測試分析

1. 兼容性測試：

瀏覽器兼容性：
- 內核差異：Chrome（Blink）、Firefox（Gecko）、Safari（WebKit）。
- 測試工具：BrowserStack、Selenium Grid。
移動端兼容性：
- 分辨率適配：iPhone 14 Pro Max（2796×1290） vs. 折疊屏（2208×1768）。
- 操作系統版本：Android 13 權限控制 vs. iOS 16 隱私標簽。

2. 性能測試（補充指標）：

前端性能：
- 首屏加載時間 ≤ 2秒（Web 端）。
- FPS（幀率） ≥ 60（移動端動畫流暢度）。
后端性能：
- 接口 99% 請求響應時間 ≤ 1秒（P99 指標）。
- 每秒事務數（TPS） ≥ 1000（高并發場景）。

3. 安全測試（滲透測試補充）：

OWASP Top 10 覆蓋：
- SQL 注入：' OR 1=1 -- 攻擊防御。
- XSS 攻擊：輸入 <script>alert(1)</script> 檢測過濾機制。
敏感數據保護：
- 日志中禁止記錄明文密碼。
- HTTPS 傳輸加密（TLS 1.3 協議）。

4. 網絡測試（弱網模擬工具）：

工具：Charles 網絡限速、Android Emulator 網絡模擬。
測試場景：
- 100% 丟包率下，檢查本地緩存是否生效。
- 2G 網絡（50kbps）下，圖片懶加載功能是否正常。

2.2 黑盒設計方法

2.2.1 等價類

又分成有效等價類和無效等價類。

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

有效等價類：對于程序的規格說明書是合理的、有意義的輸入數據構成的集合，利用有效等價類驗證程序是否實現了規格說明中所規定的功能和性能。

無效等價類：根據需求說明書，不滿足需求的集合。

1. 等價類劃分的完整步驟

步驟	說明	示例（用戶名規則：6-15位字母，不區分大小寫）
1. 分析需求，確定輸入域	明確輸入參數的類型、范圍和約束條件。	輸入類型：字符串；長度范圍：6-15位；字符類型：僅A-Z/a-z。
2. 劃分有效等價類	識別符合需求的有效輸入組合。	- 有效字符：`A-Z`或`a-z` - 有效長度：6位、10位、15位。
3. 劃分無效等價類	識別所有可能違反需求的無效輸入類型。	- 無效字符：數字、特殊字符、空格、中文等 - 無效長度：5位、16位、空字符串。
4. 設計測試用例	每個等價類選取至少1個代表值生成用例。	有效用例：`"TestUser"`（8位字母）無效用例：`"User123"`（含數字）、`"Admin#"`（含特殊字符）。
5. 補充邊界值用例	結合邊界值分析法覆蓋臨界場景。	長度邊界：`"Abcdef"`（6位）、`"A...z"`（15位）。

2. 常見錯誤與改進方案

錯誤類型	問題案例	改進方案
等價類遺漏	僅測試字母和數字，忽略特殊字符。	窮舉所有無效類型：數字、符號、空格、Emoji、SQL語句等。
用例冗余	對同一等價類多次測試（如測試多個特殊字符）。	每個等價類僅保留1個典型用例（如 `"User@"` 代表所有特殊字符）。
組合缺失	未覆蓋等價類組合（如無效字符+超長長度）。	結合正交法或判定表設計組合用例（如 `"Admin@1234567890"` 含特殊字符且超長）。

3. 等價類組合策略

場景：注冊功能需驗證用戶名和密碼規則

用戶名規則：6-15位字母。
密碼規則：8-20位，必須包含字母和數字。

字段	有效等價類	無效等價類
用戶名	`"TestUser"`	`"User123"`（數字）
密碼	`"Pass1234"`	`"password"`（無數字）

組合測試設計：

有效組合：有效用戶名 + 有效密碼 → 注冊成功。
無效組合：
- 無效用戶名 + 有效密碼 → 提示用戶名錯誤。
- 有效用戶名 + 無效密碼 → 提示密碼格式錯誤。

4. 輸出等價類設計（擴展場景）

需求：根據分數返回評級（A: ≥90，B: 70-89，C: <70）

輸出等價類	分數范圍	測試數據	預期結果
有效輸出A	90-100	95	評級A
有效輸出B	70-89	85	評級B
有效輸出C	0-69	60	評級C
無效輸出	<0或>100	-5, 105	提示錯誤

5. 實戰案例：郵箱格式驗證

需求：郵箱格式需滿足 xxx@yyy.zzz，其中：

xxx：1-64位字母/數字/點/下劃線。
yyy：1-255位字母/數字/連字符。
zzz：2-6位字母。

輸入域	有效等價類	無效等價類	測試用例示例
用戶名	`"user.name_123"`	`"user@#"`（含非法字符）	`"test@example.com"`
域名	`"example-123"`	`"exa_mple"`（含下劃線）	`"user@exa_mple.com"`
頂級域名	`".com"`（2位）	`".a"`（1位）、`".abcdefg"`（7位）	`"user@domain.a"`

2.2.2 邊界值

通常邊界值分析法是作為對等價類劃分法的補充。

1. 邊界值分析的核心概念

概念	定義	示例（用戶名長度規則：6-15位）
上點	輸入域的邊界值（即有效與無效的分界點）	6位、15位
內點	輸入域內任意一個有效值（通常取中間值）	10位
離點	距離上點最近且不屬于有效范圍的無效值（閉區間與開區間規則不同）	5位（閉區間左離點）、16位（閉區間右離點）

2. 不同區間類型的離點選擇規則

區間類型	上點選擇	離點選擇規則（以區間 [a, b] 為例）	示例（取值范圍）	離點計算
閉區間 [a, b]	a、b	離點為 a-1 和 b+1，域外	[6, 15]	5、16
開區間 (a, b)	a、b	離點為 a+1 和 b-1，域內	(6, 15)	7、14
半開半閉區間	根據開閉方向調整	如 [a, b)：離點為 a-1 和 b-1	[6, 15)	5、14

3. 邊界值分析的完整步驟

步驟	操作說明	用戶名長度示例（[6, 15]位）
1. 確定輸入域邊界	明確需求中數值、長度、時間等范圍的上下限。	最小長度6位，最大長度15位
2. 識別上點、內點、離點	按區間類型計算三類點。	上點：6、15；內點：10；離點：5、16
3. 設計測試用例	每個邊界點至少生成1個用例，覆蓋有效和無效場景。	有效用例：6位、10位、15位；無效用例：5位、16位
4. 擴展多字段組合	若存在多個輸入字段，需覆蓋邊界值的組合（如用戶名長度+字符類型邊界）。	用例：6位純字母（有效） vs. 6位含數字（無效）

4. 復雜場景下的邊界值設計

場景1：時間范圍邊界（跨天/跨月）

需求：允許選擇2023-01-01至2023-12-31的日期。
邊界用例：
- 上點：2023-01-01、2023-12-31
- 離點：2022-12-31、2024-01-01

場景2：多字段聯合邊界（折扣計算）

需求：訂單金額 ≥100元且商品數量 ≥3件，可享受9折。
邊界用例：
- 金額99元 + 數量3件 → 無折扣
- 金額100元 + 數量2件 → 無折扣
- 金額100元 + 數量3件 → 折扣生效

5. 常見錯誤與改進方案

錯誤類型	問題案例	改進方案
遺漏邊界類型	僅測試數值邊界，忽略字符串空值。	窮舉所有邊界類型（空值、超長文本、特殊字符）。
錯誤計算離點	對開區間 (6,15) 測試5位和16位。	嚴格按區間類型選擇離點（開區間離點為6和15）。
忽略多字段組合邊界	單獨測試長度和字符，未組合驗證。	使用正交法生成組合用例（如6位+特殊字符）。

6. 邊界值分析工具

工具示例：Boundary Value Checker

輸入規則：定義字段類型、范圍、步長（如數值型字段范圍[1-100]，步長1）。
自動生成：工具輸出所有上點、離點和內點用例。
輸出示例：

字段測試數據類型
年齡 0 離點
年齡 1 上點
年齡 50 內點
年齡 100 上點
年齡 101 離點

字段	測試數據	類型
年齡	0	離點
年齡	1	上點
年齡	50	內點
年齡	100	上點
年齡	101	離點

7. 邊界值與等價類法的結合策略

先用等價類劃分輸入域：將用戶名輸入分為有效字母、無效字符等等價類。
對每個等價類應用邊界值：在字符類型有效等價類中，測試長度邊界（如6位字母、15位字母）。
生成綜合用例：

等價類邊界值用例預期結果
有效字母 6位字母（“Abcdef”）注冊成功
無效特殊字符 6位含@符號（“User@@”）提示“含非法字符”

等價類	邊界值用例	預期結果
有效字母	6位字母（“Abcdef”）	注冊成功
無效特殊字符	6位含@符號（“User@@”）	提示“含非法字符”

8. 邊界值分析法局限性

不覆蓋組合缺陷：無法發現多個字段非邊界值組合引發的問題（需結合判定表）。
不適用于連續型數據：如浮點數邊界（需額外考慮精度問題，如0.999999≈1.0）。

2.2.3 因果圖/判定表

因果圖與判定表是處理 多條件邏輯組合 場景的核心方法，尤其適用于規則復雜的業務邏輯（如促銷活動、權限控制）。

1. 因果圖/判定表完整流程

步驟1：識別輸入（因）與輸出（果）

輸入（條件樁）：所有可能影響結果的獨立條件。
輸出（動作樁）：系統應有的響應或動作。

示例（618購物優惠規則）：“618購物活動，訂單已提交，訂單合計金額大于300元或有紅包，則優惠”。

輸入：訂單已提交、金額>300元、有紅包。
輸出：享受優惠。

步驟2：構建因果圖（邏輯關系可視化）

基本邏輯符號：
- 恒等（→）：條件為真 → 結果為真
- 非（?）：條件為假 → 結果為真
- 或（∨）：任一條件為真 → 結果為真
- 與（∧）：所有條件為真 → 結果為真

618購物優惠因果圖：

訂單已提交 ∧ (金額>300 ∨ 有紅包) → 享受優惠

步驟3：轉換為判定表（窮舉所有規則）

條件組合數：n 個條件 → 2^n 種組合（需合并無效場景）。
618購物案例判定表：

條件樁	規則1	規則2	規則3	規則4	規則5	規則6	規則7	規則8
訂單已提交	Y	Y	Y	Y	N	N	N	N
金額 >300元	Y	Y	N	N	Y	Y	N	N
有紅包	Y	N	Y	N	Y	N	Y	N
動作樁
享受優惠	Y	Y	Y	N	N	N	N	N

合并簡化規則：

規則1-3：訂單已提交且（金額>300 或有紅包）→ 享受優惠。
規則4-8：訂單未提交或金額≤300且無紅包 → 不享受優惠。

步驟4：生成測試用例

用例ID	訂單狀態	金額	紅包	預期結果
TC1	已提交	400元	有	享受優惠
TC2	已提交	400元	無	享受優惠
TC3	已提交	200元	有	享受優惠
TC4	已提交	200元	無	不享受優惠
TC5	未提交	400元	有	不享受優惠

2. 判定表設計技巧

技巧1：條件優先級與默認值

條件優先級：某些條件可能覆蓋其他條件（如“管理員權限”優先于普通用戶）。
默認值標記：用 - 表示條件無關（減少冗余組合）。

示例（權限系統）：

條件樁	規則1	規則2	規則3
是管理員	Y	N	N
有訪問權限	-	Y	N
動作樁
允許訪問	Y	Y	N

技巧2：合并重復動作

動作合并：不同條件組合導致相同結果時，合并規則。
示例（合并購物規則4-8）：

條件樁有效規則無效規則
訂單已提交 Y N
金額>300 或有紅包 Y N
享受優惠 Y N

條件樁	有效規則	無效規則
訂單已提交	Y	N
金額>300 或有紅包	Y	N
享受優惠	Y	N

技巧3：處理多結果場景

示例（登錄功能）：

條件樁	規則1	規則2	規則3
用戶名有效	Y	Y	N
密碼有效	Y	N	-
動作樁
跳轉首頁	Y	N	N
提示密碼錯誤	N	Y	N
提示用戶名不存在	N	N	Y

3. 常見錯誤與改進方案

錯誤類型	問題案例	改進方案
條件遺漏	未考慮“訂單已提交”狀態導致錯誤優惠。	需求分析階段識別所有顯性和隱性條件。
動作歧義	多個動作同時觸發但未定義優先級（如彈窗沖突）。	明確動作執行順序（如先校驗再提交）。
規則冗余	重復測試相同邏輯組合（如規則1和規則2完全相同）。	合并相同輸出的規則。

4. 工具輔助設計

在線判定表生成器：
輸入條件和動作，自動生成所有組合（如 Decision Table Tester）。
Excel 公式：
使用條件公式（如 IF(AND(A2="Y", OR(B2="Y", C2="Y")), "Y", "N")）快速填充判定表。

2.2.4 正交表

正交排列法（Orthogonal Array Testing）是高效覆蓋多參數組合的核心技術，特別適合參數多但組合爆炸的場景。

以下以用戶注冊功能為案例進行講解，考慮以下5個因素（用戶名、郵箱、密碼、確認密碼、驗證碼）

1. 正交表核心概念

術語	定義	示例（用戶注冊功能）
因素	測試中需要驗證的獨立變量	用戶名、密碼、驗證碼
水平	每個因素可能的取值	填寫/不填寫
正交表	滿足"任意兩列組合均衡"的特殊矩陣	$L_4(2^3)$
行數(N)	測試用例數量（最少組合數）	4行
因素數?	變量個數	5（用戶名、郵箱、密碼、確認密碼、驗證碼）
水平數(T)	每個變量的取值數量	2（填寫/不填寫）

2. 正交表表示法

通用格式： $L_N(T^C)$

3. 正交表設計五步法

步驟1：需求分析 → 提取因素和水平

因素：- 用戶名：填寫/不填寫- 郵箱：填寫/不填寫- 密碼：填寫/不填寫- 確認密碼：填寫/不填寫- 驗證碼：填寫/不填寫

步驟2：選擇正交表

選擇原則：
正交表列數 ≥ 實際因素數 正交表必須能容納所有因素
正交表水平數 ≥ 因素水平數 水平數需匹配或可映射
最小化行數 在滿足組合均衡前提下選最小N
對于 $C$ 個因素 且每個因素有 $T$ 個水平 的場景，完整約束為
- $\begin{cases} N \geq 1 + C(T-1) & \text{（最小行數約束）} \\ N \equiv 0 \pmod{\lambda} & \text{（組合均衡約束）} \end{cases}$
- $\lambda$ 為均衡系數：二水平時 $\lambda=4$
本案例： $T=2,\ C=5$
- $1 + 5 \times (2 ? 1) = 6$
- 但 $\not\equiv 0 \pmod{4}$ → 無解
- 最小滿足 $\equiv 0 \pmod{4}$ 且 $N > 6$ → $N = 8$
? 正確結論： $L_8(2^7)$ 是數學約束下的唯一可行解

正交表列數 ≥ 實際因素數	正交表必須能容納所有因素
正交表水平數 ≥ 因素水平數	水平數需匹配或可映射
最小化行數	在滿足組合均衡前提下選最小N

步驟3：因素映射到列

列號	1	2	3	4	5	6	7
因素	姓名	郵箱	密碼	確認	驗證	(空)	(空)

步驟4：填充水平值

用例	姓名	郵箱	密碼	確認密碼	驗證碼
1	1	1	1	1	1
2	1	1	1	2	2
3	1	2	2	1	2
4	1	2	2	2	1
5	2	1	2	2	1
6	2	1	2	1	2
7	2	2	1	2	2
8	2	2	1	1	1

水平映射：1：填寫；2：未填寫

步驟5：轉換為可執行用例

用例	姓名	郵箱	密碼	確認密碼	驗證碼	預期結果
TC1	填寫	填寫	填寫	填寫	填寫	注冊成功
TC2	填寫	填寫	填寫	不填寫	不填寫	提示"確認密碼未填寫"
TC3	填寫	不填寫	不填寫	填寫	不填寫	提示"郵箱未填寫"
…	…	…	…	…	…	…

4. 正交法優勢與局限

優勢	局限
? 用例數從 $2^5=32$ 減至8（-75%）	? 不覆蓋三三組合缺陷
? 保證所有兩兩組合被覆蓋	? 水平數不同時需特殊處理
? 適合配置項、兼容性測試等場景	? 業務邏輯復雜時需結合判定表

2.3 萬能測試用例模板

功能測試
- 核心流程驗證：登錄/支付/提交等關鍵路徑
- 異常處理：空輸入、重復提交、非法操作
- 數據一致性： DB字段校驗、狀態同步
- 邊界值覆蓋：數值、長度、時間臨界點
性能測試
- 響應時間：單操作≤1s，復雜操作≤3s
- 并發能力：最大用戶數、TPS閾值
- 資源消耗： CPU≤80%、內存≤90%
- 穩定性：持續運行12小時無故障
界面測試
- 布局規范：間距對齊、字體統一
- 交互反饋：加載動畫、錯誤提示
- 響應式：手機/平板/PC自適應
- 視覺驗收：顏色對比度≥4.5:1
兼容性測試
- 瀏覽器： Chrome/Firefox/Safari/Edge
- 操作系統： Win11/macOS Ventura/Ubuntu 22.04
- 移動端： iOS 16+/Android 13+主流機型
- 分辨率： 720P/1080P/2K/4K/折疊屏
易用性測試
- 操作路徑：核心功能≤3步完成
- 指引設計：新手指引/空白頁提示
- 快捷鍵： Ctrl+S保存/Enter提交
- 文案清晰：錯誤提示含解決方案
網絡測試
- 弱網模擬： 3G(500kbps)/高延遲(500ms)，比如高延遲+低帶寬 → 模擬偏遠地區；低延遲+高丟包 → 模擬地鐵場景
- 斷網恢復：自動重連/數據同步
- 協議驗證： HTTPS/TLS1.3加密
- 流量優化：圖片懶加載/API合并
安全測試
- 注入攻擊： SQL/XSS/命令注入
- 權限控制：越權訪問/垂直權限
- 數據安全：密碼加密/日志脫敏
- 漏洞掃描： OWASP Top 10覆蓋