設計上要求務必達到：
1低耦合，高內聚
這個能簡化我們實現測試的過程，又能讓我們更準確的定位問題和回歸問題。具體原因這里就不說了，可以去看看軟件設計和測試的一些資料。
2.游戲運行要高透明，游戲運行的對象是可以給定條件獲得，并且運行條件是可編輯的。
這個問題不能太深入，太深入可能公司就要找我麻煩了哈，大家原諒一下。這樣設計的目的就是為了，我們可以定制我們的測試過程和預期結果。
3.通信是是可以設置和編輯的。
其實client與server的交互的本質是通過發送數據包來實現的。我們游戲人員通常說的協議其實是制的一個一個的數據結構，而不是tcp/ip之類的協議。實現這個的目的是我們在部署大量client與server交互的時候不需要運行我們的client，只需要一個發包client就可以了，而不需要弄上幾千幾萬個物理client。
4.所有的接口在發布版本是關閉的。
這個是鑒于某公司之前出現了一次嚴重事故而增加的，之前某公司由于發布失誤，導致外網玩家可以直接編輯游戲運行的一些數據，這個做起來也非常簡單，在server上加一個宏就可以實現：ifdef _Debug define Test endif 就可以了。在編譯發布版本的時候，就不會暴露這些高危數據出來，當然方式有很多，根據自己情況定是最好的。
接著,主要說一下哪些可以用來做自動化測試。
前面我大概說了一下游戲自動化測試的一些現狀需求，這一篇主要談談游戲里面哪些可以做，哪些好做，哪些難做，哪些沒必要做以及一些原因。歡迎拍磚哈，希望大家也談談你們的做法和優點。
我們在做游戲自動化測試之前，我們先假設我們的架構已經設計的足夠好，允許我們能夠通過我們的測試工具，獲取游戲的運行狀態并且修改游戲的狀態。原本打算寫到五就差不多了，后來應一些朋友的要求，我會大概說說游戲架構沒有考慮到自動化測試的時候，自動化測試可以做的一些事情。
據我了解的情況，目前國內所有的網絡游戲都是采用面向對象的方法設計和實現的，如果有不是的，我沒接觸過，也不知道用什么辦法去做，所以再一次假設，我們的游戲都是使用的面向對象的方法設計和實現的，請記住，這里我再三提到對象這個概念。后面講的一些東西將會圍繞這個概念展開。
還是先說一下哪些東西不建議采用自動化測試吧：
1.表現類，以主觀感受為主為測試目的測試對象。
大家都知道，計算機最喜歡做的是邏輯性計算，而不是人性計算。之所以不做，原因就是這類測試幾乎無法定義預期結果，所以更不要談測試結果了，如果沒有測試結果，那么計算機做了什么呢?這種問題主要集中在client上，比如畫面，音效，操作性，當然還有設計的游戲平衡性等等。這里標準其實就是：當人無法用邏輯語言表達出預期結果的東西，不要試圖自動化。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
