關閉

                  自動化接口用例從 1 到 1000 過程中的實踐和思考

                  發表于:2019-3-18 11:54

                  字體: | 上一篇 | 下一篇 | 我要投稿

                   作者:有贊技術    來源:掘金

                    引言
                    當一個新人剛加入公司的時候,我們通常告訴新人怎么去寫一個自動化用例:從工程配置到如何添加接口、如何使用斷言,最后到如何將一個用例運行起來。
                    而在實際工作和業務場景中,我們常常面臨著需要編寫和組織一堆用例的情況:我們需要編寫一個業務下的一系列的自動化接口用例,再把用例放到持續集成中不斷運行。面臨的問題比單純讓一個用例運行起來復雜的多。
                    本人加入有贊不到一年,從寫下第 1 個 case 開始,持續編寫和運行了 1000 多個 case ,在這過程中有了一些思考。在本文中,和大家探論下如何編寫大量自動化接口用例以及保持結果穩定。
                    一、執行效率
                    目前使用的測試框架是基于 spring ,被測接口是 dubbo 的服務。 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();
                    }
                    對方法的適度封裝
                    在實際編寫用例的時候,有兩個地方可以考慮進行方法封裝,從來簡化調用,方便維護:
                    封裝基本操作。如果刪除操作依賴創建操作,查詢操作依賴創建操作,那么創建操作可以看作是個基本操作,可以對創建操作包裝一下,將注意力關注于實際需要執行和驗證的地方?梢苑庋b的東西很多,有參數封裝、異常處理的封裝、一些輪訓、重新邏輯的封裝。createCard()、getCard()、deleteCard方法就是將接口、參數組裝、檢查等封裝好的方法。
                    封裝檢查方法。上述用例中的檢查采用了一個檢查方法代替了以往的多個assert:
                    checkUpdateCardResult(ori,updated,updateDesc,kdtId); ,在方法里包裝了一些關鍵字段的比較,包括兩個對象之間成員是否一致的比較。所有的更新操作的結果都需要滿足:有變更的字段值變成新的值,未發生變更的值和原有一致。該方法實現了這種檢查邏輯,所以寫更新操作用例的同學不需要關注如何校驗,而是關心如何更新,因為檢查邏輯是現成的、通用的。將來檢查邏輯發生變更,也只需要維護這一個方法即可。
                    穩定性
                    當大批量用例進行運行時,用例集的失敗率會變得較高,幾個微小的瑕疵都會造成用例的失敗,此時我們需要更加關注用例的穩定性。一些實踐中比較好的措施和方式:
                    減少外部依賴。如果執行過程需要依賴其他系統的接口的話,那么其他系統發生了變更或故障就會影響自身用例的進行?梢钥紤]通過預先生成的數據來替代調用外部接口生成數據在用例中使用。
                    預置數據代替創建過程。由于操作越多穩定性越低,使用預置數據而不是實時生成它,速度更快,穩定性更高。
                    使用不同賬號等進行隔離。通過隔離,用例執行失敗的臟數據就不會影響其他用例。
                    調優:超時、等待時間。線上超時時間設置的比較短,測試環境的機器配置不如線上,需要適時調大超時和等待時間來保證接口調用不會超時。
                    防御式編程。編寫測試代碼時不能假設數據已存在或者沒有臟數據殘留,所以預先的判斷和清理很重要,比如檢查到數據缺失就實時修復、用例運行之前考慮清除臨時數據。
                    定位并解決不穩定的問題。有時候偶現用例失敗,可以考慮給被測應用增加日志,同時持續多次運行用例多次(如 testNg 里增加threadPoolSize=1, invocationCount=50)來復現問題,最終解決問題。
                    總結
                    對于大規模用例的編寫、組織和運行的問題,文中從三個方面給出了有贊測試的實踐和思考:精簡初始化來提高執行速度、優化用例編寫降低編寫和維護成本、多種方式提高用例穩定性,希望能給大家一些啟發。
                    
                       上文內容不用于商業目的,如涉及知識產權問題,請權利人聯系博為峰小編(021-64471599-8017),我們將立即處理。
                  《2023軟件測試行業現狀調查報告》獨家發布~

                  關注51Testing

                  聯系我們

                  快捷面板 站點地圖 聯系我們 廣告服務 關于我們 站長統計 發展歷程

                  法律顧問:上海蘭迪律師事務所 項棋律師
                  版權所有 上海博為峰軟件技術股份有限公司 Copyright©51testing.com 2003-2024
                  投訴及意見反饋:webmaster@51testing.com; 業務聯系:service@51testing.com 021-64471599-8017

                  滬ICP備05003035號

                  滬公網安備 31010102002173號

                  亚洲欧洲自拍图片专区123_久久久精品人妻无码专区不卡_青青精品视频国产色天使_A免看的日黄亚洲