自動化，如何無埋點形式復位場景

為啥會需要進行復位場景

好久沒分享了，抽取一個比較重要的做分享吧。首先自動化門檻不高，但是深入還是會跟隨程式碼能力很大變化，你目前所見都不是終點。
自動化遇到指令碼不穩定或者動圖沒有識別到導致當前指令碼失敗，影響後面指令碼，重新跑是在浪費自動化平臺的 task。
這個方案是可以不用使用埋點，埋點主要需要其他部門去共建新增，共建如果不是一個組的，還是溝通會比較慢的。
很多時候新寫一個關係圖或者很長的 Yaml 太麻煩了，這個就是解決這個問題的。

這個功能也可以衍生開發，觸發後記錄指令碼不穩定區域，比如在觸發需要復位行為的時候，記錄下自動化當前執行的時間。
如果這次復位失敗，透過自動前進到影片播放的時間去抽取圖片然後做出動圖或者擷取影片，這個不在本次分享，屬於未來的朱雀巡檢元件。
元件和平臺概念，元件不一定是服務，有一些簡潔的接入方式。平臺就是一個服務。

根由

1.從 NodeJs 找 node_moudle 的思想
2.透過日誌上下行方面檢索。

第一個的根由是 NodeJs 找 node_moudle 的順序是最近原則和使用者公共區域原則，Node 裡面的模組系統遵循是 CommonJs 規範。
第二個透過內部中間檔案轉換的日誌服務，日誌自動化分析是要取上文和下文的，一般來說日誌行為 key，內容為 value。傳入一個數字，負數為依次-1 往前行記錄，正數是往後，用於展示。

條件模式

執行方式：執行 client 或者節點端用程序，不用共享記憶體，做到變數隔離。
自動化的 TestCase 模式，要實現這個有幾個必要欄位（如果沒有平臺可以用 excel 進行管理或者資料庫的）
自動化欄位序號自增，檔名.類名，成員函式名字，檢查點介面名稱，資料沉澱區域
序號自增（int）：不用解釋了 也是會和功能測試對映
檔名.類名 (string) 是說明程式碼路徑，一個檔案一個類，拿到後在進行分割.轉換
成員函式名稱 (string) 是程式碼路徑對應類下面的成員函式，也可以透過反射拿到。填寫是為了和功能測試對映
檢查點介面（string[]）：每個 case 儘量就一個檢查點，如果有 2 個就是用,分割。
資料沉澱區域 (string[])：用於復位續跑，需要復位的類變數或者公共函式，復位可以理解為部分是 clear()，部分需要 - 一定的數字做為回退。
這裡可以存資料庫，存資料庫優勢是比較直觀，也可以不存。

核心函式

這個函式函式，作用是評估介面名稱是否支援恢復，返回是布林型別， 這個函式也可以有多個引數，比如有回退按鈕和直達路徑。
核心函式也可以用多個狀態（上面就有 2 個）去評估，這個是否可以用設定多個引數
多個引數用二進位制 0101 比如這個是 4 個，在轉成 10 進位制，10 進位制適合做列舉類，結果會呼叫透過 handler 處理函式，這個函式會進行復位的同時，把資料沉澱區域也恢復到同個 caseId.比如下面的 100 開始恢復到 97，對應需要復位的狀態就在資料沉澱區域可視。

同步場景如何做

需要一個 goto 場景的函式用於回退方式。
1.返回上個場景/介面面再次進入
2.直達路徑（遊戲產業太少了，自動化 + 效能測試退出再進就不準了）
3.返回多個場景/介面再次進入（走最短路徑）
資料沉澱區域和上面的都是根據 caseID 的，資料沉澱區域只需要做一些批次的 clear() 和做一些數字 +-和恢復具體某個資料的，所以會有多個函式。
一般資料不會很多的，如果都存在陣列套陣列裡面，拿到資料沉澱的陣列就是下標，下標就是 caseID+1.

具體例子

第 100 條 case 需要觸發復位，那就是傳入第 100 號 case，往前-1 依次尋找，然後呼叫核心函式去評估。
從 caseId 往上找對應一行自動化 case 的檢查點介面名稱，函式就是評估檢查點介面名稱的。
不同公司可以根據自己去開發評估，看到這裡就知道不用去記錄介面層級了。