破舊立新,精準測試之道

前言

第一次聽到精準測試是在幾年前了,那一瞬間就對這個流派充滿了好奇和探索的慾望,最近幾年逐漸得到了各領域各行業中測試人員的廣泛關注,那麼問題來了:

  • 什麼是精準測試;
  • 精準測試的意義和價值在哪裏;
  • 精準測試整體方案如何落地;

傳統測試的痛點

傳統測試的痛點

測試效率低下

常規的測試類型包括功能測試、迴歸測試、自動化測試、接口測試等,非常依賴於測試人員的測試經驗,基於人工主觀分析的黑盒測試,藉助常規的用例設計方法來確保產品質量。

根據收益遞減規律,雖然大量的人力投入,不斷的執行測試,但是漏測率還是居高不下。中間的無效測試和重複測試也浪費了大量的測試成本。

測試範圍無法評估

  • 多分支代碼合併到主分支,修改哪個文件哪個行,測試不可控;
  • 代碼更新影響哪些功能無感知;
  • 大部分的測試還是基於對業務的理解,與真實業務數據還有差距,準確性難以保證,盲測,風險大;

測試過程中的質量標準無法衡量

怎麼樣判定測試完成,怎麼樣判定測的怎麼樣?質量控制貫穿於整個質量保障流程。

  • 用例執行完成;
  • 探索性測試完成;
  • 開發人員缺陷修復完成;
  • 迴歸測試完成;
  • 自動化執行通過;

上述步驟完成意味着我們的產品質量是合格的嗎?

上線之後的非一致性成本逐漸增高,測試過程沒有數據量化的評定,無法衡量,只能依賴線上缺陷率,線下缺陷數,千行缺陷率等比較飄的指標來評定,測試管理難度大。

敏捷模式和分佈式微服務架構下的挑戰

挑戰

  • 迭代週期短,尤其是互聯網行業,日常版本的週期基本兩週一個迭代,對於時間成本的控制要非常精確;
  • 需求頻繁變更,每次變更都需要回歸全部用例,大量的重複勞動;
  • 軟件系統越來越複雜,服務和服務之間的調用邏輯關係沒有頭緒,無法精準的預估範圍和定位缺陷;

基於上述痛點,我們期望從以下方面解決

  1. 科學地評估代碼變更影響到的功能點,需要對這部分代碼做準確的針對性的測試,使測試更加的精準,迴歸測試所需的時間更短,迴歸的範圍更準確。釋放人力成本,將更多的時間和成本投入到更深,更底層的測試工作中;
  2. 對代碼的邏輯進行深刻的理解,哪些分支代碼被覆蓋到,哪些分支代碼沒有被覆蓋到,進行詳細的分析,找出漏測的地方,需要準,減少重複勞動,從經驗型的主觀判斷向精準的數據可視化轉變

精準測試的概念

精準測試是一套計算機測試輔助分析系統。 使用用例和代碼兩個關鍵因子,進行質量綜合考量和分析的創新測試理論方法體系,核心組件包含軟件測試示波器、用例和代碼的雙向追溯、智能迴歸測試用例選取、覆蓋率分析、缺陷定位、測試用例聚類分析、測試用例自動生成系統,這些功能完整的構成了精準測試技術體系,大大增強了測試的深度與廣度,打破了測試部門的成長天花板,爲測試過程本身的價值挖掘和測試數據資產的增值,提供了必要而充分的條件。

精準測試

核心特性之一雙向追溯

通過系統採集程序代碼執行邏輯,建立測試用例與程序代碼之間的邏輯關係,形成正向和逆向的雙向追溯機制,實現了精準無誤的數據可視化。

  • 正向追溯:測試人員執行一個測試用例以後,精準測試可以自動的記錄和顯示這個測試用例的代碼內部執行細節。每個測試用例都可以進行量化分析和統計,這些量化數據既可以用來對測試人員進行工作的考量,也可以提供開發人員和測試人員之間進行信息化的交流。
  • 逆向追溯:測試人員根據開發修改的代碼,分析代碼關聯的調用邏輯關係,快速精確的定位測試範圍,極大減少無效,重複的測試工作,使測試覆蓋率達到最大化。

精準的數據來判定,所有數據由系統自動、原生錄入,數據不可篡改,產生測試數據可直接用於測試的過程管理和實效分析。支持測試數據的精準度量以及全面的、多維度的測試分析算法,將白盒測試的視角從覆蓋率擴展到智能測試分析。

用例的智能篩選

基於用例和代碼的追溯關係在進行運算之後全自動得出的。用例和代碼精準的追溯機制,使數據開始可以實施大量的智能測試算法。

設計思路

設計思路

一、增量代碼 diff

精準測試的核心特性之一是雙向追溯,前提是基於變更代碼的雙向追溯,因此變更的代碼是整個系統最重要的一個輸入。

  • 通過 JGit 來獲取代碼差異;
  • 解析到方法級別,作爲調用鏈路推演的輸入;

增量代碼 diff

二、源碼靜態結構分析

  • 函數調用分析方法: 靜態方式基於字節碼的解析(ASM/bcel/Javassist 等),動態分析調用鏈路(使用 javaagent 對內部方法進行代碼織入等),這裏使用的是 JavaParser+JavaSymbolSolver 基於靜態代碼得到完整的調用鏈路。
  • 結合代碼增量獲得變更代碼調用鏈:
    • 根據 Controll 層 Mapping 註解,獲得變更代碼影響的上層業務相關的 Http 接口;
    • 根據 Dubbo XML 配置文件,獲得變更代碼影響的內部 Dubbo 協議調用接口;

源碼靜態結構分析

關鍵代碼:

  1. 獲取 Java 文件的符號推理器

獲取 Java 文件的符號推理器

  1. 獲取 Jar 文件的符號推理器(微服務架構下,跨服務的面向過程調用)

獲取 Jar 文件的符號推理器

到此,關鍵的一步受影響的接口已經獲得,有了上述的能力,我們可以知道通過哪些接口可以去測試這次改動的代碼,但是面對大量的接口列表,相信大部分測試人員是一臉懵逼的。

三、增量代碼覆蓋率

價值:

  1. 通過增量代碼覆蓋率的統計,對系統的內部執行邏輯深入分析,篩選分析未覆蓋或者覆蓋率較低的方法,依賴上述的調用鏈路可以獲取到影響的接口來進行用例的補充和測試;
  2. 通過研發效能平臺持續集成,進行覆蓋率卡點,當覆蓋率低於預期值將無法通過測試;

方案:

增量覆蓋率的設計方案這裏不過多介紹,請自行查閱相關資料,歸納成以下幾點:

  • Jacoco 做相應的改造,增加增量代碼的數據統計;
  • JVM 啓動參數配置 Agent,TCP 方式啓動;
  • Dump 覆蓋率文件和 class 文件解析後得到報告;

如何避免一次測試過程中,服務多次重啓和部署,導致覆蓋率丟失,有幾種解決方案:

  • 定時 Dump 覆蓋率數據進行彙總;
  • 通過 shutdown 事件,觸發 Dump 覆蓋率數據;

整體框架:

整體架構

覆蓋率曲線示波器:

覆蓋率曲線示波器

覆蓋率詳情:

覆蓋率詳情

四、智能推薦用例

**智能推薦算法:**算法是什麼?我們可以把它簡化爲一個函數。函數接受若干個參數,輸出一個返回值。

智能推薦用例

輸入參數是線上監控,覆蓋率和自動化覆蓋的各種屬性和特徵,包括調用頻次,時間分段,行業,覆蓋率,是否有自動化,發佈時間等等。經過推薦算法處理後,返回一個按照重要度,緊迫度排序的推薦用例列表。

業內常用的幾種推薦算法如下:

業內常用的幾種推薦算法如下

此外,通過篩選自動化用例可以得到哪些接口沒有被自動化,反哺到自動化平臺用例的補充,以完善自動化接口覆蓋率,流程上形成閉環。

用例

接口變更兼容性校驗:

我們還可以做接口參數變更兼容性驗證,測試過程中通過研發效能平臺持續集成觸發檢測,挑選出接口兼容性可能存在問題的接口,郵件通知到測試人員。

接口變更兼容性校驗

未來的展望

一、智能缺陷定位

傳統軟件測試過程中,缺陷由測試人員錄入到缺陷管理平臺,只負責發現缺陷。開發人員針對這些缺陷進行定位、排查和遠程調試,如果測試人員提交的缺陷是比較模糊的功能描述,那麼開發人員將會花費大量的時間去排查問題。

通過精準測試平臺,對於執行失敗或者不通過的用例,根據用例執行詳細的路徑追溯信息,自動分析缺陷產生的代碼塊,給出缺陷產生的可疑代碼排名。

參考實際的缺陷定位手法,實現把抽象的定位思路轉變成直觀的可視化圖形界面。

二、測試過程的行爲分析

通過對測試人員測試執行和代碼的路徑追溯信息,進行聚類分析:

  • 某個功能的測試範圍是否充分;
  • 測試人員的測試習慣聚焦在哪些功能;
  • 哪些分支的覆蓋比較薄弱;
  • 哪些用例的設計重複性較高;

客觀的呈現每個測試人員的測試思路和能力曲線,比如測試是否充分的功能用圓形來展現,越充分直徑越大,習慣聚焦的功能點用距離來展現,越聚焦距離該功能越近等。

總結

精準測試是一個完整的質量體系架構,傳統的黑盒測試與白盒測試相結合的模式,通過不斷的對人的行爲的分析得出不足點和漏洞點,引導開發和測試有針對性的改正糾偏,逐步的完善整個質量保障體系。

更多相關技術內容歡迎關注 網易智企技術+ 公衆號。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章