得物商家域精準測試實踐

陶然陶然發表於2023-12-08

來源:得物技術

目錄

一、背景介紹

二、商家域精準測試實踐

    1. 測試流程圖

    2. 精準測試實施計劃

三、商家迭代資料

    1. 正向收益

        1.1 豐富用例

        1.2 發現問題

        1.3 提升效率

        1.4 增量預覽

    2. 實踐過程資料

四、精準測試平臺簡介

        實現方案簡介

五、實踐經驗總結

    1. 總結

    2. 後續規劃展望

背景介紹

由於多個域共建情況比較多,一方面應用隨業務發展在不斷擴充套件,各個應用程式碼複雜度會不斷增加,如何準確、全面判定程式碼修改影響範圍會越來越重要,另一方面共建過程中如果不能準確預估出各域共同改動所帶來的影響面,就會存在測試遺漏;如果各域資訊不對稱可能會存在一方改動另外一方無感知,導致評估不到位帶來一些影響。基於以上背景商家域引入精準測試平臺實踐,可以幫助QA掃描出每個版本開發改動的介面範圍,並且可以有效地提高測試的覆蓋率和可靠性。

基於第二季度在商家地址專項上探索實踐了精準測試並取得了一定的收益;第三季度擴大規模化實踐,因此根據商家核心業務需要,選擇了核心的 4 個應用,並沉澱了持續幾個迭代的過程和結果資料。以下是幾個迭代下來使用精準測試平臺的一些實踐資料和心得。

商家域精準測試實踐

測試流程圖

得物商家域精準測試實踐

精準測試實施計劃

    精準測試應用節點

    提測之後,冒煙之前:

          - 根據測分文件改動的服務,去拉取確認改動範圍;

          - 跟開發確認改動介面是否合理,給測試明確測試範圍;

          - 確認平臺的精準度;

          - 確認需要補充自動化的清單;

    一輪測試完成之前:

          - 針對改動介面的自動化進行執行,透過率達到100%;

          - 確認改動服務覆蓋率75%。

    精準測試的貢獻度,引入前後的差異

          - 確認改動介面範圍,明確測試範圍;    

          - 新增未完成自動化的改動介面,精準獲取改動介面自動化執行結果;

          - 提高服務和需求維度的程式碼。

商家迭代資料

正向收益

豐富用例

  • 協助我們補充測試場景和用例,合併程式碼或人工評估不精準導致,避免漏測。

    例項1:迭代中透過推薦的介面發現有影響某一個介面,技術方案未體現有改動,改動一行程式碼,改動介面有過濾稽核單邏輯,需要加入迴歸場景,推薦出 1 個未評估到介面,其餘推薦出正常新增及修改介面。

    影響面:過濾被風控的稽核單,需迴歸場景,確認是否正常過濾稽核單,跳轉正常無稽核單,技術方案無該介面改動記錄。

    收益:確認影響面,保證了部分未評估到的場景被覆蓋倒,避免可能引起線上問題。

得物商家域精準測試實踐

而平臺推薦出技術方案範圍外的一個介面:

得物商家域精準測試實踐

後經確認,確實有修改:

得物商家域精準測試實踐

  • 平臺精準率
    • 精準率:a/(b+c) *100% (a: 平臺推薦出的變更介面數;b: 新增介面數,c: 變更的老介面數);
    • 平臺目前精準率:以最新迭代 528 資料為例,介面變動數 18+,推薦 15+,平均精準率為:80% 左右;
    • 以下為 526 版本 Groot 服務,介面變動 15+,平臺推薦 15+ 全部成功推薦,精準率為 100%;
    • 平臺推薦介面清單,總共 10+ 個,其中包含處理存量資料的後門介面 5+ 個。
    • 得物商家域精準測試實踐
      得物商家域精準測試實踐

綜上,從平臺推薦和開發實際的介面變更來看,當前某個服務平臺推薦精準率是 100%,幫助 QA 精準確認介面改動數量,精準定位測試範圍。

  • 豐富自動化 Case

包含新增的 Dubbo/Http 介面、老的 Dubbo/Http 介面都推薦出來,針對改動的介面已完成自動化 Case、執行自動化更精確;未完成的自動化可針對性進行左移、對比技術方案查缺補漏;左移自動化 Case數:50+ 個。

發現問題

攔截 2 個有效問題:分別歸屬為其他部門。多個域參與倉庫的程式碼開發,在多個域共建情況下,無法準確預估各域改動帶來的影響範圍,透過精準推薦能夠涉及影響的範圍,聚焦在改動介面的自動化結果分析,節省環境及其他 Case 影響時間,觸發自動化工程迴歸老功能,使問題提前暴露。

  • 提前感知:提測後,透過平臺推薦出的改動介面,觸發相關自動化,提前攔截遷移程式碼引入的一個問題,降低後續風險。

得物商家域精準測試實踐

  • 協助測試:526 版本提測後,平臺推薦出改動介面,推薦出自動化 Case,發現一個新需求程式碼合併後影響當前已有功能,及時做了修復。避免問題在後置階段發現,提前降低風險。

提升效率

自動建立計劃執行-提效點 :提效 0.5-1h/ 每人每迭代,增量程式碼預覽、分析更便捷,節省 0.1-0.5h/ 每人每迭代。

增量預覽

透過增量對比,無需重新拉取新老程式碼對比確認改動,可直接拉取分析對比,更加直觀確認程式碼改動點,確認影響範圍是否迴歸,提高人效。

得物商家域精準測試實踐



實踐過程資料

527版本迭代:介面變更數:15+;測試左移介面數6+;平臺推薦結果數:11+;精準比例:73%左右。

526版本迭代:介面變更數:90+;測試左移介面數10+;平臺推薦結果數:73+;精準比例:81%左右。

525版本迭代:介面變更數:40+;測試左移介面數30+;平臺推薦結果數:25+;精準比例:63%左右。

524版本迭代:介面變更數:22+;測試左移介面數8+;平臺推薦結果數:11+;精準比例:72%左右。

精準測試平臺簡介

得物商家域精準測試實踐

實現方案簡介

精準測試平臺主要是基於抽象語法樹 (AST) 生成方法呼叫鏈後進行精準推薦。版本迭代中生成“各應用的方法呼叫鏈”、“全域介面呼叫鏈”,(“差異分析器”+“推薦引擎”)根據“變更程式碼”提取“變更介面”和“影響介面”,進而推薦相關用例(自動化+功能用例+資損用例),結合精準度量呈現迭代版本的測試質量,具體如下:

  • 程式碼分析器-鏈路分析器:根據最新提交生成方法呼叫鏈,標記出 Http、Dubbo、Grpc 等介面的入口實現類的具體方法,並記錄介面相關屬性資訊,存入知識;

  • 介面呼叫鏈提取器:打通 Trace2.0 提取上個迭代的介面呼叫鏈,存入知識庫;

  • 程式碼分析器-差異分析器:根據 Code Diff(最新提交 - 線上提交),從 Code Diff 中提取變更的方法,結合知識庫推出變更介面,變更介面結合方法呼叫鏈,定位到影響介面;

  • 推薦引擎:(變更介面 + 影響介面)  + 自動化用例 + 功能用例介面知識庫 => 自動化用例 + 功能用例

  • 精準度量:結合程式碼覆蓋率平臺、自動化平臺、用例平臺等度量測試質量。

實踐經驗總結

總結

在第三季度透過虛擬小組的方式合作推進精準測試專項工作,在每個版本中跟進各自熟悉模組的幾個核心服務應用,對一些獨立專案也有一些實踐,獨立專案中以需求維度對每個改動的應用都做精準測試推薦,期間主要包括測試左移自動化 Case 以及跟進存量自動化失敗原因,對應用存量介面自動化 Case 補充提高應用自動化的覆蓋率,儘量保證到每次改動的老介面推薦出來的介面都能自動化覆蓋,幫助到老介面迴歸節省測試迴歸時間成本;

存在多個域共建的情況下,這個時候也能夠幫助精準推薦出測試範圍。精準測試可以有效地提高測試的覆蓋率和可靠性,可以幫助測試人員發現潛在的問題,避免多域共建的情況下資訊偏差導致漏測介面,推薦出開發改動未評估到的影響介面;

在整個第三季度過程中,每個版本透過對多個應用的推薦使用,有推薦 100% 的資料,中間也有一些平臺待最佳化的問題,資料持續收集中,以最新迭代資料為例,平均精準率為 80+%,第三季度截止目前:多個應用、幾個迭代、多位同學以虛擬小組形式共投入 6d+ 初步取得結果如下:輸出精準測試流程互動圖,攔截缺陷,推薦出未評估到的改動介面,左移自動化 Case,自動建立左移計劃並自動執行:提效 0.5-1h (每人每迭代);過程中有一些特殊 Case 的情況,比如有一個獨立專案新增及修改介面均未正常推薦出來,也需要平臺後續調整精準推薦的策略。

後續規劃展望

透過在第三季度的實踐中發現的一些問題平臺也積極配合改進,相信後續在平臺支援的基礎上做需求維度的精準測試推薦,更多應用使用精準測試平臺,每個迭代以需求維度推進會更高效精準的分析,以逐步達到最佳的測試效果和維護成本;透過每個版本迭代不斷地使用收集資料發現一些影響精準率的問題,對精準平臺系統進行再次的最佳化和改進,以提高精準測試平臺的精準率,同時修復已經發現的問題和缺陷;當精準率提高到一定水準,能夠為以後的測試工作提供依據和借鑑。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70027824/viewspace-2997584/,如需轉載,請註明出處,否則將追究法律責任。

相關文章