用例評審的內容
1.是否覆蓋測試需求上的所有功能點，不違背產品原型和**設計，用例設計的結構安排是否清晰合理，有利於高效覆蓋需求
2.用例是否具有可執行性，前提條件、執行步驟和預期結果是否正確，有明確的驗證方法。優先順序安排是否合理
3.是否從使用者層面來設計使用者使用的場景和業務流程
4.是否包含充分的異常測試用例
5.是否簡潔，不冗餘，復用性強
用例評審過程
1.提前發出初稿和會議邀約，至少提前一天發出用例初稿，並確定參與用例評審人員，以便專案經理，產品和開發提前閱讀用例，讓會議更有效率的進行
2.先做簡單的業務流程介紹，這個是在評審開始尤為重要的乙個過程，剛開始評審，參與人員會比較矇圈，產品和開發都不知道測試的思路，或者半途加入新的開發和測試，對需求和業務都不夠熟悉，如何讓評審快速進入狀態，先做簡單的需求業務流程介紹，說明白打算如何去做評審。
【舉個栗子】乙個專案有使用者體系、電子賬戶、理財、生活模組，可以先由大到小的細分下去；可用事先畫好的腦圖，各種流程圖，也可當場快速寫上板書。
3.按模組進行，有些模組，業務性不是特別強的，可以簡單說下有哪些模組，每個模組評審的時候，按測試項分類，ui、核心功能、基礎功能、邊界測試、相容測試和異常測試等，預期結果類似的，主要講清楚用例主題，讓參與人員知道每條用例是做什麼的。
4.按業務流程進行，業務流程性較強的需求，需要有業務場景和邏輯，按一定的順序來，讓參與人跟著你的思想，避免東一句西一句，
【舉個栗子】乙個理財活期產品的測試用例評審，購買和贖回，跑批時間段分日間和日終，工作日和週末四個場景，按不同場景分為不同的業務流程進行評審，有理有據，邏輯思路清晰。
5.按測試資料進行，涉及到計算邏輯、收益、報表等需求的，用例編寫時會先規劃好測試資料，儘管測試資料也是按不同的業務場景來設計的，但直接用測試資料來評審你的測試點，會更清晰，跟上你思路的開發和產品會對應上自己的產品設計和**設計去評審你的測試點是否不合理或覆蓋率不全的地方，從而有效的評審測試用例。
用例評審後的確認
為了節約時間成本，第一次評審盡量對用例設計全面考慮，提前發現其中的不足之處；但是第一次評審難免會要修修補補的地方，在評審時盡快的修復，不能在一兩分鐘修復的，記錄下來，在會議結束後進行修改，如果改動不是很多的，可以發出郵件，標明修改部分，再最後確認最終版。如果需要進行二次評審，那麼重新開始邀約會議做二次評審。
四、用例評審需要避免
1.測試點含糊用語，每個用例評審都應該確定最終版，稍有矛盾或疑惑的需求點，都應該確認下來，不能含糊不清。
2.雜亂無章的評審，有順序有邏輯的進行評審是很重要的一點，如果臆想按照自己的思路評審，不顧他人感受，那麼就等同於做無用功。這樣的用例執行出來也會有一定的質量風險。
轉於：
需求評審 SPEC評審 用例評審 歸檔用例
本文部分內容借鑑於部落格需求評審的關注點 1 評審前期準備 評審是要在寫 前發現問題，不要吝嗇將時間花在前期上，因為這會大大減少我們中後期的意外，避免做很多的無用功。在評審之前，我們要仔細閱讀相關的評審資料，了解每個點是幹什麼的。2 評審中需要關注的點 1 文筆 描述是否存在錯別字，特別是介面上的文...
如何評審功能測試用例？
用例評審目的 用例評審的四個環節 需求評審 需求實現流程圖評審 測試大綱評審 測試用例檢查 a 檢查講解的內容無丟失 b 檢查需求理解無偏差 c 檢查需求講解思路清晰 d 檢查需求討論會議提出需求建議 需求討論的問題都有體現，並且記錄的詳細 e 檢查需求講解時存在問題的記錄，跟進結論 a 檢查需求以...
如何組織測試用例？
如何組織 測試用例 比如何寫測試更重要。個人的一些經驗總結在此。1.使用describe 和 context 來區分 不同的測試分類和同乙個測試的不同方面 describe 一般用作分類，需要測試什麼東西 context 用來對需要測試的東西的不同方面 比如 descirbe order do 分類...