一 .用例評審目的

為用例評審提供一個參考標準，保證評審的覆蓋率和有效性

• 為了避免三方需求理解不一致
• 保證測試人員的質(zhì)量標準與項目標準一致
• 為了減少測試人員執(zhí)行階段無效工作
• 保證相關(guān)人員對即將要上線的需求有了解

二. 用例評審作用

1.對于產(chǎn)品經(jīng)理

• 檢查測試人員是否準確理解需求，確保每個需求點都覆蓋到。
• 通過評審正常和異常的測試用例，來反思當時設(shè)計需求時未考慮的情況，也是自我回溯的一個過程。

2.對于開發(fā)人員

• 檢查自己的程序代碼是否還有很多情況未考慮完善，對自己的代碼也是一個自我回溯檢查的過程，間接實現(xiàn)了測試左移。
• 對于用例中無法實現(xiàn)的邏輯及時溝通，三方達成高度一致。

3.對于測試人員

• 與各方人員溝通，完善測試用例

三.用例評審參與人員

用例評審一定是要求產(chǎn)品（制定該需求的產(chǎn)品經(jīng)理）、開發(fā)（實現(xiàn)該產(chǎn)品的前后端開發(fā)人員）、測試（負責該需求用例編寫和執(zhí)行的測試人員）都參與。

會議由測試人員主導(dǎo)，相應(yīng)需求的測試同學(xué)依次上去講解自己的測試用例。

• 測試組內(nèi)部的評審：測試部門成員參與
• 項目組內(nèi)部的評審：項目經(jīng)理、產(chǎn)品人員、開發(fā)人員和測試人員參與

四. 用例評審內(nèi)容

1.一般用例評審內(nèi)容

• 用例設(shè)計的結(jié)構(gòu)安排是否清晰、合理，是否利于高效對需求進行覆蓋。
• 優(yōu)先極安排是否合理。
• 是否覆蓋測試需求上的所有功能點。
• 用例是否具有很好可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數(shù)據(jù)和期待結(jié)果是否清晰、正確；期待結(jié)果是否有明顯的驗證方法。
• 是否已經(jīng)刪除了冗余的用例。
• 是否包含充分的負面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數(shù)量，畢竟一個健壯的軟件，其中80%的代碼都是在“保護”20%的功能實現(xiàn)。
• 是否從用戶層面來設(shè)計用戶使用場景和使用流程的測試用例。
• 是否簡潔，復(fù)用性強。例如，可將重復(fù)度高的步驟或過程抽取出來定義為一些可復(fù)用標準步驟。

2.測試組內(nèi)部評審側(cè)重

• 測試用例本身的描述是否清晰，是否存在二義性；
• 是否考慮到測試用例的執(zhí)行效率.往往測試用例中步驟不斷重復(fù)執(zhí)行，驗證點卻不同，而且測試設(shè)計的冗余性，都造成了效率的低下；
• 是否針對需求變更進行跟著，覆蓋了所有的軟件需求；
• 是否盡可能多的覆蓋了異常流程和異常測試點。

3.測試用例評審檢查項

• 測試用例是否按照公司定義的模板進行編寫的；
• 測試用例的本身的描述是否清晰，是否存在二義性；
• 測試用例內(nèi)容是否正確，是否與需求目標相一致；
• 測試用例的期望結(jié)果是否確定、唯一的；
• 操作步驟應(yīng)與描述是否相一致；
• 測試用例是否覆蓋了所有的需求；
• 測試設(shè)計是否存在冗余性；
• 測試用例是否具有可執(zhí)行性；
• 是否從用戶層面來設(shè)計用戶使用場景和業(yè)務(wù)流程的測試用例；
• 場景測試用例是否覆蓋最復(fù)雜的業(yè)務(wù)流程；
• 用例設(shè)計是否包含了正面、反面的用例；
• 對于由系統(tǒng)自動生成的輸出項是否注明了生成規(guī)則；
• 測試用例應(yīng)包含對中間和后臺數(shù)據(jù)的檢查；
• 測試用例應(yīng)有正確的名稱和編號；
• 測試用例應(yīng)標注有執(zhí)行的優(yōu)先級；
• 測試用例包含相關(guān)的配置信息：測試環(huán)境、數(shù)據(jù)、前置測試用例、用戶授權(quán)等；
• 每個測試用例步驟應(yīng)<=15?Step；
• 自動化測試腳本必須帶有注釋（注釋應(yīng)包括：目的、輸入、期望結(jié)果等）；
• 非功能測試需求或不可測試需求是否在用例中列出并說明

五.用例評審方式

• 線上會議
• 線下會議
• 通用OA與相關(guān)人員溝通

六.用例評審時間

• 測試用例完成后
• 需求文檔提交后，開發(fā)提測前
• 會議時間最好控制在1小時之內(nèi)，如果內(nèi)容較多，可多次評審

七.用例評審流程

1.會前準備

• 測試用例編寫完成
• 提前通知參會人員，約定好評審時間并預(yù)約好會議室
• 提前將測試用例發(fā)送給參會人員查閱
• 會議5分鐘前到達會議室，將測試用例，需求文檔等打開
• 用例較多時，提前做好標注，優(yōu)先講解優(yōu)先級高的用例，并盡量將前后端用例區(qū)分，方便側(cè)重評審
• 將自己的疑惑整理在一起，方便詢問

2.會中流程

2.1方式1：對照測試用例，從上而下，從左到右，逐條念。

普遍的流程都是這樣的。

• 優(yōu)點：逐個講解，全面仔細
• 缺點：費時，不分主次，降低參會人員的注意力

2.2方式2：先對功能復(fù)雜，優(yōu)先級高，疑問多的用例進行評審，再評審功能簡單，優(yōu)先級低的功能點。

優(yōu)先講解優(yōu)先級高的用例，其次疑惑多的用例，再者功能簡單，優(yōu)先級低的功能點。

• 優(yōu)點：有側(cè)重點，效率高
• 缺點：講解不全面，可能存在忽略點

2.3會議注意

• 對于評審過程中，超過5分鐘無法確定結(jié)果的問題，可以記錄下來，作為會后討論跟進的重點。
• 評審過程中盡量做到，思路清晰，用最簡潔的語言闡述每一個功能點。
• 對于有歧義的問題，需要與產(chǎn)品和開發(fā)確認清楚。
• 評審過程中，參會人員可能會有視覺和聽覺疲勞，主講人要抓住重點和重要人員。
• 對于評審過程中的問題，及時做好標記。
• 用例評審只針對用例，不針對個人能力。

3.會后總結(jié)

3.1用例評審會議后，需要對評審中的問題進行跟進和完善。

• 需要產(chǎn)品經(jīng)理補充和修改的點需要讓其在需求文檔和原型圖上進行記錄
• 對遺漏的測試點進行補充，對有誤的測試點進行修正，并對用例進行管理

3.2如有要求，完成用例評審文檔

3.3對個人會議行為進行總結(jié)

七.用例評審結(jié)束標準

• 評審過程中收集相關(guān)人員的反饋信息（即問題記錄清單），并在此基礎(chǔ)上進行測試用例更新，直到評審?fù)ㄟ^。
• 評審結(jié)束后，測試負責人出測試用例評審報告給到相關(guān)人員。
• 評審結(jié)果經(jīng)項目經(jīng)理同意確認

說明：具體根據(jù)公司要求，部分公司并不要求完成用例評審報告，那么可以進行自我總結(jié)復(fù)盤。文章來源地址http://www.zghlxwxcb.cn/news/detail-528265.html

到了這里，關(guān)于【軟件測試】測試用例評審說明的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！