2022-05-18 16:17發布
1、用例設計的結構安排是否清晰、合理，是否利于高效對需求進行覆蓋；2、優先級安排是否合理；3、是否覆蓋測試需求上的所有功能點 ；4、用例是否具有很好可執行性；5、例如用例的前提條件、執行步驟、輸入數據和期待結果是否清晰、正確；6、期待結果是否有明顯的驗證方法 ；7、是否已經刪除了冗余的用例 ；8、是否包含充分的負面測試用例；9、充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的量，畢竟一個健壯的軟件，其中80%的代碼都是在“保護”20%的功能實現 ；10、是否從用戶層面來設計用戶使用場景和使用流程的測試用例 ；11、是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標準步驟。
來源于網絡
1. 完整性：考慮盡可能多的對象以及對應狀態，比如注冊模塊：
對像有：用戶類型，手機號，驗證碼，界面倒計時控件;
狀態有：用戶類型狀態（選擇過/未選擇）手機號狀態(是/否被注冊；是/否被封號，是/否被警告)，驗證碼狀態（已發送/未發送/發送次數超限制），計時器狀態（計時中/計時結束）
2. 準確性：每一條測試用例都可以找到產品需求文檔，編寫用例的時候，附帶產品需求文檔或者截圖
3. 可讀性：描述清晰無歧義:誰在**預置條件下**對A進行**操作,然后**會得到**結果,who/ when /where /what/ result簡單的就是一個新來的測試能毫無歧義的理解誰在什么條件下,進行什么操作,得到什么結果(結果會影響誰的什么東西,是怎么樣的影響)
4. 精簡,不冗余
和維護開發代碼一樣,維護的工作就是去除冗余,測試人員在平時維護用例其實就是去冗余提升可復用
5. 可復用
有些流程中特有的功能性測試可以單獨成單元用例,單元用例具有可復用性,在不同的流程中只寫一份即可.
比如:用戶未登錄預置條件下,程序中點擊(1,2,3,4,5,6,7,8,9,10....100)按鈕的地方都需要跳轉到登錄頁面,登錄之后,回來的還是之前的頁面
示例:用戶未登錄點擊相關按鈕（*****）跳轉到登錄頁面，登錄成功或者失敗回到之前頁面（這樣寫以后新加需求的時候，再增加按鈕也只需要改動括號里面文字即可）
作者：易水寒2018鏈接：https://www.jianshu.com/p/c7ec5e8cebf9來源：簡書著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
同時要關注用例評審的四個環節：需求評審、需求實現流程圖評審、測試大綱評審和測試用例檢查。每個環節都包括很多內容，比如需求評審主要是檢查需求理解無偏差、檢查需求講解思路清晰、檢查需求討論會議提出需求建議以及檢查需求講解時存在問題的記錄，跟進結論等。流程圖評審包括檢查需求以及實現邏輯內容正確、檢查需求以及實現邏輯內容齊全、檢查實現邏輯的深度與仔細程度等。
模板：也看自己需求呢，可以變動
一、 部門評審，測試部門全體成員參與的評審。二、公司評審，這里包括了項目經理、需求分析人員、架構設計人員、開發人員和測試人員三、 客戶評審，包括了客戶方的開發人員和測試人員。...
1、評審之前，需要將即將評審的測試用例以及測試需求、測試分析的結果（測試點分析）等文檔提前發送給相關的人員；最好能夠讓他們有時間提前閱讀；?2、隨時的問題溝通與反饋機制。評審之前做一些問題的溝通與反饋，以便于在測試用例評審會議上能夠節省出來寶...
1.為了減少測試人員執行階段做無效工作；（執行無效case，提交無效問題）2.為了避免三方需求理解不一致；3.為了每個測試人員的質量標準與項目要求標準達成一致；
功能測試的用例評審首先需要弄清楚功能測試的用例評審的目的：第一是為了減少測試人員執行階段做無效工作，如執行無效case，提交無效問題；第二是為了避免三方需求理解不一致；第三為了每個測試人員的質量標準與項目要求標準達成一致。...
兩個時間點：
①評審過程中收集相關人員的反饋信息，并在此基礎上進行測試用例更新，直到評審通過；②評審結束后，測試負責人出測試用例評審報告給到相關人員；③評審結果經項目經理同意確認。...
測試用例本身的描述是否清晰，語言準確；是否存在二義性；測試用例內容是否完整，是否清晰的包含輸入和預期輸出的結果；測試步驟是否清晰；測試用例中使用的測試數據是否恰當，準確；測試用例是否具有指導性，是否能靈活的指導軟件測試工程師通過測試用例發現...
最多設置5個標簽!
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','/static/images/logo.png', '推薦 白桃烏龍 的問題《用例評審的標準是什么》','http://www.espanasaferx.com/q-37441.html','頁面編碼gb2312|utf-8默認gb2312'));){kind=link}
1、用例設計的結構安排是否清晰、合理，是否利于高效對需求進行覆蓋；
2、優先級安排是否合理；
3、是否覆蓋測試需求上的所有功能點 ；
4、用例是否具有很好可執行性；
5、例如用例的前提條件、執行步驟、輸入數據和期待結果是否清晰、正確；
6、期待結果是否有明顯的驗證方法 ；
7、是否已經刪除了冗余的用例 ；
8、是否包含充分的負面測試用例；
9、充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的量，畢竟一個健壯的軟件，其中80%的代碼都是在“保護”20%的功能實現 ；
10、是否從用戶層面來設計用戶使用場景和使用流程的測試用例 ；
11、是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標準步驟。
來源于網絡
回答: 2022-06-01 10:35
1. 完整性：考慮盡可能多的對象以及對應狀態，比如注冊模塊：
對像有：用戶類型，手機號，驗證碼，界面倒計時控件;
狀態有：用戶類型狀態（選擇過/未選擇）手機號狀態(是/否被注冊；是/否被封號，是/否被警告)，驗證碼狀態（已發送/未發送/發送次數超限制），計時器狀態（計時中/計時結束）
2. 準確性：每一條測試用例都可以找到產品需求文檔，編寫用例的時候，附帶產品需求文檔或者截圖
3. 可讀性：描述清晰無歧義:誰在**預置條件下**對A進行**操作,然后**會得到**結果,who/ when /where /what/ result簡單的就是一個新來的測試能毫無歧義的理解誰在什么條件下,進行什么操作,得到什么結果(結果會影響誰的什么東西,是怎么樣的影響)
4. 精簡,不冗余
和維護開發代碼一樣,維護的工作就是去除冗余,測試人員在平時維護用例其實就是去冗余提升可復用
5. 可復用
有些流程中特有的功能性測試可以單獨成單元用例,單元用例具有可復用性,在不同的流程中只寫一份即可.
比如:用戶未登錄預置條件下,程序中點擊(1,2,3,4,5,6,7,8,9,10....100)按鈕的地方都需要跳轉到登錄頁面,登錄之后,回來的還是之前的頁面
示例:用戶未登錄點擊相關按鈕（*****）跳轉到登錄頁面，登錄成功或者失敗回到之前頁面（這樣寫以后新加需求的時候，再增加按鈕也只需要改動括號里面文字即可）
作者：易水寒2018
鏈接：https://www.jianshu.com/p/c7ec5e8cebf9
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
同時要關注用例評審的四個環節：需求評審、需求實現流程圖評審、測試大綱評審和測試用例檢查。每個環節都包括很多內容，比如需求評審主要是檢查需求理解無偏差、檢查需求講解思路清晰、檢查需求討論會議提出需求建議以及檢查需求講解時存在問題的記錄，跟進結論等。流程圖評審包括檢查需求以及實現邏輯內容正確、檢查需求以及實現邏輯內容齊全、檢查實現邏輯的深度與仔細程度等。
相關問題推薦
模板：也看自己需求呢，可以變動
一、 部門評審，測試部門全體成員參與的評審。二、公司評審，這里包括了項目經理、需求分析人員、架構設計人員、開發人員和測試人員三、 客戶評審，包括了客戶方的開發人員和測試人員。...
1、評審之前，需要將即將評審的測試用例以及測試需求、測試分析的結果（測試點分析）等文檔提前發送給相關的人員；最好能夠讓他們有時間提前閱讀；?2、隨時的問題溝通與反饋機制。評審之前做一些問題的溝通與反饋，以便于在測試用例評審會議上能夠節省出來寶...
1.為了減少測試人員執行階段做無效工作；（執行無效case，提交無效問題）2.為了避免三方需求理解不一致；3.為了每個測試人員的質量標準與項目要求標準達成一致；
功能測試的用例評審首先需要弄清楚功能測試的用例評審的目的：第一是為了減少測試人員執行階段做無效工作，如執行無效case，提交無效問題；第二是為了避免三方需求理解不一致；第三為了每個測試人員的質量標準與項目要求標準達成一致。...
兩個時間點：
①評審過程中收集相關人員的反饋信息，并在此基礎上進行測試用例更新，直到評審通過；②評審結束后，測試負責人出測試用例評審報告給到相關人員；③評審結果經項目經理同意確認。...
測試用例本身的描述是否清晰，語言準確；是否存在二義性；測試用例內容是否完整，是否清晰的包含輸入和預期輸出的結果；測試步驟是否清晰；測試用例中使用的測試數據是否恰當，準確；測試用例是否具有指導性，是否能靈活的指導軟件測試工程師通過測試用例發現...