“知物由學”是網易易盾打造的一個品牌欄目，詞語出自漢·王充《論衡·實知》。人，能力有高下之分，學習才知道事物的道理，而後纔有智慧，不去求問就不會知道。“知物由學”希望通過一篇篇技術乾貨、趨勢解讀、人物思考和沉澱給你帶來收穫的同時，也希望打開你的眼界，成就不一樣的你。當然，如果你有不錯的認知或分享，也歡迎在“網易易盾”公衆號後臺投稿。
作爲國內領先的內容安全&業務安全服務商，領先的不僅僅是智能、高效、穩定的安全能力，其整個開發流程都非常具有代表性。本文就從測試角度，分享我們在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客戶的待遇。
第一步：環境對接，耗時：20分鐘
環境對接確實很快，只需要在引流平臺上執行一些基礎步驟，把他們提供的腳本放在被測應用的機器上，執行腳本成功後即可。
第二步：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的。
第四步：回放，耗時：5分鐘
將剛纔錄製下的流量，在被測應用的測試環境中進行回放，看相同的請求入口，輸入相同的請求參數，在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解決痛點，爲項目提升效率，爲質量保駕護航。
相關閱讀：