在大型項目的測試中通常都伴隨著大量的測試用例。如何優化用例以提高編寫的效率，如何組織用例以提高執行的效率經常困擾著我們；因此總結了一些在編寫用例時的心得。

1.用例框架的優化

一份好的用例設計需要有一個好的用例框架的支撐，因此用例結構優化的第一步就是優化用例框架。

一般我們的用例框架是先以測試方法作為基礎，第一層是測試類型，考慮系統所需要測試的測試類型。

如果用例偏重於場景法的話，那麽第二層是場景考慮，此時暫不要去思考如何實現；如果用例偏重於模塊測試的話，那麽第二層是你劃分的各個模塊；如果用例設計偏重於邏輯路徑的話，那麽第二層是你每個路徑主要實現的功能。

第三層是功能點，以場景為導向的考慮的是實現這個場景需要哪些功能模塊支撐，每個模塊做什麽；以模塊為導向的則考慮每個模塊中主要實現的功能點；以路徑為導向的則是考慮路徑中的功能點的實現。

2.組件機制與模塊功能的分離

不管是什麽組件，總有它自己使用的機制，與它實現的功能點沒有任何關系。最常見的是調度機制以及最基本的配置讀取的機制。這些都可以剝離出來單獨測一次就夠了，不需要在每個模塊中測一次，重復編寫用例。

3.提取公共用例

在這個方法中，什麽樣的用例可以作為公共用例是最關鍵的。一般情況下可以作為公共用例的有兩種類型：

第一種是測試方法在所有項目中通用，一般類似於翻頁、導出、上傳這些；測試方法統一，會因為設計的不同在每個項目中略有不同，但是在一個項目的各個地方的功能實現基本是一致的。此時一般會將用例設計寫為一份，作為公共用例設計，但是測試用例會分散在各個模塊中有多份以方便執行。

第二種是在一個項目中多個組件共同使用的方法，此時會將用例設計與用例都單獨作為一份進行編寫，執行時也只需要執行一遍就可以，不需要在每個組件中再單獨都執行。

另外其實還會有一種比較不常見的公共用例，例如在報表系統中的ETL過程，雖然ETL過程是對數據進行抽取、轉換、加載，是對不同的數據源進行處理，但實際在流程處理上是一致的，只會在需要進行數據進行有條件的轉換時不一致。因此整一套流程實際就是一份公共用例。

第一種公共用例比較好分辨，第二種的話需要對邏輯設計有一定的認識，並且需要從開發那邊獲取信息，比如說開發把哪些部分封裝成了公共調用方法；此時並不一定是一開始就規劃了這部分作為公共用例，而是在寫用例設計過程中發現大部分設計幾乎相同，才會考慮開發是否會把此部分作為公共代碼，能否作為公共代碼以及與開發溝通他們準備如何實現。

4.條件細分，正向組合

如果涉及到的用例是由很多條件組合控制的話，盡量將用例設計中的各個條件細分到最小的粒度，而不是使用組合的方式展現。

當條件細分到最低粒度的時候很多的用例設計就有了共同的地方，此時就會出現很多可復用的測試用例設計，這樣能夠減少用例設計的工作量。

然後再在細分到最小粒度的用例設計基礎上進行一定的組合優化，因為有些正向數據實際是由多個最小粒度的條件組合而成，不需要單獨進行驗證，所以組合後能夠減少用例執行的時間。

5.場景分析剔除

對於狀態控制很多的用例，需要進行一定的場景分析，對一些不存在的場景進行用例的刪除。因為即使開發沒有做對應的控制，要求開發修改的可能性也非常小，並且此類的修改沒有意義。

6.用例設計粒度的控制

如果測試要求粒度特別細的狀態下，用例量幾乎是翻倍的。這是可以從路徑覆蓋的角度上分析，實際會發現有很多重復檢查某一部分的用例量。此時需要我們做的是測試用例粒度的把控。在最正常的路徑中做詳細的測試，在其他路徑中做粒度略粗的測試，一定要特別註意有沒有特殊場景不能做粒度的放粗。

用例結構優化心得