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

對齊測試用例需求

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

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

快速了解產品

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

橫向業務擴展

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

縱向架構分層

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

以某云的大數據云平臺為例，大數據云平臺的核心是集群。大數據云平臺集群是由一個或多個虛擬機實例組成的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這種格式，本次需求變更，直接全文查找替換一鍵完成。

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

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

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