阿里QA導讀：每一次提測就像一次質量問題的萬箭齊發，稍不留意，中個一兩箭算是小事，亂箭穿胸那也是經常的。如何做到無懈可擊，僅僅靠閃是不夠的。這個時候，測試分析，可以幫助你。通過對業務、經驗、質量的深度理解和分析，結合測試工具，可以讓你在這漫天箭雨中，有條有理，從容不迫，閑庭信步。
測試分析與設計
測試是一門精細的學科，新人同學很容易有的誤區是認為做測試主要就是編寫測試用例和執行測試用例，進階能力是寫自動化腳本或研發工具。而實際上，測試人員最難修煉的是測試分析能力，測試分析能力是衡量一位測試同學是否專業的分水嶺。分析除了使用方法，還需要有對業務、經驗、質量的深度理解。自動化或工具實際是對分析和設計結果的一種實現，分析和設計的有效會決定實現的效果。
分析與設計過程
測試分析要從業務需求最開始就要介入，流程覆蓋業務整個生命周期。在做分析的過程要想清楚，整體后續的設計怎么做。
測試分析可總結為四步：
-
建模 - 輸出業務/系統流程（分析：業務流程 - 系統流程）
-
設計 - 測試場景（設計：測試場景）
-
細分 - 測試用例/數據（設計：測試用例）
-
擴展 - 多類型測試（性能，安全，異常等等）（基於經驗）
測試場景分析實施
測試場景和測試用例區別是什么？為什么先要設計測試場景？
上圖也描述了，測試場景對應的是實際的業務場景，業務場景是業務流程中因不同的事件觸發后的業務情景。比如銀行取款的業務辦理流程，會因為用戶的身份（VIP與否）、取款金額（大額，小額）、卡內余額（足額取，不足額取）等諸多因素，導致最后取款的結果和過程分支產生不同。測試場景就是對這類事件觸發時的業務情景在質量角度的描述。而測試用例是對測試場景在測試范圍和測試點的詳細覆蓋。
第一步：根據業務的目標（價值）、類別、技術等輸入，確定業務場景分析的范圍。
業務分析就是需求分析的過程。這里不僅僅考慮需求的功能邏輯，還需要結合不同業務類型，根據歷史業務經驗沉淀和風險沉淀進行綜合考慮。可以參考用下圖進行前期梳理。
| 需求類型 | 資源&方法需求 | 必須覆蓋點 |
|---|---|---|
| 主業務類需求 | ||
| 技改類需求 | ||
| 全鏈路 | ||
| 外部商家需求 | ||
| 大促&BU核心項目 |
第二步：業務流程梳理（業務場景）
將需求說明轉化為業務流程，完成事件流（基本流+備選流）以及業務分析過程和技術分析過程的梳理。細化出原子級別的場景分支。
事件流： 同一事件不同的觸發順序和處理結果形成事件流，事件流分為基本流和備選流
-
基本流： 程序從開始執行直到成功結束所經過的最短路徑。
-
備選流： 一個備選流可能從基本流開始，在特定條件下執行，然后重新加入基本流中；也可起源於另一個備選流，執行后加入基本流或終止用例。根結點的備選流要具備原子性。
基本流和備選流：如下圖所示，圖中經過用例的每條路徑都用基本流和備選流來表示，直黑線表示基本流，是經過用例的最簡單的路徑。備選流用不同的色彩表示，一個備選流可能從基本流開始，在某個特定條件下執行，然后重新加入基本流中（如備選流2和4）；也可能起源於另一個備選流（如備選流4），或者終止用例而不再重新加入到某個流（如備選流1和3）。
實例：
第三步：場景串聯
通過第二步中拆解的場景，根據沉淀后的場景集，用組合，合並等方法梳理出所有的事件流。事件流必須100%覆蓋所有的基本流+備選流組合。
例：
測試用例設計
測試用例的設計很多時候是測試數據設計的過程，根據事件流（基本流+備選流）、數據和根據不同的角色，進行用例覆蓋。需要確保所有場景100%覆蓋。
例：
非功能性設計擴展
測試用例在設計上除了考慮功能性質量屬性，還需要對非功能性進行覆蓋，推薦一個四字法進行設計。
-
多：針對測試用例進行大數據量覆蓋測試
-
並：針對測試用例進行大數據量同時執行，驗證並發下的測試結果
-
復：重復的參數對同一用例進行執行測試。驗證冪等結果是否符合預期。
-
異：用非正常輸入值進行用例測試。驗證結果的正確性。
測試策略
策略其實考慮兩個問題，過程和方法：“測什么”，“怎么測”。
-
你的測試對象是什么？
-
本次測試的目標是什么？
-
測試中重點、難點、風險是什么？
-
測試要覆蓋的深度和廣度
-
如何安排各種測試計划（先測什么，再測什么，時間資源安排）
-
如何准出（測試結果）
測試策略可參考模版&樣例
1. 業務整體概述
1.1 業務背景
業務背景介紹若干字……
1.2 產品目標
產品目標介紹若干字……
1.3 架構目標
架構目標介紹若干字……
1.4 業務目標
業務目標介紹若干字……
2. 項目整體分析
2.1 功能性需求拆解
核心業務模塊介紹，復雜度，測試點分析對應列表（此步驟為關鍵分析步驟）。測試分析功能點，要從產品質量標准的角度思考，針對質量特性進行功能點覆蓋。
| 名稱 | 說明 | 使用場景 |
|---|---|---|
| 需求名稱1 | 需求說明1 | 使用場景1 |
| 需求名稱2 | 需求說明2 | 使用場景2 |
2.2 測試覆蓋范圍（涉及針對哪些質量要求的測試方法）
功能性、性能效率、兼容性、易用性、可靠性、安全性、易維護性、可移植性
| PRD需求 | 優先級 | 質量特性 | 測試覆蓋度評估（深度和廣度） | 負責測試人員 |
|---|---|---|---|---|
| 需求1 | P1 | 功能性 | 59 | xxx |
| 需求1 | P0 | 功能性，性能效率 | 33 | xxxx |
| 需求1 | P2 | 安全性，功能性 | 11 | yyyy |
2.3 測試對設計方案覆蓋范圍（根據開發設計文檔羅列）
| 序號 | 接口/設計名稱 | 接口描述 | 對應產品碼/功能描述 |
|---|---|---|---|
| 1 | com.xxx.api.getInfo | 拿到信息 | 用戶獲取信息 |
| 2 | com.xxx.api.getInfo | 拿到信息 | 用戶獲取信息 |
3. 業務流程分析
3.1 被測功能總體概述
介紹若干字……
3.2 整體業務流程
介紹若干字
3.3 業務模型圖
介紹若干字
3.4 風險分析
介紹若干字
4. 測試場景覆蓋范圍
4.1 測試場景
根據上一步的業務或者系統流程圖，完成測試用例場景的設計
4.2 測試用例設計（完善測試用例，補充測試數據）
根據測試場景細化測試用例，測試用例必須對測試場景和測試覆蓋范圍進行100%的覆蓋
4.3 測試數據要求
介紹若干
4.4 其他測試補充
介紹若干
5. 測試執行計划
這部分信息通常也會放在最前面。
5.1 人員組織
包括哪些人參與，測試邊界等
5.2 測試實施計划
包括提測時間，聯調時間等
5.3 交付計划
主要是里程碑和大的時間點
測試報告
測試報告
測試報告實際就是一個質量評估的過程。內容的關鍵在於表達清晰兩點：報告的對象是誰？報告的內容是什么？測試報告不是一個項目整體結束之后的產物，而是應該在項目整個生命周期隨時同步的。
測試報告至少需要包括的信息：
-
項目背景信息
-
項目人員
-
測試覆蓋度（需求、功能性、非功能性）
-
測試過程分析（執行情況）
-
缺陷分析
-
質量目標是否達到
-
遺留風險以及應對措施
- To Be Continued -
