1.用例評審的目的

1. 為了減少測試人員執(zhí)行階段做無效工作，執(zhí)行無效case，提交無效缺陷（可以友情提醒研發(fā)同學，講到自己負責的相關模塊時，注意下是否存在異議點）
2. 為了避免三方（產品、研發(fā)、測試）需求理解不一致；
3. 為了每個測試人員的質量標準與項目要求標準達成一致。

2.評審前的準備工作

2.1用例編寫

1. 需求評審結束后，可以把需求拆分為功能點?。

測試點梳理時，要關注橫向邏輯，即功能點本身，更要關注縱向邏輯，即業(yè)務流。

• 工具：建議用XMind
• 優(yōu)點：用畫思維導圖的方式，邏輯清楚，便于評審人員（產品和開發(fā)人員）快速查看，評審效率高。

具體用什么工具方法，大家可依個人喜好和項目需要而定，不過目標都是讓用例評審高效快捷的開展，并產生價值。

2.把功能點分解為具體的測試用例?。

• 需在思維導圖上補全明確的操作步驟、預期結果；執(zhí)行階段可以追加實際測試結果，便于測試結果跟進。
• 用XMind寫思維導圖的方式設計用例更便捷，思維導圖層級可以按照用例模板進行定義，方便用例評審結束后導出excel備份。

3.用例自檢

• 整體把控用例組成，讓評審講解更清晰、有序
• 針對有疑問的點羅列出來，可事先跟產品、開發(fā)討論，確定結果后完善用例
• 討論后仍有疑問的可先做標記，評審會上拋出一起討論。
• 標注重點：【未在需求文檔中明確描述&在設計測試用例過程中已同產品確認】，需要在用例評審中著重提醒開發(fā)，保持信息同步。
  • 需求疑問：在經過產品確認后，輸出具體測試用例，記得同步給研發(fā)
  • 設計交互：未提供交互，需求文檔未描述的功能的實際交互細節(jié)，提出討論

4.提前發(fā)出用例

• 和評審人員（開發(fā)和產品）確定好具體的評審時間并提前把測試用例發(fā)給參會人員查看。

2.2用例評審通知

1. 用例評審參加人員

• 主要是產品、開發(fā)（客戶端和后端）、測試、項目負責人、運營（如性能測試的評審）。

2.約定用例評審時間、評審方式

• 評審時間：根據(jù)實際情況提前約定
• 評審方式：會議（具體的會議室或線上會議）、郵件等

3.評審時長

• 對于敏捷開發(fā)項目，建議控制在半小時以內。
• 如果項目需求復雜，功能點太多，建議：
  • 對功能點劃分優(yōu)先級，優(yōu)先評審優(yōu)先級高的用例
  • 再針對疑問多的用例評審
  • 最后對于功能簡單的用例可簡單帶過。

3.正式評審

3.1評審形式

3.1.1逐條評審

對照測試用例，從上而下，從左到右，逐條念

傳統(tǒng)評審方式的特點：

• 費時，不分主次，參會人員的熱情與注意力逐漸降低
• 整個用例評審效率低，往往講的口干舌燥，達到的效果卻是事倍功半。

相信有過這種評審經歷的同學，一定不喜歡這種方式，因為它流于形式，整個評審過程隨著時間的推移，大家互動熱情逐漸降低，往往效果不及預期。

現(xiàn)狀是業(yè)務流程較為繁長的測試用例條數(shù)較多，少則上百，多則上千，逐一講解，不論是對開發(fā)或產品，甚至測試本身，都會出現(xiàn)前后文銜接不上。本著最重要的事最先做的原則，我們對用例評審形式作出如下改進：

3.1.2邏輯概述+核心評審

“全局流程+局部細節(jié)”的方式評審測試用例，先對核心流程、功能復雜，優(yōu)先級高，疑問多的用例進行評審，再評審功能簡單，優(yōu)先級低的功能點。

• 全局流程-邏輯概述
  • 借助“Xmind”思維導圖，進行簡要的邏輯概述，闡述用例描述的基礎流程。該階段描述后，經產品和開發(fā)確認無疑問，則進行用例評審時，可略過該部分的基礎測試用例。

比如，某某系統(tǒng)要實現(xiàn)什么功能，具體包含模塊1、模塊2、模塊...，涉及的業(yè)務流程和數(shù)據(jù)交互有1...2...3...，是用例的評審重點，等下我們優(yōu)先評審。同時我在用例設計時主要包括了哪些場景，具體有頁面展示的校驗、功能按鈕實現(xiàn)的校驗、頁面元素必填項校驗、字符類型校驗、字符長度校驗、異常場景校驗等。（具體的頁面元素、字符類型、字符長度、異常場景可以粗略帶過）

• 局部細節(jié)-突出核心細節(jié)用例
  • 除了基礎業(yè)務流程外的，一些特殊場景細節(jié)的測試用例，可能影響業(yè)務流程或對公司造成損失，使用加粗/顏色標注，在用例評審時著重提醒開發(fā)。

?????????比如某系統(tǒng)的內容引用功能，被引用內容下線，對內容會產生不良的影響，這種容錯性的處理邏輯的校驗；

改進后的評審方式特點：

• 測試人員要全局了解項目目標、業(yè)務流程（想得明白才能講得明白，可以促進測試同學多多思考）
• 評審剛開始時，大家注意力集中，參與激情高，討論有難度、有疑問的問題，效率高。
• 整個評審會主次分明，有高潮有緩點，可以更高效的達到我們評審的目的。

3.2評審原則

• 評審要按用例的優(yōu)先級，核心業(yè)務流優(yōu)先、再按功能的復雜程度進行；
• 評審過程中盡量做到，思路清晰，用最簡潔的語言闡述每一個功能點；
• 超過5分鐘無法確定結果的問題留作會后討論跟進。

（正式評審過程中需要注意幾個細節(jié)，如果你都做到了，相信整個評審會是非常成功的，有成就感的。）文章來源地址http://www.zghlxwxcb.cn/news/detail-687441.html

4.評審結束后需要做些什么事？

• 總結用例評審會議紀要，包含需要作出的修改點、未確認的項和對應責任人、是否有需求變更或延期情況等
  • 用例評審會議紀要需同步給項目組其他成員，做好信息共享。
• 整理補充測試用例，把修正的內容重新整理補全。
  • 編寫用例修改記錄（如修正了哪些功能點，補全了哪些？等），修改后的用例重新發(fā)出供大家評審
• 會上未確定的內容，會后繼續(xù)跟進，直到確定結果。