關於測試用例評審，很早就有這個想法，但是鑑於以下幾個因素，一直未執行：
1.在剛來的時候-6年前，連需求都沒有，到版本提交測試時，才第一次了解到版本做成這樣，測試用例無從談起
2.來了兩三年之後-4年前，測試用例被提起，但是依然無用例：無專案流程，無寫用例時間
3.來了四五年後-兩年前，才開始有專案概念之說，開始執行專案流程，這時候，測試用例才真正被提上日程，但是專案流程還未成熟，用例也很多是事後補，無從評審
4.來了五六年-現在，專案流程趨於穩定完善，用例編寫也已規範，至此，才開始審視用例評審
現在用例評審時機到了，關於如何開展用例評審，根據目前的一些積累經驗，總結評審內容如下：
在剛實施過程中，遇到乙個問題：測試成員認為，多輸出這個文件的流程，是浪費時間。
這樣認為的原因：在無這個文件的時候，已經開始執行用例評審，用例評審的形式是一對一評審， 評審者直接在被評審用例上備註問題及補充；多這個文件，變成在原來的基礎上多一步操作-----還要多輸出乙份內容，特別是在用例份數多的情況下，到底有無必要？
具體效果如何，需要積累幾個版本後再做個總結，目前還只是剛開始執行階段
不過，個人有個困惑目前還不解：
我們的產品，是在不斷公升級的，公升級版本會對舊功能做一些補充或改造；每次在乙個公升級版本中，會專門寫乙份這個公升級版本的用例。
但是在這個版本結束後，肯定需要對這個功能的用例進行維護，那就需要整合這個功能的新舊內容；
那麼問題來了，這種情況很可能新的用例邏輯跟舊的用例邏輯不一樣，如果要整合起來的話，不是單純往舊用例上累加就可以的；邏輯需要重新整理，步驟需要重新調整；這種情況下，改造還不如重新寫；
這樣的話：乙個功能，用例寫完之後，功能有公升級變更情況下，該如何寫用例合適？在舊用例上直接進行改造還是另起乙份？
測試用例評審
1 測試組內同行評審 2 開發組內評審 1 檢查測試用例是否符合規範 流程清晰 劃分合理 是否採用了合理的測試用例設計方法 用例是否唯 一 有沒有重複 巢狀重複 有沒有考慮異常 有沒有大資料量場景 有沒有考慮冪等 有沒有考慮併發 重複請求 便於橫向比較 提高透明度 展示用例設計能力 2 業務流程有沒...
測試用例評審
首先要清楚內部評審的定義，是測試組內部的評審，還是專案組內部的評審。評審的定義不同，內容也不會相同。測試組內部的評審，應該著重於 測試用例本身的描述是否清晰，是否存在二義性 是否考慮到測試用例的執行效率，往往測試用例中步驟不斷重複執行，驗證點卻不同，而且測試設計的冗餘性，都造成了效率的低下 是否針對...
測試用例評審
一 測試用例評審的關注點 1 用例設計的結構安排是否清晰 合理，是否利於高效對需求進行覆蓋。2 優先順序安排是否合理。3 是否覆蓋測試需求上所有功能點。4 用例是否具有很好的可執行性。例如用例的前提條件 執行步驟 輸入資料和期待結果是否清晰 正確 期待結果是否具有明顯驗證方法。5 是否已經刪除了冗餘...