[技術分享] 游戲的UI自動化測試的開展新姿勢

 作者:新投云  發布于:2017-07-06  瀏覽數:

對于目前的兩大游戲引擎cocos-2dx、unity3D,其UI自動化測試的技術方案都已經實現。可以獲取、設置UI對象的各個屬性,并且可以調用UI對象及引擎的一些方法接口,實現基于引擎的UI驅動能力。有了這些能力之后,從技術上來說已經可以實現基于引擎的游戲UI自動化測試。但是單純的UI驅動能力還不足以實施一個游戲的UI自動化測試。

UI自動化測試一般需要滿足幾個條件:UI相對穩定、操作過程及結果可預期、產品生命周期長。

UI相對穩定:

是指UI元素及布局在各個版本間變動不大,各個UI元素的關鍵屬性(特別是用于唯一標識該UI元素的屬性)保持穩定,其他屬性可以根據需要發生變化。因為測試腳本是直接操作這些UI元素的,如果UI不夠穩定,測試腳本就無法定位UI元素,也無法有效的操控UI元素。

操作過程及結果可預期:

是指交互的過程及預期結果是明確的,比如以QQ的發送文本消息功能為例,其交互過程及預期結果都是相對明確的,即使有操作分支也是有限的,可以很容易遍歷。這樣測試腳本的設計就比較簡單,基本是線性往下執行。如果交互過程及預期結果不明確,有太多的隨機性,會大大增加腳本的邏輯復雜度。過于復雜的腳本邏輯對于測試人員的能力要求高,而且會提高測試腳本的后期維護成本。

產品生命周期長:

因為UI自動化測試腳本的開發、維護成本都比較高,如果被測產品的生命周期太短,或者只發幾個版本,就會導致自動化測試的投入產出比太低。

基于上述UI自動化測試的要求,我們來看看游戲的情況,一般的游戲往往不具備上述條件,常常是:

UI不穩定:UI酷炫,各種特效,每個版本都會更新UI。

操作過程及結果很難預期:

游戲戰斗過程充斥著各種隨機性和玩家操作的不確定性,導致預期結果需要復雜的實時計算才可以得出,無法提前預期。

生命周期短:

很多游戲只有短短幾個月的生命周期。這些因素都導致了游戲的UI自動化測試成本太高。

確實很多游戲不適合做UI自動化測試,但是對于一些生命周期長、收入高的游戲投入人力做UI自動化測試還是很有價值的。而且隨著測試人員技能及測試工具能力的提升,一些普通游戲也可以開展部分UI自動化測試。

下面就如何開展游戲UI自動化測試簡單談談一些個人的想法。

做任何UI自動化測試都要考慮投入產出比,我們就按投入產出比來從高到低來探討下游戲的UI自動化測試如何開展。

1、功能邏輯明確模塊UI自動化

游戲中一般只有戰斗模塊的功能邏輯各種不確定,其他輔助模塊的功能邏輯都是比較明確的,比如登錄、商城、背包、設置、社區等都跟普通的商業軟件沒有什么區別。

針對這些模塊可以很方便的實施UI自動化測試,而且這些輔助模塊占游戲的全部UI功能的比例也很高,實現UI自動化測試具有很高價值。

對于這些相對功能邏輯明確的UI模塊,實施自動化測試成本是最低的,幾乎不需要改動游戲代碼,只需要在引擎一級簡單修改就可以實現UI自動化測試。

2、簡單狀態機實現兼容測試UI自動化

目前針對游戲的兼容性測試有:簡單的monkey test、事件錄制回放。但是這兩種方式有明顯的不足:

簡單的monkey test:

只是隨機的點擊UI,沒有UI元素屬性獲取能力,更沒有UI驅動能力,無法做邏輯判斷,覆蓋的UI深度是有限的。連簡單的登錄都登錄不了,更不要說更深的UI。

事件錄制回放:

通過事件錄制、回放來實現簡單hardcode的UI自動化,也不具備UI元素屬性獲取能力,只要UI發生簡單變化就會導致自動化失敗。

針對這兩種方式的不足,利用基于引擎的UI驅動能力,可以開啟一個子線程實時檢測當前UI狀態,根據不同的UI狀態在主線程中執行適用于當前狀態的功能腳本即可實現相對穩定的UI兼容性測試。

舉個簡單的例子:以UI狀態來劃分一般游戲中會有登錄、公告、主界面、對局、結算等UI狀態。

如果子線程檢測到當前UI是登錄,則主線程執行登錄相關腳本;

如果子線程檢測到當前UI是公告,則主線程執行公告相關腳本;

如果子線程檢測到當前UI是主界面,則執行啟動對局相關腳本;

如果子線程檢測到當前UI是對局,則執行對局相關腳本(或monkey test或回放錄制的腳本);

如果子線程檢測到當前UI是結算,則執行結算相關腳本。

利用基于引擎的UI驅動能力,可以獲取、操作UI元素,再結合一定的的邏輯判斷就可以覆蓋更多/更深的UI,非常適合兼容性測試。

通過簡單狀態級實現兼容測試UI自動化也幾乎不需要改動游戲代碼,只在引擎一級簡單修改就可以實現。

3、結合接口實現實時性要求比較低的游戲的UI自動化

對于一些卡牌類游戲或者實時性要求不高的游戲,由于UI比較簡單,戰斗交互不復雜,實時性要求并不高。結合開發人員或者測試人員實現的一些接口,再加上基于引擎的UI驅動能力就可以實現功能測試的UI自動化。

如果有了關卡數據獲取接口,通過該接口在進入戰斗前獲取到關卡數據,再結合戰斗過程中的UI表現,通過一定的邏輯判斷就可以實現戰斗過程的UI自動化。

如果有了結算數據獲取接口,通過該接口在戰斗結束后獲取該局的結算數據,再獲取結算UI顯示數據即可以驗證結算結果UI顯示是否正確。

這種方式只需要游戲提供接口,可能會需要改動游戲代碼,如果通過協議截獲的方式對游戲程序影響最小,那么對UI的驅動基本不需要改動游戲代碼,只在引擎一級簡單修改即可實現。

4、結合AI實現實時性要求很高的游戲的UI自動化

對于一些復雜的,對實時性要求很高的動作類游戲,比如格斗、射擊類游戲,則建議結合AI來實現UI自動化測試。AI實現對實時性要求很高的戰斗過程的自動化,并對外提供接口用以獲取戰斗數據。

利用基于引擎的UI驅動能力實現其他模塊的自動化,結合AI實現戰斗模塊的自動化,從而實現整個游戲的UI自動化測試。

可能會有人認為:既然有了AI,就可以完全用AI實現自動化測試。

但是UI自動化測試不僅僅需要UI驅動能力,還需要自動化測試框架提供調度、執行、統計、展示等功能,這些功能顯然不適合讓AI來實現。AI最適合實現戰斗的驅動及對外提供游戲數據獲取接口。AI一般集成在游戲內部,顯然不適合用來完成整個游戲的自動化測試功能。

結合AI實現的UI自動化成本是最高的,需要開發AI代碼,好在一般具有一定規模的游戲開發團隊也都會自己開發AI來做一些開發自測或者作為內掛提供游戲托管功能,所以只需要在這些已有的AI上擴展一些功能即可,成本也是可控的。

以上就是我對游戲UI自動化測試的一些想法,各個游戲可以根據各自項目的情況有選擇性的實施投入產出比可控的UI自動化測試。

拋磚引玉,歡迎拍磚!

相關文章

三期必中一期平特肖