基於自動化用例的精準測試探索

本文做者：韓照光

來自公衆號：百度QA

☞背景☜

---

---

 

​

在當前web系統或app後端服務測試過程當中， 黑盒測試佔據了大部分的測試，即使是接口測試，也是基於場景的用例設計，這種測試方法徹底依賴於測試人員的能力，經驗和業務熟悉度，而互聯網行業的一大特色就是人員流動性高，這使得線上質量常常是「靠天吃飯」。基於黑盒的測試使的項目測試在測試過程當中存在如下幾個問題：

 

（1）黑盒測試受主觀人爲因素影響太大：黑盒測試徹底依賴測試人員的我的能力，經驗和業務熟悉度，受主觀因素影響太大，不肯定性太多，這是產生漏測的根本緣由。

 

（2）測試覆蓋面無客觀數據可衡量：測試對代碼覆蓋程度，質量高低，沒有客觀數據可衡量，徹底靠人爲主觀介定。雖然咱們能夠拿到全量或增量代碼覆蓋率數據（增量覆蓋率通常須要運行2次全量用例），但對增量代碼具體路徑是否有覆蓋，只能靠人工分析全量覆率報告，且沒法區分哪些是原有代碼，哪些是diff代碼，在代碼量稍微大點的項目中，測試排期基本上不容許這種測試方式，從而把測試人員推向黑盒測試，因爲沒有代碼分析支撐，黑盒測試覆蓋率隨着時間和用例增多，便會觸達覆蓋率的天花板，更多的是重複的無效測試。

 

（3）自動化用例做用無發有效發揮：對於web/api或app 後端服務系統，測試人員對除手工測試外，嘗試最多的測試手段改進就是接口自動化建設，但自動化建設不多有公司在這個方向作的特別好，投放產出比(ROI)特別高的，其根本緣由就是自動化的一個核心指標：穩定性太差，隨着項目的迭代，自動化用例積累愈來愈多，從幾百到幾千，想要這些自動化用例以CI級別觸發(代碼提交一次即觸發一次)，用例所有經過穩定在80%以上，幾乎都是不太可能作到的事情。自動化用例穩定性太差，不能產生收益不說，反而會成爲QA的包袱，使他們把大量的時間花在自動化用例失敗排查上面，疲於應付，又不能發現有效的bug，長此以往，便對自動化失去信任，甚至廢棄。

 

☞問題分析與思路☜

---

---

 

筆者所在產品線後端服務是基於java的SSH框架搭建的，模塊數量多， 模塊間基於rpc分步式協議通訊，模塊間耦合多， 各個投放系統業務邏輯都比較複雜，且RD和QA新人都比較多，傳統黑盒測試只能經過人員堆砌和不斷的加班加點來適應不斷擴充的業務，這使得項目測試質量很難保持在一個較高水平，和業界面臨問題同樣，也無可避免存在背景中提到的3個問題。產品線的接口自動化測試用例隨着迭代積累，用例數多達幾千個，若是讓這些自動化用例發揮它們的效用呢？

 

對於背景1，2的問題，咱們能夠總結爲：測試覆蓋面是否能夠很容易客觀數據衡量，測試覆蓋面是沒有置信度，且在達到這個置信度的過程當中有沒有工具能夠支持QA更快更有效達成？  對於背景3中的問題，當自動化用例數到千級別的量級，若100%每次都讓這些用例所有運行經過，幾乎是不可能的事情，那咱們能不能減小這些用例數量呢，每次只運行和代碼變動相關的用例，將無關用例的篩選出去呢？

 

經過對業界和公司其它產品線一些調研，咱們發現有些團隊也有在這些問題上作一些探索，即精準測試，但基本上都是聚焦在第3個問題上，即經過用例篩選來減小用例執行以提升升CI的穩定性，思路基本上相同，只是實現過程不各不相同。公司內部一些團隊嘗試也是基於不一樣的產品特色，如app和前端模板，實現過程不一樣，這裏再也不贅述。咱們探索方向是，適用於後端服務模塊(web或app後端服務，或api，不侷限於實現語言)，基於接口自動化的精準測試，並將這個概念作了擴展，再也不侷限於用例篩選，而是3個層面，即：

 

（1）自動化用例篩選

（2）測試影響面範圍評估

（3）增量代碼覆蓋率分析

 

下面具體解釋一下這3個層面的含義。

 

咱們方案/設想：基於自動化用例和覆蓋率信息，獲取單個自動化用例對應代碼覆蓋路徑信息，並創建相應的映射庫（知識庫），作爲數據源。以下圖所示

       

​

基於獲取的映射庫信息及系統提供的附加能力，支持如下3個基本場景:

 

（1）自動化用例篩選：  在生成用例和代碼覆蓋路徑映射庫信息後，當RD提測時，能夠根據代碼diff計算出變動的方法列表(新增/修改/刪除) ,用方法列表反查映射庫，即可以篩選出與變動代碼相關聯自動化用例，與CI相結合，達到精簡用例，減小執行時間， 同時減小沒必要要的用例執行，進而提高CI穩定性，減小CI維護排查代價。

 

（2）測試範圍評估：與場景1類似，在RD 提交代碼代碼後，以變動方法列表作爲條件反查映射庫，獲取與之關聯的自動化用例，根據用例URI聚合，並結合用例描述和FE代碼註釋，分析給出手工測試範圍，一是能夠減小測試迴歸範圍，二是能夠防止漏評致使的漏測

 

（3）增量代碼覆蓋分析：新項目測試過程當中，新增自動化用例對增量代碼變動diff 覆蓋信息（生成映射庫過程），能夠和增量代碼變動方法列表作爲數據源，經過算法生成增量代碼行和分支覆蓋率報告，並具體標記哪一個分支或行未覆蓋，QA能夠根據增量代碼覆蓋率分析報告，針對性進行用例設計補充，從而提高覆蓋率，減小漏測。同時報告也使得對增量代碼覆蓋狀況可量化(常見的增量覆蓋率數據生成要運行2次全量用例集合，自動化穩定性很難保證，手動迴歸成本太大，基本不太可行)。另外，對未覆蓋函數或分支進行提醒QA作相應的自動化用例補充，從面造成精準測試，雙向反饋提高良性循環，更有的放矢，更有據可依，更自信任。

 

☞方案☜

---

---

 

總體的設計方案以下：

 

​

 

方案背景介紹：

 

（1）接口自動化用例：基於公司通知接口自動化框架平臺書寫，分爲Http和Rpc兩種接口類型

（2）後端服務實現語言爲Java，基於SSH+ RPC分佈式協議框架

（3）覆蓋率工具採用Jacoco開源框架

（4）代碼管理系統爲公司基於git開發通用代碼管理平臺

 

3.1 基礎用例和覆蓋代碼映射信息庫生成

 

顧名思義，用例與代碼映射關係即：單個用例與其能覆蓋全部代碼方法列表（不是類，分支或行）映射關係，這裏面有2個難點要解決：一是單個用例覆蓋率文件生成代價比較大，二是要消除自動化用例數據構造和清理帶來的代碼覆蓋路徑干擾，在這裏咱們稱之爲消振。

 

先看第一個問題， 單個用例覆蓋率文件生成代價大。對於收集web或jvm運行後端服務來講，接口級用例覆蓋率收集比單測更爲複雜，須要很大的時間、空間開銷，並帶來穩定性隱患。具體以下

 

（1）時間開銷，每一個用例都須要命令行插樁，啓動被測服務，中止補測服務，dump並生成覆蓋率文件，且不說覆蓋率工具的命令行操做，單服務的啓停服務就會帶來不菲的時間開銷

（2）空間開銷調用腳本及源代碼，用列執行，被測服務分別處於不一樣的機器，在生成覆蓋報告時須要源代碼和覆蓋文件同源，須要額外的操做成本

（3）啓停被測服務給覆蓋文件生成帶來不可控因素，每次服務啓動均可能在啓動中或啓動失敗

 

常見的離線插樁方式獲取單個用例覆蓋報告流程以下：

 

​

 

 

經過調研選型，咱們發現基於Jacocoon-the-fly模式能夠在不停服的狀況下，經過api致使覆蓋率文件。關於Jacoco的注入原理以及注入方式，在官方網站上寫的很是詳細了，不作過多贅述。基於 On-the-fly 方式無須入侵應用啓動腳本，只需在 JVM 中經過 -javaagent 參數指定 jar 文件啓動 Instrumentation 的代理程序，代理程序在經過 Class Loader 裝載一個 class 前判斷是否須要注入 class 文件，將統計代碼插入 class ，測試覆蓋率分析就能夠在 JVM 執行測試的過程當中完成。Jacoco提供了本身的Agent，完成插樁的同時，還提供了豐富的dump輸出機制，如File,Tcp Server,Tcp Client。覆蓋率信息能夠經過文件或是Tcp的形式輸出。這樣外部程序可很方便在任意機器上經過api隨時拿到被測程序的覆蓋率。

 

基於Jacocoon-the-fly 模式獲取單個用例覆蓋率報告流程以下：

 

​

 

再來看第二個問題：如何消除自動化用例數據構造和清理帶來的代碼覆蓋路徑干擾。即單個用例能夠獨立重複在不一樣環境間重複運行，要求用例只能依賴setup/teardown作數據構造和清理，舉例來講，驗證一個update物料屬性A的用例，setup裏須要構造2個請求建立物料管理計劃，及物料自己，Case爲修改物料屬性A接口請求及其對應的校驗點，最後是teardown裏的數據清理，刪除物料及基對應的管理計劃。在這種狀況下，若以Case爲粒度收集與之對應的代碼方法列表，會有不少干擾數據進來， 物料所屬的管理計劃，物料對應 add和delete接口關聯的方法都會被收集到，因此咱們要清除這些干擾數據，要收集以包含校驗點請求與之對應代碼方法列表，即只收集update 物料屬性A這個請求對應關聯方法列表。

 

來看咱們的解決方案：

 

（1）自動化用例的原子性：單個用例驗證一個接口，且被校驗接口所在請求統一命名，如」request」。

（2）利用AOP原理，在自動化框架的執行器加一個攔截器，在覆蓋率收集開關打開且請求名稱命中request的請求時，請求執行前：reset 被測服務樁數據，請求執行後：用api導出內存中的覆蓋率數據，生成exec文件

（3）在全局變量設置覆蓋率收集開關及其它配置，這樣即不影響其它產品線使用，就能夠在同一臺機器上完成用例執行，覆蓋率數據收集，樁數據重置，覆蓋率報告生成等一系列操做了。

 

解決這兩個問題後，用例和覆蓋代碼方法列表映射關係生成方案以下圖：

 

​

 

3.2 自動化用例篩選

 

有了用例和代碼方法列表映射基礎信息庫後， 咱們來看下用例篩選實現邏輯， 這裏有2個點，一是如何獲取變動代碼方法列表，二是如何將篩選出散列的用例在自動化框架規則裏執行。

 

先來看獲取變動代碼方法列表，在這裏咱們沒有采用git原生 diff 函數獲取代碼庫2次代碼提交中間的代碼變動，若基於git原生diff功能，無論是命令行仍是api方式，都須要在本地維護一個代碼庫的副本，過於笨重且穩定性差。因此咱們在實現是基於公司通用代碼託管平臺提供版本對比功能，能夠直接獲取2次commitid間的代碼變動文件，並以json格式返回，處理起來更爲方便。獲取到代碼變動文件，再基於不一樣語言方法結構，即可直接獲取到變動方法列表。

 

用變動方法列表查詢映射信息庫即可篩選出受影響的自動化用例，但這些用例是處在鬆散狀態，批量執行須要在計劃或測試套件綁定後，加上全局變量配置等要素是沒法在自動化框架下執行的。爲解決這個問題，咱們在自動化框架內開發計劃動態更新的API，使計劃和用例綁定能夠動態更新，並同時配置環境，變量，權限等要素，這樣就能夠以計劃爲單位執行篩選出來的自動化用例了。具體的業務邏輯實現見下圖：

 

​

 

3.3 測試影響範圍評估

 

在敏捷開發模式下， 迭代多，且快。項目在迭代升級的過程，雖然自動化能幫忙覆蓋一部分後端代碼邏輯迴歸，但和前端交互部分，當前尚未好的自動化手段來解決，這部份內容迴歸仍是主要靠手工測試來保障。影響範圍評估大了，全量手動迴歸低效，代價太大；影響範圍評估小了，容易形成漏評漏測。

 

這種測試影響範圍評估徹底靠RB和QA 主觀判斷來評估，強依賴於我的的經驗和能力，再加上人員變動，項目交接等外在因素，常常會有測試範圍漏評的現象。例如：工具類B項目開發過程當中，對主流程A底層方法methodA有改動，因爲RD和 QA測試範圍評估，常常專一B 升級業務點測試，主流程A的迴歸測試沒有評估到，從而致使沒有迴歸到形成線上問題。那咱們能不能用客觀的數據來精準評估哪部分須要測試，使手工測試範圍也更具體針對性呢？

 

在這裏當某模塊的核心接口主流程場景都被自動化用例覆蓋到之後，咱們能夠認爲，底層業務邏輯的改動方法列表，一樣查詢映射庫關係獲取影響到用例列表，而後將這些用例請求URI或者接口名稱去重，聚合，以報告的形式展現出來， QA即可以根據這個報告更有針對性去作手動迴歸測試，防止漏評現象發生，同時能夠減小回歸範圍，使迴歸更有針對性。具體的實現原理和3.3中用例篩選相似，這裏再也不展開。

 

3.4 增量代碼覆蓋率分析

 

在傳統黑盒測試過程當中， 在測試前期可以比較有效發現bug，但在後期主要依賴我的能力和經驗探索性測試， 每每都是在進行無效的重複測試，並且測試質量沒有置信度，基本上沒有度量，或者由於度量代價太大被裁剪掉了。

​

 

就java語言來講，要產出模塊代碼增量覆蓋率，通常要運行先後2個代碼版本全量的用例，分別生成2次生成的全量代碼覆蓋率作，再計算出增量代碼覆蓋率。這種狀況下全量手工用例迴歸過低效，自動化全量運行狀況下，穩定性很難保證，因此沒有可操做性。

 

另外，在黑盒測試過程，若是想針對提高增量代碼覆蓋率，只能依賴開源工具生成全量代碼覆蓋率報告，但全量代碼覆蓋率報告是沒法標記變動代碼和已有代碼區別的，也不具有可操做性。

 

爲解決這2個問題，咱們利用從代碼託管平臺獲取變動方法列表和新增自動化用例生成的覆蓋率報告，在分析器中組合計算，一次性產出變動代碼增量覆蓋率報告，同時標記出未覆蓋到方法和分支代碼，爲測試覆蓋提供衡量數據並能夠針對設計用例走到未覆蓋到的代碼，具體的業務邏輯實現以下圖：

 

​

 

到如今咱們即可以將精準測試3個落地場景的業務邏輯綜合起來，以下：

 

​

 

 

 

☞當前進展（應用現狀）☜

---

---

 

（1）產品線後端模塊接口自動化用例對應增量代碼分支覆蓋率>40%作爲測試準出標準，測試覆蓋面可衡量且可針對性提高。

（2）產品線核心模塊local  階段自動化用例迴歸，接入自動化用例篩選，CI級別的觸發只運行和代碼變動相關的用例，用例平均精簡比例在50%以上。

（3）產品線線下攔截漏評4次，增量代碼覆蓋率提高過程當中發現10個bug。

 

☞後續規劃☜

---

---

 

（1）支持CI trunk/slow 階段接入精準測試

（2）用例篩選能力接入業務端系統級測試流量篩選

（3）通用能力開放和擴展，開放api 並支持常見其它語言和自動化框架用例接入

（4）將更多的測試數據源包含進來，爲我所用，如rd的歷史代碼質量狀況，方法歷史的線下線上bug狀況，均可以囊括進來，爲更有效的測試提供底層數據支持，即將更多的測試數據爲我所用

（5）擴展精準測試範圍到精細化測試，針對於代碼變動，甚至不一樣的RD，須要進行什麼範圍的測試，要進行哪些類型的測試，這些測試有什麼的技術手段，測試到什麼樣的程度，系統均可以給出分析建議和衡量指標。

 

​