策劃入門（九）遊戲測試方案的產生(轉)

策劃入門（九）遊戲測試方案的產生(轉)[@more@]

　　（九）：測試方案的產生

　　測試方案屬於軟體工程的範疇，對於策劃人員來講是測試遊戲的主力軍。好象沒聽說過哪個策劃將測試過程描繪的很愉快，因為測試本身是一個非常枯燥和痛苦的事情。一套合理的測試方案可以儘可能減少測試人員的工作量，也能夠讓測試出的問題能夠儘快解決，這就需要測試方案的制訂人員對遊戲開發有全面的瞭解，並能夠掌握好測試的進度，其中的難度可想而知了。

　　測試是遊戲開發一個極為重要的組成部分，其所需要的時間一般要佔去整個開發週期的1/3左右。測試貫穿於整個開發程式，小規模的模組測試是由程式人員自行完成的，對策劃來講，如何完成最終的產品測試才是真正需要關心的。按照軟體工程的理論，測試方法主要有兩種：黑盒測試與白盒測試。所謂黑盒測試就是把要測試的物件當作一個黑盒子，不需要知道里面是怎麼處理的，只要對輸入和輸出資料進行測試就可以了；而白盒測試正好相反，測試者必須對測試物件的內部處理過程非常瞭解，對裡面所有的分支和迴圈進行實驗從而達到測試的目的。黑盒測試與白盒測試都是最基本的測試方法，屬於低層的測試理論，實際的測試方案都是在這兩種測試方法基礎上產生出來的。

　　對於遊戲的測試，也不外乎這兩種測試方法。基於黑盒測試所產生的測試方案屬於高階測試，主要是在操作層面上對遊戲進行測試；基於白盒測試所產生的測試方案屬於低端測試，是對各種設計細節方面的測試。黑盒測試中不需要知道里面是如何執行的，也不用知道內部演算法如何設計，只要看遊戲中戰鬥或者情節發展是否是按照要求來進行的就可以了。這種測試可以找一些對遊戲不是很瞭解的玩家來進行，只要寫清楚要幹什麼，最後達到什麼樣的效果，並記錄下遊戲過程中所出現的問題。而白盒測試就需要知道內部的運算方法，比如A打B一下，按照A和B現在的狀態應該掉多少血之類都應當屬於這種測試。白盒測試需要策劃人員自己來完成，因為內部的演算法只有開發人員自己才清楚，而且發現問題策劃是最容易知道如何解決該問題的人。由於測試的工作量巨大，合理安排好測試和修正BUG的時間比例非常關鍵，否則很容易出現發現了問題卻沒有時間改正或者問題堆在一起無法解決的矛盾。測試設計應當在開發的設計階段就要完成，如果開發初期沒有給安排出合理的時間，那麼最後的結果肯定是不停的跳票！

　　在測試方案中，設計人員要根據需要把黑盒測試、白盒測試有效的結合在一起，並且按照步驟劃分好測試的時間段。根據遊戲開發過程，測試大致可以分成單元測試、模組測試、總體測試和產品測試幾個部分。單元測試一般集中在細節部分，主要是在遊戲引擎開發階段對引擎的構造能力和完善性進行檢測。該部分的工作要求細緻嚴禁，因為任何一點小的紕漏都可能導致後期大量的BUG產生。這時要求程式開發人員與策劃達到無隔閡的交流，策劃人員要清楚該引擎任何一個功能單元的使用方法和效果，這樣才能夠保證測試中能即使發現問題並指出問題的所在。模組測試是在遊戲開發程式中按照階段進行的，每當一個模型產生後就需要對該部分進行一次集中測試，從而保證系統的堅固和完善。模組之間的介面測試也屬於該部分的工作，就是說各個遊戲模組之間如何實現過度，資料如何進行交換都要進行嚴格的測試。往往在模組內部測試時一切正常，把模組拼裝在一起後反而問題百出，這就需要在階段性模組測試中及時解決！總體測試屬於比較高層的測試，在遊戲的DEMO基本完成後，要從宏觀上把整個遊戲合成在一起，這時就要求有全面控制進度的能力。最終的產品測試是遊戲質量保證的最後一道關卡，要求大量的非開發人員介入進行地毯式轟炸！產品測試往往也會伴隨一些市場活動，這就不是我們現在要討論的範疇了。

　　

　　我們已經知道了測試過程分成幾個階段，下面就一起來看看具體要包括那些內容：

　　1、 測試的時間分配：測試時間如何分配會直接影響到開發的進度，它包含測試時間、測試結果彙總時間以及修改錯誤的時間等幾個部分。一般來說，開發人員只認為測試時間才是需要分配的，其實合理的安排測試總結和修改BUG等工作佔用的時間才是更多的！如果不進行測試情況彙總，專案管理者就無法弄清到底是哪些部分出了問題；不馬上對發現的問題進行修改就會導致更多的問題發生。所以定期測試、發現問題、解決問題才是最合理的，把整個開發週期劃分為幾個階段定期測試是對產品質量的根本保證！科學安排測試的時間能夠用最少的代價解決最多的問題，否則把測試都堆積在最後結果只會是一團糟！

　　2、 測試人員的安排：測試人員的選擇和調配對遊戲質量來講是非常關鍵的。測試人員儘量不要選擇遊戲的開發人員，只有對遊戲沒有任何瞭解的人才能真正的發現程式或設計中的問題，雖然他可能對程式和遊戲設計一點都不懂。如果能有一支專門的測試隊伍當然是最好的，在經費和人員實在緊張的情況下把其他非開發部門的人借調一下不失為一個好辦法。

　　3、 測試內容清單：這部分要求測試方案設計人員精心的考慮計算，儘量把測試內容精確到操作級。意思就是說最好細化到某測試人員點選滑鼠幾百次這種程度，因為測試人員是對你的遊戲內容一點都不瞭解的，只有你把任務全都明確後才可以收到預期的效果。只規定某人去玩這個遊戲然後給予反饋是不負責任的做法，這種測試方案只能當作垃圾給丟到廢紙桶裡面去！要對每個測試人員的工作明確下去，用測試表格的形式進行填寫測試報告並簽字寫清楚測試時間，才算是合格的測試方案。

　　4、 測試結果彙報：最終測試報告彙總上來，策劃人員要對全部方案進行評估並進行分類，把測試中發現的問題確定解決優先順序然後反饋給相關部門。問題特別嚴重的要敢於要求返工，任何一點小問題也不能放過，嚴格的測試才能帶來高質量的遊戲產品，這個法則適用於任何產業，遊戲也不例外！

　　5、 調整開發進度：由於測試發現的問題所帶來的進度影響要及時反饋給上級領導，然後馬上更新專案進度表，並註明更改原因。因為開發進度的調整關係到很多部門的工作，所以最好在早期設計進度時就把測試時間預算進去，但實際上大多數情況下開發進度的變化是非常頻繁的。如何休整進度還不影響到遊戲完成的最終時間，對於任何專案管理人員來說都是一個挑戰！

　　測試方案一旦確立，剩下的就是煩瑣和枯燥的機械工作了。測試是最痛苦的，但沒有測試遊戲是不可能成為產品，這也是國內大多數趕工期的遊戲BUG百出的問題所在。科學的制訂測試方案並協調好各部門之間的進度，對任何一個專案來說都是至關重要的事情，對於剛入門的策劃來講，學會寫測試方案是必修的課程之一。

　　測試工作的全面完工，標誌著專案開發的結束。但對於策劃來說，你的工作還沒有完，接下來你就要開始教給玩家如何玩這個遊戲，讓我們來看看如何完成遊戲手冊吧