如何優雅編寫測試用例

轉載請註明出處❤️

你好，我是測試蔡坨坨。

上次我們說到測試用例的設計（可參考往期文章「測試用例設計的底層邏輯」）。

當你學會了如何設計測試用例之後，接下來便是開始用例的編寫。

在設計階段，更準確的說應該是識別測試點的過程，而編寫階段則是將測試點細化成一條條測試用例的過程，有了比較全的用例場景後，如何讓別人更舒服、更方便、更清晰地去使用你的測試用例，如何更優雅地展示你的測試用例，如何讓領導對你的測試用例滿意呢？（「降本增效」，這裡的「效」有時也指的是「效果」）

測試用例的編寫是每一個測試工程師安身立命的傢伙，也是測試的基礎，更是軟體測試的核心內容，正所謂「基礎不牢，地動山搖」，所以一定要掌握好，有些轉行的小夥伴一上來就開始自動化、效能的學習，卻忽略了最基礎的東西，這是不對的。

正好最近有小夥伴問到關於用例模板的問題，藉此機會來聊一聊「如何優雅編寫測試用例」這個話題。

PS：需要用例模板的加V獲取。

在編寫測試用例之前，首先應該根據所在公司、專案組的特點，提前制定好對應的測試用例模板以及用例維護方式，比如：Excel、XMind、TestLink、禪道等。

測試用例的組成通常包含以下內容（具體欄位根據業務需要取捨）：

用例編號

作為測試用例的唯一標識。編號取值規則可以根據專案名稱各中文首字母大寫+六位數位構成，例如：「蔡坨坨電商專案」在登入功能子模組的第一條用例編號可取值為CTTDS_000001。
用例標題

又稱之為測試點，用一句話來描述測試用例的關注點，每一條用例對應一個測試目的。

一個好的測試用例應該關注標題的規範性，一般來說如果設計用例標題不規範，別人在使用你的測試用例時，就無法做到清晰明瞭，就會浪費很多時間在溝通上。

並且需要控制用例的粒度，從測試執行者的角度來說，過細的測試用例會讓執行者感到疲憊繁瑣，過粗的測試用例又容易導致檢查點遺漏。所以測試用例標題一般控制在30個字以內。
功能模組

根據專案模組層級關係填寫，例如：組織許可權。
測試目的

簡要的測試目的，例如：賬號密碼功能校驗。
前置條件

用例在執行之前需要滿足的一些條件，否則用例無法執行，如測試環境，需要提前執行的操作等，例如：進入到某一頁面。

測試用例其實就是在某種場景下，執行一定的動作，達到什麼樣的結果。而前置條件決定了「在某種場景下」，所以是不可或缺的。
優先順序

根據需求的優先順序來定義，高優先順序要覆蓋核心業務，重要特性以及使用頻率比較高的部分。

級別的列舉值也有多種形式，比如：P0\P1\P2\P3，1\2\3\4，高\較高\中\低。

冒煙測試（高）、基礎用例（較高）、特殊場景用例（中）、錯誤場景用例（低）。
操作步驟

測試用例的步驟描述，執行人員可以根據測試步驟完成測試的執行，一般只需要寫和測試目的密切相關的步驟，一些基礎的步驟可以放在前置條件中，例如：1.輸入正確的賬號2.輸入錯誤的密碼3.點選登入按鈕4.檢視結果。

用例步驟一般不多於7步，不少於2步。

操作步驟也是不可或缺的一部分，因為它關係到如何執行。
測試資料

在執行測試時，需要輸入一些外部資料來完成測試。這些資料根據測試用例的統計情況來確定，有引數、檔案或資料庫記錄等，例如：賬號：admin，密碼：123456。
預期結果

測試用例中最重要的部分，主要用來判斷被測物件是否正常，例如：提示使用者名稱或密碼錯誤。

預期結果關係到用例需要達到什麼樣的結果，所以也是不可或缺。
執行結果

每條用例的實際執行結果，只有三個列舉值：PASS（通過）、FAIL（不通過）、N/A（未執行）。

預期結果一般不超過5個，不少於1個。
對應的 Bug Id

每條測試用例執行不通過後再記錄對應一條Bug，例如：BUG-1219。
編寫人

用例對應的編寫人員，填寫編寫人員姓名，例如：測試蔡坨坨。
執行人

用例對應的執行人員，填寫執行人員姓名，例如：測試蔡坨坨。
備註

每條測試用例的備註，備註內容可以按實際情況填寫，一般有備註的測試用例都比較重要，需要格外關注。

測試用例的編寫並沒有好壞和對錯之分，每個人編寫用例的思路也是各不相同，適合當前團隊就是最好的，不要盲目把所有的欄位都加上，應根據實際場景進行取捨。

除此之外，還有一些注意事項值得關注。

例如：

標題要清晰，推薦採用 場景+預期結果 進行描述，比如：輸入正確的使用者名稱和密碼，成功登入系統；

控制用例的粒度，比如：標題字數不超過30個字、步驟數控制在2-7步、預期結果數在1-5個；

用例之間要解耦，日常工作中經常遇到幾個用例有先後順序的情況，比如：在測試編輯之前肯定要先新建一條資料，最好把新建放在編輯用例的前置條件中，每條用例都能實現閉環；

預期要明確，不要出現一些模糊字眼，對於不明確的點應該跟產品溝通；

拒絕冗餘，用例可以多，但不要冗餘，儘可能以最小場景覆蓋最全的範圍，同一個等價類只需測一條資料，當然，因為測試不可窮盡性，測試場景肯定不會最全面，往往會受限於時間和資源等成本，這時需要在有限的資源下，尋求質量和效率之間的平衡點，優先順序這個欄位就起到了作用，再引申就是測試策略的問題了，整體上採取基於風險驅動的模式，有側重點地去驗證一些場景，優先核心功能，或者增加資源和延長週期，同時尋求自動化相關技術去提升整體效率。