評審管理小結 - 附用例評審模板

1、評審概述

一般意義上的測試過程，是一個執行被測軟件的過程。可是隨着軟件測試行業的技術理念隨着時代愈來愈成熟，不執行被測系統的測試，即「靜態測試」開始受到更多的重視。

評審就是靜態測試的一種重要開展形式，也是「測試儘早介入」原則的最佳實踐方式之一。

在項目中常見可能採用的評審類型有：

• 非正式評審（夥伴檢查，交叉互查Cross Check）
• 走查（Walk-through）
• 技術評審（Technical Review）
• 審查（Inspection）
• 特別檢查（Ad-hoc Review）
• 審計（Audit）
• 管理評審（Management Review）

從被評審的對象上來講，需求評審，設計評審，用例評審等等，都是測試團隊應該參與評審的對象。進一步說，項目全部階段的產出，與測試工做開展相關，而且測試團隊具有評審能力的，都應該積極參加。測試管理人員應該將評審視做測試活動的重要組成部分。

評審是一種經過閱讀，分析和討論發現問題的活動。與動態測試即一般意義上所言的測試執行相比，評審能夠幫助團隊從更上游的階段施加檢測，從而高效的發現和解決問題。從這個角度來講，評審又是一種預防措施。好比，若是在需求評審階段發現和解決了需求中的錯誤，那麼則能夠預防問題被帶入到後續研發階段，成本和投資回報上是一種很是有價值的活動。
評審的參與各方，能夠劃分爲：

• 做者
• 評審員
• 協調者
• 主持人
• 記錄者

其中評審員負責作出具體評審，協調者則負責協調各方意見。

2、評審過程

在具體總結評審的標準流程以前，先來討論一下評審可能會出現的問題。

不少項目也會組織評審工做，可是每每得不到很是直觀的效果，究其緣由問題可能會出如今如下方面：

• 問題1：沒有足夠的準備

臨時召開的評審會議，與會者對於評審內容和對象沒有充分的瞭解和準備。致使的結果是評審會議變成討論會議，收效不佳甚至爲零。

• 問題2：偏離評審目標

因爲評審目不明確，可能達不到理想效果。好比，評審者可能對於文檔格式等過於關注；又好比一個評審會議每每容易演變成技術討論和決策會議，甚至是吐槽大會。

• 問題3：沒有作好問題跟蹤

評審發現了問題，卻沒有後續的過程去追蹤和解決問題，致使評審失去意義。

• 問題4：評審沒有被歸入計劃

評審未被歸入計劃中，致使的問題就是全部評審的展開都將須要佔用額外的時間。這屬於規劃上的問題，一旦項目時間緊急的狀況下，評審頗有可能就要爲其餘的任務讓位。

• 問題5：評審參與度不足

也是常見的現象，評審的參與人員特別是開發人員，經常會以消極的態度看待評審，參與程度不高。

要避免這些問題的發生，那麼一個正式評審過程，須要明肯定義如下階段工做：

• 1.計劃
• 2.啓動
• 3.我的評審
• 4.評審會議
• 5.返工
• 6.問題跟蹤

計劃

正式的評審須要一整套過程的支持，因此須要提早作好計劃。計劃中須要明確的內容包括：評審採用的流程、評審的目標、時間場地安排、參與人員、角色分配等，對於更爲正式的評審，可能還須要定義入口和出口準則（即開始、結束條件）。

啓動

完善的評審過程應該包括啓動階段，這個階段的意義在於作好被測對象（好比需求文檔）的分發到位，並明確評審的目標，可能狀況下主持者還要解答與會人員的疑問。

我的評審

正式會議開始以前，須要留給與會人員時間，先行評審文檔，爲評審會議作準備，而且標註和概括本身發現的可能缺陷、問題和建議；

評審會議

評審會議上由評審的組織者主持對全部被指出的問題、疑問進行討論，討論的重心應該落腳於問題的肯定以及影響程度的判斷，而非問題的解決方案。問題的解決應該是會後的工做。

會議應該目標於得出問題清單，以及問題的責任人、級別等。

返工階段

在評審會議中，咱們得出問題清單以及相關信息彙總，這遠非評審的終結。既然知道了問題，那麼接下來的工做必定是解決這些問題，這就是返工階段的意義。責任人須要在預設的時間週期內，完成問題的解決、修復。

追蹤階段

最後咱們須要跟蹤問題的修復，並肯定評審的工做已達結束標準。

若是對於被評對象具備比較多的疑慮，返工以後的二次甚至屢次評審也是有可能的。

最後附上用例評審模板一份，以供參考：
連接：https://pan.baidu.com/s/1gcDSli4thx9cwLbsijKqHw 提取碼：2ri2