測驗工程師都是怎么寫測驗用例的？

開發提測之后，就照著測驗用例點點點，可能一天就走完用例了，開發代碼寫得真好，測驗用例執行完畢都沒有測出bug，然后美其名曰：測驗完了，達到上線標準，

測完之后，測驗用例毫無價值，像隨手仍垃圾一樣，隨地保存，終于無跡可尋，

在他們眼里，從事測驗作業，和去東莞進廠打工沒什么區別，

反正測驗用例寫久了，都能成為人人愛戴的熟練工，想著到了35歲，光榮下崗，回老家享受榮華富貴，

最后上線之后，bug一大堆，反而還怪寫測驗用例浪費時間，且沒有用，

目錄

1. 明確為什么要寫測驗用例？
2. 傳統的測驗用例撰寫規范？
3. 臻叔獨創的測驗用例撰寫大法？
4. 沒時間寫測驗用例怎么辦？
5. 全量的測驗用例是否有必要？
6. 測驗用例應當如何保存？

一、為什么要寫測驗用例？

或者說，寫測驗用例到底有什么用？

敲黑板！測驗用例主要有以下六大作用：

1. 方便理清測驗思路，避免漏測
2. 有助于測驗作業量的評估
3. 便于提前準備測驗資料
4. 相當于作業日志，把控測驗作業進度
5. 方便進行上線前的回歸測驗
6. 便于測驗作業的組織，提高測驗效率，降低測驗交接成本

所以，寫測驗用例是很有必要的！

那些沒有寫測驗用例、或者說寫測驗用例沒有用的，都是沒有掌握測驗用例的使用姿勢，

二、傳統的測驗用例撰寫規范

一般寫測驗用例，大家習慣于用 「Excel（表格）」 或者 「Xmind（思維腦圖）」，

一般用 Excel 要表達的元素有：用例編號、用例標題、測驗專案、用例級別、預置條件、測驗輸入、執行步驟、預期結果，

比如說，我們要測驗一個“常規搜索關鍵詞輸入”的功能，我們用 Excel 來表達，類似下圖所示：

假如我們用 Xmind 來撰寫測驗用例，大概呈現成：

可以看到用 Excel 和 Xmind 去設計測驗用例，粒度以及使用場景都不太相同，

「在一些功能比較單一、步驟簡單、輸入和預期比較明確的場景，可以采用 Excel 的風格去撰寫測驗用例，」

「在一些功能比較繁雜、依賴測驗人員的主觀能動性的場景，可以采用 Xmind 的風格去撰寫測驗用例，」

三、測驗用例撰寫模版

現在在互聯網公司，產品迭代很快，功能也比較復雜，

如果用 Excel 去設計測驗用例的話，會花費比 Xmind 更多的時間去撰寫，而且編輯維護、可讀性等等，都比較差，

專案這么緊急，用 Excel 去寫測驗用例，顯然是不合理的，

「所以用 Xmind 的方式去撰寫測驗用例，在互聯網測驗圈子里面也是深得人心，」

「但是，在一些回歸驗證的場景，是可以用 Excel 去寫測驗用例的，我們習慣把回歸用例當作上線 CheckList，逐條去驗證，防止遺漏，」

小細節

• 日常測驗作業，用 Xmind 去撰寫測驗用例，
• 上線環節，用 Excel 去撰寫回歸用例，確保萬無一失，

那么，我們日常測驗，「用 Xmind 撰寫測驗用例時，需要注意些什么呢」？

1. 「照抄產品需求檔案沒有必要的！」 這么做的壞處是：做了很多重復作業，而且思維容易被產品思維框住，有些不合理的地方或許難以發現，
2. 「測驗用例一定是可執行的！」
3. 「測驗用例并不是寫得越多越好」，寫得太多，可讀性很差，也會無形之間給自己增加心理壓力，而且根據二八原則，80%的bug都出現在20%的主流程上面，那例外測驗做不做？當然要做！但是千萬不要把例外測驗作為重點，重點應該是站在用戶的角度，優先保證核心主流程，
4. 「測驗用例要體現測驗目標」，注意，這里不僅僅是預期，而是測驗目標，要明白測驗這條用例，到底目的是啥，產品功能和意圖是否已經實作，
5. 測驗用例設計最好遵循金字塔原理，「盡量窮盡，完全獨立，避免太多重復的用例」，
6. 「測驗用例千萬要做好分等級」，優先重點，
7. 根據測驗用例逐條進行測驗時，還可以在「測驗用例上做一些標注」，標記測驗情況，
8. 測驗用例不僅僅是用例，對于一些構造的「測驗資料也可以在測驗用例上體現出來」，方便后續回歸驗證，
9. 「測驗用例需要注明用例基本資訊」，還可以記錄一些檔案的鏈接（比如需求檔案、技術檔案）等等，
10. 「用盡可能少的用例，覆寫絕大部分的測驗場景」，

所以，新式的測驗用例，感覺不該叫測驗用例，應該叫 「“測驗日志”」 更加合適，

下面，我將把我是「如何構思和設計測驗用例」，一步一步給大家呈現出來，是時候展示真正的技術了！

第一步，把測驗用例的基本資訊表示出來，

基本資訊包含：「干系人、測驗范圍、用例說明、關聯檔案」等等資訊，

有了這些資訊，就可以把測驗用例當成一個入口，提升查找相關檔案的效率，

?

第二步，開始寫測驗用例，

這一塊可以因人而異去設計，遵循幾個原則：「不要照抄需求檔案、設計的用例都是可執行的、用例做到分級、盡量窮盡，完全獨立，避免太多重復的用例」，

設計用例的時候，最好可以從測驗目標出發，再進行向下延展，

舉個例子：

第三步，用例評審，

用例評審就是拉個會，喊上開發、產品和設計，針對撰寫好的測驗用例進行評審，這個環節需要在開發提測之前進行，

主要目的：

• 溝通測驗用例有沒有遺漏的地方，評估當測驗用例執行完，沒有bug的情況下，是否可達到上線標準，
• 和開發約定好，在開發自測階段，開發需要保證冒煙測驗用例能夠通過，冒煙用例通過基本上可以作為提測標準，
• 和開發、產品對接好上線前的驗收標準，

第四步，執行用例，

一邊執行用例，一邊做好標記，方便查處bug之后，后續有針對性的去驗證，而不是又從頭把用例再走一遍，提升回歸驗證的效率，

另外，對于測驗程序中，用到的一些測驗資料，也可以直接在用例上標注出來，提高后續回歸測驗的效率，

「當測驗完畢，達到上線標準之后，我們需要準備一份 CheckList，在上線當天使用」，

CheckList 比較強調步驟性，所以適合用 Excel 去表達，

上線無小事，一定得謹慎！

所以，知道怎么寫測驗用例了么？

下面是閑聊時間，我想和大家一起聊聊三個很現實的問題：

• 「沒時間寫測驗用例怎么辦？」
• 「全量的測驗用例是否有必要？」
• 「測驗用例應當如何保存？」

四、沒時間寫測驗用例怎么辦？

身處互聯網公司，專案時間緊，三天兩頭就要上線一個新功能，這是常態，

有的測驗老司機在這種情況下，就放棄寫測驗用例，直接上手就測，其實這是很不好的習慣，

寫測驗用例不是面子工程，沒有必要追求極致，寫得像滿分作文一樣，

「其實寫測驗用例最主要的作用，就是幫助測驗人員提升作業效率」，

一方面，通過寫測驗用例可以對需求更加熟悉，腦子理順；

另一方面，測驗用例可以更好的指導你進行測驗作業，尤其是你做好測驗標記之后，對于后續驗bug很有必要，

不寫測驗用例，不應該拿時間緊作為借口，

「我們應該根據需求的重要程度、難易程度來評定要不要寫測驗用例，」

如果是一些緊急且重要的需求，那肯定要寫測驗用例；如果只是一句話的需求、幾個文案的改動，那這種不寫測驗用例也罷，

都是成年人了，應該要有判斷力，

五、全量測驗用例是否有必要？

以前入職一家新公司，導師總會要求新員工去寫一份全量的測驗用例，或者說丟一份很全的用例給新員工去閱讀，說是幫助新員工更好的熟悉系統，

但是作業久了，我發現這對于新員工的培養，并不能起到什么效果，反而讓新員工產生厭煩的心理，

寫一份全量的測驗用例是沒有意義的，就像你讓一個小學生去背字典一樣，毫無意義，

「那怎樣讓新員工更好的融入到作業當中，快速上手呢？」

最好的辦法就是將心比心，你「把自己所有的檔案分門別類，多畫點系統架構圖、流程圖，新員工培養手冊等等，把這些給到新員工」，我覺得是比丟一個全量測驗用例給一個測驗新手更有用，

六、測驗用例應當如何保存？

當然不是隨手一丟，仍垃圾桶，

如果公司有條件的話，可以有個用例平臺，把 專案-需求-測驗用例 進行關聯，后續遇到bug，都可以有跡可循，方便總結和回溯，

如果公司沒有那么好的條件，可以用gitlab進行維護，進行版本控制，

位元組跳動推出了飛書，里面的飛書檔案也是特別香的，自帶檔案管理功能，而且還有飛書腦圖可以替代 Xmind 進行測驗用例撰寫，也是一種不錯的保存測驗用例的方案，

最后感謝每一個認真閱讀我文章的人，作為一位過來人也是希望大家少走一些彎路，在這里我給大家分享一些自動化測驗的學習資源，如果你用得到的話可以直接拿走，希望能給你前進的路上帶來幫助，（包括Python編程、WEB自動化測驗、app自動化測驗、介面自動化測驗、測驗框架、持續集成、自動化測驗開發、性能測驗、安全測驗、大廠面試真題、簡歷模板等等、當然還有一些測驗基礎、工具、app測驗、介面測驗、linux、mysql資料庫等基礎知識），相信能使你更好的進步！這些學習資料我都放在我的測驗學習交流裙：1033482984 里面了，同時還有幾千個行業大佬相互進行技術交流、經驗分享，如果你也感興趣，那么期待你的加入，

原文轉載于：公眾號：軟體測驗小dao

標籤：其他

上一篇：面試官：作業三年，還來面初級測驗？恐怕你的軟體測驗工程師的頭銜要加雙引號...

下一篇：返回列表