遊戲尚未進入市場，沒有被玩家接觸到的時候，基本就是軟體開發流程，測試配合開發工程師進行一部分的操作，一般情況下，需要做的是以下的步驟
第一步：以正常玩家的名義進行模組的測試，提出自己的不足，比如這個模組我玩的時候，這兒感覺不懂，那兒感覺不對，這些都可以提成建議，放到案子中，拿給策劃審核，因為策劃同學不可能考慮到乙個模組的所有情況，所以，測試的第一感覺就能增加遊戲的易於理解性，降低了難度
第二步：詳細閱讀策劃文件，徹底搞明白整個的模組的具體內容，並且能用等價類劃分的方法列出不同的破壞性的測試用例，可能是反向使用等價類劃分方法，可能涉及到時間或者空間，舉個簡單的例子：策劃同學寫了乙個活動的模組，活動內容是這樣的，玩家第一天領取了乙個寵物，整個寵物有成長值，成長值每天會自動增加
10點成長值，當成長值長到
100的時候，那麼寵物就會突出一顆經驗丹，並且寵物自動消亡。玩家如果有錢的話，每天可以直接花費
20元寶購買
1次成長值，這個內容中最主要的是時間，那麼我們從頭開始，玩家如果沒有購買寵物，自然，這個模組不會開啟，所以我們從玩家購買了這個寵物開始，玩家購買寵物後，可能有幾種情況，
one、玩家可能會扔掉這個寵物，那麼第二天會不會有**的殘餘，導致成長值依然增長了
10點。
two、玩家沒有扔掉這個寵物，那麼第二天是不是增加了
10點成長值。
three
、玩家購買了寵物後，直接下線了，第二天也沒上線，第三天檢視的時候，成長值是不是
20點。
four
、玩家購買了寵物後，直接
10天沒有上線，到了第
11天的時候，寵物是不是已經消失了，還是成長值超過了
100（測試的時候，這裡已經超越了上限，並且寵物無法銷毀，是乙個a類的
bug）。
five
4中情況的綜合考慮，作為一名測試，面對這些問題，必須要好好分析，並且測試出最終的結果，當然，這個是非常簡單的模組
第三步、邊界值問題的考慮，玩家購買成長值的時候，如果身上元寶數目為19、
20、21的時候的情況是如何考慮的。玩家身上的包裹空間不夠的時候，是如何考慮的。玩家的成長值是
90的時候，購買了一次成長值等等的情況。
第四步、考慮與其他模組的相容情況，比如遊戲中都有排名的問題，這個經驗值是否增加到了對應的獲得經驗獎勵的排名中的等等情況，凡是涉及到經驗的模組，都需要從新測試一遍，並且和策劃核實一遍。
這是遊戲尚未進入市場的時候進行的操作，當然遊戲上線後，策劃同學還是會不斷地出新的策劃案，新的模組或者舊的模組的修改，這個地方最重要的就是要與線上玩家的資料進行匹配，線上是否有玩家因為模組的修改導致了自己的不平等待遇，這部分度需要自己斟酌，並且提出相應的建議給策劃，做好更新後的預警。我就遇到幾次測試的舊的模組，策劃更改了玩家的屬性，會導致更新後玩家的戰力值的變化。其實是正常的，但是如果不提前通知運營的同學做好相應的準備，結果是很可怕的。
下面講講遊戲上線後，測試應該擔任的職責。
第一點，測試需要做和上線前差不多的操作。這些是普通的測試都應該做的事情。
第二點，測試的職責已經從測試轉變為qa（
quality assurance
）。質量保證員。遊戲上線後，如果出現了
a類或者b類的
bug，就需要承擔責任了。這個壓力是很大的，你需要保證線上的遊戲不出現問題，這個每乙個測試人員都需要有相應的思想準備，有些模組涉及內容多，複雜，很多問題考慮不到其實是正常的，但是你做為一名
qa，你有推卸不掉的責任，曾經我每天加班到晚上
10點，壓力很大，導致一整夜無法入眠的情況也是很多的
,後來漸漸地也就習慣了，確實是很辛苦的。
第三點，既然從測試的角色轉移到了
qa，那麼我們就該醒一醒了，因為
qa保證了線上的質量，同時他也擁有了測試無法比擬的權利，我們有權利檢視開發同學修改的**、策劃同學修改的配置等等的內容，原先，我們使用
redmine
，策劃同學提交的需求任務、開發任務等我們讀能直接的檢視到，並且只有測試才有關閉的許可權，這個做法是很好的，但是我們已經從測試轉化為
qa，我們要做的就不僅僅是這些了，我們在開發同學的內部開發環境中，使用的
svn中，需要將對應的內容進行匹配，確定是不是有內容的變更的錯誤等，所以
qa的壓力很大，工作量也很大。
第四點、
qa是對整個遊戲負責，所有從開發環境到測試環境再到玩家的環境，都要謹慎對待。所以有經驗的
qa會把自己遊戲的模組的注意點等用
excel
**全部寫在一起，美其名約，冒煙測試，這個是第一種冒煙的版本。所以每次版本上線的時候，
qa都必須在前一天晚上把所有模組的重要的功能點都重新過一遍冒煙測試，確認最終沒有問題。然後從測試環境轉移到線上環境，要通過運維同學的操作，這邊需要第二種冒煙的版本，就是伺服器客戶端的版本號，相應的內容是否正確，所以每次起早更新的時候，伺服器、客戶端、運維、測試都必須有人值班，如果發生意外，能直接修復相關問題。
當然了對於遊戲的一些常規模組如何測試，我想網上有相應的其他的
qa的文件可以為大家講解，一些中規中矩的問題就不再囉嗦了。
上次說到了測試人員職責的變動，這邊肯定有很多同學覺得很奇怪，社會上有公開的
qa招聘，為什麼還要測試人員來做呢，其實對於乙個遊戲，最了解的是測試人員，開發負責提供了一切模組的介面，測試測試過了，然後策劃提供了相應的數值，測試也讀測試通過了，對乙個遊戲哪兒賺錢，策劃當然是明白了，但是測試同學讀進行了相應的預算和估計，所以測試人員來做出一些決策絕對是正確的，第二點，中國大部分做遊戲的都是小型公司，隨著開發的要求越來越高，在開發成本不變的情況下，測試同學遭受的待遇可想而知。然而在這個時候，測試轉變為
qa後，
qa所要做的事情主要有兩點
第一點、
對於正常的遊戲的運營，
qa會參與，
qa主要負責的是冒煙測試，就是上面提到的用功能點堆成的測試用例，這個地方，一般公司需要都會做自動化測試，有人叫做回歸，就是每次上線前，對乙個軟體進行常規性的冒煙，如果純粹的手動，確實是耗時耗量，而且成果偏低，由於遊戲的特殊性與測試人員的水平問題，國內還沒有太多的公司能做出自動化來輔助與
qa工作。
第二點、
qa需要對策劃同學提出的新的模組進行測試，只是在這種條件下，開發寫完**，通過測試測試，直接就會放出去給玩家玩，給公司帶來收益了。
效能測試：遊戲的效能測試是由開發人員完成的。首先，開發同學自己寫出一套不錯的機械人的**，然後開發同學通過
linux c++
的效能優化的方式，分別對
cpu、記憶體、
i/o進行極限測試，測試出最大的能容量的玩家數目，其實這樣做還是不錯的，只是有乙個小問題，開發同學寫的機械人終究還是在伺服器執行的，會佔據一定量的伺服器資源，同時，如果機械人要實現很複雜的操作步驟，佔據的記憶體更大，同時也要保證這部分**中不會出現死迴圈的東西，所以一般測試結果只能做參考，（這邊違背了測試的乙個需求，最大化的模擬玩家的實際操作）。而作為測試的同學來說，是不應該涉及**的，還是要通過客戶端的操作來測試極限值，只是也沒有找到好的測試工具。
綜上所述，其實對於遊戲測試來說，乙個好的遊戲公司，應該有一套能提供給測試做自動化和效能的工具。以上只是我個人思考的結晶，可能不同的公司有不同的情況，也應該不能以偏概全。
我的遊戲雜想
網遊，應該是 娛樂，教育，傳媒。人在遊戲世界裡的化身是 滑鼠和鍵盤，遊戲規定好的頭像，衣服。現實中人通過視覺聽覺分辨不同的人，遊戲中通過id。現實人物在遊戲裡表現，如果通過攝像頭可能會對頻寬要求過高，而且成像質量不好。是否可以考慮使用簡單的人臉跟蹤技術，提取出眼瞼嘴巴肩膀手的動作，然後在對方的電腦上...
微想睿思之細節
昨天在床上仔細的想了想專案delay的原因，發現細節是乙個很大的因素 在需求分析階段，在設計階段，我們有太多的細節沒有去考慮，有太多的粗略的想法 直到最後實作的時候才發現問題，比如介面沒有定義阿 資料庫裡面還沒有該資料表阿 恩 有多種方法可以補救這種情況，比如，採用迭代的開發流程，多進行一次迭代，通...
推薦系統之我讀，我思，我惑
年前，開始系統接觸推薦系統。說到這，我想提下，最早知道推薦系統，是源於研一的時候，一次實驗室組會，乙個本科生的畢設。他是用周的heat spread 方法，其實就是利用二部圖方法進行推薦。資料是乙個使用者和物品的連線關係的二部圖。其實，這個方法很簡單，也很容易實現。但是，後來，開始接觸項亮的博士 的...