你們測試用例越來越多，刪不刪？

7 人贊了文章

你們測試用例越來越多，刪不刪？

測試用例怎麼寫出來的

在聊「測試用例怎麼沒的」之前，先看看「測試用例是怎麼來的」。

• 需求驅動，在迭代中增加測試用例

1. 我們通常會做需求評審，消除「需求二義性」，準確的理解需求。
2. 我們通常會和開發討論設計方案，講需求中的內容通過「時序圖」、「流程圖」、「狀態機」等UML做標準化的表達。
3. 我們通常會基於「狀態遷移覆蓋」、「時序交互異常」、「流程判斷覆蓋」等方法去設計測試用例，保證每個場景都能覆蓋到。

• 缺陷驅動，補充異常測試用例

1. 不幸的是，系統往往會出現這樣那樣的缺陷。
2. 為了讓出過的問題不再出，我們總是會基於缺陷去補充測試用例，期望提前發現老問題。
3. 這些測試用例通常需要運行在「某種故障環境」下，常常需要「故障注入」等技術的輔助。

• 風險驅動，補充全鏈路測試用例

1. 在SOA/微服務等模式下，我們做好對單一系統的測試是不夠的。
2. 同樣的，我們的功能場景通常也需要串起來；例如「創建券」->「發券」->「領券」->「用券」這個場景，會出現分開驗證都正確，合到一起就有問題的情況。
3. 這些測試用例通常需要運行在「穩定的系統集群」下，常常需要對「環境穩定性」、「搭環境效率」提出要求。

• 效能驅動，對測試代碼進行重構，出現了新的測試代碼

1. 為了讓測試用例對被測對象持續有效，我們通常會把測試用例自動化，並CI。
2. 用代碼測代碼，靠譜嗎？我們認為測試代碼的複雜度低於業務代碼，在風險上以小博大是靠譜的。
3. 和業務系統代碼重構類似，測試代碼也可以沉澱自己的「領域模型」，降低測試代碼開發風險、降低測試代碼編寫成本。

• 效能驅動，能不能不寫測試代碼

1. 考慮把測試用例拆分成「觸發」與「驗證」兩部分，要求觸發場景儘可能全，要求驗證策略儘可能簡單。
2. 我們耳熟能詳的錄製回訪/AB測試等，通過流量複製/分流等手段，在延長測試時間的基礎上，可以做到更全的場景被覆蓋；在驗證策略上，我們採用「和老版本對比」/「和其他版本」對比的方式，找到驗證的錨點。

• 體驗驅動，數據/推薦場景下的Badcase定義

運營改了一個配置規則，導致某些地區內容推薦失效；

運營配置的營銷頁面，時間太長失效了，成為了死鏈接；

新的數據引入了一些體驗不好的「臟數據」，並且推薦給了用戶；

神經網路等不可解釋性的模型，不知道哪天就引入了一些badcase。

質量可能不止和代碼相關，還和規則配置、數據、演算法模型相關，需要定義「質量需求」，需要在線上做出很多「主動監測」、「實時核對」的測試代碼。張翔：更聰明的做線上質量

• 其他的驅動方式，讓你寫出越來越多的測試用例

一定會有這樣那樣的方式，驅動你寫下越來越多的測試用例（例如，代碼分支覆蓋率這種指標驅動方式）。測試用例越來越多，通常會出現以下問題：

1. 更耗時：工作中總有那麼多時間是拿來寫case的，而且case集跑一次時間越來越長了。
2. 可解釋性：為什麼要跑這麼多case，我改了這行代碼，哪些用例需要跑？
3. 穩定性：測試用例缺乏良好設計，互相影響、干擾；也有的用例所依賴的數據過期導致不work；無人維護。

寫到什麼時候夠

• 還有沒有問題，要不要多測一下啊？

上述的「耗時」、「可解釋性」、「穩定性」問題，通常降低我們對被測對象的質量信心。通常我們要找出一些衡量指標與錨點，證明我們的質量工作是enough的，通過這些反饋加強信心。

• 代碼覆蓋率&業務覆蓋率

如果不看業務覆蓋率，就算做到了100%代碼覆蓋率，也會有bug漏掉。

我們期望所有的「情況」被測試，而不是所有的「代碼」被測試。最常見的問題就是邏輯判斷寫少了，並非所有的設計都會被真正寫入代碼（代碼對設計的保真度）

引用 @鄭子穎 的例子：

// Setting certificate expiry.

endTime.wYear = fromTime.wYear + 1;

endTime.wMonth = fromTime.wMonth;

endTime.wDay = fromTime.wDay;

//用endTime創建一個新證書

這段代碼是Azure臭名昭著的Leap Year Bug。這段代碼就算100%執行到了，也還是不能發現這個bug，除非fromTime是2012/2/29（業務覆蓋）

• 數據有效性&演算法有效性

在DT/AI時代，我們的被測對象遠不止代碼。數據、演算法在越來越廣泛的搜索推薦場景發揮作用，並非所有業務邏輯都可以通過「有限的代碼」、「有限的規則」進行表達。

推薦場景下的問題

店鋪的地址是否準確？

給用戶推薦的東西是否OK？

在面向用戶的發散場景下，我們可能永遠無法定義好「什麼是對的」，我們也可能永遠無法找到那個衡量我們enough的錨點。但我們堅信，在定義用戶體驗的現階段，做得多、做得細，會更好。

需要「刪」用例嗎

以「代碼覆蓋率&業務覆蓋率」作為錨點，我們在什麼場景下會開始思考刪除用例/挺跑用例？

• 跟隨業務發生變化

1. 業務/功能下線了，被測對象不存在了，測試代碼是刪除還是保留？自動化用例是刪除還是停用？
2. 業務發生了變化，兩個功能合併到了一起；我們是否刪除老測試用例，創建新測試用例？

• 測試代碼重構

從需求視角往產品視角上走一步，可以發現很多固有的測試用例可以放到一個場景下；此時可以對用例進行重構，讓一條用例可以觸發更多、驗證更多。

• 引入新技術賦能

1. 當靜態掃描程序可以批量發現各種空指針/PMD時，我們可以下線一部分異常測試用例。
2. 當用戶端體驗巡檢可以統一檢測特殊字元/錯別字/內容長度等問題時，我們可以下線一部分異常測試用例。
3. 當統一的資金核對體系能夠快速發現資金風險問題時，我們可以下線一部分資金測試用例。

怎麼做會更好

在「代碼覆蓋率&業務覆蓋率」不降低的情況下，先定一個讓「測試用例更少」的小目標

它體現出對更低維護成本、更高執行效率等方面的追求。

• 去冗餘：精準感知業務變化

我們會不斷的去考慮業務是否發生了變化，新老業務是否有所關聯；

我們會嘗試通過技術手段識別出現有測試用例與業務場景/業務代碼之間的關係，進而指導我們按照「業務場景」對測試用例進行優化：

團隊曾經做過這樣的事情

1. base on interface：靜態解析測試用例代碼中import的被測介面/方法，及其參數；對測試用例按照「方法/參數」做分組統計，選出這些相關的用例並指導重構。

2. base on DAO：靜態解析測試用例代碼中造數據的部分(DAO層方法)，及其參數；對測試用例按照「方法/參數」做分組統計，選出這些數據相關的用例並指導重構。

• 優底盤：精益求精的追求

對於爛測試代碼會有持續改進的追求，它不應該很隨意的寫出來；

注重「測試分析設計」的同時，也應該關注「測試用例設計」，保證測試用例中CRUD的原子性絕對正確嗎？在分散式構建場景下如何做好「環境準備」、「數據準備」與「跑Case」的解耦？

在每一種被測對象下面，應該採用什麼樣的「測試分層框架」？Itest的數據、代碼的抽象方式，是否適合所有場景的用例設計模式？

• 搭基建：沉澱質量技術的大中台

在業務中，一定會孵化出有特色的質量技術：

店鋪的地址是否準確？

Hard to check, easy to solve.

推薦的內容和用戶所在地不一樣

Easy to check, hard to solve.

而這些質量技術中台能力，一定也會為其他的業務場景提供幫助。更多的復用中台能力，讓被測對象可以在自己的領域「測試用例更少」，「質量更高」。