簡介：從2019年雙十一的 “蓋樓 ”到今年618的 “開列車”，在大促互動遊戲背後，是業務多變性、產品穩定性和研發效率的多重博弈。本文介紹了淘系互動前端團隊如何應對研發效率 & 產品穩定性的挑戰，內容涵蓋“互動智能測試” & “彈窗規模化生產”這兩個技術方案。
2020年618大促已經過去，作爲淘系每年重要的大促活動，淘系前端在其中扮演着什麼樣的角色，如何保證大促的平穩進行？又在其中應用了哪些新技術？淘系技術特此推出「618 系列|淘系前端技術分享」，爲大家介紹 618 中的前端身影，上篇內容《618 大促背後的淘系前端技術體系》。
前言
本篇來自於 淘系技術部 互動前端團隊，今年我們帶來了名爲“幸運列車”的互動遊戲，攜全國各地的特色農貨和美食，讓大家在這個夏天尋味中國。
從2019年雙十一的 “蓋樓 ”到今年618的 “開列車”，在大促互動遊戲背後，是業務多變性、產品穩定性和研發效率的多重博弈。**本文介紹了淘系互動前端團隊如何應對研發效率 & 產品穩定性的挑戰，內容涵蓋“互動智能測試” & “彈窗規模化生產”這兩個技術方案。
**
互動智能測試
當前互動玩法愈發新穎多樣，這給業務開發的效率帶來很大的挑戰，我們需要在視圖模型中維護大量的狀態。
以列車合成區域（下圖紅框）的狀態爲例，共有10個合成位可以放置車廂，每個車廂有58個等級，開發的時候需要模擬大量的數據。另外在互動過程中還有抽中紅包等概率事件，異常狀態情況的驗證也有很高的成本。
618互動遊戲的玩法可以簡單歸納爲：用戶通過各種行爲獲取喵幣，消耗喵幣升級列車換取驚喜紅包，最後兌換現金紅包的過程。
我們通過機器學習的手段，幫助我們模擬用戶的行爲，獲得真實交互環境中產生的數據，而不是手動枚舉方式造測試數據。同時還結合 Puppeteer 模擬真實客戶端環境，在線上需要變更時，快速的進行前端功能迴歸驗證，減少研發成本。
▐ 強化學習
強化學習是機器學習中的一個領域，強調如何基於環境行動，以取得最大化的預期利益，也意味着能夠更快速的到達互動玩法的最終狀態。
其中環境通常被規範視爲馬爾可夫決策過程（MDPs）。首先介紹幾個概念：
- Agent：學習和做決策的主體
- Environment：Agent 交互的對象
- State：Agent 的狀態
- Action：行動，Agent 會根據當前的狀態選擇 Action
- Reward：獎勵
MDPs 簡單說就是一個智能體（Agent）採取行動（Action）從而改變自己的狀態（State）獲得獎勵（Reward）與環境（Environment）發生交互的循環過程。Agent 會持續的和環境交互，根據當前的狀態選擇 Action，而環境會給 Agent 新的狀態和 Reward。
爲了在項目中生成數據，我們定義瞭如下 Action：收金幣、購買車廂、合成車廂等。Agent 不斷與賽車玩法交互，Agent 從初始化狀態開始，進行“發送 Action -> 更新狀態”的循環，直到最終達到目標“抽大獎”，學習過程到此結束。
學習流程圖
我們將學習過程中的狀態快照記錄了下來，作爲服務接口的測試數據，幫助前端側開發和調試。
▐ 自動迴歸測試
互動場景下的前端交互非常複雜，然而前端功能迴歸一直以人工方式爲主。我們在項目中嘗試自動生成測試用例，用於迴歸測試。
從用戶交互的視角出發，收金幣、購買車廂、合成車廂都對應用戶的一次交互行爲。我們在 Puppeteer 環境中運行頁面，根據沉澱下來的數據，回溯到特定的狀態。並結合強化學習，擇優觸發前端Action事件，模擬真實的用戶操作，最終形成用戶的前端交互行爲樹。
用戶交互行爲樹
得到用戶交互行爲樹之後，我們會對行爲路徑再進行優化，排除無價值的鏈路，合併重複鏈路，並最終拆分成簡短的片段便於測試。如合成車廂 N 次，會處理成爲 N 個測試用例，儘量以同種狀態下的最短路徑作爲最終的測試用例。
前端測試用例圖
在需要回歸測試時，我們可以在 Puppeteer 環境中回放測試用例，做到了前端功能的自動迴歸。這個過程中，我們把各個測試用例的UI快照保存了下來，利用圖像識別技術進行最後的校驗。
以倒計時瀏覽任務爲例，我們需要驗證在跳轉後的頁面上，是否正確的展示了某個組件，通過圖像元素的對比，可以判斷該功能點是否正常。
檢測到組件，測試用例通過
互動項目的業務邏輯，是一系列用戶行爲帶來的反饋的組合體，智能測試方案在本次 618 互動項目中，成爲了前端開發測試階段的提效利器。在線上階段發生變更時，可以快速完成線上功能的全量回歸和新功能的驗證，保障線上業務的穩定。
彈窗規模化生產
今年的618的彈窗場景數量是去年618的2.5倍，彈窗由於可以避免觸及到遊戲區域的複雜變動，常常被用來滿足各類支線乃至主線需求，幫業務完成各個細分領域的玩法覆蓋，在無線營銷互動領域中，彈窗需求一直處於持續增量的狀態。
彈窗看似簡單，但每個彈窗都有自己的意義以及屬性，可複用範圍非常受限，傳統方式研發彈窗的成本較高，在業務快速發展的背景下，我們需要有更快更好的研發交付能力。
▐ 表達層與邏輯層的解耦
一般情況我們可能會將彈窗沉澱成包含UI的彈窗組件庫，也會進一步會將彈窗細節抽象出header、body、button、footer 等配置項。但這樣會有一些問題，在互動領域下的一個按鈕佈局、一個圖標形式都會讓這個“組件”越來越臃腫，所以不要天真的試圖用前端的設計思路，去預判設計師天馬行空的設計理念。畢竟不同的玩法和品牌形象下，對UI的定製往往有較強的訴求，因此在營銷互動中很難達到真正的UI可複用，因此我們要將表達層完全抽離出來，彈窗方案的邏輯層只負責模型的處理，表達層通過接受數據變化帶來的“表達”變化。
例如實現了一個抽獎玩法，邏輯層包含了數據模型、登錄初始化請求數據以及抽獎事件的後續邏輯行爲，那麼該數據模型下最終表達層選用的是老虎機、大轉盤還是直接點擊抽獎按鈕其實都是兼容的。
▐ 解耦下的彈窗邏輯層
參照上述的解耦方法，我們將彈窗的能力分爲UI層跟邏輯層，大致結構是邏輯通過事件喚起彈窗，先拋開UI層那麼先對邏輯進一步結構化，最終邏輯層的結構以及邏輯層跟UI層的關係如下圖所示：
邏輯層通過監聽業務數據層變換，初始化後Trigger管理器負責從配置隊列中檢索到匹配條件的行爲，開發者幾乎可將所有訴求類的彈窗根據Conditions（觸發條件）、 Times（展示次數）、Level（層級面）等能力描述出來，並通過配套的runtime快速生成業務所需的邏輯，例如一個初始化進來後的彈窗只需要描述這樣一個DSL：
▐ 解耦下的彈窗視圖層
爲了給予設計師更多的發揮空間，我們對UI進一步結構化拆解，直到要達到可以快速編排出UI，以及支持動態下發。
一個項目中往往會有多個彈窗，每個彈窗有許多圖層組合，假設類型比較簡單隻會有組、圖片、文案等類型的圖層，圖層上會有靜態&動態的屬性描述。
我們可以通過經驗所得來的項目 > 場景 > 圖層各個維度的拆解，把靜態配置+動態綁定等能力對彈窗的UI進行結構化描述，如下圖：
首先UI部分是純函數式的，所以只需要支持UI描述以及動態參數，就可以展示實際的彈窗UI，讓業務開發專注在彈窗的邏輯描述上。
配合提供相應的UI設計器，開發者就可以根據需求繪製出所有彈窗，把彈窗的UI開發成本降到最低：
618彈窗部分截圖
UI設計器
通過結構化UI層我們就很方便的做很多事情，首先彈窗UI跟邏輯方案都是DSL+Runtime的相同機制，所以只需要配合搭建平臺或者異步接口，就能快速支持動態下發的能力。
以及面向開發者協同以及視覺還原的真實預覽能力，在發佈時，平臺上的彈窗預覽功能將原來可能需要近半小時的彈窗配置review環節，縮短到幾分鐘，且準確度更高。
釘釘掃碼加入「淘系互動交流羣」
▼
關注「淘系技術」微信公衆號，一個有溫度有內容的技術社區~
原文鏈接：https://developer.aliyun.com/article/766550?
版權聲明：本文中所有內容均屬於阿里雲開發者社區所有，任何媒體、網站或個人未經阿里雲開發者社區協議授權不得轉載、鏈接、轉貼或以其他方式複製發佈/發表。申請授權請郵件[email protected]，已獲得阿里雲開發者社區協議授權的媒體、網站，在轉載使用時必須註明"稿件來源：阿里雲開發者社區，原文作者姓名"，違者本社區將依法追究責任。 如果您發現本社區中有涉嫌抄襲的內容，歡迎發送郵件至：[email protected] 進行舉報，並提供相關證據，一經查實，本社區將立刻刪除涉嫌侵權內容。