模板
教程
環境
性能
功能
管理
軟件測試用例評審說明
發表于：2023-07-07來源：csdn作者：daisyr07點擊數：
標簽：
軟件測試用例評審是一個重要的環節，它是質量保證的關鍵手段，可以有效地幫助確保軟件符合預期的功能要求和質量標準。 軟件測試用例評審的工作流程是，首先準備工作，收集相關
軟件測試用例評審是一個重要的環節，它是質量保證的關鍵手段，可以有效地幫助確保軟件符合預期的功能要求和質量標準。 軟件測試用例評審的工作流程是，首先準備工作，收集相關的軟件測試用例文檔，確定用例評審活動的主要參與者；然后進行用例評審，確定測試用例的有效性、識別測試用例的缺陷、評估測試用例的可行性以及提出改進建議；接著編寫評審報告，整理評審結果并發布評審報告；最后完成后續工作，包括實施改進建議、更新用例文檔以及進行測試等。
一 .用例評審目的
一 .用例評審目的
為用例評審提供一個參考標準，保證評審的覆蓋率和有效性
為了避免三方需求理解不一致
保證測試人員的質量標準與項目標準一致
為了減少測試人員執行階段無效工作
保證相關人員對即將要上線的需求有了解
二. 用例評審作用
1.對于產品經理
檢查測試人員是否準確理解需求，確保每個需求點都覆蓋到。
通過評審正常和異常的測試用例，來反思當時設計需求時未考慮的情況，也是自我回溯的一個過程。
2.對于開發人員
檢查自己的程序代碼是否還有很多情況未考慮完善，對自己的代碼也是一個自我回溯檢查的過程，間接實現了測試左移。
對于用例中無法實現的邏輯及時溝通，三方達成高度一致。
3.對于測試人員
與各方人員溝通，完善測試用例
三.用例評審參與人員
用例評審一定是要求產品（制定該需求的產品經理）、開發（實現該產品的前后端開發人員）、測試（負責該需求用例編寫和執行的測試人員）都參與。
會議由測試人員主導，相應需求的測試同學依次上去講解自己的測試用例。
測試組內部的評審：測試部門成員參與
項目組內部的評審：項目經理、產品人員、開發人員和測試人員參與
四. 用例評審內容
1.一般用例評審內容
用例設計的結構安排是否清晰、合理，是否利于高效對需求進行覆蓋。
優先極安排是否合理。
是否覆蓋測試需求上的所有功能點。
用例是否具有很好可執行性。例如用例的前提條件、執行步驟、輸入數據和期待結果是否清晰、正確；期待結果是否有明顯的驗證方法。
是否已經刪除了冗余的用例。
是否包含充分的負面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數量，畢竟一個健壯的軟件，其中80%的代碼都是在“保護”20%的功能實現。
是否從用戶層面來設計用戶使用場景和使用流程的測試用例。
是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標準步驟。
2.測試組內部評審側重
測試用例本身的描述是否清晰，是否存在二義性；
是否考慮到測試用例的執行效率.往往測試用例中步驟不斷重復執行，驗證點卻不同，而且測試設計的冗余性，都造成了效率的低下；
是否針對需求變更進行跟著，覆蓋了所有的軟件需求；
是否盡可能多的覆蓋了異常流程和異常測試點。
3.測試用例評審檢查項
測試用例是否按照公司定義的模板進行編寫的；
測試用例的本身的描述是否清晰，是否存在二義性；
測試用例內容是否正確，是否與需求目標相一致；
測試用例的期望結果是否確定、唯一的；
操作步驟應與描述是否相一致；
測試用例是否覆蓋了所有的需求；
測試設計是否存在冗余性；
測試用例是否具有可執行性；
是否從用戶層面來設計用戶使用場景和業務流程的測試用例；
場景測試用例是否覆蓋最復雜的業務流程；
用例設計是否包含了正面、反面的用例；
對于由系統自動生成的輸出項是否注明了生成規則；
測試用例應包含對中間和后臺數據的檢查；
測試用例應有正確的名稱和編號；
測試用例應標注有執行的優先級；
測試用例包含相關的配置信息：測試環境、數據、前置測試用例、用戶授權等；
每個測試用例步驟應<=15 Step；
自動化測試腳本必須帶有注釋（注釋應包括：目的、輸入、期望結果等）；
非功能測試需求或不可測試需求是否在用例中列出并說明
五.用例評審方式
線上會議
線下會議
通用OA與相關人員溝通
六.用例評審時間
測試用例完成后
需求文檔提交后，開發提測前
會議時間最好控制在1小時之內，如果內容較多，可多次評審
七.用例評審流程
1.會前準備
測試用例編寫完成
提前通知參會人員，約定好評審時間并預約好會議室
提前將測試用例發送給參會人員查閱
會議5分鐘前到達會議室，將測試用例，需求文檔等打開
用例較多時，提前做好標注，優先講解優先級高的用例，并盡量將前后端用例區分，方便側重評審
將自己的疑惑整理在一起，方便詢問
2.會中流程
2.1方式1：對照測試用例，從上而下，從左到右，逐條念。
普遍的流程都是這樣的。
優點：逐個講解，全面仔細
缺點：費時，不分主次，降低參會人員的注意力
2.2方式2：先對功能復雜，優先級高，疑問多的用例進行評審，再評審功能簡單，優先級低的功能點。
優先講解優先級高的用例，其次疑惑多的用例，再者功能簡單，優先級低的功能點。
優點：有側重點，效率高
缺點：講解不全面，可能存在忽略點
2.3會議注意
對于評審過程中，超過5分鐘無法確定結果的問題，可以記錄下來，作為會后討論跟進的重點。
評審過程中盡量做到，思路清晰，用最簡潔的語言闡述每一個功能點。
對于有歧義的問題，需要與產品和開發確認清楚。
評審過程中，參會人員可能會有視覺和聽覺疲勞，主講人要抓住重點和重要人員。
對于評審過程中的問題，及時做好標記。
用例評審只針對用例，不針對個人能力。
3.會后總結
3.1用例評審會議后，需要對評審中的問題進行跟進和完善。
需要產品經理補充和修改的點需要讓其在需求文檔和原型圖上進行記錄
對遺漏的測試點進行補充，對有誤的測試點進行修正，并對用例進行管理
3.2如有要求，完成用例評審文檔
3.3對個人會議行為進行總結
七.用例評審結束標準
評審過程中收集相關人員的反饋信息（即問題記錄清單），并在此基礎上進行測試用例更新，直到評審通過。
評審結束后，測試負責人出測試用例評審報告給到相關人員。
評審結果經項目經理同意確認
原文轉自：https://blog.csdn.net/Daisy74RJ/article/details/131562723
