針對 “測試用例最佳實踐” 的說明

前面開了測試用例最佳實踐這個話題，沒想到反對聲音很多。另外，所列部分條目，沒有直觀的例子，有些同僚不理解什麼意思。決定再開個話題進行詳細剖析說明。

關於 “最佳實踐” 的說法

我的定義是能把工作做得更好的工作實踐，同時也是一個目標。這些條目，我們可以根據實際情況做相應的取捨，沒有強制必須全部做到。但是我們應當把它們作為一個目標，力求全部做到。

是束縛自己嗎？

有些評論說這是吃力不討好，我覺得恰恰相反。首先應該明確，這些不是規則，而是工作方法。採用這些方法，我們能把工作做得更好，直接來說就是更能保障質量，那麼相應的，我們的績效也會更好。反過來，如果不遵循這些實踐，大機率我們也無法保證質量，也就沒辦法把本職工作做好，相應的績效也會不好。

無論功能大小，必須寫測試用例

關於這一條，大家反對最多。關於寫不寫，我只列出寫測試用例的好處：

• 理清思路，避免遺漏。這是最大的好處和目的，因為用例可以讓我們減少漏測。
• 跟蹤測試進度。從用例的執行情況，可以大致估算測試進度。不然只能靠感覺評估。
• 迴歸測試時很有用。
• 問題定責。線上出現問題，從用例中可以判斷是漏測還是用例沒覆蓋。
• 好的用例設計可以避免冗餘測試，節省時間，提升測試效率。當然設計起來也挺難。
• 與同事協同的需要。如果有用例，那麼與其他同事協同會更方便。
• 文件傳承。用例是測試人員很重要的文件沉澱，不僅能體現自己的工作成果和專業性，而且對新人透過用例熟悉業務也是很有幫助的。

有人說自己不寫用例，直接寫程式碼。這種情況本質上是寫了用例的，程式碼就是你的用例。
有人說自己時間不夠，只用思維導圖做了測試分析，列測試點。這種情況其實也是寫了測試用例的，只是用例的質量差。
有人是時間不夠，沒法寫。有兩個辦法，第一是自己想辦法縮短寫用例的時間，比如測試用例最佳實踐中提到的第 5、6、7 點就是針對縮短寫用例的時間的，第二是跟團隊爭取時間，我相信只要有質量意識的團隊，不至於不會給這個時間，再不濟我們也可以透過宣講的方式跟團隊逐漸傳播相關的質量意識，相信團隊會慢慢理解的。

測試用例必須得到嚴格和完整的執行

寫用例只是第一步，我們的目的終究是揭露問題，如果沒有嚴格地執行，那寫了也等於 0。

除了一次性專案，測試用例需要持續維護

部分團隊特別是採用敏捷的團隊，專案迭代很快，並行專案很多，很難有精力去維護用例，特別是用例很多的情況下。但是仔細想一想，用例需要維護的場景，一般是迴歸測試，或者功能改變，不管是哪一種情況，只要我們是對著用例測試的，那麼自然而然就會需要對用例做修改的。如果時間實在不夠，我建議是記錄下改動點，專案緊張時刻過後再找時間修改用例，也是可以接受的。

可以使用版本控制軟體對測試用例進行版本控制

我目前能想到的是三種情形：
1、如果團隊使用專案管理軟體維護用例，那麼一些專案管理軟體是自帶版本控制功能的。如果用例有修改，可以直接在原來的基礎上新建一個版本，比如 PingCode：

2、有些團隊有專門的伺服器用於沉澱文件，一般會有配套的 SVN 等版本控制軟體，那麼可以用此類軟體來進行管理。
3、如果沒有專門的軟體進行管理，也應該在用例文件中記錄下每次改動的內容。以 Excel 文件為例，可以有以下內容記錄用例的每次修改：

使用模板，模板必須簡潔，儘量提供預選項，並且提供必要的統計功能。

使用模板可以使得我們能更快捷地編寫測試用例。
模板必須簡潔是指根據團隊需要，儘量只包含必要的欄位。
提供預選項是指可以提供預選項的欄位，儘量提供，這樣我們在編寫用例的時候，直接透過選擇的方式即可填寫對應欄位。比如以下用例模板，用例級別欄位提供了預選項：

提供必要的統計功能，避免二次的人工統計。比如統計各個實際結果值的用例數、已實現自動化的用例數等等。

應該儘量設計通用的測試用例，避免過於細緻的描述。

舉一個簡單的例子說明。比如現在要測試銷售訂單列表的搜尋功能。
其中的一條用例，操作步驟可以這樣寫：
點選銷售訂單圖示，進入銷售訂單列表，點選搜尋框，輸入訂單編號，回車，觀察結果是否正確。

上面這種寫法就是沒有通用性、描述過於細緻的寫法。

如果採用通用的、避免描述過於細緻的寫法，可以這樣寫：
進入單據列表，點選搜尋框，輸入單據編號，回車，觀察結果是否正確。

使用這種寫法，遮蔽具體的單據型別，對執行用例並無影響，但是用例具有通用性。比如下次你要測試採購訂單列表的搜尋功能的時候，這條用例是可以直接複製、不做修改就可以直接使用的。

除了這種情形，還有其他情形。比如跨平臺的用例，做到 Android 和 IOS 平臺可以使用同一條用例。

可以抽象出公共用例，變成可複用的用例模組

比如我們可以抽象出列印功能、上傳圖片等公共用例，在測試具體的單據的相關功能的時候，可以直接引用用例即可，這樣就節省了很多時間。

維護快速迭代 checklist，應對緊急釋出

與其盲目的測試，還不如維護一份 checklist。剛開始可以很簡單，只覆蓋主流程功能。後面可以慢慢加上一些典型問題，每遇到一個典型問題就加進去。