當需求基線確定后，測驗工程師即開始設計測驗計劃、測驗方案和撰寫測驗用例，測驗用例設計完成后，是否代表該測驗用例已經達到要求了呢?不管從研發流程還是從軟體質量控制角度來說，此時的測驗用例都不能歸檔，必須進行測驗用例評審，只有評審后的測驗用例才能歸檔，
從研發流程角度來說，在整個研發程序中要求每個程序必須有相應的檢查點，這樣才能確保軟體質量可控制，從質量保證角度來說，也要求測驗用例進行評審，因為測驗是驗證系統需求是否被實作的程序，提高測驗的覆寫率顯然可以更好地保證軟體的質量，測驗用例的評審更像是集多人的思想來提高測驗的覆寫率，因此，從這兩個角度來說，測驗用例設計完成后都必須進行評審，
測驗用例的評審形式一般有兩種：一種是正式會議評審，另一種是非正式會議評審，正式會議評審要求必須執行同行評審的流程，評審的專家主要是專案組的相關成員，即測驗工程師、開發工程師、需求工程師、專案經理、QA 工程師等，對于非正式會議評審則可以不必那么正式，可以是專案組中的測驗工程師對彼此的用例進行檢查，或者組織一個非正式的會議，
測驗用例評審的目的有以下幾個方面：
- (1)提高測驗覆寫率，
通過對測驗用例評審，完善測驗的覆寫率，因為在評審程序中，不同評審專家看待問題的角度不完全一致，所以可以更充分地考慮測驗的方法，擴充測驗用例的全面性，這樣可以更好地確保基本功能和核心功能的測驗覆寫率，進而提高軟體質量，
- (2)確保需求的可追溯性，復審需求，
通過測驗用例的評審，可以確定每個需求是否都有測驗用例與之對應，只有每個需求都是相應的測驗用例與之對應才能保證測驗的全面性，同時也相當于對需求進行了一次復審，通過評審測驗用例可以反過來驗證需求設計是否合理、是否存在遺漏等情況，
- (3)開發工程師可帶入新的測驗角度，
由于開發工程師對業務的處理流程很清楚，這樣在評審測驗用例時，可以對設定的引數和流程提出新的測驗用例，進而從邏輯角度來改善測驗用例覆寫的情況，
- (4)預防缺陷，改善開發質量，
在對測驗用例的評審程序中，可以開拓開發工程師對代碼邏輯的思維，彌補以前設計程序中存在的缺陷，將潛在的缺陷挖掘出來，這樣可以進一步預防缺陷的發生，進而改善軟體質量，
在評審測驗用例時主要關注規范性規則、內容符合性、質量目標和其他方面，具體的檢查點如下：
(1)規范性規則，
- 1)用例是否按照公司規定的模板進行撰寫，
- 2)用例的編號是否符合規范命名要求(專案縮寫-子特性-ST-測驗型別-編號，如HaiDaTicket-Login-ST-Func-001)，
- 3)用例與方案中的用例是否一致，或者是否完全覆寫方案中描述的所有系統測驗項，
- 4)是否更新了需求跟蹤矩陣，用例編號和需求跟蹤矩陣中的用例編號是否一一對應，
- 5)用例是否覆寫了基線化后的SRS，
- 6)用例設計是否按照測驗計劃安排的時間完成，
- 7)用例對新增或者變更的需求是否做了相應的調整，
(2)內容符合性，
- 1)用例設計是否考慮了正向和反向兩方面的情況，
- 2)用例是否可測驗，
- 3)用例的重要級別和優先級是否定義合理，
- 4)用例是否清晰地描述了測驗用例的標題，
- 5)用例是否清晰地描述了預置條件，
- 6)用例是否清晰無二義地描述了操作步驟，
- 7)用例是否清晰描述了用例的輸入且輸入(測驗資料)的準備是否有相關的描述，
- 8)用例是否清晰地描述了預期結果以及預期結果是否可以驗證，
- 9)用例設計是否使用了等價類分析、邊界值、因果圖、判定表、錯誤推測、正交分析、流程分析、狀態遷移分析、輸入域覆寫、輸出域覆寫等測驗用例設計方法?是否針對不同的測驗特性設計使用合適的設計方法，
- 10)重點特性用例設計是否結合了多種方法來設計，是否過濾掉了重復的測驗用例，
- 11)用例中需要進行列印輸出(如報表)、表格的匯入、匯出是否說明了列印位置、表格名稱、指定資料庫表名或檔案位置;表格和資料格式是否有說明或附件，
- 12)測驗用例的預期結果是否唯一，即一個測驗用例不可能出現多種測驗結果，
- 13)預置條件是否正確，
- 14)測驗用例中資料輸入是一個固定值還是一類值(一般輸入應為一類值，如輸入用戶名為test，這樣可以引導測驗執行工程師進行思考，從而發現更多的缺陷)，
- 15)測驗用例是否存在冗余，
- 16)業務流程的路徑是否全部覆寫，
- 17)每個測驗用例的步驟不應該超過12 步，
- 18)對于核心和基本功能，每潭訓本路徑應該覆寫到，
- 19)對升級的功能，在評審時需要重點關注，
(3)質量目標，
- 1)用例覆寫率(如用例個數/KLOC)是否達到相應質量目標，
- 2)用例評審發現的缺陷率(缺陷總數/用例總數)是否達到了相應的質量目標，
- 3)用例的粒度是否合理和統一，是否均勻覆寫了測驗需求，
- 4)用例發現的問題是否占整個測驗執行發現問題的80%(當然越高越好)以上(事后驗證)，
- 5)測驗用例設計的時間占整個系統測驗程序的時間是否合理(一般在30%～40%，這里排除一些專項測驗，如穩定性測驗、長時間測驗等)，
(4)其他方面：
- 1)測驗執行程序中發現用例不完善時是否做相應的調整，
- 2)由于軟體版本的升級，用例是否做相應的調整，
由于一個完整的專案測驗用例數量比較多，如果每個測驗用例都評審，那么將花費很大的作業量，
一般情況下測驗用例評審的策略分以下三種：
(1)完全評審，
完全評審是指對整個專案中的所有測驗用例進行評審，這種評審方式的優點是可以對所有的用例都進行評審，進而完善測驗用例質量;但同樣缺點也很明顯，完全評審需要更多的時間和精力，么在作業中可能很難有充裕的時間進行完全評審，這種評審方式適用于新的專案，對于一個新的專案來說，為了保證軟體質量，必須對所有的測驗用例進行充分的評審，
(2)有選擇性的評審，
有選擇性的評審，即不對所有的測驗用例進行評審，只對部分測驗用例進行評審，該方法的優點是使用最少的時間對最重要功能的測驗用例進行評審;缺點是未評審的測驗用例無法完全保證質量，
該方法更適用于維護產品，假設當前的版本是升級的版本，只修改了部分功能，那么評審測驗用例的時候可以將重點轉向這些新添加的用例，以前評審過的測驗用例則可以不用花費過多的時間進行評審，
(3)指標評審法，
指標評審法是指研發流程中規定每個專案測驗用例的評審覆寫率需要達到多少(如60%等)，
指標評審法使用較少，因為指標評審法很容易導致為了達到指標而評審，并不一定能真正提高測驗用例質量，所以經常將指標評審法與有選擇的評審合并使用，
不管使用哪種方法進行評審，對于客戶經常使用到的功能和業務流程一定要詳細地評審，一定要將所有可能的路徑全部覆寫，因為這類功能如果存在缺陷，被投訴的概率就很大，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/292884.html
標籤：其他