用例評審目的：

• 為了減少測試人員執(zhí)行階段做無效工作；（執(zhí)行無效case，提交無效問題）

• 為了避免三方需求理解不一致；

• 為了每個測試人員的質(zhì)量標(biāo)準(zhǔn)與項(xiàng)目要求標(biāo)準(zhǔn)達(dá)成一致；

?

用例評審的四個環(huán)節(jié)：

需求評審、需求實(shí)現(xiàn)流程圖評審、測試大綱評審、測試用例檢查

?

• 需求評審：

A 檢查講解的內(nèi)容無丟失

B 檢查需求理解無偏差

C 檢查需求講解思路清晰

D 檢查需求討論會議提出需求建議、需求討論的問題都有體現(xiàn)，并且記錄的詳細(xì)

E 檢查需求講解時存在問題的記錄，跟進(jìn)結(jié)論

?

• 需求實(shí)現(xiàn)流程圖評審：

A 檢查需求以及實(shí)現(xiàn)邏輯內(nèi)容正確

B 檢查需求以及實(shí)現(xiàn)邏輯內(nèi)容齊全,補(bǔ)充流程缺失部分

C 檢查實(shí)現(xiàn)邏輯的深度與仔細(xì)程度

例如：軟件升級實(shí)現(xiàn)邏輯--什么時候獲取服務(wù)器版本信息？版本信息有什么？ 版本信息獲取失敗的處理？獲取的版本信息版本比對策略是什么？比對后的下載邏輯策略是什么？下載的文件保存在哪里？下載過程的失敗處理？下載成功后的安裝策略是什么？安裝失敗的處理邏輯是什么？安裝成功后的數(shù)據(jù)加載時機(jī)以及加載哪些數(shù)據(jù)？ 等等

?

• 測試大綱評審：

A 檢查用例大綱結(jié)構(gòu)、思路清晰

B 檢查用例大綱內(nèi)容齊全--對象齊全\影響因素齊全：

1.需求邏輯功能

2.UI（靜態(tài)+動態(tài)）

3.用戶行為（用戶常用場景， 常用數(shù)據(jù)） ?

4.黑盒用例設(shè)計方法

5.平臺系統(tǒng)的特點(diǎn)（windows，ios，android，web）

6.開發(fā)語言特點(diǎn)

7.發(fā)現(xiàn)過的歷史bug

8.自身的版本兼容性

9.功能之間相互影響

10.開發(fā)實(shí)現(xiàn)邏輯和建議

C 檢查用例大綱語言描述清晰

D 檢查用例去除冗余用例

E 檢查用例進(jìn)行集成，為測試執(zhí)行的高效做準(zhǔn)備

（由于我們是面向?qū)ο蟮挠美O(shè)計思想，會把流程拆分成幾段，所以在執(zhí)行的時候不夠流暢，因此需要將case整合集成）

?

• 測試用例檢查：

（站在正規(guī)化測試用例的角度進(jìn)行用例的審核）

A 檢查大綱和用例內(nèi)容一一對應(yīng)，影響因素?zé)o丟失

B 檢查語言描述簡潔、清晰、明了

C 檢查每條測試用例都有明確的預(yù)期結(jié)果

D 根據(jù)正規(guī)化用例的各個字段要求對應(yīng)的細(xì)節(jié)

（測試目的、前提條件、實(shí)現(xiàn)說明、測試環(huán)境準(zhǔn)備、測試步驟、優(yōu)先級別、是否自動化等）

?

轉(zhuǎn)載于:https://www.cnblogs.com/dayaodao/p/5666053.html

總結(jié)

以上是生活随笔為你收集整理的如何评审功能测试用例？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。