作者：吉玉
智能化測驗
在互動中經常需要維護大量的狀態，對這些狀態進行測驗驗證成本較高，尤其是當有功能變動需要回歸測驗的時候，為了降低開發測驗的成本，在這方面使用強化學習模擬用戶行為，在兩個方面提效：
- mock介面：將學習程序中的狀態作為服務介面的測驗資料；
- 回歸測驗：根據mock介面資料回溯到特定狀態，Puppeteer根據強化學習觸發前端操作，模擬真實用戶行為；
什么是強化學習呢？
強化學習是機器學習的一個領域，它強調如何基于環境行動，獲取最大化的預期利益，強化學習非常適用于近幾年比較流行的電商互動機制：做任務/做游戲 -> 得到不同的獎勵值 -> 最終目標大獎，在這型別的互動游戲中，獎勵是可預期的，用戶的目標是使得自己的獎勵最大化，這個程序可以抽象為馬爾科夫決策模型：玩家（agent）通過不同的互動行為（action），改變游戲（environment）的狀態（state），反饋給玩家不同的獎勵 （reward）；這個程序不斷回圈迭代， 玩家的最終目標是獎勵最大化，
接下來，我們使用比較簡單的Q-learning，來實作類似的智能化測驗目的，
Q-learning
對于不同狀態下，Q-learning的Q(s,a)表示在某一個時刻的s狀態下，采取動作a可以得到的收益期望，演算法的主要思想是將state和ation構建一張Q-table來存盤Q值，根據Q值來選取能夠獲得最大收益的動作，Q值的公式計算如下：
其中，s表示state，a表示action，α為學習率，γ為衰減率，r表示action能帶來的收益，
這個公式表示當前狀態的Q值由“記憶中”的利益（max Q[s',a]）和當前利益（r）結合形成，衰減率γ越高，“記憶中”的利益影響越大；學習率α越大，當前利益影響越大，Q-learning的目標是通過不斷訓練，最后得到一個能拿到最多獎勵的最優動作序列，
在賽車游戲中，玩家的互動行為包含購買車廂、合成車廂、做任務獲得金幣（為了方便理解，此處簡化為一個任務）；玩家從初始化狀態開始，通過重復“action -> 更新state”的程序，以下的偽代碼簡單的說明我們怎么得到一個盡量完美的Q表格：
// action: [ 購買車廂，合成車廂，做任務獲得金幣 ]
// state: 包含等級、擁有車廂等級、剩余金幣表示
初始化 Q = {}
while Q未收斂：
初始化游戲狀態state
while 賽車沒有達到50級：
使用策略π，獲得動作a = π(S)
使用動作a，獲得新的游戲狀態state
更新Q，Q[s,a] ← (1-α)*Q[s,a] + α*(R(s,a) + γ* max Q[s',a])
更新狀態state
簡單的demo地址：
https://github.com/winniecjy/618taobao
Puppeteer
由上面Q-learning的訓練程序，我們可以得到一系列的中間態介面作為mock資料，可以很快的回溯到特定狀態進行測驗，這一點在回歸測驗的時候十分有用，但是僅僅只是自動mock資料對效率提升還是有限，在618互動中，友商的互動團隊結合Puppeteer對整個流程進行自動化測驗，Puppeteer是chrome團隊推出的一個工具引擎，提供了一系列的API控制Chrome，可以自動提交表單、鍵盤輸入、攔截修改請求、保存UI快照等，
結合Puppeteer的一系列操作邏輯，部分是可以沉淀成為一個通用的測驗環境的，比如：
- 不同用戶型別，如登錄、非登錄、風險、會員等；
- 介面攔截mock邏輯；
- 頁面快照留存；
- 頁面性能資料留存；
- 其他常見的業務邏輯，如互動任務體系，跳轉后等幾秒后回傳，加積分；
- ...
彈窗規模化
在互動中，彈窗一直是視覺表現的一個重要組成部分，對UI有比較強的定制需求，
友商的思路是將所有的邏輯盡可能的沉淀，對于電商場景來說，彈窗的業務邏輯是可窮舉、可固化的，而互動場景之下，UI定制化需求很高，所以將UI層抽離， 僅對可復用的邏輯進行固化，以DSL + Runtime的機制動態下發，
結合這一套邏輯層模型，表達層/UI層也可以相應的結構化，根據專案 > 場景 > 圖層的維度，靜態配置和動態系結相結合，搭配對應的配置平臺就可以實作動態下發，
總結
對于智能化測驗，80%的流程其實成本是相對較低的，從測驗用例的生成到puppeteer自動化測驗，都是可以參考學習的，影像對比的部分需要較多訓練，對于固化的功能可以進行探索，如果是新的模式性價比較低，
對于彈窗規模化，部門內部的做法是將彈窗沉淀成一個通用的組件，只包含通用的兼容邏輯，包括顯示/隱藏、彈窗出現底層禁止滾動、多彈窗層級問題等，對于UI和其他業務邏輯，復用性較低，所以每次都是重寫，這種做法盡可能地保持了組件的通用性，在會場線比較適用，因為會場線的彈窗一般不包含業務邏輯（如抽獎、PK等），但是對于互動線來說，復用的內容相較于彈窗的“重量”來說顯得有些微不足道， 友商的沉淀思路前提在于上游介面的邏輯需要可復用，上游邏輯如果無法固定下來，前端的互動邏輯也較難固化，總體來說，友商在互動方面的沉淀思路大部分是從開發提效出發，主要供給內部使用；京東內部已有類似的互動提效方案終極目標是盈利，如京喜的社交魔方平臺和最近正在成型的滿天星平臺，所以沉淀方式都是以成套的H5，
參考
[1] 生產力再提速，618互動專案進化之路
[2] 機器學習相關教程 - 莫煩
[3] Puppeteer docs
歡迎關注凹凸實驗室博客：aotu.io
或者關注凹凸實驗室公眾號（AOTULabs），不定時推送文章，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/2368.html
標籤：Html/Css