測試用例並非一成不變。如果軟體修改之後發生變化，或者需求發生變更，那麼測試用例便不再滿足當前版本軟體的測試需求，由此需要進行修改和變更操作。
首先要清楚內部評審的定義，是測試組內部的評審，還是專案組內部的評審。評審的定義不同，內容也不會相同。
如果是測試組內部的評審，應該著重於：
1.測試用例本身的描述是否清晰；
2.是否考慮到測試用例的執行效率.往往測試用例中步驟不斷重複執行，驗證點卻不同，而且測試設計的冗(rong)余性，都造成了效率的低下；
3.是否針對需求文件，測試用例是否覆蓋了所有的軟體需求；
4.是否完全遵守了軟體需求的規定。這並不一定的，因為即使再嚴格的評審，也會出現錯誤，應具體情況具體對待。
如果是專案組內部的評審，也就需要評審委員會來做了，角度不同，評審的標準也不同。比如收集客戶需求的人員注重你的業務邏輯是否正確，分析軟體需求規格的人注重你的用例是否跟規格要求一致，開發負責人會注重你的用例中對程式的要求是否合理。
測試用例的評審能夠使用例的結構更清晰，覆蓋的使用者場景更全面對於測試工程師來說也是乙個快速提高用例設計能力的過程。
1、需要評審的原因
測試用例是軟體測試的準則，但它並不是一經編制完成就成為準則。由於用例開發人員的設計經驗和對需求理解的深度各不相同，所以用例的質量難免會有不同程度的差異。
2、進行評審的時機
一般會有兩個時間點。第一，是在用例的初步設計完成之後進行評審第二是在整個詳細用例全部完成之後進行二次評審。如果專案時間比較緊張，盡可能保證對用例設計進行評審，提前發現其中的不足之處。
3、參與評審人員
這裡會分為多個級別進行評審。
1)部門評審，測試部門全體成員參與的評審。
2)公司評審，這裡包括了專案經理、需求分析人員、架構設計人員、開發人員和測試人員。
3)客戶評審，包括了客戶方的開發人員和測試人員。這種情況在外包公司比較常見。
4、評審內容
評審的內容有以下幾個方面
1)用例設計的結構安排是否清晰、合理，是否利於高效對需求進行覆蓋。
2)優先極安排是否合理。
3)是否覆蓋測試需求上的所有功能點。
4)用例是否具有很好可執行性。例如用例的前提條件、執行步驟、輸入資料和期待結果是否清晰、正確期待結果是否有明顯的驗證方法。
5)是否已經刪除了冗餘的用例。
6)是否包含充分的反面測試用例。充分的定義，如果在這裡使用2&8法則，那就是4倍於正面用例的數量，畢竟乙個健壯的軟體，其中80%的**都是在"保護"20%的功能實現。
7)是否從使用者層面來設計使用者使用場景和使用流程的測試用例。
8)是否簡潔，復用性強。例如，可將重複度高的步驟或過程抽取出來定義為一些可復用標準步驟。
5、評審的方式
1)召開評審會議。與會者在設計人員講解之後給出意見和建議，同時進行詳細的評審記錄。
2)通用郵件與相關人員溝通
3)通用im(辦公通訊)工具直接與相關人員交流
方式只是手段，得到其它人員對於用例的反饋資訊才是目的。
無論採用那種方式，都應該在溝通之前把用例設計的相關文件傳送給對方進行前期的學習和了解，以節省溝通成本。
6、評審結束標準
在評審活動中會收集到用例的反饋資訊，在此基礎上進行用例更新，直到通過評審。
測試用例評審
1 測試組內同行評審 2 開發組內評審 1 檢查測試用例是否符合規範 流程清晰 劃分合理 是否採用了合理的測試用例設計方法 用例是否唯 一 有沒有重複 巢狀重複 有沒有考慮異常 有沒有大資料量場景 有沒有考慮冪等 有沒有考慮併發 重複請求 便於橫向比較 提高透明度 展示用例設計能力 2 業務流程有沒...
測試用例評審
關於測試用例評審，很早就有這個想法，但是鑑於以下幾個因素，一直未執行 1.在剛來的時候 6年前，連需求都沒有，到版本提交測試時，才第一次了解到版本做成這樣，測試用例無從談起 2.來了兩三年之後 4年前，測試用例被提起，但是依然無用例 無專案流程，無寫用例時間 3.來了四五年後 兩年前，才開始有專案概...
測試用例評審
首先要清楚內部評審的定義，是測試組內部的評審，還是專案組內部的評審。評審的定義不同，內容也不會相同。測試組內部的評審，應該著重於 測試用例本身的描述是否清晰，是否存在二義性 是否考慮到測試用例的執行效率，往往測試用例中步驟不斷重複執行，驗證點卻不同，而且測試設計的冗餘性，都造成了效率的低下 是否針對...