1、以獨立模塊為索引

　　2、以操作流程為索引。

　　其各種利弊在MM圖上標明，不多言。其實我認為測試用例設計的初衷是為了幫助查找更廣更深入的問題。一味的追求格式的統一有方便部門整體工作的優勢，但強調過頭即也不值當。只要我們遵循幾點：

　　1、實操人員看的懂，看的省事。提出補充可方便更新且不打亂主題結構。

　　2、編寫人員要互相更換不同類型模塊，并互相審核。

　　3、格式應根據測試模塊可作細微調整。

　　4、有獨立突出地方存放特殊用例即只有在具體測試過程中才能發現和能發現價值bug的用例。

　　5、用例的從誕生到后確認過程，應跟隨項目的變化，策劃案的變化，周遭其他因素的變化而變化，從理念上排除盡早確定已做好測試準備的想法。實際情況中，用例和策劃案確定一樣，是相對而非。所以至少應經過5輪真正意義上的修改包括審核。

　　游戲白盒測試

　　相關游戲的白盒測試。多體現在項目研發初期游戲架構和邏輯模塊開發階段。對于此類測試工作沒必要退避三舍，不必有非有程序能力才可做的想法。當然在實操過程中積極的學習是很關鍵的，這個比在大學里學到的更實用和快速。一些白盒測試工具我認為實際應用價值不是很大。所以從架構而言我們可以關注游戲各組件的協同工作關系，從中查找瓶頸，如修改數據庫數據，單獨加壓崩潰聊天服務器而查看區域服務器情況，斷開通信服務器查看協議包的處理情況等等。從邏輯模塊初期測試而言，我們可以在非完整客戶端的環境下改變模塊某些變量參數來校驗功能模塊的整體功能，同時考慮各接口應用，調用的關系。避免模塊終的互相功能影響。

　　我們掌握了基本游戲測試技能后，我們何去何從？

　　1、職業經理人

　　2、職業工程師

　　這只是個方向。是否能做好，取決于你的業務面是否寬廣，所以無論你已經是部門主管，經理，總監或是測試工程師。發揮部門價值才能突顯自我價值是不變的道理。而通俗的多做事是好的辦法。有幾個業務是可以考慮的。

　　游戲評測

　　這也是一個比較悲催的職業，當然是國內而言。我們現在的游戲對bug都可笑之放過何況可玩性。畢竟這是個策劃一家獨大的時代。對于“反策劃”而產生的工作實際當中難免是道理站得住腳，實操無人支持的尷尬境地。想要改變這個現狀只能是上面的那個經理總監或工程師以利弊關系和專業的報告和BOSS交涉。仁者見仁吧，這里說明評測的幾個基點。

　　1、將結論前置，開頭突出關鍵點

　　2、觀點鮮明，數據論證，切忌個人觀點描述冗余

　　3、考慮整體，好的獨立設計未必適合

　　4、考慮游戲生存的大環境

　　5、分析現象發生原因。切忌一味描述現象

　　6、明確自身定位，切忌使用高端玩家身份

　　7、切忌將個人習慣引導評測思路

　　8、避免以點蓋面，細小問題單一處理，不影響整體評價。并保持真實，認真對待

　　9、“二八定律”利用20%時間發現問題，80時間引用數據論證和解決方案提供

　　10、要提出分期處理建議。以實際進度落實不同解決方式。

　　還要注意的是針對的部門和人群。對策劃，運營，市場，玩家，BOSS有具體的報告關鍵點。把握好這些才能輸出一份合理專業的報告，并將轉為實操。

　　其他測試

　　除了游戲測試意外。公司必然有其他業務，如工具，平臺開發等等。既然是QA部門，應該經質量意識貫穿整個公司行為中，所以只要用到的東西都必須經過QA之手，此也對QA的專業多面性提出的要求。

　　QA在公司其他職能？

　　記得一點，你該做什么事情不要老倚仗別人告訴你。將部門放在公司發展的高度想問題。會發現你可以在產出部門設立各種標準，可以給人事考核部門提供相應考核的數據等等。只要你做這個行業，應該不斷問自己，如果你是BOSS，你如何讓公司快速高效有價值的發展，哪些是你能以部門之力能做到的？

　　歡迎批評更正。