簡介：從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?

版權聲明：本文中所有內容均屬于阿里云開發者社區所有，任何媒體、網站或個人未經阿里云開發者社區協議授權不得轉載、鏈接、轉貼或以其他方式復制發布/發表。申請授權請郵件developerteam@list.alibaba-inc.com，已獲得阿里云開發者社區協議授權的媒體、網站，在轉載使用時必須注明"稿件來源：阿里云開發者社區，原文作者姓名"，違者本社區將依法追究責任。 如果您發現本社區中有涉嫌抄襲的內容，歡迎發送郵件至：developer2020@service.aliyun.com 進行舉報，并提供相關證據，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的生产力再提速，618 互动项目进化之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。