本文要點
1、分散式微服務架構下的自動化測試，傳統的金字塔分層測試理論是否仍然無懈可擊？為什麼說基於服務的介面自動化及全鏈路迴歸最具價效比？
2、如何破解介面自動化測試及全鏈路迴歸技術門檻搞、用例準備效率低、構造資料難、鏈路複雜、結果校驗等痛點？全鏈路智慧測試自動生成測試場景、一鍵呈現全鏈路校驗資料，自動生成測試報告，鏈路整合測試由2天縮短為10分鐘。
3、生產流量錄製回放，自動錄製線上數以萬計的真實場景用例資料，有效提升線下回放的測試覆蓋率和充分度，用例構建1天減少到分鐘級，效率提升百倍。
出處:https://mp.weixin.qq.com/s?__biz=MzU3NzczMDI4Ng==&mid=2247484320&idx=1&sn=3e650dc5f2dd9a255a2a3570eaa8de59
01
前言
質量和效率，是業務研發過程中最注重的兩個維度。高質量是保障業務平穩進行的絕對前提，高效是更好保障高質量地重要條件，二者不可分割。在業務飛速發展的當下、產品迭代越來越快、專案越來越多，交付週期越來越短，這給質量和測試帶來了前所未有的挑戰。基於經典金字塔模型分層自動化等最佳實踐為解決質量和測試的挑戰提供了很好的思路。
02
經典測試分層理論
金字塔分層測試的自動化，有這如下的特點
單元測試自動化可重用的測試用例 ：在相同或更改的環境下輕鬆地多次重用相同的測試用例，透過消除場景中的人為因素來保證準確性，以一半的預算提供更精準的結果。執行時間更少：允許“快速失敗”，可以及早發現程式碼中的錯誤和故障，減少返工成本。最大的測試覆蓋：可以同時執行多個複雜的測試用例，提供了比傳統測試更大的覆蓋範圍，從而使團隊可以構建更全面，更高質量的產品。具有成本效益的解決方案 ：最初投資似乎很多，但從長遠來看，它以更少的體力勞動，早期的錯誤修復以及開發和測試人員之間的協作確保了生產成本的最小化。基於服務的介面測試自動化相對UI測試更為前置，把問題攔截在前期，降低問題修復成本。前後端分離結構，各服務之間更多的是透過介面來實現互通，對介面進行直接測試，相比Unit單元測試可以更全面的覆蓋各類測試場景。價效比較高：相對來說，介面就比較穩定，入參和出參相對固定的，用例這樣維護起來也比較方便。因為按介面測試，出現問題後在被測介面中排查，UI自動化：價效比最低，辛辛苦苦寫好的測試用例，跑了還沒幾天，新的需求之後，開發把頁面改了，原來定位的控制元件失效了，N條測試用例跑不通了。維護成本高，自動化測試指令碼構造的越快，維護成本也就越大。比如一個UI節點細微的變化，可能導致自動化工具沒有識別UI控制元件，那麼所有用到這個控制元件的測試用例都需要更新，查詢替換並且保證沒有替換錯就是一個很大的工作量，更別說一般錄製的指令碼人工都不容易理解。穩定性差，某條測試用例本地除錯的時候是通的，批次執行的時候就失敗了。上次跑通了，這次又失敗了。。。這既有程式碼的問題，也有影象識別解析度的問題。03
我們的看法
在《google 測試之道》一書，對於google產品，70%的投入為單元測試，20%為整合、介面測試，10% 為UI層的自動化測試，對分層自動化測試來說，這有一定的指導意義。
UI自動化位於分層金字塔的頂層，貼近客戶真實需求和業務場景的黑盒測試。但受限於各方面因素，投入了人力、物力、財力，但往往收穫頗微，這更適合UI相對穩定和大量UI重複操作等場景的自動化。我們認為在UI方向的自動化測試投入應該更為慎重，主要依靠人工測試是可以接受的。Unit單元測試自動化有著白盒程式碼覆蓋全、效率更高、返工成本更低。但由於其主要聚焦在單系統內的實現邏輯，某種意義上說離整個系統的表現、客戶需求、業務場景距離仍太遠。在分散式微服務架構下，業務鏈路和微服務間互動尤為複雜，介面自動化天生為高複雜性的平臺帶來高效的缺陷監測和質量監督能力，系統越龐大介面測試的效果越明顯，能有效提高測試效率，提升使用者體驗，降低研發成本。綜合UI自動化和單元自動化兩者的優勢和不足，我們認為基於服務的介面自動化及全鏈路迴歸是最值得投資和投入的，所以我們推薦以下橄欖球分層模型。
03
介面自動化痛點
這裡所說的介面自動化測試包含兩類，一類是純介面的驗證，一類是介面場景類的測試。前者類似於用Postman之類的測試工具改改引數再下發介面，檢視一下結果是否符合介面邏輯，這一類相對來講比較簡單，螞蟻智慧測試平臺也有非常成熟的產品能力。後者是由介面構造一個測試場景，實際上是一種業務功能的測試，只不過由介面來銜接，這類介面自動化涉及到了業務功能的測試，往往會節省較多的測試工作量，尤其是在進行迴歸測試的時候。
介面場景類的測試，即使用介面來完成業務的邏輯測試，特別是全鏈路迴歸是本文主要探討的方向，其主要的痛點如下：
鏈路複雜，一個支付寶的全鏈路可能涉及幾百個系統，海量的驗證點人工難以有效梳理。入參構造困難，對於下游系統來說入參有上百個，很難去模擬某一筆業務的真實的業務入參進行測試驗證。資金流涉及人員多、資料確認複雜導致確認週期長。老業務迴歸需要金融核心層系統反覆確認資金流資料。環境不穩定，重試依賴各種環境和人，難以快速發起。例如在一個典型的支付場景中，不光鏈路複雜，單純一個資金流的資訊也極為龐大，涉及到大量的系統和資料互動。
04
解決思路
全鏈路介面智慧測試的一個核心思想是採用自動化，智慧化，平臺化的方式去自動生成場景、一鍵式呈現全鏈路校驗資料，自動生成測試報告，幫助使用者快速理解業務和進行校驗，並提供極致簡單的測試服務。
無需編寫測試指令碼，將使用者行為透過元件化編排，拖動元件快速生成全鏈路用例，不同業務場景可以自由組合執行用例，實現全鏈路跨系統的自動化整合測試，標準化質量執行。
通過錄制線上流量，對線下環境的開發分支進行回放校驗，以達到對系統比較全面的業務迴歸。
05
最佳實踐
全鏈路介面測試
新建用例模板，可自由對元件、管道進行編排和設定。生成用例，只需要在模板上填入基本資訊就可以新增一個用例，然後在每個節點上可以編輯用例引數，填入自己用例的入參和用例名稱。用例執行和排程，透過實驗室管理用例集，支援手動執行或定時自動執行。測試報告和執行詳情。錄製回放錄製回放通過錄制線上的全量資料，包括測試驅動資料，下游需要mock的資料，以及校驗的基線資料，所以可以做到降低介面測試的建設成本，覆蓋比較全面的場景，有效的mock，以及全面的校驗
線下自動拉取線上錄製資料並構造用例，免去了開發線下編寫測試用例的時間和精力；自動錄製線上數以萬計的真實場景用例資料，有效提升了線下用例回放的測試覆蓋率和充分度；用例迴歸更能接近線上真實環境的行為，貼近業務真實資料。錄製回放的核心邏輯主要包括以下幾個部分
資料採集：無侵入的統一資訊模型採集能力，在鏈路系統中採集全鏈路的必要資訊（物件、db、訊息），轉換成統一格式日誌進行列印。資料模型統一：智慧測試平臺經過E（extract）、T（transform）、L（load)對全鏈路資料進行提取加工。模型化智慧推薦核驗關係：智慧測試平臺對資料進行規則處理，把校驗規則自動清洗沉澱成表-表一致性校驗規則、物件-表一致性校驗規則、訊息-表校驗一致性規則等。可擴充套件校驗引擎：最後透過自動校驗引擎，輸出整體的全鏈路校驗報告和通知，並且每個服務化能力都有統一的服務能力提供給使用方。錄製回放技術仍然面臨較多挑戰，需要透過技術創新不斷得到解決
錄製 - 全場景且最小子集：錄製期望利用線上的真實流量，獲取系統全量的業務場景用例集；但是同時希望用例集是沒有重複用例的，對於回放來說，同樣的用例不需要線上下回放兩次以上。落地 - 迭代變更的適配（側新）：之所以要進行錄製回放是因為有變更，有變更就有可能對我們已經錄製的資料造成影響，甚至導致大部分的用例無法在此次迭代使用，迭代變更對回放效果的影響是導致大部分團隊放棄利用此方案的最主要原因之一。回放 - 不斷降噪（問題排查）：因為錄製用例的龐大，假設目前用例有10w左右，就算透過達到了99%以上，失敗的用例也有1k左右！其中除了以上的迭代變更影響，各種噪音是影響方案最終落地的攔路虎。排除環境差異、配置差異、資料差異引起的回放資料和錄製資料不一致（噪聲），那麼剩下的應該就是發現缺陷了。06
落地效果
全鏈路介面測試
操作簡單，使用方便，透過自動規則引擎，不需要人工配置任何校驗規則，比以往傳統的透過編寫業務規則指令碼效能上提升了百倍，並且透過全鏈路的資料串聯能力，幫助我們更好分析全鏈路的資料，保障資金安全。網商銀行、支付寶等：解決使用者業務聯調過程中人工觸發聯調效率低、結果校驗易遺漏痛點問題，提供完整自動化測試解決方案，用例構建1天減少到分鐘級，效率提升百倍。錄製回放結合內部開源工具，開創性地構建了無侵入錄製採集框架工具，能夠靈活對被測系統進行資料採集，透過大資料處理，自動分析合併業務場景，產出符合業務語義的用例場景，並透過高效迴歸引擎驅動，做到了億級流量降維用例轉化，自動保鮮、高效迴歸。
在金融核心各業務接入情況來看，自動化測試用例膨脹增長了10倍：
06
結語
全鏈路介面智慧測試方案可以幫助開發和測試同學不再困擾於本地測試用例的編寫和維護，從而專注於業務程式碼功能的研發；與此同時透過對線上真實流量的模擬模擬回放達到對系統更加全面的業務迴歸，幫助測試同學提升測試的充分度，增加測試迴歸的信心指數。
出處:https://mp.weixin.qq.com/s?__biz=MzU3NzczMDI4Ng==&mid=2247484320&idx=1&sn=3e650dc5f2dd9a255a2a3570eaa8de59