寫完一后就被人嚴重的bs了一下，說我界面不友好.....我只好說，這就是我的風格!嘿嘿，對于這個界面確實因為能力有限，編輯起來特別麻煩，所以在我沒有找到好方法前，我決定不改這個風格了!
這一篇，我主要說說游戲自動化測試對游戲架構的需求：
首先，如果在一款成熟運營的游戲中，試圖讓測試自動化起來，幾乎是不大現實的。原因不外有二：
1.我要想在游戲世界里刷出一個怪或要取得一個player的信息，如果我們的開發人員沒有暴露接口出來，請問，我們該怎么辦?
2.我們要做一個自動化體系，是我們自己再去開發一個新的系統呢?還是用原來的系統?如果開發一個新系統，那么我可以告訴你，國內幾乎沒有那個項目老大允許你這么做，運營期的游戲，最重要是一個持續穩定，如果你插入你的開發量進去，我可以明確的告訴你，你會完全打亂你老大的計劃。那好，那我們在原來的系統上改吧?對這一點，我相信有經驗的同學都知道，去改別人的代碼的效率遠遠低于自己開發的效率(如果是小改動，可能是達不到自動化的效果的)。
這2個原因是阻礙游戲自動化的主要因素，當然還有其他因素，比如對項目組對測試認識方面等等的問題，這些我不在這里討論，這里只說說技術上的需求。
這一篇，我將會從游戲架構設計上大概談談，游戲自動化對架構的需求，下一篇會說說，成熟運營的游戲自動化可以做些什么。軟件測試
在項目風格基本確定后，就是程序架構的設計了，如果在這個時候不考慮到測試的一些需求的話，那后期做起來就會很難。
一般來說，游戲設計分3大塊：1.數據庫設計。2游戲邏輯server。3 游戲的邏輯client。這里的server是廣義的server，不同公司的設計是不一樣的，不細分。游戲client就是指平時我們運行的，可以實際“玩”的游戲，運行在我們玩家的pc機上的可執行程序。
對于我們測試來說，其實可以把數據庫獨立出來，數據庫和游戲的交互無非就是存取修改操作。在不考慮的性能情況下，自動化測試可以不考慮數據庫，當然對于數據安全性等的操作其實屬于策略問題。
其實我們實際做的自動化測試主要是游戲server的實際運行和與client的交互。這里再強調一下，自動化的本質是為了提高測試效率，所以我們只讓計算機做他適合做的事情，而不是把所有的測試都交給計算機，那可能就本末倒置了，反而是為了自動化而自動化，沒意義。
設計上要求務必達到：
1低耦合，高內聚
這個能簡化我們實現測試的過程，又能讓我們更準確的定位問題和回歸問題。具體原因這里就不說了，可以去看看軟件設計和測試的一些資料。
2.游戲運行要高透明，游戲運行的對象是可以給定條件獲得，并且運行條件是可編輯的。
這個問題不能太深入，太深入可能公司就要找我麻煩了哈，大家原諒一下。這樣設計的目的就是為了，我們可以定制我們的測試過程和預期結果。
3.通信是是可以設置和編輯的。
其實client與server的交互的本質是通過發送數據包來實現的。我們游戲人員通常說的協議其實是制的一個一個的數據結構，而不是tcp/ip之類的協議。實現這個的目的是我們在部署大量client與server交互的時候不需要運行我們的client，只需要一個發包client就可以了，而不需要弄上幾千幾萬個物理client。
4.所有的接口在發布版本是關閉的。
這個是鑒于某公司之前出現了一次嚴重事故而增加的，之前某公司由于發布失誤，導致外網玩家可以直接編輯游戲運行的一些數據，這個做起來也非常簡單，在server上加一個宏就可以實現：ifdef _Debug define Test endif 就可以了。在編譯發布版本的時候，就不會暴露這些高危數據出來，當然方式有很多，根據自己情況定是最好的。
今天主要就這么多內容了哈，不能太深入，深入會涉及到公司的一些機密，但是思想還是可以分享的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
