知物由學 | 無需瞭解業務 也可進行低成本高覆蓋的測試方法

​​“知物由學”是網易易盾打造的一個品牌欄目，詞語出自漢·王充《論衡·實知》。人，能力有高下之分，學習才知道事物的道理，而後才有智慧，不去求問就不會知道。“知物由學”希望透過一篇篇技術乾貨、趨勢解讀、人物思考和沉澱給你帶來收穫的同時，也希望開啟你的眼界，成就不一樣的你。當然，如果你有不錯的認知或分享，也歡迎在“網易易盾”公眾號後臺投稿。

作為國內領先的內容安全&業務安全服務商，領先的不僅僅是智慧、高效、穩定的安全能力，其整個開發流程都非常具有代表性。本文就從測試角度，分享我們在API專案引流測試上的實踐，即透過引流平臺，將線上使用者的真實流量複製，並運用於自動化迴歸測試中，精準覆蓋核心業務邏輯，實現了低成本的日常自動化迴歸。

你們有沒有遇到過一個專案，曾易手多人，開發和QA換了一茬又一茬，短時間內無法全面熟悉內部邏輯，沒有完善的自動化迴歸用例集，每次上線前都感覺心好慌？

我所在的網易易盾部門，致力於提供業內領先的安全服務解決方案，隨著近幾年的高速發展，安全產品線越來越豐富，目前已多達20餘個。在這過程中，有些業務線出現重組，人員變更的情況。我現在手裡就有這麼一個API專案，在迭代過程中，開發換了兩三個，QA換了兩三個，歷史的介面用例在幾經易手後七零八落，沒有完整的介面自動化迴歸用例。然而，一個API服務沒有完善的自動化迴歸用例，這是任何一個有擔當有作為的QA同學所不能忍受的。我還記得那位靠譜的開發小哥哥過來問我：“我最佳化了底層服務的一些邏輯，你們有沒有自動化迴歸用例集跑一遍”，而我尷尬地說沒有的時候，他失望的表情深深地刺痛了我的心。

此處插個題外話，這個專案最初的1.0版其實就是我測的，後來轉手給其他QA同學，最後兜兜轉轉，又回到了我手裡，真是天道好輪迴，蒼天繞過誰。

然而要從頭梳理完整的介面迴歸用例集可不是一件容易的事情，尤其是在短時間內無法快速熟悉內部邏輯，用例設計遺漏風險是較高的。

另外，這個專案有個特殊之處，它會呼叫好幾個外部供應商服務，而這些供應商服務是收費的，平常測試時資料量不大，費用不高，專案組也能接受。而如果頻繁地進行迴歸，日積月累，勢必是一筆不小的開支。所以如果要進行自動化迴歸，必須把這些供應商服務mock掉。

mock這些供應商服務可是一個不小的工作量！看了下這些供應商服務，除了常見的http服務，還有一個是web service服務（使用soap協議），兩者的mock解決方案是不通用的，我得搭兩套mock服務。

還要設計各種各樣的mock用例，覆蓋不同供應商介面的返回值，後期維護這些mock用例也是個巨大的工程。

綜上所述，我大致羅列了下完善自動化迴歸用例目前的難點和痛點：

1、需要自己搭建mock供應商介面的服務，低效耗時；

2、設計較多mock供應商介面的用例，後期維護成本高；

3、部分固定的自動化迴歸用例執行過一次之後會失效，需要做一些資料清理工作；

4、短期內難以全面熟悉內部邏輯，用例設計遺漏風險較高。

​ 這時，引流平臺向我們丟擲了橄欖枝。

他們說：

我們有完善的mock機制，你說的上述mock痛點我們都能解決！

線上資料多種多樣，資料清理工作不用做了！

錄製線上流量在測試環境回放，可以真實模擬線上使用者行為，核心業務邏輯覆蓋不遺漏！

快速接入平臺，支援錄製實時回放，快速驗證錄製用例的有效性，快速建立迴歸用例！

降本提效，唯快不破！

​為了證（偷）明（懶）他（不）們（用）沒（寫）有（接）在（口）吹（用）牛（例），我決定試一試這個引流平臺。

引流測試的主要原理就是將線上流量錄製下來在測試環境中回放，並將線上流量的結果與測試環境回放的結果進行比對，如果兩者一致，說明測試環境功能和線上是一致的，如果不一致，則需要排查測試環境是否有bug，或者是因為功能改動造成的。回放一致的流量可以沉澱成迴歸用例集，這部分用例可以反覆使用進行迴歸，節省錄製新流量的時間。

原理沒毛病，接下來就是實踐了。引流平臺的小夥伴熱心又負責，讓我感受到了VIP客戶的待遇。

環境對接確實很快，只需要在引流平臺上執行一些基礎步驟，把他們提供的指令碼放在被測應用的機器上，執行指令碼成功後即可。

第二步：Mock配置，耗時：若干天

Mock是引流平臺的一大特性，它會將線上流量每一步的呼叫鏈路都錄製下來，記錄下每個中間步驟的入參和返回結果，從而實現mock。平臺提供了通用的中介軟體mock配置，比如Redis，kafka，mybaits等，但是對於程式碼中一些時間戳、隨機數，本地快取等資料，還有引數校驗、呼叫供應商等方法，需要提供具體的類名和方法名才能實現精準mock。透過這種手段，可以解決測試環境和線上環境業務資料不一致的情況。如圖所示：

這一步往往需要閱讀程式碼找出那些需要mock的類和方法，而且為了最大限度覆蓋程式碼業務邏輯，一般是需要找到最底層的呼叫方法。否則把上層方法mock了，那底層的程式碼邏輯就覆蓋不了了。但有時候會出現引流平臺錄製不到底層的mock方法，只能選擇mock往上一層的方法。所以這一步mock配置很難一次性就能配置正確的，需要閱讀程式碼找到mock的具體類和方法，會耗費較多時間，。在一次次回放失敗中不斷調式定位，反覆分析程式碼，終於補全了所有的mock方法：

第三步：錄製，耗時：20-30分鐘

錄製，即引流操作，是將使用者實際操作的流量或者測試人員手工測試的流量記錄下來，錄製下來的資料為作為回放的資料來源。

平臺支援全量介面的錄製，也可以選擇錄製某幾個介面。錄製時長和錄製總條數都可以手動設定，哪個條件先滿足就停止錄製，我一般設定的錄製時長是20-30分鐘。另外還要設定取樣率，例如取樣率10%，就是錄製10%的流量。這裡遇到的問題就是我們的專案需要設定mock的方法較多，導致引流平臺在錄製取樣時鏈路跟蹤記錄過多出現執行緒安全問題，會丟棄某些資料，導致回放失敗，所以每次錄製的取樣率不能設的過高，目前取樣率需要控制在10%以內。而有些專案沒有這方面的問題，取樣率100%也是ok的。

將剛才錄製下的流量，在被測應用的測試環境中進行回放，看相同的請求入口，輸入相同的請求引數，在Mock了基準資料後，請求的返回是否與錄製的時候一樣，以此來實現功能驗證。被測應用是個API服務，因此回放速度是很快的。我還嘗試了下錄製並實時回放功能，一邊錄製一邊回放，錄製結束的同時回放也結束了，十分高效。

回放結束之後，就能立馬看到成功和失敗的用例。如果全部成功，則說明測試環境功能正常，我們主要關注失敗的用例，分析失敗的原因，是bug引入or需求變動導致的。平臺跟蹤並記錄了請求過程中呼叫鏈路上的每個環節，並提供線上環境與測試環境的比對，可以點選進入詳情頁檢視：

第六步：沉澱迴歸用例集

引流平臺會將回放成功的用例進行彙總統計，放進【用例統計】中，然後可以在這些用例中，自定義選取用例生成用例集合，用這個用例集合回放實現迴歸測試。同時提供用例去重功能，即相同介面且入參一樣的用例，只保留最新的。目前已沉澱了一批用例，後續日常回歸可以將這批用例全量進行回放，省去線上環境錄製新流量的時間，整個流程只要幾分鐘就搞定了。

當然隨著程式碼的變更迭代，用例統計中錄製的歷史資料在後續回放中可能會失敗，可以將這些回放失敗的用例一鍵刪除，這個功能我覺得十分好用。

衡量引流測試效果的指標當然是程式碼行覆蓋率了，引流平臺的未來規劃是將覆蓋率整合進來，透過覆蓋率做自動推薦用例，但該功能還在孵化中，我只能自己手動統計了。最後統計出來程式碼行覆蓋率達 63% ，分析了下，基本覆蓋了線上使用者的主要使用路徑，沒有覆蓋的程式碼行主要是以下幾點：

1、mock了一些引數校驗方法

2、有些mock方法較上層，少了部分覆蓋

3、異常邏輯覆蓋，比如針對供應商返回錯誤碼的處理，線上較少出現這種情況，沒有錄製到相關流量

理論上來說，隨著錄製量越來越多，以及不同時間段錯開錄製，資料會更加多樣化，程式碼行覆蓋率也會越來越高。

在實踐引流測試之前，引流平臺負責人曾和我一起展望了下預期收益率，如今回顧了下，它確實做到了當初的一些承諾：

1、彌補迴歸用例缺失：透過錄制回放快速回歸，保障專案質量

2、節約時間成本：自帶mock機制，無需額外實現mock供應商的微服務

3、節約用例維護成本：回放成功的用例不斷沉澱形成迴歸用例集，並且提供去重功能，用例維護成本低

4、降低用例遺漏風險：真實模擬線上使用情況，無需全面熟悉內部邏輯，依然可以實現主幹業務邏輯的精準覆蓋

當下一次開發小哥哥讓我回歸一下API服務時，我可以從容不迫地開啟引流平臺，建立迴歸用例集，啟動錄製回放任務，然後去泡一杯菊花枸杞茶 ，悠哉地喝上一口，點選檢視測試報告，然後向開發小哥哥報告：迴歸測試透過，可以上線啦。

當然還有一些問題

沒有完美的測試工具，此次引流測試實踐也遺留了一些問題。

1、程式碼行覆蓋率的提升

根據我們測試團隊的實踐經驗，一個API服務的程式碼行覆蓋率是可以達到 70% 以上的，目前我們核心業務自動化迴歸測試的程式碼行覆蓋率均在70%以上。引流測試實現主幹業務邏輯的精準覆蓋，然而因為mock原因以及線上流量缺少異常邏輯覆蓋，導致程式碼行覆蓋率無法進一步提升，這些未覆蓋的程式碼還是需要額外手段去覆蓋補充。

2、用例穩定性考量

目前是透過引流測試建立迴歸用例集，所以線上流量結果和測試環境回放結果是一致的（若不一致就是引流平臺的bug了），後續隨著業務迭代變更，若出現兩者結果不一致的情況，是否能夠快速定位分析問題所在，修復迴歸自動化用例，缺少實際經驗，迴歸用例穩定性方面有待考量。

1、開展更多引流測試實踐

這次接入引流平臺的專案是一個整體架構較為簡單、核心功能只有一個模組應用的小型API專案，本身也比較適合引流測試。後續希望開展更多專案的引流測試實踐，在現有測試手段的基礎上，透過引流測試真實模擬使用者使用情況，有效確保核心業務邏輯精準覆蓋，提升質量信心。

2、將引流測試融入日常研發流程

引流測試可以進行歷史功能迴歸、重構功能的測試與驗收，相比其他測試手段，引流測試是一種低成本高覆蓋的測試方案，無需測試分析、人工設計用例，測試準備和測試執行的工作大大減少，非常適合成為開發自測的手段。如何讓引流測試融入日常研發流程，也是需要不斷摸索的。在後續的實踐過程中，要讓引流測試真真切切帶來降本提效，為開發自測賦能，為QA解決痛點，為專案提升效率，為質量保駕護航。

相關閱讀：

知物由學第五十四期 | 社交風控中遇到的問題，可以用這些手段進行“圍追堵截”

知物由學第五十三期 | ESIM模型的“全能版”！網易易盾實驗室研究員解讀HIM混合推理模型

知物由學第五十二期 | 淺談網易易盾雲真機檢測

點選免費試用【穩定的】網易易盾安全服務。