簡介：從2019年雙十一的 “蓋樓 ”到今年618的 “開列車”，在大促互動游戲背后，是業(yè)務(wù)多變性、產(chǎn)品穩(wěn)定性和研發(fā)效率的多重博弈。本文介紹了淘系互動前端團隊如何應(yīng)對研發(fā)效率 & 產(chǎn)品穩(wěn)定性的挑戰(zhàn)，內(nèi)容涵蓋“互動智能測試” & “彈窗規(guī)模化生產(chǎn)”這兩個技術(shù)方案。

2020年618大促已經(jīng)過去，作為淘系每年重要的大促活動，淘系前端在其中扮演著什么樣的角色，如何保證大促的平穩(wěn)進行？又在其中應(yīng)用了哪些新技術(shù)？淘系技術(shù)特此推出「618 系列|淘系前端技術(shù)分享」，為大家介紹 618 中的前端身影，上篇內(nèi)容《618 大促背后的淘系前端技術(shù)體系》。

前言

本篇來自于 淘系技術(shù)部 互動前端團隊，今年我們帶來了名為“幸運列車”的互動游戲，攜全國各地的特色農(nóng)貨和美食，讓大家在這個夏天尋味中國。

從2019年雙十一的 “蓋樓 ”到今年618的 “開列車”，在大促互動游戲背后，是業(yè)務(wù)多變性、產(chǎn)品穩(wěn)定性和研發(fā)效率的多重博弈。**本文介紹了淘系互動前端團隊如何應(yīng)對研發(fā)效率 & 產(chǎn)品穩(wěn)定性的挑戰(zhàn)，內(nèi)容涵蓋“互動智能測試” & “彈窗規(guī)模化生產(chǎn)”這兩個技術(shù)方案。
**

互動智能測試

當前互動玩法愈發(fā)新穎多樣，這給業(yè)務(wù)開發(fā)的效率帶來很大的挑戰(zhàn)，我們需要在視圖模型中維護大量的狀態(tài)。

以列車合成區(qū)域（下圖紅框）的狀態(tài)為例，共有10個合成位可以放置車廂，每個車廂有58個等級，開發(fā)的時候需要模擬大量的數(shù)據(jù)。另外在互動過程中還有抽中紅包等概率事件，異常狀態(tài)情況的驗證也有很高的成本。

618互動游戲的玩法可以簡單歸納為：用戶通過各種行為獲取喵幣，消耗喵幣升級列車換取驚喜紅包，最后兌換現(xiàn)金紅包的過程。

我們通過機器學習的手段，幫助我們模擬用戶的行為，獲得真實交互環(huán)境中產(chǎn)生的數(shù)據(jù)，而不是手動枚舉方式造測試數(shù)據(jù)。同時還結(jié)合 Puppeteer 模擬真實客戶端環(huán)境，在線上需要變更時，快速的進行前端功能回歸驗證，減少研發(fā)成本。

? 強化學習

強化學習是機器學習中的一個領(lǐng)域，強調(diào)如何基于環(huán)境行動，以取得最大化的預(yù)期利益，也意味著能夠更快速的到達互動玩法的最終狀態(tài)。

其中環(huán)境通常被規(guī)范視為馬爾可夫決策過程（MDPs）。首先介紹幾個概念：

• Agent：學習和做決策的主體
• Environment：Agent 交互的對象
• State：Agent 的狀態(tài)
• Action：行動，Agent 會根據(jù)當前的狀態(tài)選擇 Action
• Reward：獎勵

MDPs 簡單說就是一個智能體（Agent）采取行動（Action）從而改變自己的狀態(tài)（State）獲得獎勵（Reward）與環(huán)境（Environment）發(fā)生交互的循環(huán)過程。Agent 會持續(xù)的和環(huán)境交互，根據(jù)當前的狀態(tài)選擇 Action，而環(huán)境會給 Agent 新的狀態(tài)和 Reward。

為了在項目中生成數(shù)據(jù)，我們定義了如下 Action：收金幣、購買車廂、合成車廂等。Agent 不斷與賽車玩法交互，Agent 從初始化狀態(tài)開始，進行“發(fā)送 Action -> 更新狀態(tài)”的循環(huán)，直到最終達到目標“抽大獎”，學習過程到此結(jié)束。

學習流程圖

我們將學習過程中的狀態(tài)快照記錄了下來，作為服務(wù)接口的測試數(shù)據(jù)，幫助前端側(cè)開發(fā)和調(diào)試。

? 自動回歸測試

互動場景下的前端交互非常復(fù)雜，然而前端功能回歸一直以人工方式為主。我們在項目中嘗試自動生成測試用例，用于回歸測試。

從用戶交互的視角出發(fā)，收金幣、購買車廂、合成車廂都對應(yīng)用戶的一次交互行為。我們在 Puppeteer 環(huán)境中運行頁面，根據(jù)沉淀下來的數(shù)據(jù)，回溯到特定的狀態(tài)。并結(jié)合強化學習，擇優(yōu)觸發(fā)前端Action事件，模擬真實的用戶操作，最終形成用戶的前端交互行為樹。

用戶交互行為樹

得到用戶交互行為樹之后，我們會對行為路徑再進行優(yōu)化，排除無價值的鏈路，合并重復(fù)鏈路，并最終拆分成簡短的片段便于測試。如合成車廂 N 次，會處理成為 N 個測試用例，盡量以同種狀態(tài)下的最短路徑作為最終的測試用例。

前端測試用例圖

在需要回歸測試時，我們可以在 Puppeteer 環(huán)境中回放測試用例，做到了前端功能的自動回歸。這個過程中，我們把各個測試用例的UI快照保存了下來，利用圖像識別技術(shù)進行最后的校驗。

以倒計時瀏覽任務(wù)為例，我們需要驗證在跳轉(zhuǎn)后的頁面上，是否正確的展示了某個組件，通過圖像元素的對比，可以判斷該功能點是否正常。

檢測到組件，測試用例通過

互動項目的業(yè)務(wù)邏輯，是一系列用戶行為帶來的反饋的組合體，智能測試方案在本次 618 互動項目中，成為了前端開發(fā)測試階段的提效利器。在線上階段發(fā)生變更時，可以快速完成線上功能的全量回歸和新功能的驗證，保障線上業(yè)務(wù)的穩(wěn)定。

彈窗規(guī)模化生產(chǎn)

今年的618的彈窗場景數(shù)量是去年618的2.5倍，彈窗由于可以避免觸及到游戲區(qū)域的復(fù)雜變動，常常被用來滿足各類支線乃至主線需求，幫業(yè)務(wù)完成各個細分領(lǐng)域的玩法覆蓋，在無線營銷互動領(lǐng)域中，彈窗需求一直處于持續(xù)增量的狀態(tài)。

彈窗看似簡單，但每個彈窗都有自己的意義以及屬性，可復(fù)用范圍非常受限，傳統(tǒng)方式研發(fā)彈窗的成本較高，在業(yè)務(wù)快速發(fā)展的背景下，我們需要有更快更好的研發(fā)交付能力。

? 表達層與邏輯層的解耦

一般情況我們可能會將彈窗沉淀成包含UI的彈窗組件庫，也會進一步會將彈窗細節(jié)抽象出header、body、button、footer 等配置項。但這樣會有一些問題，在互動領(lǐng)域下的一個按鈕布局、一個圖標形式都會讓這個“組件”越來越臃腫，所以不要天真的試圖用前端的設(shè)計思路，去預(yù)判設(shè)計師天馬行空的設(shè)計理念。畢竟不同的玩法和品牌形象下，對UI的定制往往有較強的訴求，因此在營銷互動中很難達到真正的UI可復(fù)用，因此我們要將表達層完全抽離出來，彈窗方案的邏輯層只負責模型的處理，表達層通過接受數(shù)據(jù)變化帶來的“表達”變化。

例如實現(xiàn)了一個抽獎玩法，邏輯層包含了數(shù)據(jù)模型、登錄初始化請求數(shù)據(jù)以及抽獎事件的后續(xù)邏輯行為，那么該數(shù)據(jù)模型下最終表達層選用的是老虎機、大轉(zhuǎn)盤還是直接點擊抽獎按鈕其實都是兼容的。

? 解耦下的彈窗邏輯層

參照上述的解耦方法，我們將彈窗的能力分為UI層跟邏輯層，大致結(jié)構(gòu)是邏輯通過事件喚起彈窗，先拋開UI層那么先對邏輯進一步結(jié)構(gòu)化，最終邏輯層的結(jié)構(gòu)以及邏輯層跟UI層的關(guān)系如下圖所示：

邏輯層通過監(jiān)聽業(yè)務(wù)數(shù)據(jù)層變換，初始化后Trigger管理器負責從配置隊列中檢索到匹配條件的行為，開發(fā)者幾乎可將所有訴求類的彈窗根據(jù)Conditions（觸發(fā)條件）、 Times（展示次數(shù)）、Level（層級面）等能力描述出來，并通過配套的runtime快速生成業(yè)務(wù)所需的邏輯，例如一個初始化進來后的彈窗只需要描述這樣一個DSL：

? 解耦下的彈窗視圖層

為了給予設(shè)計師更多的發(fā)揮空間，我們對UI進一步結(jié)構(gòu)化拆解，直到要達到可以快速編排出UI，以及支持動態(tài)下發(fā)。

一個項目中往往會有多個彈窗，每個彈窗有許多圖層組合，假設(shè)類型比較簡單只會有組、圖片、文案等類型的圖層，圖層上會有靜態(tài)&動態(tài)的屬性描述。

我們可以通過經(jīng)驗所得來的項目 > 場景 > 圖層各個維度的拆解，把靜態(tài)配置+動態(tài)綁定等能力對彈窗的UI進行結(jié)構(gòu)化描述，如下圖：

首先UI部分是純函數(shù)式的，所以只需要支持UI描述以及動態(tài)參數(shù)，就可以展示實際的彈窗UI，讓業(yè)務(wù)開發(fā)專注在彈窗的邏輯描述上。

配合提供相應(yīng)的UI設(shè)計器，開發(fā)者就可以根據(jù)需求繪制出所有彈窗，把彈窗的UI開發(fā)成本降到最低：

618彈窗部分截圖

UI設(shè)計器

通過結(jié)構(gòu)化UI層我們就很方便的做很多事情，首先彈窗UI跟邏輯方案都是DSL+Runtime的相同機制，所以只需要配合搭建平臺或者異步接口，就能快速支持動態(tài)下發(fā)的能力。

以及面向開發(fā)者協(xié)同以及視覺還原的真實預(yù)覽能力，在發(fā)布時，平臺上的彈窗預(yù)覽功能將原來可能需要近半小時的彈窗配置review環(huán)節(jié)，縮短到幾分鐘，且準確度更高。

釘釘掃碼加入「淘系互動交流群」
▼

關(guān)注「淘系技術(shù)」微信公眾號，一個有溫度有內(nèi)容的技術(shù)社區(qū)~

原文鏈接：https://developer.aliyun.com/article/766550?

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。