自動化接口用例從 1 到 1000 過程中的實踐和思考
引言
當一個新人剛加入公司的時候，我們通常告訴新人怎麽去寫一個自動化用例：從工程配置到如何添加接口、如何使用斷言，最後到如何將一個用例運行起來。
而在實際工作和業務場景中，我們常常面臨著需要編寫和組織一堆用例的情況：我們需要編寫一個業務下的一系列的自動化接口用例，再把用例放到持續集成中不斷運行。面臨的問題比單純讓一個用例運行起來復雜的多。
本人加入公司不到一年，從寫下第 1 個 case 開始，持續編寫和運行了 1000 多個 case ，在這過程中有了一些思考。在本文中，和大家探論下如何編寫大量自動化接口用例以及保持結果穩定。
一、執行效率
目前使用的測試框架是基於 spring ，被測接口是 dubbo 的服務,服務使用方的初始化需要經歷以下這幾個步驟：
- 監聽註冊中心
- 連接服務提供端
- 創建消費端服務代理
本地調試用例時，發現速度非常慢，運行一個用例需要 30s，而實際執行用例邏輯的時間大概在 1s 左右，主要時耗在服務消費者的初始化階段。
測試工程中，各服務的 test 類繼承了同一個基類，基類裏面做了各服務的初始化的步驟。在對接的服務數目較少時，需要初始化的對象較少，對用例運行的影響並不大，但隨著業務的增多，服務數目也增多，導致跑 A 服務接口的用例時把大量未用到的 B 服務、C 服務也一起初始化了，導致整體時耗大大增加。
解決辦法：在運行用例時只初始化需要的服務使用方，減少不必要的初始化開銷。
二、用例編寫和維護
一個用例示例
以一個簡單的業務場景為例：商家可以在後臺創建會員卡給店鋪的會員領取，商家可以對會員卡進行更新操作，這裏需要有一個自動化用例去覆蓋這個場景。
用例編寫的基本步驟為：
- step 1 :準備數據構造新建會員卡和更新會員卡的對象
- step 2 :執行創建會員卡
- step 3 :執行更新會員卡
- step 4 :檢查更新結果
- step 5 :清理創建的會員卡
轉換成代碼為:
@Test public void testUpdate() { try { /* * 創建新建和更新的卡對象 */ CardCreateDescriptionDTO descCreate = new CardCreateDescriptionDTO(); descCreate.setName(xxxx); //此處省略若幹參數設置過程.... CardUpdateDescriptionDTO descUpdate = new CardUpdateDescriptionDTO(); descUpdate.setName(xxxxx); //此處省略若幹參數設置過程.... /* * 新建會員卡 */ cardAlias = cardService.create((int) kdtId, descCreate,operator).getCardAlias(); /* * 更新會員卡 */ cardService.update(kdtId, cardAlias, descUpdate, operator); /* * 校驗編輯是否生效 */ CardDTO cardDTO = cardService.getByCardAlias(cardAlias); Assert.assertEquals(cardDTO.getName(), xxxx, "會員卡更新失敗"); //此處省略若幹參數校驗過程.... } catch (Exception e) { Assert.assertNull(e); } finally { try { if(cardAlias!=null) { cardService.deleteByCardAlias((int) kdtId, cardAlias, operator); } } catch (Exception e) { Assert.assertNull(e, e.getMessage()); } } }
按照預期的步驟去寫這個 case ，可以滿足要求，但是如果需要擴展一下，編寫諸如：更新某種類型的會員卡、只更新會員卡的有效期這樣用例的時候，就會覺得按這個模式寫 case 實在太長太啰嗦了，痛點在以下幾個地方：
- 數據準備比較麻煩，需要逐一設值
- 數據檢查部分逐字段檢查，心好累
- 每個創建相關的用例都需要清理資源，每次都需要做一次，太重復了
用例本身關註的是更新這個操作，卻花了太多時間和精力在其他地方，很多是重復勞動。代碼編寫裏有一個重要原則，DRY（Don‘t Repeat Yourself），即所有重復的地方都可以考慮抽象提煉出來。
三段式用例
可以將大部分用例的執行過程簡化為三個部分：
- 數據準備
- 執行操作
- 結果檢查
用簡單的三個部分來完成上述用例的改寫：
數據準備：
@DataProvider(name="dataTestUpdate")
public Object[][] dataTestUpdate() {
return new Object[][]{
{cardFactory.genRuleNoCreate(...),cardFactory.genRuleNoUpdate(...)},
{cardFactory.genRuleCreate(...),cardFactory.genRuleUpdate(...)},
{cardFactory.genPayCreate(...),cardFactory.genPayUpdate(...)}
};
}執行操作+結果檢查
Test(dataProvider = "dataTestUpdate")
public void testUpdate(CardCreateDescriptionDTO desc,CardUpdateDescriptionDTO updateDesc){
try {
/*
* 執行操作：創建+更新
*/
//創建會員卡
CardDTO cardBaseDTO = createCard(kdtId,desc,operatorDTO);
cardAlias=cardBaseDTO.getCardAlias();
recycleCardAlias.add(cardAlias); //將卡的標識放入垃圾桶後續進行回收
CardDTO ori = getCard(kdtId,cardAlias);
//更新會員卡
updateCard(kdtId,cardAlias,updateDesc,operatorDTO);
CardDTO updated = getCard(kdtId,cardAlias);
/*
* 結果檢查
*/
checkUpdateCardResult(ori,updated,updateDesc,kdtId);
} catch (Exception e) {
Assert.assertNull(e);
}
其中可行的優化點將在下面娓娓道來。
測試數據的優化
在這個用例中，數據準備的部分使用了 dataProvider 來復用執行過程，這樣不同參數但同一過程的數據可以放在一個 case 裏進行執行和維護。
數據生成使用了工廠方法 CardFactory ，好處是簡化了參數，避免了大量 set 操作（本身包裝的就是 set 方法）;另一方面,根據實際的業務場景，可以考慮提供多個粒度的構造方法，比如以下兩個構造方法需要提供的參數差別很大：
第一個主要用在驗證創建接口的場景，檢查各個傳入的參數是否生效。
public CardCreateDescriptionDTO genRuleCreate(Boolean isPost,Integer discount,Long rate,Long pointsDef, String couponIds, Long num, Long growth,Long termToCardId,Long amount,Long points,Long trade){第二個用在如刪除的場景，所以只需要一個創建好的會員卡對象，並不是很關註創建的內容是什麽。
public CardCreateDescriptionDTO genRuleSimpleCreate(String name){
在上面的優化過的用例中，能夠執行更新操作的前置條件是需要有一個已經創建的會員卡，在實際用例編寫的時候通過直接創建一個會員卡，然後執行更新完成後再回收刪除這張會員卡來滿足這個條件。另一種提供滿足操作所需前置數據的方式是預置數據（預先生成數據）。
以下情況可以考慮預置數據的方式：
- 提高用例穩定性，解依賴，加快執行速度
- 需要對特定的類型、狀態的對象進行查詢
- 創建或者構造比較麻煩
典型的場景：比如編寫查詢的用例時預先創建滿足條件的對象供查詢用例使用。
談到預置數據，不得不談的一個問題是數據管理。在編寫用例的時候，*"我們往往需要一個____的資源"*，框框裏面的即是對數據的描述和要求，比如我需要一個全新的賬號，一個支付過的訂單號，一張免費的會員卡，來完成我們的用例。所以需要對數據進行標記而不是簡單硬編碼的方式在用例中使用。
如：通過特定名字的變量名和數據進行關聯。
/**只做查詢卡，不做領卡刪卡*/
public Long queryCardUid = DataMocker.MOCK_YZUID.get(1);
/**用戶卡類操作，領卡刪卡*/
public Long takeCardUid = DataMocker.MOCK_YZUID.get(6);
/**退款用*/
public Long refundCardUid =DataMocker.MOCK_YZUID.get(4);
對數據進行標記後，會發現有一部分數據是用來驗證寫操作（如創建、更新），有一部分數據是查詢使用。如果數據又要被寫操作的 case 使用，又要被讀操作的 case 使用，那麽寫操作的問題和異常就會影響讀操作 case 的執行結果。所以，在代碼工程中，可以進行約定，將讀寫用到的資源進行分離來降低數據的耦合：
- 查詢 case 用的賬號不做更改對象的操作
- 查詢 case 用的對象不做修改、刪除的操作
- 驗證增、刪、改行為的資源使用特定賬號，且資源最後做回收刪除處理(因為資源總數有限)
最後，用例執行完成後需要清理資源。這裏的清理資源采用的是一個全局的 list 的方式保存需要清理的資源信息，在用例執行過程中往裏增加數據:（recycleCardAlias.add(cardBaseDTO.getCardAlias());）,
然後用對應的方法取其中的數據進行刪除，類似垃圾桶。與原有執行完就執行清理動作相比，使用垃圾桶更加靈活，可以選擇控制下清理頻率。
比如每次在 AfterMethod 或 AfterClass 中去清理。
//統一回收
@AfterMethod
public void tearDownMethod() {
for(int i =0;i<recycleCardAlias.size();++i) {
try {
deleteCard(kdtId, recycleCardAlias.get(i), cardOperatorDTO);
} catch (Exception e) {
logger.error("clear card fail: " + recycleCardAlias.get(i));
}
}
recycleCardAlias.clear();
}對方法的適度封裝
在實際編寫用例的時候，有兩個地方可以考慮進行方法封裝，從來簡化調用，方便維護：
封裝基本操作。如果刪除操作依賴創建操作，查詢操作依賴創建操作，那麽創建操作可以看作是個基本操作，可以對創建操作包裝一下，將註意力關註於實際需要執行和驗證的地方。可以封裝的東西很多，有參數封裝、異常處理的封裝、一些輪訓、重新邏輯的封裝。
createCard()、getCard()、deleteCard方法就是將接口、參數組裝、檢查等封裝好的方法。封裝檢查方法。上述用例中的檢查采用了一個檢查方法代替了以往的多個assert：
checkUpdateCardResult(ori,updated,updateDesc,kdtId);，在方法裏包裝了一些關鍵字段的比較，包括兩個對象之間成員是否一致的比較。所有的更新操作的結果都需要滿足：有變更的字段值變成新的值，未發生變更的值和原有一致。該方法實現了這種檢查邏輯，所以寫更新操作用例的同學不需要關註如何校驗，而是關心如何更新，因為檢查邏輯是現成的、通用的。將來檢查邏輯發生變更，也只需要維護這一個方法即可。
穩定性
當大批量用例進行運行時，用例集的失敗率會變得較高，幾個微小的瑕疵都會造成用例的失敗，此時我們需要更加關註用例的穩定性。一些實踐中比較好的措施和方式：
減少外部依賴。如果執行過程需要依賴其他系統的接口的話，那麽其他系統發生了變更或故障就會影響自身用例的進行。可以考慮通過預先生成的數據來替代調用外部接口生成數據在用例中使用。
預置數據代替創建過程。由於操作越多穩定性越低，使用預置數據而不是實時生成它，速度更快，穩定性更高。
使用不同賬號等進行隔離。通過隔離，用例執行失敗的臟數據就不會影響其他用例。
調優：超時、等待時間。線上超時時間設置的比較短，測試環境的機器配置不如線上，需要適時調大超時和等待時間來保證接口調用不會超時。
防禦式編程。編寫測試代碼時不能假設數據已存在或者沒有臟數據殘留，所以預先的判斷和清理很重要，比如檢查到數據缺失就實時修復、用例運行之前考慮清除臨時數據。
定位並解決不穩定的問題。有時候偶現用例失敗，可以考慮給被測應用增加日誌，同時持續多次運行用例多次（如 testNg 裏增加
threadPoolSize=1,invocationCount=50）來復現問題，最終解決問題。
總結
對於大規模用例的編寫、組織和運行的問題，文中從三個方面給出了實踐和思考：精簡初始化來提高執行速度、優化用例編寫降低編寫和維護成本、多種方式提高用例穩定性，希望能給大家一些啟發。
自動化接口用例從 1 到 1000 過程中的實踐和思考