精準測試實踐

背景介紹

• 每次上線一大堆程式碼改動，到底影響了哪些功能，比較依賴經驗
• 測試完了之後，不清楚把這次改動涉及到的功能點是否都測到了
• 在敏捷迭代的背景下，釋出頻繁，測試時間不足，我們必須要了解核心流量在哪裡，優先保障核心流量經過的功能高可用
• 服務中的廢棄程式碼，留著又不知道做什麼的，刪的話又沒把握
• 微服務架構下，如何評估對業務方的影響

方案設計

對於上述測試痛點，要解決的核心問題就是測試效率和測試質量，我們從以下幾個方面來逐個擊破：

• 首先要解決的問題就是，科學地評估程式碼變更影響到的功能點；最好能夠做到智慧推薦用例
• 再就是要獲取到測試的增量覆蓋，清楚的知道哪些變更的程式碼還未覆蓋到

測試功能點評估

這裡涉及到幾個關鍵能力：

1. 從程式碼變更獲取方法集合

• 通過Jgit來獲取程式碼差異
• 使用classParser，通過解析源class檔案，獲取常量池

2. 通過變更方法獲取影響介面

• BCEL：通過深入JVM的彙編來建立、分析、操縱class檔案
• 常量池：包含class檔案中所有的東西，通過對常量池的分析可以得出函式間的呼叫關係

覆蓋結果分析

在增量覆蓋率的基礎上，通過對未覆蓋方法的分析，可以得知影響到了哪些介面，結合下面的介面分析能力來進行測試

介面分析

有了之前的能力，我們可以知道通過哪些介面可以去測試這次改動的程式碼；然而不同的介面重要程度是不同的，在時間有限的情況下，我們需要清楚哪些介面是一定要保證，這就需要獲取到介面的以下資訊：

• 介面的優先順序，幫助我們明確該介面是否在核心功能路徑上
• 介面是否有自動化覆蓋，包括介面自動化和流量回放等自動化手段；以及自動化case覆蓋到的程式碼方法樹
• 介面的前端呼叫入口，方便快速找到測試入口
• 介面影響的業務方，用以判斷是否需要通知業務方進行迴歸

介面優先順序分析

1. 假設選取1個月作為時間視窗，拉取系統API 1個月的呼叫情況。時間視窗選取過長，可能會有歷史高呼叫量資料影響結果，而這些介面可能已經下線；選取過短，可能有運營活動或其他突發狀況造成的次優先順序API呼叫量較高，不具有統計分析的意義。
2. 對拉取的離散資料進行曲線擬合，採用簡單的最小二乘法
3. 對擬合後的資料求取拐點。假設：相同priority的資料有相同的分佈 4.採用拐點切分資料，獲得priority區間

介面自動化覆蓋情況

介面自動化覆蓋的情況可以從持續整合的結果獲取，需要自動化平臺提供相關介面。

自動化用例覆蓋程式碼函式

通過自動化框架排程與精準測試和覆蓋率平臺對接可以獲取每個自動化case覆蓋到的方法樹。

介面入口以及影響業務方介面

從監控系統獲取服務間呼叫關係的資料進行分析，獲取影響的依賴方介面以及呼叫入口。

智慧用例推薦

應用場景

具備以上的能力後，回過頭來看精準測試解決了哪些問題：

• 明確程式碼影響範圍，避免全量測試
• 測試用例平臺可以通過程式碼變更智慧推薦用例，方便開發自測；結合增量覆蓋率，可以提高測試准入門檻
• 單case測試時能夠收集到影響程式碼中的方法樹，可以幫助新人快速熟悉業務
• 整合測試環境的增量覆蓋率可以評估測試效果，做上線卡點
• 根據單case覆蓋率資料可以精簡流量，提高迴歸效率
• 線上的覆蓋率資料可以標記冗餘程式碼
• 中臺類服務可以明確被影響的依賴方，提供業務方迴歸範圍

想了解更多關於酷家樂技術質量的文章，歡迎關注我們的公眾號