高效編寫測試用例的技巧

本話題暫不探討是否有必要編寫詳細的測試用例，在確定要交付詳細的測試用例這個前提下，分享如何更高效地完成測試用例的編寫。

對齊測試用例需求

首先、明確要完成的測試用例文檔目標要求，模板、範圍、粒度等。

**用例文檔使用者：測試人員用例文檔範圍：覆蓋產品所有需求用例模板內容：**編號、模塊、子模塊、測試功能點、預置條件、數據、步驟、預期結果、優先級、用例類型、關聯需求、(編寫人、更新時間、執行人、狀態、執行時間、執行結果) **測試用例粒度：所有功能的正反用例測試用例驗收負責人：**活久見（對齊目標）

快速瞭解產品

最快的速度熟悉產品業務背景與技術架構，從而勾勒出測試用例整體框架。任何一款產品，最終都能映射到【橫向擴展】+【縱向分層】的組合模式下來完成用例覆蓋。

橫向業務擴展

是指產品輔平來看，總共有哪些業務場景，提供了哪些能力，即產品最上層的功能全景。

縱向架構分層

是指從產品的技術架構層面來分析，當前產品可以宏觀上分爲幾層，以便於在用例驗證是從不同層次上進行驗證和用例覆蓋。

以某雲的大數據雲平臺爲例，大數據雲平臺的核心是集羣。大數據雲平臺集羣是由一個或多個虛擬機實例組成的 Hadoop、Flink、ZooKeeper 集羣。以 Hadoop 爲例，每個虛擬機實例上通常都運行了一些 daemon 進程（例如，NameNode、DataNode、ResouceManager 和 NodeManager），集羣上還可安裝各類大數據服務組件（例如：HBase、Hive、Presto、Spark 等）。大數據雲平臺的橫向核心業務功能全景線路圖（以 Hadoop 集羣爲例），其核心流程有：Hadoop 集羣創建 -> 集羣管理 -> 大數據組件管理 -> 虛擬主機管理 -> ... ->Hadoop 集羣釋放；功能全景如圖 1 所示：

大數據雲平臺功能全景

大數據雲平臺的縱向核心架構分層簡化爲以下四層，如圖 2：

• 最頂層：大數據雲平臺的門戶控制檯界面【UI】

• 次頂層：大數據雲平臺的門戶後端 API【OpenApi】

• 次底層：大數據雲平臺的服務端【大數據服務組件】

• 最底層：大數據雲平臺的基礎設施【雲服務器】

大數據雲平臺架構圖

快速制定方案

用例覆蓋範圍

從產品業務功能全景出發，圍繞 PRD（Product Requirement Document）、結合縱向架構層次，用例無死角全面覆蓋產品（論範圍）。

(1) 水平方向拓寬【寬度】，圍繞它的產品的主生命週期由大模塊至小模塊、主功能至次要功能逐步擴展枝葉，借用魚骨圖梳理（如下圖 3）或 Xmind 腦圖來整理。先梳理內部，然後梳理外部對接的服務或產品場景（如：消息中心、費用中心、告警中心、文檔中心、數據開發等等)。

(2) 橫向擴展發散完成後，開始縱向挖掘【深度】，比如，大數據雲平臺核心架構分爲四層，每一層都需要拆開了看：

• 最頂層：UI 層端對端用例走查（如前面所述），從頂層 UI 操作測試除了驗 UI 結果、還要確保底層集羣服務器上的實際結果與界面顯示一致

• 次頂層：第二層是門戶後端 Api，直接調用 OpenApi 的相關測試用例覆蓋

• 次底層：直接操作使用或強幹預 Hadoop 集羣服務組件、檢驗整個大數據雲平臺的質量；由於大數據平臺上的服務組件非常多（有三十多），除了單個服務使用外，更要多個常用服務組件搭配組合驗證

• 最底層：直接操作使用或強幹預服務器層（增、刪、停、重啓、擴、縮、升、網絡、磁盤、軟件配置等），檢驗整個大數據雲平臺的質量

到目前爲此，大數據雲平臺整個 Hadoop 集羣的測試用例全部範圍梳理完畢。

用例設計方法

從測試類型出發，有功能與非功能測試用例覆蓋。本次不需要交付非功能用例，因此不展開；功能性用例設計方法：

• 等價類劃分法（正等價類、負等價類）

• 邊界值分析法（邊界內、邊界外）

• 判定表分析法

• 因果圖

• 錯誤推測法

用例編寫原則

• 拆分原則：全文制定統一的邊界。比如：以模塊爲邊界、當不同模塊之間有關聯互動時、預置條件作爲分界線，預置條件裏的內容放在上游模塊驗證。

• 優先級原則：【創建】【查看】【使用（啓停等）】【修改】【刪除】爲序 【主場景】優先、【次要場景】其次 【正例】優先、【反例】其次

• 基礎原則：用例無重複、無遺漏， 單一性原則、即一個用例僅覆蓋一個場景清晰的步驟、明確的預期結果不存在二義性 反覆執行結果相同

快速編寫小妙招

制定統一標準

以某雲大數據雲平臺產品爲例，很多需求功能統一要求，爲此設計一套標準化用例：

• 比如：創建新增的頁面，表單輸入項，需求約束統一要求（是否必填、長度限制、字符要求），設計一套標準化用例，供其他頁面複用。

• 比如：每個模塊的權限測試用例，設計統一標準用例；

• 比如：所有的 OpenApi 測試，都是針對返回碼 200、400、401、403、405、500 的場景測試；

• 比如：大數據平臺服務 30 多個，每個服務是不同的，但操作是類似：添加、啓動、停止、修改配置、部署，爲此設計統一標準用例 （此刻你是否有一種代碼重構的既視感，定義一個標準的方法、供大家反覆調用）。

提取公共組件

以某雲大數據雲平臺產品爲例，其中包含了 10 個以上的列表頁面，對於每個列表都有分頁組件、篩選、搜索、排序，這些公共組件的用例抽爲【公共組件用例】，設計一套標準化用例，相關頁面複用即可。

注意：統一標準用例中，可變的項用 {ABC} 來替換，比如：在集羣查看列表中篩選集羣狀態時，把統一標準用例中的 {ABC} 替換成 {集羣狀態} 即可。

批量編寫與自動生成

在用例編寫過程中，發現很多情況除了 {某名稱或字段} 不同，其它都是一樣的，此時可以批量編寫（如：藉助 Sublime 或直接傳變量用代碼生成），這樣也可以大大提高編寫效率。

在編寫 OpenApi 相關測試用例時，直接定義出一套 OpenApi 標準用例，以 QA 設計出的標準用例爲模板，然後編寫代碼生成用例，通過讀取 OpenApi 的 Json 文件，快速生成 71 個 Api 的測試用例，近 1000 條詳細測試用例，高效。

活用全文替換

編寫用例時，QA 人員一定要用統一語言文字或格式，一來是給閱讀的人方便、二來是方便查找替換，即通過全文查找替換能 快速維護用例。

有一次需求變更：由原來的一級菜單 A001 下二級菜單 B002，變爲了一級 C001 下 D002；由於在整個產品的用例中，從一級菜單進入二級菜單，全部都使用：A001->B002 這種格式，本次需求變更，直接全文查找替換一鍵完成。

前邊提到過設計了多套統一標準用例，新的頁面複用時，直接替換變量內容，生成當前用例。又或者需求變更的剛好是統一標準用例的內容，活用全文查找替換、一分鐘搞定用例維護。

總之，必須要總結一套自己的方法來應對這麼龐大的編寫工作量，否則在短期的時間內無法完工。而高效編寫用例的秒招，離不開可複用、找共性、提煉統一標準，借用一些手段或工具自動生成。

結尾送君一句話：劃清領域邊界、高複用、低耦合。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/54y4H0zI8itUfk5HESzTkg