本文部分內容借鑑於博客需求評審的關注點
需求評審、SPEC評審
1、評審前期準備
評審是要在寫代碼前發現問題，不要吝嗇將時間花在前期上，因爲這會大大減少我們中後期的意外，避免做很多的無用功。在評審之前，我們要仔細閱讀相關的評審資料，瞭解每個點是幹什麼的。
2、評審中需要關注的點
（1）文筆
描述是否存在錯別字，特別是界面上的文案。例如，登陸->登錄
描述是否清楚，是否存在歧義
沒有統一術語，多處地方用不同詞語來表示同一概念
是否雜亂無章，不便於閱讀和查找信息
（2）邏輯性
流程的出入口：是否明確，是否過多（連用戶都會昏頭轉向）
條件與規則說明是否清晰明瞭
缺少說明數據的來源、類型、精度、取值範圍、默認值、顯示格式、計算處理方式
是否考慮其它功能或需求的關聯影響
用戶體驗如何
（3）實現
人力、時間等資源是否存在困難
實現難度較大
遺留的坑會導致出嚴重bug的概率大，風險高
性能不佳，會造成用戶體驗差
是否有比產品經理想到的更好的方案
能否複用已有的邏輯或使用業界更通用的有開源實現的做法
後續的迭代考慮，是否在設計上預留可擴展性
不重要的部分（例如後臺系統）由開發自行決定界面和交互
3.其他
在評審前我們閱讀完相關資料後，就可以走整理我們想要提出的問題或是建議了
在評審的過程中，我們要站在用戶的角度去思考，站在用戶的角度去提出問題
對於新需求來講，若出現開發和設計人員爭執的情況，這時試人員就需要作爲第三方站在用戶的角度去剖析問題。否則，有些需求實現之後，在進行FUT測試的時候，才發現不合適，那之前做的工作都白做了，這就是資源的一種浪費
用例評審、歸檔用例
一個測試人員設計出的測試用例，可能會存在考慮不周的問題，如果沒有及時的發現這些問題，就可能會出現用戶發現問題導致對產品產生不好的影響。所以測試用例設計出來後，如何保證它的質量呢？這時我們將多位測試人員聚集在一起，集思廣益，就有了用例評審。用例評審又分爲正式評審和非正式評審。
1、評審方式
- 同行評審
測試用例的評審有很多種，但是最敏捷應當是臨時的同行評審。同行評審，尤其是臨時的同行評審，應當演變成類似結對編程的一種方式。從而體現出敏捷的“個體和交互比過程和工具更有價值。”要體現出測試用例設計者之間的思想碰撞，可以通過討論、協作完成測試用例的設計。原因很簡單，編寫的測試用例需要儘可能的覆蓋全部需求，而測試人員的思維總會存在缺陷，一個人的思維總是存在侷限性，所以需要大家一起來設計。
結對編程：一種敏捷開發的方式，指兩個程序員在一臺計算機上共同工作。一個人輸入代碼，另一個人審查他輸入的每一行代碼。輸入代碼的人叫做駕駛員，審查代碼的人叫做觀察員（或導航員），兩個程序員經常互換角色。
- 用戶檢查
除了同行評審，還應該儘量引入用戶參與到測試用例的設計中來，讓用戶參與評審，從而體現敏捷的“顧客的協作比合同談判更有價值”這一原則。這裏顧客的含義比較廣泛，關鍵在於如何定義測試，如果測試是對產品的批判，則顧客應該指最終用戶或顧客代表（在內部可以是市場人員或領域專家）；如果測試是被定義爲對開發提供幫助和支持，那麼顧客顯然就是程序。
- 項目組評審
由測試負責人組織開展會議，用例編寫人對用例就行講解，參會人員有異議的當場提出。
2、用例評審內容
在進行用例評審的時候，我們要準備的材料除了測試用例之外，還有測試方案。一般我們都用xmind工具來編寫測試方案，
3、歸檔用例
歸檔用例就是在用例評審結束之後，將評審中的意見建議修改之後的用例提交到對應的平臺上，這就叫做用例的歸檔。最遲的用例歸檔時間是在項目版本集成之前。歸檔用例主要是給其他的測試人員看的。