作為一個合格的測試工程師，必須掌握測試的日常工作流程。

那么在一個產品周期里面，測試工程師是什么時候介入工作的呢？具體承擔了哪些工作呢？這兩問題，也是在日常面試中經常遇到的，這里我用一張思維導圖進行簡單的概括（如下圖）

今天我們就來說說“測試用例設計”和“測試用例評審”。

測試用例設計

常見的測試用例方法大家都在網上和日常測試過程中都有用到過。這里給大家講解一些特殊的測試點該如何進行用例設計。

詳情頁字段校驗

方法：場景組合設計用例

實現：同一個詳情頁不同字段，通過場景組合用例設計，可實現在“同一條測試數據”的基礎上，校驗“不同字段，不同枚舉值”，節約測試工作量。

通過上面這個場景，實現在“同一條測試數據”的基礎上，校驗“不同字段，不同枚舉值”。

原本需要8條測試用例，經過“場景用例設計”后，只需要3條測試用例即可校驗。

查詢條件校驗

方法：全局到細化

實現：

2.1全局校驗查詢條件字段是否齊全或正確

2.2具體查詢條件功能校驗

測試用例評審

由于設計測試用例的標準：一條用例盡可能只驗證一個點。

所以測試人員設計的測試用例對開發來說簡直是“又臭又長”。 在測試用例評審時，大部分開發估計都在神游。評審會議時間長達一兩個小時，但是對開發來說有效的吸收不到百分之一。

那么如何有效的進行用例評審呢？

用例標注重點

需求疑問：在經過產品確認后，輸出具體測試用例

設計交互：UI未提供交互，需求文檔未描述的功能的實際交互細節

......

以上在設計測試用例過程中，【未在需求文檔中明確描述&在設計測試用例過程中已同產品確認】，需要在用例評審中著重提醒開發，保持信息同步。

邏輯概述+核心評審

業務流程較為繁長的測試用例條數較多，少則上百，多則上千，逐一講解，不論是對開發或產品，甚至測試本身，都會出現前后文銜接不上。此時可以使用“全局流程+局部細”的方式來評審測試用例。

全局流程-邏輯概述

借助“Xmind”思維導圖，進行簡要的邏輯概述，闡述用例描述的基礎流程。

該階段描述后，經產品和開發確認無疑問，則進行用例評審時，可略過該部分的基礎測試用例。

局部細節-突出核心細節用例

除了基礎業務流程外的，一些特殊場景細節的測試用例，可能影響業務流程或對公司造成損失，使用加粗/顏色標注，在用例評審時著重提醒開發。

特殊場景包括：

前后端數據同步交互、多人同時操作數據等，以下為邏輯校驗的核心測試用例（僅供參考）

總結

不論是在測試用例設計或者是在用例評審時，使用“先概述，后細節”的方式，不論是對開發或者測試本身都有益處。

針對測試：

• 保持清晰的評審邏輯，避免評審時出現混亂
• 提高用例評審的效率，節約團隊時間成本
• 提高開發對測試用例的重視

針對開發：

• 節約精力，提高對核心用例的重視和吸收
• 及時改善代碼設計缺陷，提高開發質量

......

總結

以上是生活随笔為你收集整理的【实战】如何有效的进行测试用例评审（测试用例评审又臭又长，怎么办）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。