一、評審概述
通常意義上的測試過程，是一個執行被測軟件的過程。但是隨着軟件測試行業的技術理念隨着時代越來越成熟，不執行被測系統的測試，即“靜態測試”開始受到更多的重視。
評審就是靜態測試的一種重要開展形式，也是“測試盡早介入”原則的最佳實踐方式之一。
在項目中常見可能采用的評審類型有：
- 非正式評審（伙伴檢查，交叉互查Cross Check）
- 走查（Walk-through）
- 技術評審（Technical Review）
- 審查（Inspection）
- 特別檢查（Ad-hoc Review）
- 審計（Audit）
- 管理評審（Management Review）
從被評審的對象上來說，需求評審，設計評審，用例評審等等，都是測試團隊應該參與評審的對象。進一步說，項目所有階段的產出，與測試工作開展相關，並且測試團隊具備評審能力的，都應該積極參加。測試管理人員應該將評審視作測試活動的重要組成部分。
評審是一種通過閱讀，分析和討論發現問題的活動。與動態測試即通常意義上所言的測試執行相比，評審可以幫助團隊從更上游的階段施加檢測，從而高效的發現和解決問題。從這個角度來說，評審又是一種預防措施。比如，如果在需求評審階段發現和解決了需求中的錯誤，那么則可以預防問題被帶入到后續研發階段，成本和投資回報上是一種非常有價值的活動。
評審的參與各方，可以划分為：
- 作者
- 評審員
- 協調者
- 主持人
- 記錄者
其中評審員負責做出具體評審，協調者則負責協調各方意見。
二、評審過程
在具體總結評審的標准流程之前，先來討論一下評審可能會出現的問題。
很多項目也會組織評審工作，但是往往得不到非常直觀的效果，究其原因問題可能會出現在以下方面：
- 問題1：沒有足夠的准備
臨時召開的評審會議，與會者對於評審內容和對象沒有充分的了解和准備。導致的結果是評審會議變成討論會議，收效不佳甚至為零。
- 問題2：偏離評審目標
由於評審目不明確，可能達不到理想效果。比如，評審者可能對於文檔格式等過於關注；又比如一個評審會議往往容易演變成技術討論和決策會議，甚至是吐槽大會。
- 問題3：沒有做好問題跟蹤
評審發現了問題，卻沒有后續的過程去追蹤和解決問題，導致評審失去意義。
- 問題4：評審沒有被納入計划
評審未被納入計划中，導致的問題就是所有評審的展開都將需要占用額外的時間。這屬於規划上的問題，一旦項目時間緊急的情況下，評審很有可能就要為其他的任務讓位。
- 問題5：評審參與度不足
也是常見的現象，評審的參與人員特別是開發人員，常常會以消極的態度看待評審，參與程度不高。
要避免這些問題的發生，那么一個正式評審過程，需要明確定義以下階段工作：
- 1.計划
- 2.啟動
- 3.個人評審
- 4.評審會議
- 5.返工
- 6.問題跟蹤
計划
正式的評審需要一整套過程的支持，所以需要提前做好計划。計划中需要明確的內容包括：評審采用的流程、評審的目標、時間場地安排、參與人員、角色分配等，對於更為正式的評審，可能還需要定義入口和出口准則（即開始、結束條件）。
啟動
完善的評審過程應該包括啟動階段，這個階段的意義在於做好被測對象（比如需求文檔）的分發到位，並明確評審的目標，可能情況下主持者還要解答與會人員的疑問。
個人評審
正式會議開始之前，需要留給與會人員時間，先行評審文檔，為評審會議做准備，並且標注和歸納自己發現的可能缺陷、問題和建議；
評審會議
評審會議上由評審的組織者主持對所有被指出的問題、疑問進行討論，討論的重心應該落腳於問題的確定以及影響程度的判斷，而非問題的解決方案。問題的解決應該是會后的工作。
會議應該目標於得出問題清單，以及問題的責任人、級別等。
返工階段
在評審會議中，我們得出問題清單以及相關信息匯總，這遠非評審的終結。既然知道了問題，那么接下來的工作一定是解決這些問題，這就是返工階段的意義。責任人需要在預設的時間周期內，完成問題的解決、修復。
追蹤階段
最后我們需要跟蹤問題的修復，並確定評審的工作已達結束標准。
如果對於被評對象具有比較多的疑慮，返工之后的二次甚至多次評審也是有可能的。
最后附上用例評審模板一份，以供參考：
鏈接：https://pan.baidu.com/s/1gcDSli4thx9cwLbsijKqHw
提取碼：2ri2