8月7日下午，愛奇藝技術產品團隊舉辦了第17期“i技術會”，本次技術會的主題是“智能化、精準化測試前沿探索”，本次沙龍與TesterHome社區聯合舉辦。
其中，來自愛奇藝的技術專家蘇慧爲大家帶來了“愛奇藝精準測試體系”建設的分享，講述了愛奇藝精準測試實踐過程中，爲了走出迴歸測試困境、實現精細化測試能力建設進行的一系列技術攻堅，例如採用自研代碼覆蓋率工具，改變原生代碼覆蓋率工具實現方式，支持服務端多人並行測試以及微服務調用鏈串聯，最終實現迴歸測試質量與效率雙向提升。
福利!!! 關注公衆號，在後臺回覆關鍵詞“測試”，就可以獲得本次i技術會嘉賓分享PPT和錄播視頻。
以下爲“愛奇藝精準測試體系建設”乾貨分享，根據【i技術會】演講整理而成。
01
爲什麼要做精準測試？
精準測試是爲了解決迴歸測試的質量和效率問題。
在具體的業務中，產品功能的迭代、缺陷修復等等是極爲常見的需求場景，但這些看似微小且常見的改動都有可能會對產品龐大的歷史功能產生影響，所以需要通過迴歸測試進行質量保障。
迴歸測試在多個場景都可能會被引入，除上文提到的兩種外，測試完成之後需求發生變更、合併代碼上線階段、客戶端封版之前的集成測試階段等等都會涉及。
而在迴歸測試的過程中，首先會遇到測試範圍如何選取的問題。
如果每次都對全量用例進行迴歸，隨着項目的快速迭代，用例庫中的用例數量也會不斷攀升，迴歸成本也將居高不下；如果不做全量回歸，就需要人工判斷迴歸範圍，而這往往依賴於測試同學和研發同學的溝通、測試同學的經驗積累或部分同學的代碼走讀。這些方法都較爲主觀，往往不夠準確，容易出現質量風險。根據愛奇藝歷史數據，由歷史功能影響引入的問題比重達到了50%。
所以精準測試就是要解決傳統迴歸測試的問題，通過技術的手段讓迴歸測試變得精準，提升其質量和效率。其基本方法爲，在用例執行過程中，通過代碼覆蓋率工具記錄用例與代碼的映射關係，保存在知識庫中。當代碼發生變動時，可以通過查詢知識庫，準確找到本次變更的代碼影響了哪些測試用例，有針對性地進行迴歸。這樣就能夠達到提高測試效率，同時減小質量風險的目標。
02
愛奇藝精準測試體系建設
愛奇藝精準測試體系主要有以下三個特點：
（1）從使用場景上看，支持客戶端和服務端多端使用，支持手工和自動化測試場景，和愛奇藝內部的多個平臺聯動，打通了整體使用流程；
（2）從實現層面看，可以準確捕獲單個用例的代碼覆蓋。服務端能做到系統級串聯，客戶端則能實現多組件整合；
（3）從精準度方面看，已實現用例和代碼分支或代碼塊級別的關聯。
下圖是愛奇藝精準測試體系整體架構圖，中間的紅色部分是核心的精準測試服務，負責建立用例和代碼映射關係知識庫並根據GIT提交記錄計算測試範圍及影響範圍。
在採集用例執行代碼的過程中，不同的終端需要用到的代碼覆蓋率工具也會不同。目前，愛奇藝精準測試體系已經能夠支持安卓端、iOS客戶端以及服務端。
在與外圍平臺的集成上，服務端可以和環境平臺結合，通過環境平臺實現代碼覆蓋率工具的安裝；客戶端則可以和構建平臺做集成。
因爲愛奇藝當前大部分使用場景爲手工測試，因此我們也將其和公司內部用例管理平臺進行了打通，配合使用。
03
精準測試實現方案與關鍵問題解決
精準測試的實現方案主要有兩個關鍵步驟，第一步是在用例執行過程中採集用例和代碼的映射關係，建立知識庫。第二步是當代碼發生變更時，通過查詢知識庫，進行測試範圍的精準推薦。
1.用例代碼關係採集實現方案及關鍵問題解決
這一步驟首先要藉助代碼覆蓋率工具。
目前，在愛奇藝，代碼覆蓋率工具的安裝可以通過與構建平臺的結合，在構建過程中自動安裝，無需人工介入。構建平臺可以靈活控制本次編譯是否開啓覆蓋率功能，如果開啓，客戶端會編譯帶有覆蓋率工具的安裝包，安裝到移動設備上。服務端則會將覆蓋率工具掛載到被測應用上，然後部署到測試環境中。同時，構建平臺會把本次編譯產物和編譯信息，發送給精準測試服務，用於後續代碼覆蓋解析。
工具安裝後測試服務器或者APP上即可以執行測試，手工或自動化執行均可。
用例執行結束後，精準測試服務會採集當前測試的代碼覆蓋率數據，並進行一系列處理如單個用例代碼覆蓋的匹配、服務端系統級串聯、客戶端多組件聚合等，最後利用代碼覆蓋率數據、編譯的產物以及源代碼，解析得到當前用例所執行的代碼信息，包括用例執行了哪些類，哪些方法及基本的語句塊，並將其保存在知識庫中。
在這一步驟中，存在以下幾個關鍵問題：
1.關鍵問題一：服務端單用例代碼採集
現實中，我們的測試環境往往無法獨佔，如果採用開源的代碼覆蓋率工具，會出現以下問題：當多個人在同一環境並行進行測試的時候，我們採集到的是這段時間所有測試請求覆蓋的代碼，而無法知道具體的代碼行與用戶之間的對應關係，進而影響對測試範圍的判斷。
爲了解決這個問題，愛奇藝提出了兩種方案。
第一個方案是給每個測試同學搭建一套獨立測試環境，保證在一段時間內這個測試環境沒有其他人的干擾。另外，我們還要保證測試用例之間是串行執行的，不能併發。
這個方案原理非常簡單，但落實到操作上，給每個人搭建一套測試環境接入成本較高，保證所有測試用例串行執行，執行效率較低，落地的可能性極小。
因此，第二個方案就應運而生了。愛奇藝採用自研的代碼覆蓋率工具，改變原生代碼覆蓋率工具的實現方式，讓它能夠支持多人使用、並行測試。
上圖的上半部分是原生代碼覆蓋率工具，它只能獲取到一段時間內，所有測試請求覆蓋的代碼，如果同一測試環境中、同一時間內有多人共同使用，採集到的代碼就無法準確映射到單個測試用例上。
下半部分是愛奇藝自研的代碼覆蓋率工具，通過字節碼插裝技術，給每一個請求打上一個請求維度的標識，然後把代碼覆蓋信息按照請求維度進行記錄和保存。同時，它會攔截每個請求的請求數據，比如請求接口、參數、header信息（包含來源用戶IP）等。這樣就可以知道當前用戶或本條用例執行了哪個測試請求，它所覆蓋的代碼是什麼，解決了多人同時使用測試環境的問題。
2.關鍵問題二：服務端微服務架構
爲了提升服務的可擴展性，目前我們的很多業務都會採用分佈式的微服務架構。以支付業務爲例，當用戶發起支付請求時會經過網關層服務，轉發到產品層服務，然後調用具體支付渠道服務，整個過程中還會用到基礎服務層的多個基礎服務，共同完成一次請求任務。
但是在測試的過程中，我們可能只會從最外層發起調用，執行系統級測試。這個過程中有一個關鍵問題：在採集用例對應的代碼映射關係時，怎麼把底層微服務串聯起來，體現整體（系統級）代碼覆蓋情況？此外，在衡量代碼改動影響範圍時，也不能僅考慮單個模塊的影響，服務間調用關係的影響也必須納入考量範圍之中。當底層服務發生改動時，我們需要知道它所關聯的是具體外側模塊上的哪個用例。最後，對這類微服務底層模塊變更的影響範圍的判斷也比較困難，容易出現問題。
爲了解決微服務串聯的問題，愛奇藝參考了APM工具原理，給每個請求打上一個鏈路級別的標識，即鏈路的TraceID，放進請求的Header裏，在不同微服務模塊之間傳遞。我們只需獲取每個請求的TraceID，具有相同TraceID的請求就表示在同一個鏈路上，把同一鏈路上所有請求執行的代碼都和測試用例關聯起來，就可以完成系統級的串聯。
3.關鍵問題三：客戶端多組件聚合
客戶端多組件聚合的問題和服務端微服務架構問題有些類似。
近年來，客戶端開發模式逐漸向組件化的方向發展，例如對於安卓系統來說，一個組件對應一個SDK；對於IOS，一個組件則是一個POD。
組件化一方面是爲了讓各個業務線進行獨立的代碼管理和開發，降低代碼耦合；另一方面，是爲了抽取出一些基礎的組件以便複用。以愛奇藝app爲例，其主工程中包含很多提供基礎功能的基礎組件如網絡、播放、搜索、支付組件等等，還包括各個垂線業務的業務組件。所以在採集用例覆蓋代碼的時候，我們不能僅考慮主工程代碼，還要將各個組件的代碼聚合起來。
聚合多組件的方法是：在打包平臺上打包的時候，主工程和每個獨立的組件都會把各自打包的編譯產物和編譯信息上傳到存儲服務中。愛奇藝從APP獲取覆蓋率數據之後，需要找到每個組件的編譯產物進行解析。這首先需要找到主工程中組件依賴關係管理文件，比如IOS工程中的podfile。其次，通過解析podfile找到當前工程依賴的每個組件對應版本的編譯產物，就可以實現多組件的解析和聚合。
2.測試範圍精準推薦的實現方案及關鍵問題解決
用例代碼映射關係採集完成之後，便要利用知識庫進行測試範圍精準推薦。
當需求提測或者代碼發生變更，可以通過手工觸發或者CICD流水線自動觸發測試範圍評估。我們首先要獲取代碼變更的起始和終止版本，通過git查詢出兩個版本之間所有代碼提交記錄，解析發生變化的代碼，然後反查知識庫，計算出當前需要測試的範圍。
如果是手工測試，可以將影響用例自動生成手工執行的測試計劃。如果是自動化測試，在流水線裏觸發相應自動化用例執行即可。
但在第一個版本的精準推薦完成之後，仍然存在部分推薦效果不佳的狀況。例如當底層或公共代碼發生改動時，由於這些代碼關聯的用例較多，系統會推薦出大量冗餘用例，影響測試效率。此外，我們對推薦用例進行分析時，發現其中某些用例和我們改動的代碼邏輯並不相關。
這就引出了這部分的一個關鍵問題：推薦精準度提升。
針對這一問題，愛奇藝提出了降噪和分支級別精準兩種解決方案。
1.推薦精準度提升——降噪
以客戶端測試場景爲例，用例在設計過程中因爲執行步驟較長，在執行路徑中可能會關聯一些非驗證點的頁面或者操作。
例如，下圖中這三個用例都關聯到了“打開首頁”這一相同的前置步驟，當首頁代碼發生變化時，這三個用例都會被推薦出來，但這和我們的預期並不相符。
對此，愛奇藝採用設置基礎用例的方法進行降噪，把其他用例都會關聯到的公共操作或者一些起到承接作用的步驟設置爲基礎用例。比如圖中的用例1——打開首頁操作就可以作爲基礎用例，當基礎用例關聯代碼發生變更時，我們僅推薦基礎用例，其他的用例不再推薦，這樣便可以達到部分降噪的目的。
2.推薦精準度提升-分支級別精準
在第一個版本的精準推薦方案裏，精準度是代碼的方法級別或函數級別。我們會把用例和代碼的具體方法進行關聯，在精準推薦時，首先解析出有哪些方法發生變更，然後反查影響用例。但按照方法粒度去進行推薦可能產生用例冗餘。以下圖的方法爲例，這個方法中共兩個分支，用例1執行a=0分支，用例2執行a=1分支。當分支a=0內的代碼發生變化，若以精確到方法級別的推薦策略進行推薦，這兩個用例都會被推薦出來，但實際上用例2是完全不會受到影響的，這樣就產生了冗餘用例。
針對這個問題，愛奇藝對精準推薦方法做了升級，由之前的精確到方法級別優化爲精確到代碼分支級別。
首先，在建立知識庫的時候，就要將用例與代碼分支進行關聯。在進行分支解析時，我們會得到用例執行的分支條件（下圖右側紅色部分）及分支的內容即分支所對應的代碼塊（下圖右側藍色部分）。知識庫建立後，精準推薦時差異代碼的計算也要精確到有哪些具體的分支發生變更。這裏的方法是首先將本次提交代碼的分支條件與用例庫中用例的分支條件進行匹配，匹配一致再對比分支內容有無變化。如果發生變化，則需要做推薦，如果沒有發生變化，就說明它不受影響，也無需進行迴歸。
04
愛奇藝精準測試應用場景與效果
下圖是愛奇藝精準測試平臺能力展示。
通過平臺，可以實現對知識庫進行查詢，查看每個用例所關聯的代碼信息；另外，也可以看到每次精準推薦的結果，對這一結果進行分析，如有哪些用例被推薦出來、出於什麼原因被推薦、因爲哪些代碼的變更導致被推薦等等。
另外平臺還提供異常監控能力，這是因爲在用例代碼錄製過程中，尤其是在手工測試中，很有可能出現因測試同學人爲操作原因導致用例沒有被正確記錄下來的情況，從而影響精準推薦的準確性，進而影響到測試質量。
因此，愛奇藝會對關聯的代碼文件比較可疑的用例進行監控，可以在平臺上進行確認，或者重新錄製，以保證知識庫的準確性。
精準測試體系在愛奇藝服務端、客戶端手工測試及自動化測試場景中落地後，也實現了較好的效果。
在手工測試場景中，愛奇藝在服務端和客戶端多個業務線、多種迴歸測試場景中使用精準測試體系，數據顯示，針對迴歸測試的用例量級有較明顯的裁減，並且沒有出現因迴歸不全面而導致的問題。
對於自動化測試而言，其使用精準測試的原因一般是自動化用例量級過大、執行的時間過長或自動化結果的分析成本過高。
上圖右側是一個非常經典的自動化落地的場景：服務端流量錄製回放。要把線上用戶的真實流量轉到線下回放，進行迴歸測試。但是，線上流量量級非常大，不可能做全量回歸。
因此，愛奇藝首先通過代碼覆蓋率工具將一些代碼執行路徑重複的請求過濾掉，這樣可以去掉大部分請求。然而，過濾之後的用例在項目中測試或者CI過程中執行，量級仍然較大。因此愛奇藝又增加了一層精準篩選。最終，無論自動化CI執行時間還是自動化最終結果的分析時間都得到顯著降低。
05
未來規劃
未來，愛奇藝會對精準測試分析體系進行進一步完善，擴展更多的使用場景來建立測試流程整體上的閉環。
首先在精準迴歸領域，會擴展更多應用時機，例如監控客戶端灰度期間代碼變更，給出迴歸測試建議；實現前後端精準測試聯動，對於前後端集成測試用例，可以同時關聯前端代碼和後端代碼，實現全鏈路精準。另外，還可以採取更加智能化的推薦方法，比如自動給測試用例劃分等價類、通過智能算法給不同的用例推薦不同的迴歸優先等級。
其次，還會向其他更多的環節拓展，例如利用精準測試促進研測協同。當在測試過程中遇到bug的時候，可以通過精準測試技術在測試環節將bug執行的代碼軌跡記錄下來，再配合智能缺陷定位方法輔助bug定位。
最後，可以對測試結果進行充分度分析，分析測試的用例是否完全覆蓋了變更代碼，如果沒有覆蓋，可以通過一些方法幫助用例的手工補充，甚至自動生成用例進行補充。
福利!!! 關注公衆號，在後臺回覆關鍵詞“測試”，就可以獲得本次i技術會嘉賓分享PPT和錄播視頻。
也許你還想看
關注我們，更多精彩內容陪伴你！
本文分享自微信公衆號 - 愛奇藝技術產品團隊（iQIYI-TP）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。