下載本文檔
版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)
文檔簡介
1、游戲測試員提高測試工作效率的方法曾被很多次問到,怎樣提高測試工作的效率?實(shí)話實(shí)說,我自己也是只有一些零零散散的思路,并沒有一個(gè)可以解釋的很完善的方法論。先考慮三個(gè)問題:第一個(gè)問題:在游戲公司里目前常用的測試方法有哪些?其實(shí)在大部分游戲公司內(nèi)部的測試都挺常規(guī)的,延續(xù)軟件測試的方法,對著需求寫測試用例,然后逐條測試,并沒有什么特別的地方。這里說說我們公司的做法。組織結(jié)構(gòu)上:我們把功能測試與專項(xiàng)測試分離,項(xiàng)目組的測試人員只針對游戲功能進(jìn)行測試,相對比較常規(guī),把功能邏輯覆蓋全了就可以。專項(xiàng)測試放到一個(gè)叫做支撐組的測試小組負(fù)責(zé),對接每個(gè)項(xiàng)目的性能測試、弱網(wǎng)測試、壓力測試、sdk測試等等非常規(guī)功能內(nèi)容。這
2、樣做的初衷是讓專業(yè)的人做專業(yè)的事,而且不同的組織會(huì)在自己的小領(lǐng)域內(nèi)越挖越深。當(dāng)然我們也希望能夠有全能型人才,但是畢竟可遇不可求。所以我們退而求其次,讓不同的人負(fù)責(zé)不同的專一內(nèi)容,避免事務(wù)太繁雜導(dǎo)致的雜而不精。我想,這也是一種保證效率的側(cè)面方式。項(xiàng)目階段上:在項(xiàng)目的不同階段,可能我們采取的策略稍有不同。在研發(fā)初期階段:我們只關(guān)注功能能夠跑通,因?yàn)楹芏嗪诵倪壿嫼兔佬g(shù)資源后期都會(huì)調(diào)整,花費(fèi)太多精力在周邊事務(wù)上得不償失。在研發(fā)中期階段:我們會(huì)把重心放在功能邏輯細(xì)節(jié)上,當(dāng)然測的時(shí)間長了,可能會(huì)出現(xiàn)一些思維定式的情況,所以我會(huì)定期安排做交叉測試。另外就是,我們在測試過程中,如果發(fā)現(xiàn)任何地方不恰當(dāng),一定不要
3、放過,如果你自己覺得都有問題,那么就一定存在問題,沒必要等到讓玩家去反饋出來。這個(gè)階段我們也會(huì)安排一到兩次的公司全員體驗(yàn),會(huì)設(shè)定一些發(fā)現(xiàn)bug或建議最多的獎(jiǎng)勵(lì),激勵(lì)大家多發(fā)現(xiàn)問題,外部人員的體驗(yàn)會(huì)發(fā)現(xiàn)很多問題,因?yàn)樵谝粋€(gè)項(xiàng)目久了,很多東西我們自己習(xí)慣了,但是作為純玩家角度來看可能還存在很多UE和邏輯問題。在研發(fā)后期階段:我們會(huì)放一部分精力在客戶端性能、弱網(wǎng)、適配和服務(wù)器壓力測試上,我們需要讓盡可能多的設(shè)備和不同網(wǎng)絡(luò)環(huán)境下都能良好的獲得游戲體驗(yàn)。在這個(gè)階段,如果有資源,可以找小渠道導(dǎo)入一部分用戶來做一輪真實(shí)玩家測試。另外,現(xiàn)在有很多云測平臺,可以花點(diǎn)錢讓他們幫忙做適配方向的測試。以上所有階段,測
4、試人員都是需要做 冒煙->詳細(xì)測試->回歸測試等常規(guī)流程的。而且需要關(guān)注每個(gè)重點(diǎn)功能可能存在的風(fēng)險(xiǎn)點(diǎn),有必要可以頭腦風(fēng)暴一下。第二個(gè)問題:哪些是高效率的?有什么技術(shù)門檻嗎?哪些是有針對性的?高效這個(gè)確實(shí)不好談,畢竟每個(gè)公司提供的測試資源、資源質(zhì)量都不太一樣,通用的方法大概有以下幾點(diǎn):1,做好溝通,盯緊需求:游戲的需求變更頻率簡直可以用恐怖來形容。任何需求的變更都需要及時(shí)的溝通,確保不要出現(xiàn)信息孤島的情況。不怕需求變,就怕變更后不知道,從而導(dǎo)致漏測的情況。2,做好測試規(guī)劃:來什么測什么,顯然是不科學(xué)的。我記得小學(xué)學(xué)過一篇統(tǒng)籌方法的課文,在同樣的時(shí)間內(nèi)最大化工作量,做好統(tǒng)籌還是很有必要
5、的。尤其是你的測試團(tuán)隊(duì)人員比較多的情況下。3,一定要做交叉測試:上面也說了,時(shí)間久了,人會(huì)出現(xiàn)思維定式,要想早點(diǎn)發(fā)現(xiàn)bug,一定要有不同的思維出現(xiàn)。4,做好跟進(jìn)工作。在別的文章中也提到過,發(fā)現(xiàn)bug僅僅是測試工作的開始。bug提了,還要跟進(jìn),避免一個(gè)問題被拖的時(shí)間太久,這樣最終會(huì)導(dǎo)致項(xiàng)目的整體延期。技術(shù)門檻做好游戲測試工作還是有一定技術(shù)門檻的1,玩游戲的門檻,我們怎么定性一個(gè)bug,一方面是與需求不符,這個(gè)大家都能夠理解。另一方面偏主觀,那就是與常識相違背。這個(gè)主觀的常識問題,就需要我們玩大量的游戲才能體會(huì)的到。好與壞,美與丑,是需要有對比的。2,計(jì)算機(jī)知識,測試時(shí)不可能什么都求助于程序人員,
6、那對程序員的打擾就太多了,會(huì)降低他們的效率。比如要測試一個(gè)游戲活動(dòng),那就需要改時(shí)間,改配置,來達(dá)到各種條件,這就需要我們掌握一定的linux命令(大部分游戲服務(wù)器都是linux系統(tǒng)的前提下);比如要調(diào)整玩家數(shù)據(jù),那就需要我們掌握數(shù)據(jù)庫知識(目前比較流行的是redis+mongo 或 mysql),能夠調(diào)整一些玩家數(shù)據(jù)以達(dá)到測試條件;比如我們要測試接口,那就需要我們掌握一些腳本知識,能夠通過腳本向服務(wù)器發(fā)送請求并查看結(jié)果。等等吧,還有很多,遇到哪些層面的測試,可能就需要掌握哪些層面的知識。測試一般都是要了解很多技術(shù)知識,但是也不可能什么都精通,精一知多就是挺好的狀態(tài)了。哪些是有針對性的?參照上面
7、一段的例子,比如性能、弱網(wǎng)、數(shù)據(jù)庫、壓力、接口等等測試都是相當(dāng)有針對性的。第三個(gè)問題:對于測試來說,有哪些基本法?在我看來,就一條:認(rèn)真負(fù)責(zé)、勤學(xué)心細(xì)。測試過程:持續(xù)優(yōu)化測試過程的優(yōu)化問題,也可以看作是提升測試效率的一個(gè)零散的點(diǎn)。想到這個(gè)問題,還是因?yàn)檫@兩天抽時(shí)間優(yōu)化前段時(shí)間用python寫的一個(gè)分析統(tǒng)計(jì)項(xiàng)目工作量的腳本時(shí)想到的。最初的這個(gè)python腳本,我只是按照想法直接實(shí)現(xiàn)了一版,并沒考慮太多結(jié)構(gòu)上的東西,能跑出結(jié)果來就挺滿意,中間還解決了郵件發(fā)送圖片的問題,當(dāng)時(shí)覺得還是挺有意思的一件事。But, 在實(shí)際使用的這段時(shí)間,我發(fā)現(xiàn)項(xiàng)目每進(jìn)一個(gè)新人,我都要改動(dòng)代碼中非常多的地方,痛苦不堪。于是
8、被迫重新優(yōu)化一下原來的腳本,當(dāng)我回過頭去看我最初寫的那個(gè)版本,代碼爛的簡直是一坨屎。于是花了一些時(shí)間,重新調(diào)整結(jié)構(gòu),把人員變量抽離出來,這樣項(xiàng)目新加人的時(shí)候,只需要增加新的變量就好了,不用調(diào)整太多代碼。完成這個(gè)版本后,覺得已經(jīng)很好了。但是,又過了幾天,我回過頭再去看調(diào)整后的代碼時(shí),發(fā)現(xiàn),還是一坨屎。雖然添加人員方便了很多,但是代碼明顯存在很多冗余的地方,這樣當(dāng)我們查看具體邏輯時(shí),還是顯得很混亂。于是,我又抽時(shí)間優(yōu)化了一版,把可復(fù)用的內(nèi)容都抽象出來,讓代碼邏輯上更清晰一些。整個(gè)過程,腳本代碼從一千多行優(yōu)化到只有六百多行,可見,最初版本的代碼簡直不忍直視。通過修改這個(gè)腳本的過程,帶給我的感觸就是,很多事情,做完了并不意味著是一種良好的狀態(tài)。當(dāng)我們在過程之中遇到問題時(shí),還是要嘗試去優(yōu)化以前的內(nèi)容。優(yōu)化也并不意味著是一次完結(jié)的事情,可能要反復(fù)很多次,總會(huì)有更優(yōu)的解決方案出現(xiàn)。實(shí)例化到我們?nèi)粘5臏y試過中,會(huì)有很多類似的問題。比如我們測試一個(gè)功能時(shí),發(fā)現(xiàn)了很多bug,以為測試全面了。但是當(dāng)我們靜下心來再次回顧這個(gè)功能時(shí),往往還是能夠發(fā)現(xiàn)很多以前沒有測試到的地方。同樣寫用例也是如此,哪怕功能需求沒變更,等我們寫完之后,再去回顧通篇用例時(shí),還是能夠發(fā)現(xiàn)遺漏或冗余的地方。同樣的情況可能會(huì)出現(xiàn)在我們?nèi)粘9ぷ髦械暮芏嗟胤?,測試的過程是個(gè)持續(xù)優(yōu)化的過程,通過不斷的優(yōu)化和迭代,可以使得我們的
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 2024網(wǎng)絡(luò)安全防護(hù)與監(jiān)測服務(wù)合同
- 2024離婚雙方的特殊財(cái)產(chǎn)(如古董、藝術(shù)品)分配合同
- 2025年度住宅小區(qū)蟲鼠害預(yù)防與治理專項(xiàng)服務(wù)合同模板4篇
- 2025年度安全生產(chǎn)應(yīng)急預(yù)案編制合同規(guī)范3篇
- 2025年度新能源汽車銷售代理及售后服務(wù)合同3篇
- 2025年度智慧停車系統(tǒng)車位租賃管理合同樣本4篇
- 2025年度出租車公司車輛更新改造升級合同3篇
- 2025年度現(xiàn)代農(nóng)業(yè)示范區(qū)場地平整與灌溉系統(tǒng)建設(shè)合同3篇
- 2025年度特色菜肴研發(fā)及廚師團(tuán)隊(duì)聘用協(xié)議4篇
- 2025年度數(shù)據(jù)中心專用電纜供應(yīng)與安裝服務(wù)合同范本4篇
- 易普拉格科研管理系統(tǒng)
- 最終版 古城文化修復(fù)監(jiān)理大綱
- GB/T 43391-2023市場、民意和社會(huì)調(diào)查調(diào)查報(bào)告編制指南
- 拔罐技術(shù)操作考核評分標(biāo)準(zhǔn)
- 軟件無線電原理與應(yīng)用第3版 課件 第4-6章 軟件無線電硬件平臺設(shè)計(jì)、軟件無線電信號處理算法、信道編譯碼技術(shù)
- RB-T 099-2022 進(jìn)口食品供應(yīng)商評價(jià)技術(shù)規(guī)范
- 戒賭法律協(xié)議書范本
- (完整版)A4筆記本模板(可編輯修改word版)
- 競選市級三好學(xué)生PPT
- 2024屆甘肅省蘭州市五十一中生物高一上期末檢測模擬試題含解析
- (國家基本公共衛(wèi)生服務(wù)項(xiàng)目第三版)7高血壓患者健康管理服務(wù)規(guī)范
評論
0/150
提交評論