遊戲自動化型別和方向

####話題
來自看到UI自動化覺得無用，但是網路層不知道怎麼寫，只會抓包。這裡來談談目前見到和實現和寫過Demo的遊戲自動化型別。
先從驅動測試套件方式和快速編寫 緯度來談談，裡面部分內容可能存在爛大街，但是儘量把一些技巧給寫出來。

驅動測試套件方式

測試套件就是你要執行的測試用例方式，大體如下。
1.單元測試框架驅動測試case目錄。
2.訊息佇列驅動case目錄。
"小茅屋"流程圖如下。
執行單位(執行緒/程式)==>adb驅動手機 ==>橋接==>電腦程式 ==>find測試執行路徑==>bind手機序列號（佔用）==>開始執行testsutie.

根據業務收集，主流是第一種，第一種優點是框架本身提供了一些完備功能（驅動執行，決定執行順序，條件表示式可以跳過，統計測試結果，配合檔案提供報告等）
如果Python棧的話，pytest和unittest，都是重約定，差異是前者是以裝飾器為主的外掛流派，裡面case不用遵守ascii命名規則，後者提供了（靜態和動態）重排測試用例執行功能。

動態重排模式如下：
檔案1：case排列.py（依賴字串模板和配置描述檔案生成）一開始只有預設帶pass空函式，但是會引用測試用例模組下面的init.py，這個裡面會提前匯入所有測試套件類。
init.py裡面內容會匯入到檔案1.
檔案2：前置設定等行為.py（用於負責自動化case前置步驟和一些前置步驟檢查包的元件，這個回頭在其他文章自動化元件內會提到）
檔案3：main.py(能短就短) main檔案內初始，引用了檔案1和檔案2.裡面第一行寫字串模板和配置描述檔案生成的方法呼叫，填充檔案1成功後。
檔案內部內容順序 1.檔案1填充方法 2.檔案2呼叫.3.檔案1方法驅動。
缺點:
1.一旦斷線和異常斷開只能重新跑。
2.如果混合單測框架進行開發，一些繼承自研方法類無法被繼承。
3.不使用全域性的，驅動下個檔案會被覆蓋。

訊息佇列模式和前者差異最大為前者要有類物件，訊息佇列反而不推薦有，當然有也可以。
優點：
可以斷開續傳，只需要記錄當前一批生產者函式資訊，下次從最近一次應該執行函式開始走起。

訊息佇列模式，細分為2類，一個是引用資料型別的訊息佇列，一個是mq的訊息佇列。
推薦使用mq的訊息佇列（rabbitmq），自己寫的訊息佇列加了很多功能也比較簡陋，這個我頭鐵試驗過已踩坑。
連結佇列實體，生產者定義一個佇列名（消費者用同一個），生產者批量傳輸按測試用例模組劃分的用例函式插入，消費端進行接收後可以確認後執行。
自動化要做阻塞模式，介面部分場景用非阻塞模式。

需要預防出現訊息重發，可以引用一套資料結構，這個資料結構並且可以作用到單測框架使用中去。
{"project":"xxxxGame","data":{"case1":{"status":"pass","err_code":"自定義\n----------\n加堆疊資訊","pic":"視訊拆出的動圖/錯誤截圖"}}}
每個case都是key，case就是函式物件名稱，每次接過去更新對映map物件。

快速編寫

1.視覺化編輯
一些帶IDE和啟動端開源具備的，佼佼者比如Airtest，企業版是企業版的IDE，似乎功能更多，沒用過。
這種使用視覺化編輯和OCR結合實現自動化，最終也可以輸出報告。
目前業內也有一批公司在用，但不如寫成專案更靈活支援更多功能。

2.回放
這個我只做了預研了Demo，實現細節不公開。
本質就是把跑一次把二進位制報文記錄下來，然後退出遊戲，重播。其實介面測試如果在跑，其他使用者是可以看到你這個角色線上的，如果是3D可見周圍玩家，如果你還在跑，也見的。
缺點：
一些來回視窗事件的丟失，回放時會先出現斷流和快速補幀，人物行動在其他人那邊看來很詭異，但依然會造成傷害。
由於是錄製協議回放的自動化，無報告，如果要實現測試報告，需要做插樁處理。
同上原因，因為無渲染關係，可能會穿牆並且沒法收集效能，也不是說不能回放時採集，根據缺點第一條，這樣採集資料和實際完全不準啊。
總結：目前來看尚缺大量構造（時間序列儲存資料，解構客戶端一些計算，人物屬性關係繫結等等）和不成熟，和遊戲型別更多關係，比如位置同步的，就會缺失更多。

提高維護性的指令碼框架

這裡不談平臺，那個只是為了執行後統一化展示和收攏資料。指令碼框架的分層和其描述檔案分層是提高可維護性，多處檔案但檔名字清晰和對稱也是好維護的。
分層位置：
場景測試用例：功能測試用例在寫自動化時，需要做到和自動一起調整順序，這裡是按場景劃分，跑完的case會在最後一起填入。
場景操作方法封裝：用到具體Case裡面。
場景同名的描述檔案：標記當前場景的常量和一些可變更的，這裡如果會配置中心，可以丟配置中心上面修改，減少檔案數量。
修改時就按場景"解耦"修改，主要是容易找。