- 功能評審定義：由研發經理主推，測試協助推進
由研發經理和測試負責人定義，相關測試人員負責推進
小功能由研發和測試自行定義 - 人員
研發人員
測試人員
研發經理
需求人員 - 時間
由測試人員編寫完測試用例和思路后，進行評審，評審時間必須根據預期時間（提前預期24小時）給出，如有延誤提前通知與會人員。
考慮需求功能交互疑問的地方，認為不合理，或者不理解的地方-->文檔 - 地點
會議室 - 資料准備
提前調試好設備投影
測試思路，用例文檔，
需求功能交互疑問的地方，認為不合理，或者不理解的地方，是否需要研發協助提供相關數據支持-->文檔
打印測試思路和需求以及功能實現疑問。此處需要給出制式表格，提前一小時分發給參審人員。 - 評審流程
- 開始
由測試人員根據測試思路和用例結合需求原型和設計文檔進行測試策略的講解：評審人員進行評審
過程中提出當前功能的所有疑問點：相關評審人員進行回復 - 評審內容
測試思路是否合理，不合理，那些不合理，提出意見
測試是否有缺失點，有，有哪些，明確指出具體位置和功能
測試提出的疑問是否為有效問題，有，是什么問題，如何解決
參審人員是否有自己需要補充的地方，有，補充問題
測試用例是否有結構性，流程性，比如根據用戶的操作流程，或者測試整體的構思
當前測試人員和研發人員隨時做好所有爭論問題記錄和解決方案，后續對功能進行拓展和刪減
用例設計的結構安排是否清晰、合理，是否利於高效對需求進行覆蓋。
優先極安排是否合理。
是否覆蓋測試需求上的所有功能點以及用戶的交互流程
用例是否具有很好可執行性。例如用例的前提條件、執行步驟、輸入數據和期待結果是否清晰、正確；期待結果是否有明顯的驗證方法。
是否有無效冗余的用例。有哪些，此處研發需要注意
是否包含充分的負面測試用例。充分的定義，
是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標准步驟。
是否能夠形成有效的：冒煙測試，回歸測試，系統測試 - 結束
評審內容進行完畢
無爭論存在
有爭論考慮是否給出二次評審計划和時間
功能預期實現定義，按照此次溝通實現，或者需要重新考慮和設計處理（可分為一期，二期，三期后續加強）
- 信息記錄
測試和對應研發人員做好信息記錄