摘要：随着雙 11 全球狂歡節的深入人心，在大促規模越來越大的同時，難題也擺在阿裡測試人面前。如何既遵守大促保密性要求不提前透露玩法，又能提前驗證到大促當天運作的功能？本次分享再現大促曆史性難題的解題過程，并由此展開，談到從一個大促保障平台産品，将該産品的底層能力分拆和下沉，為阿裡巴巴集團各業務測試團隊提供創新的底層能力。
演講嘉賓簡介：
李子樂（太禅），阿裡巴巴資深測試開發專家。畢業于浙江大學信電系。2010 年初加入淘寶，負責 PC 自動化測試架構的設計，包括淘寶全網 Web 自動化和旺旺用戶端自動化等測試體系的建構，是淘寶開源自動化測試架構 automan 的架構和主要開發人員。從 2011 年接觸無線，開始搭建團隊，負責設計無線自動化測試架構，及無線自動化持續內建體系，并完成阿裡第一套無線自動化架構 athrun 的開源。2013 年 all in 來往，後于 2014 年加入天貓，負責手機天貓測試團隊，現為新零售技術品質測試效能與飛豬品質的負責人。
點選直播視訊精彩回顧
以下内容根據演講視訊以及 PPT 整理而成。
一、背景-大促活動保障難點
玩法極其複雜： 阿裡大促保障活動中的玩法極其複雜多樣，如下圖中的幾個頁面。第一個頁面是日常态玩法，包括紅包和店鋪優惠卡券。但在雙 11 玩法會增加很多種類，如第二個頁面中的預設玩法，第三個頁面中雙 11 當天的售賣情況，以及最後一個頁面中的雙 11 整體的優惠情況，其中包括購物津貼、店鋪卡券、滿減、限時優惠等等非常豐富玩法。
無法真實驗證： 此外，阿裡做預演時無法提前預演雙 11 當天的活動。目前的驗證方法一般通過建構一個測試活動或者預發項目 debug 的方式驗證。以上兩種驗證方式效率非常低，而且無法驗證真實的場景。
量級大： 資料顯示，2018 年雙 11 達到了 2135 億的 GMV，菜鳥資料顯示 2018 年線上包裹量約為 10.24 億。如此量級的包裹數量無論對于交易還是履約或者物流系統都是極其大的考驗。
在此情況下，阿裡希望有一套方案，可以解決大促難點。首先，可以提前模拟大促情況，且覆寫新老玩法，并且需要關注在老玩法疊加新玩法的情況下，系統是否會産生額外的問題。
其次是模拟真實使用者場景，包括使用者會在優惠活動之前以及預熱時提前湊單，提前加購等場景。最後是場景聚類分析。一旦模拟真實場景下的使用者行為，需要分析覆寫了多少使用者，覆寫度如何，弄清楚哪些使用者沒能覆寫，這些場景都需要聚類分析的能力。
二、全鍊路功能-能力建設與實作
1. 環境能力
JVM 修改時間： 環境能力是從阿裡兩三年前開始建構的，當時是隔離環境，專供給壓測使用的。當時的能力可以将環境隔離出來且不會影響線上。隔離能力是之前壓測所具備的一個基礎能力，在隔離能力之上，阿裡開始研究是否需要具備時間修改的能力。時間修改主要是兩個方案。首先是修改機器時間，其缺點是需要改很多實體機或者實體機上某幾台虛拟機，但虛拟機可能不在隔離環境，可控性非常差。阿裡最終選擇了第二套方案，JVM 修改時間。将系統時間在初始化在界面布置時做一個偏移，可以令系統在啟動時的時間設為已經偏移好的系統。JMV 修改時間最基本的時間控制的能力。
隔離環境： 阿裡起初建設的隔離環境時并沒有很完善，其中包括環境的 HTTP 入口，ACL 的流量，或者直接從 VIP 入口過來。入口梳理不全會導緻被修改過時間的系統上跑了一些線上的流量，這是極其可怕的。
流量大圖： 有了流量大圖之後，非預期的流量可以看得非常清楚，可以作為兜底保護。在發現有非預期的流量進來之後，執行一套控制機制。如一些應用在隔離環境上部署，而有一些應用是隔離環境上沒有部署的，應用之間互相調用時，一旦發現下遊的應用沒有在隔離環境裡出現，則會有一個 fall back 機制重新讓它回到線上。進行了整體的邏輯梳理後，可以厘清哪些應用需要修改時間，哪些應用不需要修改時間。
灰階環境： 2018 年阿裡開始做灰階環境，灰階環境是隔離環境的更新版，其最主要特點是具備多套環境能力。一旦環境的使用方越來越多，可以在多套環境之間切換。
能力更新： 除了多套環境之外，阿裡還開發了一些能力的更新，如流量定制，資源管控和灰階流程。流量定制可以定制比如 8 套環境，定制不同流量到到不同的環境中，可以互不幹擾。資源管控包括環境的申請，業務方可以通過接口方式調用申請環境，也可以對環境進行擴容或釋放。并且整個釋出流程跟阿裡的釋出系統 Aone 進行了打通。越來越多的釋出需要走預發環境，beta 環境，或者 SPE 環境。灰階環境跟 Aone 打通之後，預發環境執行完後可以走到灰階環境進行釋出，灰階環境驗證通過之後再上線。
2. 資料能力
業務關聯表的維護：資料層面真正需要關心的業務很多。如使用者層面包括使用者收貨位址、積分、淘金币、卡券紅包、資産類和購物車等資訊，以及使用者資訊的脫敏，包括使用者手機号、收貨位址等。商品層面包括商品優惠、運費模闆、服務、庫存和店鋪賣家資訊等。業務關聯表的維護包含兩部分。首先是購物車方面，既使用者層面的加上商品層面。另外一部分是新玩法的模拟。如預售時 N 免 1 或者雙 11 購物券，需要将相應玩法的庫表進行同步。預售商品還包括預售訂單以及後面尾款的推進。根據 2017 年資料，整體具備的能力達到 1.07 億使用者，4379 萬的商品，165 台機器 12 小時做整體的資料同步，資料同步的量級達到 65 億。
3. 執行
執行需要做全鍊路模型的建構。首先，必填項不會修改，且會相應完善，如果沒有必填項資訊則無法下單，如選擇門店、身份證、手機号等。此外，按最優盡量多的覆寫邏輯，比如收貨位址會選擇目前位址首選收貨位址、卡券紅包預設勾選、購物車盡量多的選擇使用者目前購物車裡面的商品。按比例模型包括 PC 無線固定的占比、購物車立即購買、淘金币積分的比例。
4. 校驗
此外，阿裡在下單方面補充了校驗能力。通過執行大量用例衡量測試效果，構造過程中的失敗分析。構造完之後去下單并傳回傳回值，再校驗傳回值。BCP 是阿裡通過規則做校驗的架構，用來做消息的校驗和資料的校驗。
5. RBC—基于請求的代碼覆寫
發現有錯誤碼之後，需要逐個對錯誤碼進行分析，這時就引出 RBC。錯誤碼一旦真正跑出來，由于用例非常多，發現的錯誤也非常多。此時需要一個機制做不同的錯誤碼的分析。即使是相同的錯誤碼，經過的路徑可能是不一樣的。是以阿裡實作的 RBC—基于請求的代碼覆寫工具，起初在發現很多錯誤碼情況下做錯碼的分類，目前可以做目前執行情況的分析。
RBC 的特點首先是基于請求的代碼覆寫，與傳統的代碼覆寫不同，傳統代碼覆寫是跑一兩個小時或者跑半天，然後停掉覆寫率，再覆寫資料收集上來。而 RBC 會将每一個請求生成一個覆寫率的檔案。另外，RBC 具備跨應用聚合能力，在不同應用間通過 trace 做聚合。在跑很多用例之後，RBC 可以推薦真正有效的用例。後續可以通過有效用例集做持續內建回歸。
三、全鍊路功能-結果
1.2016 年雙 11
自 2016 年，阿裡開始實作全鍊路功能，可同步 1.07 億的買家，4379 萬加購商品，覆寫八大類優惠，7 種紅包玩法，覆寫積分，淘金币等 4 類資金交易工具，覆寫天貓超市，國際等 6 大垂直業務。執行用例達到億級，并發現了三個隐藏的 bug。
2.2017 年雙 11
2017 年除了購物車提前下單之外，覆寫了一些新的核心玩法。同步 6200W 買家的加購商品 5896W 個，包含優惠 313 種，紅包 17 種。核心玩法對接了多種玩法，涵蓋 2017 年雙 11 核心玩法，包括預售、搶先訂、買返、全管道、智慧門店、天貓出海、以及 TP3 遷移等風險較大的業務。2017 年提前發現問題 19 個，其中 7 個問題是通過線上資料訂正或者是線上配置解決的，7 個是一定要線上釋出的，因為全鍊路功能基本是在 11 月 1 号之後開始測試，7 個線上釋出的 bug 都需要緊急釋出。另外，發現 5 個影子問題，主要是影響壓測的風險。
3.2018 年雙 11
在購物車具體玩法覆寫的基礎上添加了用例精簡的回歸。精簡回歸将購物車仿真的用例通過 RBC 的能力精簡出來，精簡用例可以反複運作。2018 将 3000 萬的用例精簡到了 46 萬，46 萬基本上在雙 11 之前進行每日的回歸。2018 雙 11 新業務接入了所有核心的業務，包括飛豬回遷和新零售。此外，接入的新玩法包括信用購、新預售、零售通、優惠精簡等。接入的行業大型項目包括 1 小時達與超市主站融合、招商商品大促多報項目、阿裡健康 OTC 首報大促項目。貼近重點玩法提前發現了 34 個 bug，其中包括 11 個預售問題，以及 164 萬筆訂單無法支付尾款問題。
四、測試水電煤-資料、環境、RBC
在全鍊路功能演進過程當中，資料、環境和 RBC 作為整個測試的基礎設施，正在慢慢變成業務測試創新的驅動力，可謂是不可或缺的水電煤。
資料能力
資料具備怎樣的能力？首先資料需要具備從線上同步到影子的能力。其次，資料需要具備脫敏規則。另外，資料可以指定商品增量同步。阿裡剛開始做了全鍊路同步，包括同步購物車、億級的商品、龐大的使用者，都是一次性同步，量級達到 60 多億。後來實作增量增量同步的功能，一旦指定了某個商品進行同步，商品對應的後端所有庫表都可以被同步。
環境能力
環境能力包括多套環境，如兩個互相的業務方都依賴同一應用，之間不會互相沖突。其次是動态擴縮容，無論在 beta 環境還是 SPE 環境，在環境裡面機器相對來說是固定的，環境的資産投入是一次性的。動态擴縮容需要用某一套環境做一個大型活動，可以臨時的去其它環境或者從線上臨時将機器挪過來。動态擴縮容可以節約很大的成本。自定義引流政策支援的能力可以根據相應的 HTTP-head 資訊，使用者 id 或者根據相應的 IP 位址的規則進行自定義。
RBC 能力
RBC 具備跨應用聚合能力，在不同應用間通過 trace 做聚合。流量按代碼覆寫聚合，将每一個請求生成一個覆寫率的檔案，報告覆寫率。在跑很多用例之後，RBC 可以推薦真正有效的用例。
1.資料能力
資料賦能-零售通-全鍊路精準自動化平台
零售通是流動式的小店，包括校園店，夫妻店等店。零售通本身邏輯非常複雜，可分成幾個區塊。第一區塊是商品區域化售賣，其中包括倉配和店配。其次是整個複雜的區域化的營銷。供應鍊的體系包括倉組的體系，區域，城市到前置倉分級的體系。另外是倉庫路由，倉庫路由包括從倉到供應鍊的關系。零售通的背景模型組合較多，并且資料複雜。由于零售通線上資料很多，通過手工測試極其容易遺漏。此外，零售通業務疊代非常快，模型改動非常頻繁。零售通會經常做較大的重構，玩法更新較快。
零售通的解決方法是實作了一個實時建構的模型系統。查出線上模型的模型體系，考慮商品是一口價異或是不同的單品優惠，以及店鋪優惠的使用的情況，還有各個倉配的模型。模型從現場拉下來之後，可以根據模型實時比對出線上的資料，将其同步到影子表。零售通的案例與全鍊路功能的案例相似，都是模拟整個下單交易的體系，相對複雜的地方是交易和優惠等部分。零售通不同點是 Join 能力，零售通複用了 PC 自動化能力和無線自動化能力。首先線上上将具體單子跑下來，線上基準模型，再與預發上的模型進行比對，做圖檔對比校驗。下圖應用了從線上讀，并同步到影子寫的場景。同步的庫表包括會員的大量庫表，商品和營銷的庫表。零售通整體結果是支援 100 多個項目，整個模型構造的速度達到五分鐘以内。目前用例數達到 4 萬，整體執行效率每分鐘 2000 個，發現 30 多個 bug。
資料賦能-菜鳥-神舟
菜鳥和阿裡集團體系不同，菜鳥的特點是整體鍊路較長。菜鳥分為下單、發貨、接單、下發倉、倉接單、倉出庫、具體的分撥、幹線攬收情況，快遞員配送，以及最終妥投。整個鍊路涉及到兩百多個應用。另外，菜鳥無法複用交易下單能力。全鍊路壓測功能建構起來的影子體系難以複用。此外，菜鳥整體變更較多，架構更新非常頻繁。架構更新頻繁意味着菜鳥需要通過全鍊路的方式做保障。
神舟依賴影子鍊路和資料同步的能力，将商品、買家、賣家資訊等基礎資料進行同步，再分析線上訂單情況，對線上訂單進行分析和聚類後，做相應的訂單的偏移。菜鳥沒有直接同步訂單，而是找開發包裝了一個接口，接口會直接建立物流單。線上原來有個物流單，做偏移之後建立的物流單可以開始往下流轉，跳開鍊路中下單的過程。建立物流單之後再往下去流轉，與線上進行對比校驗。這導緻整體方案對比校驗難度較高。菜鳥的校驗是使用 DB 層 binlog 對比，對過程資料進行校驗。記錄線上快照寫入的字段，維護映射關系。影子再向 DB 層插一條資料，與原來線上插入的資料進行對比。神舟開發了多種執行政策，包括預發/線上影子鍊路，執行模式有區間式，全鍊路和單鍊路。區間式在全鍊路中選擇幾個應用。神舟整體結果到 2019 上半年用例數達到 60000+，發現 207 個有效 bug。
2.環境能力
環境賦能-中間件-灰階驗收平台 MASA
Pandora sar 包是一個隔離 jar 包依賴之間複雜性的容器。中間件測試團隊負責維護 sar 包，包括 sar 包版本的疊代和更新。中間件測試團隊遇到的困難首先是測試環境真實性不足，導緻 Pandora sar 包頻繁重發。在日常環境中很多情況測試不到。預發環境除了資料庫共用一套之外，機器、網段和機器的配置都和線上不同。此外，Beta 環境中部分應用沒有 beta 機或者沒有綁定 VIP，沒有隔離或者隔離不幹淨。小淘寶配置和代碼與線上環境千差萬别，導緻無法非常好的應用環境。另外一個痛點是應用非常多，且用法各異。上萬個應用，每個應用的用法都不同，如不同二方包的依賴，類加載順序的不同，插件配置的不同都會導緻 Pandora 啟動失敗。
中間件測試團隊的解決方法是首先使用灰階環境。從線上動态的劃分機器到灰階環境裡面。其優點是不需要實時保持機器都在灰階環境裡，日常或許隻需要 100 個應用，或者再上雲驗證時再多拉取一些應用。定向引流引的是功能流量和壓測流量。起初 MASA 隻使用了壓測流量，但隻有壓測流量不能提供很好的服務。功能流量像現有的自動化流量，支援全鍊路自動化功能，建立回歸的能力，中間件等。MASA 的結果在 2019 年驗收 sar 包 1292 次，即表明 MASA 通過不同的政策做了 1000 多次驗證。在灰階提前發現了 38 個 bug。
環境賦能-新零售終端-天狼灰階平台
新零售終端服務的業務還是較多的。終端指店員手持的終端 POS 機。目前零售通，居然之家，紅星美凱龍，盒馬都在使用新零售終端的 POS 做線下業務。而線上業務與線下業務在具體問題上是非常不同的。首先是線下業态直接進行灰階釋出風險較大。在超市結算排隊的場景，傳統的灰階可能 100 台機器會灰階一兩台機器，可能在某一單中顧客購買了 20 個商品，其中一個商品下單、結算時會出現問題。這個機率可能達到 1/4~1/5。灰階過程中如果按照傳統方式做灰階，百分比流量的影響面是不可控的。其次，灰階一旦發現問題，復原非常慢，若想将線上發現問題的機器復原掉，可能需要半個小時到 1 小時。線下體驗的故障影響時常是不可控的，缺乏快速恢複的能力。如果出現線下故障導緻 POS 機不能結賬，消費者就會把購物車丢到排隊線上，還需要保安維護秩序。顧客線下購物的成本非常高，如花費半個小時到超市，又花半小時挑選物品，這時顧客得知不能結算，線上下體驗會非常差。整體的風險需要額外方案去保障。
對于終端服務的解決方案是使用整個環境的能力做流量定制。按 POS 做灰階，比如一共有十條 POS 線，其中一條 POS 線是可能會壞掉，則可以請顧客先不要在這條線排隊，告訴顧客這台機器壞掉了，請到其它線排隊，相對來說顧客會比較了解。另外一個好處是可以做到快速復原，因為按 POS 其實是一個引流規則，引流規則可以很快的删掉，快速切流復原，恢複線下消費。天狼灰階平台的結果是整體灰階釋出驗證 345 次，提前發現 13 個問題。
新零售終端和天狼灰階平台還在一起建設灰階有效性度量标準。因為無論是通過灰階環，還是通過安全市場，灰階規則的設定還是偏向于“拍腦袋”決策。共建灰階有效性度量标準會做整個灰階的測試報告，灰階整體流量的情況做灰階範圍的确定。比如，新釋出的代碼是否都已經被灰階流量覆寫到？如果沒有覆寫到，則會有一個灰階報告出來，到灰階報告裡去确認流量都是有自己線下手工驗證過的，或者再補充手工測試用例確定可以覆寫到那部分代碼。
3.RBC—基于請求的代碼覆寫
RBC 賦能-螞蟻國際-精準回歸
目前阿裡龐大的單元測試用例，接口用例，導緻回歸耗時很長，以螞蟻國際某一個核心支付應用為例，4000 個自動化的用例，通過持續內建和持續傳遞，代碼合并之後跑一次需要 60 分鐘，整體的回歸非常慢，持續傳遞價值難以發揮。傳統做法是對用例篩選分類，如通過應用或者接口做分類，維護某幾個接口分别對應的用例，更新接口時隻需要跑一部分用例。另一個痛點是維護關系需要定期維護。這種方式相對來說粒度較粗，準确度不高，人工投入較大。螞蟻國際的解法是通過将用例執行引擎，接入 RBC，記錄用例經過的具體代碼，根據代碼變更去推薦用例，做到精準推薦和精準執行。上線新的代碼，相應的代碼在之前執行用例時 trace 被記錄下來。一旦 trace 修改過，将之前已經執行過的用例篩選出來重新做執行。
目前，螞蟻國際有 180+應用在使用精準回歸。螞蟻國際精準回歸的應用叫 Compass。Compass 每月支援 1.25 萬次精準測試的建構，單次平均節約時間 12 分鐘，累積節省回歸等待時間 14.4 萬分鐘。
RBC 賦能-新零售-暴雪
暴雪采集線上真實的流量做回放。通過采集記錄應用入口流量以及下遊調用的其它應用的流量，在下一次回放時直接依賴之前記錄的資料做回放，生成自動執行的接口測試用例。暴雪的特點是門檻低，無需提前準備資料，也不需要提前編寫腳本。暴雪第一個版本的缺點是大量的錄制回放用例重複度非常高。每天有不同的消費者在下單，請求跟請求之間的邏輯覆寫差不多，并且回歸的時間非常長。其缺點是執行場景不可控，而且沒有沉澱，無法得知覆寫是否足夠。針對上述痛點嘗試對用例進行相應的打标，如識别優惠券使用的情況。打标需要對業務邏輯進行人工梳理，成本較高，整體投入非常大。
暴雪的解決方法是與 RBC 合作，通過對流量逐個請求代碼覆寫收集。對流量進行精簡，篩選一緻和不一緻的流量，提取并儲存出不一樣的流量。再進行用例推薦，如跑了兩三天或者一星期存了很多的流量，後面又跑了一天跑出新流量，新的流量會被推薦出來，推薦給測試，測試确認新的流量确實有新的業務含義，則儲存下來。同樣，RBC 也被廣泛使用到業務平台的天啟，以及菜鳥青龍的自動化平台。目前暴雪推薦用例數目超過 50 萬，整體發現 bug 的能力上佳，使用者上報發現的有效的 bug 數統計超過 70 個。
最後，希望有越來越多的測試産品下沉，成為驅動測試創新的水電煤。目前的一些産品，如流量的采集和回放，都可以變成一個基礎設施。希望效能團隊真正做出一個産品後，不停深挖每個能力。做出一個創新之後，創新所依賴的非常多的底層能力可以沉澱出來。沉澱出來的功能可以賦能非常多的産品去做創新。這時業務測試同學也可以有自己的創新空間，效能同學也會有動力更好的維護下沉的産品，更好的做測試創新，成為驅動測試創新的水電煤。最後，希望有越來越多的測試産品下沉，成為驅動測試創新的水電煤。目前的一些産品，如流量的采集和回放，都可以變成一個基礎設施。希望效能團隊真正做出一個産品後，不停深挖每個能力。做出一個創新之後，創新所依賴的非常多的底層能力可以沉澱出來。沉澱出來的功能可以賦能非常多的産品去做創新。這時業務測試同學也可以有自己的創新空間，效能同學也會有動力更好的維護下沉的産品，更好的做測試創新，成為驅動測試創新的水電煤。
文章來源：阿裡巴巴技術品質
開發者社群整理