移動遊戲的測試再平衡策略

文 / 張敬峰

經常有小夥伴問我，一個測試人員如果端遊測得好，是否也能測試好手遊？從微觀角度來看確實沒什麼問題，因為使用的測試方法，測試技術，測試思路幾乎沒有什麼變化。但是從巨集觀角度來看，則因遊戲整體的研發及運營模式發生了變化而導致測試策略會發生一些變更。

那麼從端遊時代到手遊時代，發生了哪些變化呢？簡單的來說就是一個字：快。無論是研發節奏還是上線後的運營節奏，都變快了。對於端遊，更新一個版本可能要大半個月，更新一個資料片可能大半年甚至一年，這對於手游來說幾乎是不敢想象的，很多手遊也許都活不過半年。

具體到測試而言，在手遊專案，留給測試的時間被大大壓縮了，而且需求的變更頻度也變大了，時間的不足與需求變更的頻繁程度是一個很難調節和平衡的事情，會出現一些很難解決的事情，比如臨近版本上線突然出現新需求，到底怎麼處理？新需求不加到版本里可能會導致遊戲體驗下降或收入降低，加到版本里可能會因為測試不充分導致出現事故。從下面的圖表，我們對端遊專案和手遊專案的簡單流程做個對比，也許能窺出一二：


有問題發生，自然會有相應的解決方法。一個簡單的平衡策略是加人或者延期，如下圖：


這種方式比較粗暴，看似能夠解決問題，實際則可能帶來更大的問題。比如說增加人手，這個短期會有效果，但是同時也帶來了成本增加以及管理複雜度提升的新問題。人員增加也會增加溝通的複雜度，進而提升了人員帶來的不確定風險。

另一方式是版本延期，這點是最不靠譜的，影響的是上上下下整個環節的節奏。因為延期不僅僅會導致研發團隊的任務調整，打亂研發節奏。更可能導致運營策略跟著調整，運營節奏也會被打亂。

那麼有沒有比較合適的方式來應對敏捷手遊專案的測試問題呢？我想還是存在的，在這裡我們可以根據以往的經驗和專案實際情況，給出一個再平衡策略，以期能夠給出一個相對靠譜的解決方案。首先我們來看下圖：


通過這個簡單圖表來看，我們可以從七個方面來優化我們的工作，從而能夠讓我們應付快節奏下的需求變更與測試時間縮短帶來的挑戰。

1，合理的版本管理


上圖是一個簡單的分支和伺服器對應關係，專案實際情況可能要複雜一些。

我們需要規劃好各個分支版本，以及對應的測試伺服器，確保我們要更新的內容是清晰明瞭的，而且對應的測試環境是無汙染的環境，從而確保我們的測試有效且明確。

2，主動溝通

不要等待別人告知我們去測試什麼，主動去了解版本內容，瞭解內容製作進度，避免出現資訊孤島的情況。我見過很多專案在版本釋出前，突然發現某個需求進了版本但是沒有被測試，或者某個需求不應該進這個版本但是進來了。這種情況是需要儘量避免的，這會導致工作出現無用功的狀況，或者增加臨時工作。

3，主動關注版本資訊

對於某些程式設計師或者策劃來說，他們總是出奇的自信，總覺得修改的內容很簡單，無需測試，直接上線就好。實際線上的問題往往來源於這些沒有經過測試的內容。

我們測試人員需要時刻關注版本資訊動態，避免未經測試的內容出現在版本里，這些可以通過多檢視svn日誌，git日誌等手段來解決。

4，多梳理遊戲內容

遊戲功能之間的耦合度比較高，往往一個功能的變更會引發另一個功能出現問題。所以我們測試人員需要多梳理遊戲功能，熟悉功能之間的關聯度，當需求變更時，我們能快速的對該功能進行測試，也能夠及時測試關聯功能，從而儘量提高測試的覆蓋度，減少疏忽帶來的風險。

5，預留時間管理

當我們做版本計劃時，需要根據需求內容的多少，團隊現有人力的工作效率，開發所需時間等內容作出一個綜合判斷，在做判斷時，需要儘量流出一定的預留時間，來應對一些突發狀況，從而確保版本能夠穩妥地在合理的時間內完成。

6，關鍵點檢查

很多時候，版本的迫切程度是超乎想象的，完整的跑一遍測試用例的時間可能都無法保證。那麼我們就需要一份能夠快速的被執行的關鍵檢查點列表。當這份列表被細緻的執行完畢之後，我們可以確保整體版本是穩定的且風險是可控的。

這個關鍵點列表需要跟隨專案的進展不斷的總結完善，不斷的把核心點新增進去，把非必要的內容剔除。任何一次版本釋出前，至少需要保證關鍵點被遍歷一遍。

7，勤做總結

越是突發狀況多的專案，越是需求變更頻繁的專案，越需要勤總結。不確定性是風險的主要來源，勤總結則是降低不確定性的有效手段之一。

通過以上這些策略，我們嘗試著在頻繁地需求變更、時間不足與專案質量之間取得一種平衡。當然，這些努力並不是完整的，我們也需要根據專案實際情況，作出更多的嘗試和變化，最終的目的還讓我們專案的質量不斷的提升，讓專案可能存在的風險不斷降低。

相關閱讀：開發者進行遊戲測試需要注意的一些事項

via：遊戲測試風雲錄