測試分類詳解

測試分類

一、按測試對象分類

1. 界面測試

1.1 測試內容介紹
界面測試驗證用戶界面(UI)的視覺呈現和交互邏輯，確保符合設計規范并提供良好的用戶體驗。測試內容包括：

頁面布局和元素對齊
字體、顏色和圖標一致性
交互反饋（懸停、點擊狀態）
導航邏輯和流程
響應式設計（不同設備適配）

1.2 關鍵指標

設計規范符合度 ≥ 95%
操作路徑深度 ≤ 3步（核心功能）
元素響應時間 ≤ 300ms
無障礙標準（WCAG 2.1 AA級）

1.3 常見界面錯誤

文字重疊
截斷顯示
不合理換行
錯位元素
焦點丟失
狀態不一致
未對齊元素

2. 可靠性測試

2.1 可靠性概念

可靠性指系統在規定條件下和時間內，無故障執行所需功能的能力。反映軟件的健壯性和持續服務能力。

2.2 關鍵指標

可靠性等級	年故障時間	適用場景
99.9%（三個9）	≤8.76小時	普通應用
99.99%（四個9）	≤52.6分鐘	企業系統
99.999%（五個9）	≤5.26分鐘	金融/醫療

2.3 常見可靠性問題

服務不可用（HTTP 503）
數據損壞或丟失
事務處理中斷
資源耗盡導致的崩潰
級聯故障（一個組件故障引發系統崩潰）

3. 容錯性測試

驗證系統在異常輸入或故障環境下的自我恢復能力：

輸入容錯：非法字符、超長文本、空值提交
環境容錯：
- 硬件故障（磁盤滿、內存不足）
- 網絡中斷（丟包率>50%）
- 依賴服務不可用
恢復機制：
- 自動重試策略（如指數退避）
- 事務回滾能力
- 優雅降級方案

4. 文檔測試

國家有關計算機軟件產品開發文件編制指南中共有14 種文件，可分為3 大類。

開發文件：可行性研究報告、軟件需求說明書、數據要求說明書、概要設計說明書、詳細設計說明書、數據庫設計說明書、模塊開發卷宗。
用戶文件:用戶手冊、操作手冊，用戶文檔的作用：改善易安裝性；改善軟件的易學性與易用性；改善軟件可靠性；降低技術支持成本。
管理文件：項目開發計劃、測試計劃、測試分析報告、開發進度月報、項目開發總結報告。

在實際的測試中，最常見的是用戶文件的測試，例如：手冊說明書等。也會有一些公司對需求文檔進行測試，來保證需求文檔的質量。

測試要點：

步驟可執行性（按文檔操作能否達成目標）
術語一致性（與UI和代碼保持一致）
截圖與版本匹配
多語言翻譯準確性
搜索功能有效性（PDF/在線文檔）

5. 兼容性測試

跨維度兼容驗證矩陣：

維度	測試范圍	工具推薦
操作系統	Windows/macOS/Linux/iOS/Android	VirtualBox, Docker
瀏覽器	Chrome/Firefox/Safari/Edge	BrowserStack
分辨率	720P/1080P/4K/折疊屏	Viewport Resizer
外設	打印機/掃描儀/特殊輸入設備	Device Farmer
API版本	向后兼容3個歷史版本	Postman, Swagger

6. 易用性測試

基于尼爾森十大原則的驗證：

系統狀態可見性 → 進度指示器
系統與現實匹配 → 符合領域術語
用戶控制與自由 → 可撤銷操作
一致性與標準 → 統一交互模式
防錯設計 → 危險操作確認
識別優于回憶 → 可視化操作路徑
靈活高效 → 支持快捷鍵
美學與簡約 → 信息層級清晰
容錯與恢復 → 錯誤指導方案
幫助文檔 → 上下文敏感幫助

7. 安裝卸載測試

關鍵測試場景矩陣：

階段	Windows	macOS	Linux	Mobile
安裝	管理員/普通權限安裝	應用商店/直接安裝	源碼編譯/包管理器	應用商店/側載
升級	增量更新/覆蓋安裝	版本兼容升級	依賴沖突解決	熱更新/強更
卸載	控制面板卸載殘留檢測	AppCleaner驗證	包管理器卸載驗證	清除用戶數據
回滾	版本回退功能	TimeMachine恢復	快照還原	歷史版本安裝

8. 安全測試

OWASP Top 10 2023核心測試點：

注入攻擊
認證失效
敏感數據泄露
XXE漏洞
訪問控制缺陷
安全配置錯誤
XSS攻擊
反序列化漏洞
組件已知漏洞
日志監控缺失

滲透測試工具鏈：

偵察階段：Nmap, Shodan
漏洞掃描：OWASP ZAP, Nessus
滲透利用：Burp Suite, Metasploit
后滲透：Cobalt Strike, Mimikatz

9. 性能測試

分層性能指標：

層級	關鍵指標	測試工具
前端	FCP/LCP/FID/CLS	Lighthouse
接口	TPS/響應時間P99/錯誤率	JMeter, Locust
服務器	CPU/內存/磁盤IO/網絡吞吐	Prometheus, Grafana
數據庫	查詢耗時/鎖等待/連接池	SQL Profiler
全鏈路	端到端延遲/事務成功率	SkyWalking

性能反模式檢測：

循環內數據庫查詢
未分頁的大數據加載
同步阻塞調用
緩存穿透/雪崩
線程死鎖

10. 內存泄漏測試

內存泄漏檢測方法論：

內存泄漏典型場景：

未釋放資源：數據庫連接、文件句柄
監聽器未注銷：事件總線訂閱
靜態集合膨脹：緩存無淘汰策略
線程局部變量：未清理的ThreadLocal
第三方庫缺陷：Native代碼泄漏

排查黃金法則：

監控內存趨勢（持續增長即泄漏）
對比GC前后內存快照
定位支配樹(Dominator Tree)中的異常對象
檢查引用鏈(Reference Chain)中的非預期持有者

二、按是否查看代碼分類

1. 黑盒測試

1.1 測試方法概覽

等價類劃分
邊界值分析
因果圖/正交判定表
正交測試法
場景設計法
錯誤猜測法

1.2 黑盒測試優缺點總結

優點	缺點
? 無需了解內部實現細節	? 無法覆蓋所有代碼路徑
? 貼近用戶實際使用場景	? 可能遺漏邊界條件組合
? 早期即可開展測試	? 測試用例設計依賴需求質量
? 適合功能驗證	? 難以檢測深層次邏輯錯誤

2. 白盒測試

2.1 語句覆蓋（Statement Coverage）

定義：確保程序中的每條可執行語句至少被執行一次

測試用例設計：

# 示例函數
def login(username, password):if username == "admin":  # 語句1print("管理員登錄")   # 語句2else:print("普通用戶登錄") # 語句3return True              # 語句4# 滿足語句覆蓋的用例
test_case1 = ("admin", "123456")  # 覆蓋語句1,2,4
test_case2 = ("user", "password") # 覆蓋語句1,3,4

覆蓋能力：?

缺陷檢測：無法發現條件分支中的邏輯錯誤

2.2 判定覆蓋（Decision Coverage）

定義：每個邏輯判斷的真假分支至少執行一次

測試用例設計：

# 示例函數
def check_discount(amount, is_vip):if amount > 100 and is_vip:  # 判定點return 0.8return 1.0# 滿足判定覆蓋的用例
test_case1 = (150, True)   # 真分支
test_case2 = (50, False)   # 假分支

覆蓋能力：??

局限：無法檢測條件內部的錯誤（如 amount > 100 寫成 amount >= 100）

2.3 條件覆蓋（Condition Coverage）

定義：每個子條件的真假取值至少出現一次

測試用例設計：

# 示例函數
def grant_access(age, has_permission):if age >= 18 and has_permission:  # 條件1: age>=18, 條件2: has_permissionreturn Truereturn False# 條件覆蓋用例
test_case1 = (20, True)   # 條件1真, 條件2真
test_case2 = (15, False)  # 條件1假, 條件2假

覆蓋能力：???

特點：比判定覆蓋更細致，但可能遺漏判定組合

2.4 判定-條件覆蓋（Condition/Decision Coverage）

定義：同時滿足判定覆蓋和條件覆蓋

測試用例設計：

# 接上例
test_case1 = (20, True)   # 真分支, 條件1真, 條件2真
test_case2 = (15, True)   # 假分支, 條件1假, 條件2真 → 覆蓋假分支
test_case3 = (20, False)  # 假分支, 條件1真, 條件2假 → 覆蓋假分支

覆蓋能力：????

價值：平衡了判定和條件的驗證深度

2.5 條件組合覆蓋（Multiple Condition Coverage）

定義：所有條件取值的可能組合都被覆蓋

測試用例設計：

# 兩個條件，需4種組合
test_case1 = (20, True)   # 條件1真, 條件2真 → 真分支
test_case2 = (20, False)  # 條件1真, 條件2假 → 假分支
test_case3 = (15, True)   # 條件1假, 條件2真 → 假分支
test_case4 = (15, False)  # 條件1假, 條件2假 → 假分支

覆蓋能力：?????

代價：條件數n → 組合數2^n（指數級增長）

2.6 路徑覆蓋（Path Coverage）

定義：覆蓋程序中所有可能的執行路徑

測試用例設計：

def process_order(status, amount):if status == "PAID":          # 分支1if amount > 1000:         # 分支2print("大額訂單審核")else:print("訂單直接發貨")else:print("等待付款")# 路徑覆蓋用例
test_case1 = ("PAID", 1500)  # 路徑：分支1真→分支2真
test_case2 = ("PAID", 500)   # 路徑：分支1真→分支2假
test_case3 = ("UNPAID", 0)   # 路徑：分支1假

覆蓋能力：?????

挑戰：循環結構可能導致路徑無限（需設置最大迭代）

2.7 白盒測試優缺點總結

優點	缺點
? 高代碼覆蓋率（可達100%）	? 需要編程能力和源碼訪問權限
? 發現深層次邏輯錯誤	? 測試成本高（設計/維護）
? 適合關鍵模塊測試	? 可能產生"過度測試"
? 支持自動化測試	? 無法檢測遺漏功能

3. 灰盒測試

3.1 典型應用場景

API測試：基于接口文檔設計用例 + 監控代碼執行路徑
性能優化：負載測試（黑盒） + 代碼熱點分析（白盒）
滲透測試：模擬攻擊（黑盒） + 漏洞源碼定位（白盒）

3.2 灰盒測試優缺點總結

優勢	挑戰
? 兼顧內外視角	? 需要跨領域技能
? 高效定位缺陷根源	? 測試設計復雜度高
? 適合微服務架構	? 工具鏈整合成本
? 優化測試資源分配	? 可能遺漏純黑盒場景

三、按開發階段分類

1. 單元測試

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

測試階段：編碼后或者編碼前（TDD）
測試對象：最小模塊
測試人員：白盒測試工程師或開發工程師
測試依據：代碼和注釋+詳細設計文檔
測試方法：白盒測試
測試內容：模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試

2. 集成測試

集成測試也稱聯合測試（聯調）、組裝測試，將程序模塊采用適當的集成策略組裝起來，對系統的接口及集成后的功能進行正確性檢測的測試工作。集成主要目的是檢查軟件單位之間的接口是否正確。

測試階段：一般單元測試之后進行
測試對象：模塊間的接口
測試人員：白盒測試工程師或開發工程師
測試依據：單元測試的模塊+概要設計文檔
測試方法：黑盒測試與白盒測試相結合
測試內容：模塊之間數據傳輸、模塊之間功能沖突、模塊組裝功能正確性、全局數據結構、單模塊缺陷對系統的影響

3. 系統測試

將軟件系統看成是一個系統的測試。包括對功能、性能以及軟件所運行的軟硬件環境進行測試。

測試階段：集成測試通過后
測試對象：完整可交付系統
測試人員：專業測試團隊
測試依據：需求規格說明書(SRS)
測試方法：黑盒測試為主
環境要求：功能、界面、可靠性、易用性、性能、兼容性、安全性等

4. 回歸測試

回歸測試是指修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。

5. 冒煙測試

冒煙測試的對象是每一個新編譯的需要正式測試的軟件版本，目的是確認軟件主要功能和核心流程正常，在正式進行系統測試之前執行。冒煙測試一般在開發人員開發完畢后提交給測試人員來進行測試時，先進行冒煙測試，保證基本功能正常，不阻礙后續的測試。

如果冒煙測試通過，則測試人員開始進行正式的系統測試，如果不通過，則測試人員可以讓開發人員重新修復代碼直到冒煙測試通過，再開始進行系統測試。

回歸測試和冒煙測試都屬于系統測試

6. 驗收測試

驗收測試是部署軟件之前的最后一個測試操作。它是技術測試的最后一個階段，也稱為交付測試。驗收測試的目的是確保軟件準備就緒，按照項目合同、任務書、雙方約定的驗收依據文檔，向軟件購買都展示該軟件系統滿足原始需求。

測試階段：系統測試通過之后
測試對象：整個系統（包括軟硬件）。
測試人員：主要是最終用戶或者需求方。
測試依據：用戶需求、驗收標準
測試方法：黑盒測試
測試內容：同系統測試(功能…各類文檔等)

四、按實施組織分類

1. Alpha測試

2. Beta測試

類型	執行者	典型活動
Alpha測試	內部用戶	受控環境模擬操作
Beta測試	外部公測用戶	真實環境收集反饋
UAT(用戶驗收測試)	真實客戶	生產環境驗證業務流程
合同驗收測試	客戶+供應商	SLA(服務等級協議)驗證