曾被很多次問到,怎樣提高測試工作的效率?實話實說,我自己也是只有一些零零散散的思路,并沒有一個可以解釋的很完善的方法論。
先考慮三個問題:
第一個問題:在游戲公司里目前常用的測試方法有哪些?
其實在大部分游戲公司內部的測試都挺常規的,延續軟件測試的方法,對著需求寫測試用例,然后逐條測試,并沒有什么特別的地方。這里說說我們公司的做法。
組織結構上:
我們把功能測試與專項測試分離,項目組的測試人員只針對游戲功能進行測試,相對比較常規,把功能邏輯覆蓋全了就可以。
專項測試放到一個叫做支撐組的測試小組負責,對接每個項目的性能測試、弱網測試、壓力測試、sdk測試等等非常規功能內容。
這樣做的初衷是讓專業的人做專業的事,而且不同的組織會在自己的小領域內越挖越深。當然我們也希望能夠有全能型人才,但是畢竟可遇不可求。所以我們退而求其次,讓不同的人負責不同的專一內容,避免事務太繁雜導致的雜而不精。
我想,這也是一種保證效率的側面方式。
項目階段上:
在項目的不同階段,可能我們采取的策略稍有不同。
在研發初期階段:我們只關注功能能夠跑通,因為很多核心邏輯和美術資源后期都會調整,花費太多精力在周邊事務上得不償失。
在研發中期階段:我們會把重心放在功能邏輯細節上,當然測的時間長了,可能會出現一些思維定式的情況,所以我會定期安排做交叉測試。另外就是,我們在測試過程中,如果發現任何地方不恰當,一定不要放過,如果你自己覺得都有問題,那么就一定存在問題,沒必要等到讓玩家去反饋出來。這個階段我們也會安排一到兩次的公司全員體驗,會設定一些發現bug或建議最多的獎勵,激勵大家多發現問題,外部人員的體驗會發現很多問題,因為在一個項目久了,很多東西我們自己習慣了,但是作為純玩家角度來看可能還存在很多UE和邏輯問題。
在研發后期階段:我們會放一部分精力在客戶端性能、弱網、適配和服務器壓力測試上,我們需要讓盡可能多的設備和不同網絡環境下都能良好的獲得游戲體驗。在這個階段,如果有資源,可以找小渠道導入一部分用戶來做一輪真實玩家測試。另外,現在有很多云測平臺,可以花點錢讓他們幫忙做適配方向的測試。
以上所有階段,測試人員都是需要做冒煙->詳細測試->回歸測試等常規流程的。而且需要關注每個重點功能可能存在的風險點,有必要可以頭腦風暴一下。
第二個問題:哪些是高效率的?有什么技術門檻嗎?哪些是有針對性的?
高效
這個確實不好談,畢竟每個公司提供的測試資源、資源質量都不太一樣,通用的方法大概有以下幾點:
1,做好溝通,盯緊需求:游戲的需求變更頻率簡直可以用恐怖來形容。任何需求的變更都需要及時的溝通,確保不要出現信息孤島的情況。不怕需求變,就怕變更后不知道,從而導致漏測的情況。
2,做好測試規劃:來什么測什么,顯然是不科學的。我記得小學學過一篇統籌方法的課文,在同樣的時間內最大化工作量,做好統籌還是很有必要的。尤其是你的測試團隊人員比較多的情況下。
3,一定要做交叉測試:上面也說了,時間久了,人會出現思維定式,要想早點發現bug,一定要有不同的思維出現。
4,做好跟進工作。在別的文章中也提到過,發現bug僅僅是測試工作的開始。bug提了,還要跟進,避免一個問題被拖的時間太久,這樣最終會導致項目的整體延期。
技術門檻
做好游戲測試工作還是有一定技術門檻的
1,玩游戲的門檻,我們怎么定性一個bug,一方面是與需求不符,這個大家都能夠理解。另一方面偏主觀,那就是與常識相違背。這個主觀的常識問題,就需要我們玩大量的游戲才能體會的到。好與壞,美與丑,是需要有對比的。
2,計算機知識,測試時不可能什么都求助于程序人員,那對程序員的打擾就太多了,會降低他們的效率。比如要測試一個游戲活動,那就需要改時間,改配置,來達到各種條件,這就需要我們掌握一定的linux命令(大部分游戲服務器都是linux系統的前提下);比如要調整玩家數據,那就需要我們掌握數據庫知識(目前比較流行的是redis+mongo或mysql),能夠調整一些玩家數據以達到測試條件;比如我們要測試接口,那就需要我們掌握一些腳本知識,能夠通過腳本向服務器發送請求并查看結果。等等吧,還有很多,遇到哪些層面的測試,可能就需要掌握哪些層面的知識。測試一般都是要了解很多技術知識,但是也不可能什么都精通,精一知多就是挺好的狀態了。
原文轉自: http://www.sykong.com/2016/06/126572