要了解如何測試游戲必需了解如何做游戲，了解它的開發過程，才能真正的測好游戲。游戲要成功，其基本的必要條件有三。分別為Vision(設計)、technology(技術)和Process(過程)。三個條件，缺一不可。

　　·Vision則是對游戲還沒有實現的總體上的把握，前瞻性的理解與策略的考量。

　　·Technology：有了vision，如果沒有技術的話，則各種美妙的想法只能停留在虛無縹緲的階段，通過技術來實現Vision。

　　·Process：有了Vision作為指導，有了技術作為保證，也不一定能夠把好的想法轉換成高質量的游戲。要創造高品質的游戲，尚缺重要的一環，即過程，制造游戲是一個非常是一個長時間的動態過程。游戲產品的質量則是要靠動態過程的動態質量來進行保證。過程由很多復雜的相互牽制的環節與部件組成，如果任意的環節或者是部件出了問題都會對最終的產品形成質量上的影響。因此對這個動態的過程，一定要有規劃與控制，以保證按步就班，按質按時完成工作。

　　游戲測試與開發過程的關系

　　CMM(Software Capability Maturity Model)軟件成熟模型，大家都比較熟悉了，但在實施的過程中卻存在這樣那樣的問題，對于游戲開發就更沒有一個固定的路可以講了，我們的團隊是一個長期的游戲開發團隊，對游戲開發有著很深的認識，我們認為游戲的Process(過程)實際上也是軟件過程，不過是特殊的游戲軟件開發過程，各個生命周期還是相通的。所以我們總結一套以測試作為質量驅動的、屬于自己的開發過程。

　　由于網絡游戲的生命周期也是3、4年，所以采用迭代式的開發過程，既可以適應網絡游戲本身這種長周期的開發，又可以利用RUP的迭代式開發的優點與CMM的里程碑控制，從而達到對游戲產品的全生命周期的保證。

　　在游戲開發過程中，通用軟件的需求分析階段被策劃所代替，但起的作用是一樣的，明確游戲的設計目標(包括風格，游戲玩家群)，游戲世界的組成，為后期的程序設計，美工設計，測試提出的明確的要求。由于開發是一個階段的過程，所以測試與開發的結合就比較容易，從圖上我們可以看到測試的工作與游戲的開發是同步進行的，每一個開發階段中測試都進行了參與，能夠深入的了解到系統的整體與大部分的技術細節，從而從很大程度上提高了測試人員對錯誤問題判斷的準確性,并且可以有效的保證重要游戲系統的穩定。

　　游戲策劃與測試計劃

　　測試過程不可能在真空中進行。如果測試人員不了解游戲是由那幾個部分組成的，那么執行測試就非常的困難，同時測試計劃可以明確測試的目標，需要什么資源，進度的安排，通過測試計劃，既可以讓測試人員了解此次游戲測試中那些是測試重點，又可以與產品開發小組進行交流。在企業開發中，測試計劃書來源于需求說明文檔，同樣在游戲開發過程中，測試計劃的來源則是策劃書。策劃書包含了游戲定位，風格，故事情節，要求的配制等等。在策劃評審中我們的高級測試人員可以參與進來，得到詳細的游戲策劃書，從里面了解到游戲的組成，可玩性，平衡(經濟與能力)，與形式(單機版還是網絡游戲)，而我們測試在這一階段主要的事情就是通過策劃書來制定詳細的測試計劃，主要分兩個方面一是游戲程序本身的測試計劃，比如任務系統，聊天，組隊，地圖等等由程序來實現的功能測試計劃，二是游戲可玩性有測試計劃，比如經濟平衡標準是否達到要求，各個門派技能平衡測試參數與方法，游戲風格的測試，三是關于性能測試的計劃，比如客戶端的要求，網絡版的對服務器的性能要求。同時測試計劃書中還寫明了基本的測試方法，要設計的自動化工具的需求，為后期的測試打下良好的基礎。同時由于測試人員參與到策劃評審，資深的游戲測試人員與產品經理由于對游戲也有很深入的了解，會對策劃提出自己的看法，包含可玩性，用戶群，性能要求等等并形成對產品的風險評估分析報告，但這份報告不同于策劃部門自己的風險分析報告，主要從旁觀者的角度對游戲本身的品質作充分的論證，從而更有效的對策劃起到控制的作用。

　　游戲設計與測試

　　設計階段是做測試案例設計的最好時機。很多組織要么根本不做測試計劃和測試設計，要么在即將開始執行測試之前才飛快地完成測試計劃和設計。在這種情況下，測試只是驗證了程序的正確性，而不是驗證整個系統本該實現的東西。而我們的測試則會很明確，因為我們的測試計劃已經寫的很明確，需要測試那些游戲系統，但是我們還需要了解系統的組成，而設計階段則是設計系統的過程，所有的重要系統均是用UML狀態圖進行了詳細的描述，比如用戶登陸情況。

　　在我們的團隊中資深的測試人員要具備的一項基本的素質就是可以針對UML的用例圖，時序圖，狀態圖來設計出重要系統的測試案例，只有重要系統的質量得到充分的測試，游戲程序的質量才可以得到充分的保證。比如上圖中就是一個用戶登陸游戲系統的時序圖。從這里我們可以很明確的了解玩家是如何驗證并登陸系統的，在這個過程中要與那些對象進行交互，比如這里我們就是三個系統之間的交互，客戶端(玩家部分)，網關，賬號服務之間的一個時序變化關系，為了能夠完整的對這個流程進行測試，我們必需設計出可以覆蓋整個流程的測試案例，并考慮其中可能的非法情況，因為這個時序圖只是考慮了用戶正常登陸成功的情況，并沒有考慮密碼錯誤，通信失敗等許多可能存有的情況，并形成完整的測試案例庫，從而對登陸系統的系統化測試做了充分的準備。同時通過這張圖，性能分析人員還可以分析出可能存的性能瓶頸，比如這里可能有的瓶頸如下，總網關是否可以達到多少用戶的并發，是如果達不到，是否可以采用分布式部署或是支持負載平衡，三者之間的網絡帶寬的比例分配，賬號服務器是否可以承載多個網關的連接請求，最大連接請求可以達到多少等等，同時會針對這些風險做性能測試的設計，并提出自動化測試的需求，比如模擬玩家登陸的壓力工具等等。