做者：吉玉html
智能化測試
在互動中常常須要維護大量的狀態，對這些狀態進行測試驗證成本較高，尤爲是當有功能變更須要回歸測試的時候。爲了下降開發測試的成本，在這方面使用強化學習模擬用戶行爲，在兩個方面提效：前端
- mock接口：將學習過程當中的狀態做爲服務接口的測試數據；
- 迴歸測試：根據mock接口數據回溯到特定狀態，Puppeteer根據強化學習觸發前端操做，模擬真實用戶行爲；
什麼是強化學習呢？git
強化學習是機器學習的一個領域，它強調如何基於環境行動，獲取最大化的預期利益。強化學習很是適用於近幾年比較流行的電商互動機制：作任務/作遊戲 -> 獲得不一樣的獎勵值 -> 最終目標大獎，在這類型的互動遊戲中，獎勵是可預期的，用戶的目標是使得本身的獎勵最大化。這個過程能夠抽象爲馬爾科夫決策模型：玩家（agent）經過不一樣的交互行爲（action），改變遊戲（environment）的狀態（state），反饋給玩家不一樣的獎勵 （reward）；這個過程不斷循環迭代， 玩家的最終目標是獎勵最大化。github
接下來，咱們使用比較簡單的Q-learning，來實現相似的智能化測試目的。算法
Q-learning
對於不一樣狀態下，Q-learning的Q(s,a)表示在某一個時刻的s狀態下，採起動做a能夠獲得的收益指望，算法的主要思想是將state和ation構建一張Q-table來存儲Q值，根據Q值來選取可以得到最大收益的動做。Q值的公式計算以下：chrome
其中，s表示state，a表示action，α爲學習率，γ爲衰減率，r表示action能帶來的收益。api
這個公式表示當前狀態的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），不定時推送文章。