據我了解的情況,目前國內所有的網絡游戲都是采用面向對象的方法設計和實現的,如果有不是的,我沒接觸過,也不知道用什么辦法去做,所以再一次假設,我們的游戲都是使用的面向對象的方法設計和實現的,請記住,這里我再三提到對象這個概念。后面講的一些東西將會圍繞這個概念展開。
還是先說一下哪些東西不建議采用自動化測試吧:
1.表現類,以主觀感受為主為測試目的測試對象。
大家都知道,計算機最喜歡做的是邏輯性計算,而不是人性計算。之所以不做,原因就是這類測試幾乎無法定義預期結果,所以更不要談測試結果了,如果沒有測試結果,那么計算機做了什么呢?這種問題主要集中在client上,比如畫面,音效,操作性,當然還有設計的游戲平衡性等等。這里標準其實就是:當人無法用邏輯語言表達出預期結果的東西,不要試圖自動化。
2.性價比低,一次性勞動且開發量大的測試對象。
自動化的目的是為了提高效率,而不是為了自動化而自動化,也不是為了來表演某個人的技術能力。我見過某公司的一個朋友,曾經花了幾大天的時間做了一個測試工具,僅僅是為了節省一個人半天工作量的測試工作。這種主要是需要做一個評估:這個測試工作是經常的嗎?這個的自動化測試的開發成本是多少?我以前才開始做的時候,一個同事給我提了一個需求,讓我單獨給他做一個工具,用來檢查策劃新提的一個數據文件,這個數據文件只是他們的一個設計文件,而且文件內數據的關系只是有這個策劃的心情來決定的,我當時傻不拉嘰的給她做了(我估計我當時是色迷心竅)。而我花2天做的東西,她就點了一下鼠標,從此以后這個東西就永久的存儲在工具庫里了,不知道何年何月這個工具才能重見天日。因為我不知道將來是否有一天,還會有策劃會按這個規則去設計他們的數據表。說明一下,這類數據文件之間的關系完全是通過數據來對應,一旦對應關系發生改變,測試代碼也需要改變,所以重用性不高,而且這個僅僅是他們拍腦袋的結果,并不是我們實際運行在游戲中的數據文件。
說了這么多,現在開始說哪寫東西適合做自動化測試:
計算機喜歡干重復性邏輯活動,那我們就讓他干這種事情吧。
簡單算一下效率,假設某個測試工作需要5人*2小時/天的工作量,而且每天都是重復的工作,比如我們做游戲的,一般游戲發布前都需要對版本質量進行review,這個事情如果我們可以在我們下班后,讓計算機去做,會是多么幸福的一件事情啊!假設游戲生命期3年,每周發布一次版本,每次發布前需要10個小時的絕對工作量,那么3年就是10*52*3/7=223,也就是要花費一個人223天的工作量,這其實是一個人一年的工作量了,而我們開發這個東西只需要10天!
我們做自動化測試的時候,一般做通用性的東西,也可以叫做平臺類的工具,在這個平臺上,我們再設計自己的行為,通過這個平臺作用于游戲,再通過平臺將結果返回給我們的測試代碼。
而這個平臺就要回歸到前面所說的對象概念了,我們運行在游戲種的一些邏輯其實都是一些對象的行為。結合我們的測試可以說其實我們測試就是側某一個對象在某一個狀態下,是否產生了某種行為和沒有產生不應該的行為。有了這個概念,我們設計自動化測試思路就清晰了。
首先,這個平臺我在二里面沒提出這個說法,但是其實就是這個概念。這個平臺主要是實現:實現測試代碼和游戲的通信,通過這個平臺,我們測試代碼可以獲得和修改游戲運行的環境。
這個平臺是長期維護的,當游戲一些邏輯發生變化的時候,平臺可能需要相應的變化,否則可能會阻礙測試。平臺是通用的,測試代碼是針對具體的測試對象而設計的。
我們假設現在需要測試一個任務(下列是我將這個任務分解了一下,為條件和步驟哈):
1.找a npc能接取到 a1任務。
2.找其他npc不能接到a1任務。
3.角色等級>=10級。
4.角色有道具b。
5.角色pk值大于5.
6.扣除b道具后,角色接得a1任務。
7.角色殺20個怪后,可以交任務。
8.任務不能重復做。
接下來,我大概說說測試思路哈:
player = GetPlayerByName('xxx') 首先獲得一個player對象,這里前面就是談到的對象概念了。
player.SetLevel(10) 設置player對象等級
player.AddItem(b,n) 設置角色身上道具b
player.SetPkValue(5) 設置pk值
player.ChangePos(x,y,z) 將player傳送到npc那
player.GetMenu(npc,choice) 選擇和npc對話和具體選項。
if player.GetItemNum(b)!=n-1 or player.task[taskid].status:判斷是否正確接到任務和扣除道具
Error(player) 如果錯誤,則返回player的數據(包含任務等數據)
return false
好了,這里說個思路就是了,我們實現自動化測試的思路大概就是這樣的。當然其實這個還可以進一步做的,相信大家見過一些地圖編輯器和任務編輯器,我現在可以說一個,其實我們自動化測試的時候可以做測試編輯器。思路還是和上面說的一樣。
只是要做這個測試編輯器,就需要更好的設計優化我們的測試平臺,將我們測試行為分離成指令+數據的形式。比如上面說的找npc對話接任務,我們平臺可以設計一個接口:GetNpcOption(npcid,choice,player)實現把player傳送到npcid那并選擇某個選項。這個接口首先需要能找到這個npcid的npc,然后吧player傳送到這里來,然后player選擇這個choice。好了,我們假設我們這個也已經做過優化了。接下來,我們設計用例吧:
操作過程
player.level=10
player.SetItem(b,n)
player.pkValue=5
GetNpcOption(npcid,choice,player)
預期結果:
player.GetItemNum(b)==n-1 and player.task[taskid].status
測試結果就拿來和預期結果比較就可以了。相信這樣說大家已經明白了這個測試編輯器怎么做了,就是將我們行為和數據簡化成指令+數據,我們可以通過這個編輯器來編輯測試行為,而我們的測試平臺需要能解釋這些行為。這里測試平臺要吧這些行為翻譯成游戲能理解的數據。這個最初我以為開發量會很大,但實際做下來,這個翻譯行為比預想的輕松得多(當然,前提還是架構充分考慮到這些問題哈)。
原文轉自:http://www.anti-gravitydesign.com