成為測試主管第一步--制作測試流程(2)

　　服務(wù)器的穩定性，網(wǎng)絡(luò )流量，與安全是游戲最至關(guān)重要的，(往往有很多游戲不是不好玩，而是太不穩定);

　　游戲由于有及時(shí)的即時(shí)更新，會(huì )經(jīng)常在同時(shí)修改缺陷的時(shí)候，還在同一模塊下增加新功能;

　　好的網(wǎng)絡(luò )游戲開(kāi)發(fā)，其的功能必然會(huì )是迎合玩家的需求(游戲性分析)。;

　　對于游戲軟件產(chǎn)品來(lái)說(shuō)，這些需要特別注意重點(diǎn)控制的點(diǎn)關(guān)鍵，要求測試團隊必需要加強以下幾個(gè)方面，性能測試，代碼的融合、相關(guān)性影響面的判斷、版本的變更與控制，還有游戲性的分析與測試。性能測試主要加強以下幾點(diǎn)，則需要注意在并發(fā)下服務(wù)器的穩定性監控，、網(wǎng)絡(luò )流量與游戲客戶(hù)端在大場(chǎng)面下的表現。;而版本控制在游戲軟件的過(guò)程中，其意義更多——則會(huì )避免已經(jīng)改了的問(wèn)題重復出現，或是改了更新上去問(wèn)題還是存在，如何高效的合并代碼，、合成游戲資源、圖片與角本腳本還是一個(gè)比較難度很高的事情，尤其涉及到多個(gè)部門(mén)。;而游戲性測試主要是避免那種些與游戲風(fēng)格相背的情況，或是開(kāi)發(fā)團隊累死累活拼命完成得功能性任務(wù)做出的功能沒(méi)有可延續性。

　　性能測試與版本控制，在大多數軟件的測試流程中都會(huì )涉及，但是在不同的軟件產(chǎn)品/項目中都有其特點(diǎn)。一般屬于通用軟件測試流程的部分，但而游戲性測試則需要對游戲感覺(jué)很好有比較深刻的了解，并由真正懂懂得的玩家的人來(lái)?yè)?，。某些時(shí)候，他甚至可以不是一個(gè)很好的軟件測試人員，但他一定是一個(gè)真正懂游戲的人，這里有一些扯遠，但這里，本文稍后一節，將我會(huì )在后面會(huì )強調人的因素也決定了流程的實(shí)施。

　　下圖是游戲迭代開(kāi)發(fā)模型圖

　　如果你去做電子商務(wù)，或是做門(mén)戶(hù)，這些項目的適時(shí)性，高性能，復雜的功能會(huì )給你更高的技術(shù)要求，更高強的時(shí)間性效率挑戰，對測試的設計，、執行，、與性能測試提出更高的要求。其實(shí)在大多數互聯(lián)網(wǎng)公司經(jīng)常會(huì )出現這樣的情況：剛出去的功能又撤下來(lái)修改，或是性能達不到要求仍需要又要調優(yōu)。許多一些人都會(huì )犯這樣一個(gè)錯，認為測試的時(shí)間不夠，就只要測試執行，而忽略了其他幾個(gè)環(huán)節就可以了，不做細致的分析與設計，為后續工作帶來(lái)很大壓力。其實(shí)，一個(gè)充分測試過(guò)的有質(zhì)量保證的產(chǎn)品，可以減輕客服，、市場(chǎng)，、等各方面很多的壓力。產(chǎn)品在用戶(hù)和研發(fā)之間，反復，幾次不如晚一些上提供給用戶(hù)。從另外一方面看，這還需要測試主管能頂住某些壓力。時(shí)間緊迫當然這不是理由，如何在流程上保證測試的需求分析，、用例的設計與研發(fā)在開(kāi)發(fā)時(shí)同步進(jìn)行是最重要的，這時(shí)你要加強早期的測試介入，明確卡住需求確認這一部分，。這樣，在研發(fā)進(jìn)入開(kāi)發(fā)階段時(shí)，測試團隊也能進(jìn)入測試設計，。當研發(fā)開(kāi)發(fā)完成時(shí)，你測試團隊事實(shí)上已經(jīng)其本基本上完成了大部分的測試設計，并準備進(jìn)入測試執行，。不要在開(kāi)發(fā)提交后再去想如何測測試，抱怨之聲也就不絕于耳了。這樣才可能測試好一個(gè)時(shí)間比較緊的項目不管在用于測試的時(shí)間上，還是測試的質(zhì)量上都無(wú)法滿(mǎn)足要求。

　　，同時(shí)測試設計的很好，不僅可以節約測試執行的時(shí)間，也可以在反復提交的過(guò)程中，由于用例執行的一致性，保證了測試在多次的執行中的質(zhì)量，;。同時(shí)也有發(fā)布的標準，一是缺陷的情況，二是用例的執行與覆蓋。同時(shí)由于研發(fā)給的測試時(shí)間比較緊，所以有兩件事情就必需作做好，：一是明確產(chǎn)品提交測試時(shí)間，并在研發(fā)延遲時(shí)給自己爭取時(shí)間;二是在質(zhì)量達不到要求的情況下，時(shí)間及時(shí)的做出反應，不要到最后在研發(fā)不了解項目質(zhì)量的情況下建議研發(fā)延遲項目。為了達到上面的要求你必需要一個(gè)很好的測試平臺，把設計，測試用例管理，執行與用例的聯(lián)動(dòng)，缺陷管理與報表統計打通，盡可能的利用平臺解決事務(wù)性工作，降低流程執行的成本，。也就是說(shuō)，既讓測試人員可以集中精力去測試，同時(shí)又能夠讓研發(fā)管理人員隨時(shí)獲取正在進(jìn)行測試的進(jìn)度與質(zhì)量，。當這些工作做到透明化時(shí)以后，就算讓研發(fā)延遲發(fā)布，研發(fā)部門(mén)也會(huì )接收接受，。下圖是這一階段的大致流程

　　在這里可以跟大家說(shuō)一下，我就曾經(jīng)在產(chǎn)品發(fā)布權限不在測試這里部門(mén)的情況下，成功的讓研發(fā)決定推遲發(fā)布了大約一半以上的項目,。大多數的測試部門(mén)主管，很難頂住來(lái)自項目/技術(shù)經(jīng)理的壓力是有理由的，因為他們根本不了解你做了哪些工作。有時(shí)候一些情況下，看似不可能的事情任務(wù)要想做成完成，關(guān)鍵要看在于事情的技巧，。流程表示了只是一個(gè)大方向的東西，而且，你永遠也無(wú)法將責任推卸給流程也許是對的，更多情況下，作為測試主管，需要但將做事的方法與風(fēng)格可以影響到推廣到測試流程的推廣中。

　　在測試互聯(lián)網(wǎng)項目時(shí)，還有一個(gè)更重要的就是如何保證性能，。

　　也許大家會(huì )說(shuō)不就是性能測試并不是單獨存在的。其實(shí)不是完全正確，如果有充足的優(yōu)秀高手人力資源做性能測試當然很好，但性能測試也不能完全保證所有的項目完全沒(méi)有性能問(wèn)題都完美無(wú)缺，因此，項目投入期間，同時(shí)性能測試是一個(gè)這個(gè)費時(shí)費力的工作，所以往往都是一般在資源不足的情況下開(kāi)展的。作為測試主管，更應該，要學(xué)會(huì )判斷那些相對更加重要的問(wèn)題項目影響面會(huì )更廣，需要集中做性能測試。這時(shí)你也許會(huì )問(wèn)，那么會(huì )有人問(wèn)其它相對不太重要的項目與問(wèn)題怎么辦，?其實(shí)做過(guò)性能調優(yōu)的人都知道，大部分的性能問(wèn)題都是由于一兩個(gè)弱智的SQL語(yǔ)句導致的，所以可以從流程上加強對SQL查詢(xún)語(yǔ)句在I/O問(wèn)題的跟蹤與評審,，從而避免大部分性能問(wèn)題。

　　上面分析了不同公司根據上文的分析，不同類(lèi)型的產(chǎn)品在測試流程上的是有很大差異的。這時(shí)，也許大家你也許可以把握測試流程大的方向了，但真正是否適合現有的測試團隊與研發(fā)團隊，則仍需要精心的調整，。當我遇到問(wèn)題的時(shí)候，第一時(shí)間往往有時(shí)候不是去尋找流程不對的問(wèn)題，而是通過(guò)現有資源與執行的方法可能需要著(zhù)手來(lái)微調一下你的測試流程，直到發(fā)現問(wèn)題的所在，并紀錄下來(lái)，最后整合到原來(lái)設定的流程中。

　　這樣的情況大概常常發(fā)生：比如說(shuō)在需求上的處理，可能會(huì )有很多的測試人員會(huì )經(jīng)常指責需求人員撰寫(xiě)的文檔非常粗糙不詳細，無(wú)法進(jìn)行測試，。好像在我的記憶中，需求人員常常就是被罵的得灰頭土臉，但是經(jīng)過(guò)這些年在測試崗位上的工作，我才漸漸發(fā)現，其實(shí)有時(shí)候需求人員更需要鼓勵鼓勵是比職責更加有效的工作方式。這可能是一個(gè)放之四海皆準的工作態(tài)度。，指責只能加深對立，。其實(shí)在驗收需求時(shí)，由于當時(shí)大家也只是知道一個(gè)大概我們的需求人員也只能從大致上把握核了解，可能大多數情況下是：原則上沒(méi)有問(wèn)題就通過(guò)了，。但然而，這種不負責任的態(tài)度卻是給我們在做的測試工作帶來(lái)相當多的麻煩。也只有在這樣的時(shí)候，這些問(wèn)題才能真正暴露出來(lái)，從而使測試設計時(shí)就會(huì )發(fā)現很多問(wèn)題并沒(méi)有寫(xiě)清楚，。一般情況下，很多測試人員這時(shí)就多半會(huì )放棄手邊的工作，并消極地認為認為無(wú)法做工作無(wú)法繼續下去。，等東西出來(lái)，并將問(wèn)題最終歸結到是需求給的不詳細，而大加指責。

原文轉自：http://kjueaiud.com