網絡游戲行業QA（軟件測試工程師）職業發展

           

淺談網游行業QA職業發展

　　很久沒敲鍵盤寫些東西了,對于我這個"整理控"來說一直遵循著"好記性不如爛筆頭"(咋這么不押韻呢?)的原則,工作中整理的感悟匯成筆記壘起來已有我大腿高了.當然你可以質疑我悲催的身高.

　　廢話少說,這次配文主要是回饋一些朋友所言,看到用MindManager畫的圖希望有一些解釋文字能夠閱讀起來更清晰明了.其實MM的一些便簽和附注都對各引線已做過一些解釋.可下載這個工具打開看原mmap格式的文稿看下.

        點擊下載： 淺談網游行業QA職業發展mmap文稿

　　--------------------------

　　初涉游戲行業的QA人員應具備什么技能?

　　傳統意義的概念,很多人將QA即質量保證工作當作一份簡單的測試來看,更簡之而言便是無止境的玩游戲而已.不可否認的是,測試是QA的核心所在,他是整個質保工作的砥柱支撐.我們要將這份工作做好變需要掌握一定的測試技術.當然高強度的"玩"游戲也是其中手段之一.正因為如此,很多剛畢業的學生將踏入游戲圈的第一份工作選擇了游戲測試.然而他們心中卻向往著游戲策劃這個很崇高的職業.這也是我面試很多沒有工作經驗或較少工作經驗應聘者所想的.作為他們的面試官,我是很理解他們的心情.我見過很多一直在這份行業走下去并做的很不錯的職業工程師,也有部分最后走上管理層,當然相當一部分也選擇了轉行,無論哪條路,我們都應該有一份沉著的積淀,沒有踏實的跳板,哪個崗位都是岌岌可危.

　　我們要將游戲測試做到得心應手,并有足夠手段查找出程序設計漏洞以至于對整個版本質量可控.不可少的就要思考"測試"是否有方法和思路可循呢?

　　具體的層次關系參見MM圖吧.這里抽取幾個點說明一下.

　　游戲測試思路

　　功能導向.就游戲中"背包"而言.我們可以假想游戲的世界和現實世界在某種程度是近似的.游戲內的背包可以想象成我們日常生活的口袋一樣.我們要檢測背包是否達到期望功能,簡單而言也就是想知道"我們的口袋是否能裝的了東西,并且在我想取出的時候可以隨時取出,不會丟失.".為了這個功能.我們就可以粗淺的畫一些思維圖.以功能為基點發散導向.如:

　　1 我們能裝什么物品呢?---這條路走向不同物品的兼容,數量等.

　　2 我身上能有最多能有幾個口袋?幾種口袋呢?---考慮背包欄的分類,擴容道具功能等.

　　3 我的口袋安全嗎?是否能跟隨我翻山越嶺持之以恒呢?---考慮不同場景下,不同時間段(上下線,服務器維護前后)物品的存留

　　.......這里不做詳解了.

　　其他的如流程導向,即區別在于更多以操作為指引,如"好友"系統,這個系統的問題一般暴漏在客戶端做各種操作所引發,其功能其實很簡單也就是添加成功可交互即可.所以選擇這種思路比較適合.人人交互,這里的人人是一個概念,主要關注點是復雜交互類的模塊,如"組隊""副本"系統.可以考慮A和B,C...等多種單位之間獨自行為,整體行為等對組隊功能的影響,所以這個是較其他比較復雜的.(一定要衍生到一個獨立A的概念,即獨立游戲場景行為至單PC帳號角色行為)

　　其他的一些測試思路這里不多講了,畢竟這是個尷尬的話題.早初尋一本游戲測試的書籍著實不容易,即便現在有了基本也是概念居多,應用于實際效率不盡人意.曾閱過一本外文相關書籍,奈何英文水平有限,打著有道硬是在本上記錄完全,最終取之可用之處十之有三罷,加之幾年的工作心得而總結出一些.所以實際中的應用體會才是基礎.故希望大伙能自己總結.

　　游戲測試用例

　　用例的編寫是每個測試人員必備的基本功.所以實際當中我見過的用例模板也是五花八門各有千秋.其中最主要的矛盾集中在兩種方式上.1 以獨立模塊為索引 2 以操作流程為索引.其各種利弊在MM圖上標明,不多言.其實我認為測試用例設計的初衷是為了幫助查找更廣更深入的問題.一味的追求格式的統一有方便部門整體工作的優勢,但強調過頭即也不值當.只要我們遵循幾點:1 實操人員看的懂,看的省事.提出補充可方便更新且不打亂主題結構. 2 編寫人員要互相更換不同類型模塊,并互相審核. 3 格式應根據測試模塊可作細微調整. 4 有獨立突出地方存放特殊用例即只有在具體測試過程中才能發現和能發現價值bug的用例. 5 用例的從誕生到最后確認過程,應跟隨項目的變化,策劃案的變化,周遭其他因素的變化而變化,從理念上排除盡早確定已做好測試準備的想法.實際情況中,用例和策劃案確定一樣,是相對而非絕對.所以至少應經過5輪真正意義上的修改包括審核.

　　游戲白盒測試

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

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

　　1 職業經理人

　　2 職業工程師

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

　　游戲評測

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

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