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

對齊測試用例需求

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

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

快速了解產(chǎn)品

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

橫向業(yè)務擴展

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

縱向架構(gòu)分層

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

以某云的大數(shù)據(jù)云平臺為例，大數(shù)據(jù)云平臺的核心是集群。大數(shù)據(jù)云平臺集群是由一個或多個虛擬機實例組成的Hadoop、Flink、ZooKeeper集群。以Hadoop為例，每個虛擬機實例上通常都運行了一些daemon進程(例如，NameNode、DataNode、ResouceManager和NodeManager)，集群上還可安裝各類大數(shù)據(jù)服務組件(例如：HBase、Hive、Presto、Spark等)。

大數(shù)據(jù)云平臺的橫向核心業(yè)務功能全景線路圖(以Hadoop集群為例)，其核心流程有：Hadoop集群創(chuàng)建->集群管理->大數(shù)據(jù)組件管理->虛擬主機管理-> ... ->Hadoop集群釋放;功能全景如圖1所示：

大數(shù)據(jù)云平臺功能全景

大數(shù)據(jù)云平臺的縱向核心架構(gòu)分層簡化為以下四層，如圖2：

• 最頂層：大數(shù)據(jù)云平臺的門戶控制臺界面【UI】
• 次頂層：大數(shù)據(jù)云平臺的門戶后端API【OpenApi】
• 次底層：大數(shù)據(jù)云平臺的服務端【大數(shù)據(jù)服務組件】
• 最底層：大數(shù)據(jù)云平臺的基礎設施【云服務器】

大數(shù)據(jù)云平臺架構(gòu)圖

快速制定方案

用例覆蓋范圍

從產(chǎn)品業(yè)務功能全景出發(fā)，圍繞PRD(Product Requirement Document)、結(jié)合縱向架構(gòu)層次，用例無死角全面覆蓋產(chǎn)品(論范圍)。

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

(2) 橫向擴展發(fā)散完成后，開始縱向挖掘【深度】，比如，大數(shù)據(jù)云平臺核心架構(gòu)分為四層，每一層都需要拆開了看：

• 最頂層：UI層端對端用例走查(如前面所述)，從頂層UI操作測試除了驗UI結(jié)果、還要確保底層集群服務器上的實際結(jié)果與界面顯示一致
• 次頂層：第二層是門戶后端Api，直接調(diào)用OpenApi的相關測試用例覆蓋
• 次底層：直接操作使用或強干預Hadoop集群服務組件、檢驗整個大數(shù)據(jù)云平臺的質(zhì)量;由于大數(shù)據(jù)平臺上的服務組件非常多(有三十多)，除了單個服務使用外，更要多個常用服務組件搭配組合驗證
• 最底層：直接操作使用或強干預服務器層(增、刪、停、重啟、擴、縮、升、網(wǎng)絡、磁盤、軟件配置等)，檢驗整個大數(shù)據(jù)云平臺的質(zhì)量

到目前為此，大數(shù)據(jù)云平臺整個Hadoop集群的測試用例全部范圍梳理完畢。

用例設計方法

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

• 等價類劃分法(正等價類、負等價類)
• 邊界值分析法(邊界內(nèi)、邊界外)
• 判定表分析法
• 因果圖
• 錯誤推測法

用例編寫原則

• 拆分原則：全文制定統(tǒng)一的邊界。比如：以模塊為邊界、當不同模塊之間有關聯(lián)互動時、預置條件作為分界線，預置條件里的內(nèi)容放在上游模塊驗證。
• 優(yōu)先級原則：【創(chuàng)建】【查看】【使用(啟停等)】【修改】【刪除】為序 【主場景】優(yōu)先、【次要場景】其次 【正例】優(yōu)先、【反例】其次
• 基礎原則：用例無重復、無遺漏， 單一性原則、即一個用例僅覆蓋一個場景清晰的步驟、明確的預期結(jié)果不存在二義性 反復執(zhí)行結(jié)果相同

快速編寫小妙招

制定統(tǒng)一標準

以某云大數(shù)據(jù)云平臺產(chǎn)品為例，很多需求功能統(tǒng)一要求，為此設計一套標準化用例：

• 比如：創(chuàng)建新增的頁面，表單輸入項，需求約束統(tǒng)一要求(是否必填、長度限制、字符要求)，設計一套標準化用例，供其他頁面復用。
• 比如：每個模塊的權(quán)限測試用例，設計統(tǒng)一標準用例;
• 比如：所有的OpenApi測試，都是針對返回碼200、400、401、403、405、500的場景測試;
• 比如：大數(shù)據(jù)平臺服務30多個，每個服務是不同的，但操作是類似：添加、啟動、停止、修改配置、部署，為此設計統(tǒng)一標準用例 (此刻你是否有一種代碼重構(gòu)的既視感，定義一個標準的方法、供大家反復調(diào)用)。

提取公共組件

以某云大數(shù)據(jù)云平臺產(chǎn)品為例，其中包含了10個以上的列表頁面，對于每個列表都有分頁組件、篩選、搜索、排序，這些公共組件的用例抽為【公共組件用例】，設計一套標準化用例，相關頁面復用即可。

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

批量編寫與自動生成

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

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

活用全文替換

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

有一次需求變更：由原來的一級菜單A001下二級菜單B002，變?yōu)榱艘患塁001下D002;由于在整個產(chǎn)品的用例中，從一級菜單進入二級菜單，全部都使用：A001->B002這種格式，本次需求變更，直接全文查找替換一鍵完成。

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

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

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