網絡游戲測試過程，開展和如何進行[3]

　　網絡游戲測試過程，開展和如何進行[3]  軟件測試

　　游戲策劃與測試計劃

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

　　游戲設計與測試

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

　　圖2用戶登陸情況

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

　　同時在設計評審時，測試人員的介入可以充分的對當前的系統構架發表自己的意見，由于測試人員的眼光是最苛刻的，并且有多年的測試經驗，可以比較早的發現曾經出現的設計上的問題，比如在玩家轉換服務器時是否作了事務的支持與數據的校驗，在過去設計中由于沒有事務支持與數據的校驗從而導致玩家數據丟失, 而這些風險可以在早期就規避掉。上面所說的是對游戲程序本身的測試設計，對于游戲情節的測試則可以從策劃獲得，由于前期的策劃階段只是對游戲情節大方向上的描述，并沒有針對某一個具體的情節進行設計，進入設計階段時，某個游戲情節邏輯已經完整的形成了，策劃可以給出情節的詳細設計說明書，稱為任務說明書，通過任務說明書我們可以設計出任務測試案例，比如某一個門派的任務由那些組成，我們可以設計出完整的任務測試案例，從而保證測試可能最大化的覆蓋到所有的任務邏輯，如果是簡單任務，還可以提出自動化需求，采用機器人自動完成。

　　游戲測試與開發

原文轉自：http://www.anti-gravitydesign.com