一.
測試
評審會背景
目前，開發有需求說明會、設計評審會、**複審會等各種會議，但多是站在開發的角度，從需求和**層面進行複審和風險規避。在測試環節和測試階段缺少以測試為主體的評審機制和溝通機制，容易造成以下幾方面的問題：
1. 由於文件的質量良莠不齊，以及書面語言的侷限性，僅從文件獲取資訊，可能會造成資訊不對稱，認識片面，理解錯誤或不深入等問題。
2. 缺少同行交叉評審和開發評審機制，無法充分發揮集體智慧型，個人的思維難以突破，可能會出現測試遺漏的情況
3. 開發同事無法了解測試
工作
的進展程度，不利於雙方更好的配合。
此文件只適用版本的測試評審，專案的測試評審需參考規範。
二. 測試評審會目的
通過測試評審會，一方面，測試人員對需求和系統實現方式的疑問能得到開發的解答，並最終與開發達成共識；另一方面，測試人員對測試方法，測試策略，測試思路進行展現，開發和其他評審人員進行提問和補充，目的是能在有限的時間和人力條件下，以高效的測試手段，達到比較理想的覆蓋率。
1. 呈現測試的工作
2. 與開發達成共識
3. 不同的思維方式碰撞出火花，借鑑被人的思考方式
4. 培養這樣的行為模式：願意為團隊或他人出謀劃策。
5. 發揮團隊協作，最大限度發揮個人的經驗，特長，實現技能互補。
三. 測試評審會準備
1. 訂會議室（時間地點確認清楚是開會的基本前提）
2. 發出會議邀請（至少提前一周預約，以免發生會議衝突）
3. 對需求進行充分的分析（詳細請參考文件《由淺入深分析測試需求》）
4. 如有嚴重阻礙測試分析的問題，需事先跟開發個別溝通，以保證在評審前能完成基本完整的測試分析。
5. 如需求複雜，可以先邀請其他測試人員，進行同行交叉評審後，再邀請開發進行評審，以保證開發參與評審會的效率和效果。
四. 測試評審會議程
由於在需求評審甚至設計評審階段，需求和設計方案都具有很多不確定因素。後期測試人員只能通過文件獲取最終資訊，但僅僅通過文件又無法完全保證資訊的完整可靠。所以，我們通過測試評審會針對重要邏輯進行口頭確認的方式來作為文件確認的補充。
另一方面，測試方會對測試思路，測試方法，測試點進行呈現，開發等其他評審人員提問和補充修正，以達到完善測試案例的目的。
測試評審會主要包括三部分:
1. 確認答疑：
測試方針對需求和程式實現方式提出疑問，開發給予解答（時間控制在30分鐘內）
2. 測試呈現:
3. 測試呈現測試思路，方法，策略等（詳細參考文件《由淺入深分析測試需求》中的測試分析部分）（時間控制在30分鐘內）
4. 評審提問：
開發等其他評審人員進行提問和補充修正。（時間控制在20分鐘內）
五. 測試評審會技巧
1. 會議需要主持人：
推動討論，控制節奏，適時轉移和終止。
聚焦時間在50-80分鐘，不要讓一次會議超過2個小時。
3. 需要做會議記錄：
評審中無法確定的問題和後續需要跟蹤的任務，需要通過會議紀要記錄並跟進。
4. 有側重的進行評審：
區分重點難點，需求中已明確的無需重複哪些是需要一筆帶過的，哪些是需要重點詳細評審的。
5. 評審的目的是提出問題而非解決問題，所以終止對細節和不確定問題的討論，記錄跟蹤即可。
6. 測試呈現的重點：
1） 採用的測試方法
2） 等價類劃分的依據
3） 測試資料的選取和準備方法
4） 流程測試的路徑組合
5） 資料比對選取的物件和資料檢查點
6） 是否需要模擬資料及模擬資料的方法
7） 基於風險的測試取捨。
如何開需求評審會
參考自 要讓相關人員詳細了解需求 知道自己處於什麼位置，要做什麼 評估需求的難度和時長，進行分解和計畫安排 最好是所有干係人 如果不能都到會，也要所有干係負責人到會 如果負責人本人不能到會，需要該負責人的backup到會 前提是開發計畫已經被排期，進入確認階段 在開發計畫開始前3 5天進行評審 分為...
需求評審會
大多數從事軟體開發的人士都有這樣的體會，需求分析是乙個軟體成功與否的關鍵。在當今軟體工程領域出現的許多問題，都源於需求的不清晰。正因為如此，我們現在面臨的客戶，我們的專案經理自身，以及我們的管理層已經開始嚴控需求。我們不僅定製了需求提交的流程，還定製了需求說明的格式。但在實際操作過程中，通常是大家先...
需求評審會議如何召開
需求評審會議如何召開 需求評審會的目的，是為了讓相關人員，對產品的需求方案達成共識，讓boss提前知道完成專案所需的資源投入等等 由於相關人員較多，需要討論的問題也較多，所以會前對會議的全面準備，反覆預演練，是乙個產品對於每個需求評審會，都一定要做到的 1.評審會前 會前較為必要的是複雜問題或容易有...