前面我大概說了一下游戲自動化測試的一些現狀需求，這一篇主要談談游戲里面哪些可以做，哪些好做，哪些難做，哪些沒必要做以及一些原因。歡迎拍磚哈，希望大家也談談你們的做法和優點。
我們在做游戲自動化測試之前，我們先假設我們的架構已經設計的足夠好，允許我們能夠通過我們的測試工具，獲取游戲的運行狀態并且修改游戲的狀態。原本打算寫到五就差不多了，后來應一些朋友的要求，我會大概說說游戲架構沒有考慮到自動化測試的時候，自動化測試可以做的一些事情。
據我了解的情況，目前國內所有的網絡游戲都是采用面向對象的方法設計和實現的，如果有不是的，我沒接觸過，也不知道用什么辦法去做，所以再一次假設，我們的游戲都是使用的面向對象的方法設計和實現的，請記住，這里我再三提到對象這個概念。后面講的一些東西將會圍繞這個概念展開。
還是先說一下哪些東西不建議采用自動化測試吧：
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.任務不能重復做。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
