週末就快要結束啦，因為疫情，又因為天氣悶熱悶熱的，實在心生不起戴著口罩還出去玩的想法了，所以我又是在家裡蹲的乙個週末，大家是不是也跟我一樣呢
昨天說到測試用例的設計方法，然後我想到，在對整個特定系統設計完測試用例之後，需要對測試用例進行乙個評審工作。
用例評審的目的在於查漏補缺，保證評審的覆蓋率和有效性。其閱讀物件為專案經理、測試工程師及專案組所有成員，適合於任何產品和專案。
評審又分為測試組內部的評審，由測試部門成員參與;專案組內部的評審由專案經理、產品人員、開發人員和測試人員參與。
那麼評審的內容及檢查項都有哪些，接著往下看?
評審內容
用例設計的結構安排是否清晰、合理，是否利於高效對需求進行覆蓋
優先順序安排是否合理
是否覆蓋測試需求上的所有功能點
用例是否具有很好可執行性。例如用例的前提條件、執行步驟、輸入資料和期待結果是否清晰、正確;期待結果是否有明顯的驗證方法
是否已經刪除了冗餘的用例
是否包含充分的負面測試用例。充分的定義，如果在這裡使用2＆8法則(也就是缺陷的二八定理)，那就是4倍於正面用例的量，畢竟乙個健壯的軟體，其中80%的**都是在「保護」20%的功能實現
是否從使用者層面來設計使用者使用場景和使用流程的測試用例
是否簡潔，復用性強。例如，可將重複度高的步驟或過程抽取出來定義為一些可復用標準步驟。
評審檢查項
測試用例是否按照公司定義的模板進行編寫的
測試用例的本身的描述是否清晰，是否存在二義性
測試用例內容是否正確，是否與需求目標相一致
測試用例的期望結果是否確定、唯一的
操作步驟應與描述是否相一致
測試用例是否覆蓋了所有的需求
測試設計是否存在冗餘性
測試用例是否具有可執行性
是否從使用者層面來設計使用者使用場景和業務流程的測試用例
場景測試用例是否覆蓋最複雜的業務流程
用例設計是否包含了正面、反面的用例
對於由系統自動生成的輸出項是否註明了生成規則
測試用例應包含對中間和後台資料的檢查
測試用例應有正確的名稱和編號
測試用例應標註有執行的優先順序
每個測試用例步驟應<=15 step。
好咯，明天就是周一了，又可以持續充電+放電了，我希望明天可以看到元氣滿滿的你?
測試用例評審
1 測試組內同行評審 2 開發組內評審 1 檢查測試用例是否符合規範 流程清晰 劃分合理 是否採用了合理的測試用例設計方法 用例是否唯 一 有沒有重複 巢狀重複 有沒有考慮異常 有沒有大資料量場景 有沒有考慮冪等 有沒有考慮併發 重複請求 便於橫向比較 提高透明度 展示用例設計能力 2 業務流程有沒...
測試用例評審
關於測試用例評審，很早就有這個想法，但是鑑於以下幾個因素，一直未執行 1.在剛來的時候 6年前，連需求都沒有，到版本提交測試時，才第一次了解到版本做成這樣，測試用例無從談起 2.來了兩三年之後 4年前，測試用例被提起，但是依然無用例 無專案流程，無寫用例時間 3.來了四五年後 兩年前，才開始有專案概...
測試用例評審
首先要清楚內部評審的定義，是測試組內部的評審，還是專案組內部的評審。評審的定義不同，內容也不會相同。測試組內部的評審，應該著重於 測試用例本身的描述是否清晰，是否存在二義性 是否考慮到測試用例的執行效率，往往測試用例中步驟不斷重複執行，驗證點卻不同，而且測試設計的冗餘性，都造成了效率的低下 是否針對...