遊戲自動化型別和方向
#### 話題
來自看到 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 裡面。
場景同名的描述檔案:標記當前場景的常量和一些可變更的,這裡如果會配置中心,可以丟配置中心上面修改,減少檔案數量。
修改時就按場景"解耦"修改,主要是容易找。
相關文章
- 自動化測試的方向
- 介面自動化與ui自動化區別UI
- 高人氣互動投影遊戲型別大盤點遊戲型別
- 什麼型別是未來的方向呢?從梳理遊戲新分類談起型別遊戲
- 元件化下EventBus的訊息型別自動編譯元件化型別編譯
- jsp頁面number型別自動轉為String型別JS型別
- 6.字串型別和年齡遊戲的升級字串型別遊戲
- python執行麟遊介面自動化--什麼是介面、介面優勢、型別(詳解)Python型別
- GAutoNext 全平臺遊戲自動化測試利器遊戲
- python自動化測試框架pytest和unittest區別!!!Python框架
- 自動化和AI 真正的區別是什麼?AI
- 使用者型別劃分和遊戲體驗的進化方式:從gamer到player型別遊戲GAM
- Java資料型別自動轉換(++ ,+=)Java資料型別
- “應對型遊戲”和“計劃型遊戲”的設計特點遊戲
- 全自動遊戲的明天遊戲
- 自動化測試框架選型和落地實踐路徑框架
- Jenkins:批次自動將 Maven 型別 Job 遷移到自由風格型別JenkinsMaven型別
- 自動化專項應當研究的是什麼,請教一個落地方向 (介面自動化)
- 自動化裝置測試與自動化測試的區別
- Google Play 放置遊戲產品型別分析Go遊戲型別
- Of Bird and Cage:一個新的遊戲型別?遊戲型別
- 驗證碼基礎(小遊戲型別)遊戲型別
- 自動做遊戲(2):自動生成人物行走圖遊戲
- 自動走迷宮小遊戲~遊戲
- RPG遊戲設計探究:RPG不是一種遊戲型別而是一種遊戲元素遊戲設計型別
- ? python 介面自動化 (一)-- 什麼是介面、介面優勢、型別 (詳解)Python型別
- 遊戲研發的設計規範(三):場景型別化製作遊戲型別
- 關於安卓遊戲自動化方面的資料整理-1安卓遊戲
- 值型別和引用型別型別
- 自動做遊戲(1):自動生成人物側面圖遊戲
- 遊戲心理學研究:人類活動的三種型別及解說遊戲型別
- java基本資料型別與自動轉換Java資料型別
- Steam或已開始整治「hentai」型別遊戲AI型別遊戲
- 做敘事型別遊戲掙錢容易嗎?型別遊戲
- 探究F2P手遊中的遊戲貨幣型別設計和運用遊戲型別
- 2020超休閒遊戲及其他型別遊戲的資料指標遊戲型別指標
- RPA機器人流程自動化的發展方向與挑戰機器人
- 遊戲玩家也有“九型人格”?品牌如何與遊戲聯動引流遊戲