遊戲中常見的Bug也有你不知道的祕密
一、什麼是Bug？
根據當代IT類行業，Bug通常而言指的是計算機軟體與硬體的漏洞或缺陷，在遊戲測試的領域中，也包括遊戲玩家、測試人員所發現和提出的遊戲體驗問題或與策劃案（需求檔案）存在差異的功能實現等，那麼如何區分它是否是Bug呢？
我們大致從以下幾點得出結論：
（1）策劃案中所提及的內容，程式未實現。
例如：策劃案中說明玩家在商城充值10元后發放元寶至玩家賬戶，但程式未實現該功能
（2）策劃案中明確不要做的內容，程式已實現。
例如：策劃案中說明不可將商城充值的元寶發放至郵件，但程式實現了
（3）策劃案中未提及的內容，程式已實現。
例如：策劃案中沒有說明要將元寶以道具形式發放至揹包，但程式實現了
（4）策劃案中未提及但必須要做的內容，程式未實現。
例如：策劃案中未提及弱網環境下充值需要到賬，但程式未實現該功能
（5）遊戲實現的內容難以理解、對新手不友好、執行緩慢等，測試人員站在最終玩家的角度看到的問題是平常的且不是正確的。
例如：當玩家在充值系統進行充值時，展示發放元寶獎勵，但未說明發放的具體數量讓玩家難以理解或是在獎勵發放過程出現卡頓現象
二、Bug分類
2.1 Bug的型別
遊戲測試中的Bug也分為很多種型別，我們在發現Bug的時候也要對Bug進行分類，遊戲測試的Bug主要分為8大型別:
（1）功能錯誤：最常見的錯誤型別，功能錯誤即為功能性上的錯誤
例如：充值未到賬、經驗卡加成道具無法使用、無法接收到郵件等
（2）程式碼錯誤：開發人員程式碼程式上的錯誤邏輯與漏洞
例如：伺服器下發資料錯誤、if else等的邏輯錯誤，大小寫、中英文符號錯誤等
（3）設定錯誤：策劃設定表上的設定錯誤，少配、多配、漏配以及不符合設定規範
例如：必填項的內容未設定、需要設定5個內容但設定了4個，要求填寫的數值為1到100，但填寫了1000等
（4）設計缺陷：策劃案中所描述的內容不正確、不合理或與其他系統、模組擁有明顯衝突等情況
例如：結婚系統每日5點20分重新整理情緣任務，但遊戲的通用邏輯是6點重新整理。社交系統可以讓兩個陌生異性結婚而沒有好感度的培養等
（5）安裝部署：測試環境搭建錯誤、專案部署錯誤、打包地址無法登入等
例如：IP對映錯誤、測試環境並非純淨環境，夾雜了開發環境的因素，伺服器到期、證書過期導致無法登入等
（6）專項測試：專項測試領域相關的錯誤
例如：匹配隊伍的效能卡頓、弱網路下無友好提示、商城介面適配排版錯誤，賽季重新整理或排行榜的資料相容錯誤等
（7）介面錯誤：UI介面上的錯誤，UI展示不合理，對話方塊樣式、文字描述錯誤
例如：社群介面的UI排版錯誤、商城介面的UI不合理、NPC對話文字偏離、運營活動的時間開放文字描述錯誤等
（8）建議型別：通常指的是玩家或測試人員對於遊戲內玩法、流程上等內容的一些體驗建議
例如：攻擊動作體驗上不夠流暢、玩法相對於單一，缺少玩家的互動性、團隊共同作業性等的參考建議
大部分情況下，遊戲公司的測試組成員並不會在提交Bug單時附帶上Bug的分類。部分公司受Bug管理工具的影響，會按照上述的方式內容進行提交，例如禪道系統。（如下圖1-1、1-2所示）
圖1-1
圖1-2
三、Bug嚴重程度與優先順序
在遊戲測試的行業當中，會有許許多多的Bug，自然和軟體測試一樣少不了嚴重程度以及優先順序的劃分，對於Bug的嚴重程度通常而言劃分為5個等級。
3.1嚴重程度等級劃分
（1）致命級：伺服器宕機，無響應、使用者端閃退，崩潰，核心內容阻塞，涉及高價值商業營收等金錢類計算內容、資料相容錯誤等。
（2）嚴重級：嚴重的功能錯誤、功能與策劃案有嚴重出入，系統或模組中的重要功能失效、無響應等
（3）一般級：普通的功能錯誤，功能與策劃案有較小出入，影響面較小的問題，明顯UI問題等
（4）輕微級：輕微的UI問題、文字錯誤，色彩搭配違和等
（5）建議級：某系統、玩法或者某一條需求上的易用性及建議性問題
3.2優先順序劃分
（1）緊急：該問題需要立刻解決，問題需要立刻得到修復響應，關係到系統運作、收入等
（2）高階：該問題急需解決，該問題的修復很有必要，應引起高度重視，關係到該系統的主要功能是否正確實現等
（3）中級：該問題正常處理，問題未過於影響功能實現或與需求有明顯出入，系統功能與需求有較小偏差
（4）低階：該問題考慮時間可嘗試性處理，問題不緊急，可延期、可後續關注，經確認與評估可不解決。
（4）無關緊要：該問題幾乎不涉及影響面，對於體驗或需求而言微不足道，在空閒時關注
值得一提的是，通常情況下優先順序與嚴重等級相對應，但有時嚴重級別高，優先順序不一定高，一些嚴重級別低的，優先順序高的，反而要優先處理。
例如：某款新手遊即將在國慶期間上線，本意為國慶活動，活動的文案寫成了11月1日-11月10日充值258元可以獲得1次抽獎機會，100%抽獎獲得實物活動。這種問題隸屬於低階或中級，但它的優先順序卻是高階的，會影響到上線後眾多玩家活動的參與、準備等內容，會直接或間接造成營收損失。
例如：某款手遊的登入介面的登入按鈕偏移了，沒有處於居中位置，它的嚴重級別定義為中級或低階，但優先順序會定義為高階，可能按鈕只有一點偏移或者有較為明顯的偏移，但該問題影響的使用者廣泛（每一個玩家想玩這款遊戲，就必須會經過登入介面），意味著這將影響到所有的遊戲玩家，那也是需要引起高度重視的問題。
例如：某款手游出現了使用者端閃退的致命問題，但平均有10萬名玩家才可出現一次或半年都沒有第二次出現，該問題的定義為致命，但優先順序會定位中級或低階。
看到這裡，大家也應該能夠理解了，其實嚴重程度我們通常會按照問題去定義它的嚴重程度，但優先順序我們主要是通過出現頻率、時間、影響面去做定義的。
在國內99%的網際網路IT公司是依據嚴重程度進行Bug修復排列的，而部分國外公司會參照優先順序進行修復。
四、Bug修復的代價
Bug的修復代價與我們所處的條件息息相關，通常而言分為研發期間以及遊戲上線，在各個所處場景下也分各種條件，具體如下圖1-3所示
圖1-3
五、Bug的生命週期
Bug與遊戲、軟體一樣，也存在生命週期，Bug生命週期如下圖1-4所示：
圖1-4
六、如何預防Bug的產生
6.1認真對待需求評審
需求評審階段應該做些什麼？
（1）熟悉該需求相關內容，提前考慮到需求風險，及時反饋需求風險，讓開發人員在研發過程中注意，避免產生更多的Bug
（2）分析需求漏洞，及時反饋設計缺陷，需求評審會議時可以立刻修改策劃案或會議後修改，避免研發後大量修改或重做
（3）在三方人員對於需求看法的討論過程中大致確認部分需求的負責人，更加明確處理人，方便後續提單
（4）在評審討論的過程中通過開發人員、策劃所描述的邏輯以及實現方式，考慮可能會出現的程式碼邏輯漏洞以及設定漏洞
（5）對於需求中存在疑問的地方及時提出，讓策劃方解答問題，為後續的測試用例編寫以及測試做準備
（6）可以幫助策劃提供一些需求上的建議內容、以及後續的優化，分析玩家群定位，也可以避免研發需求後大量修改或重做
（7）根據討論的各類要素判定，從測試用例的編寫以及測試流程的結束所使用的測試時長，以把控需求風險及測試品質
很多測試人員認為需求評審只是簡單的過一下需求，讓測試人員大概瞭解接下來要做什麼內容，應該如何準備，但其實遠遠不止如此，認真的對待需求評審，就可以在需求品質上「更勝一籌」，如果每個人都可以認真對待需求評審，測試品質以及測試效率就會大幅提高，讓我們的遊戲產品贏在「起跑線」上！
6.2認真對待用例評審
測試用例評審階段應該做些什麼？
用例評審前：
（1）認真梳理自行編寫的測試用例，以準備測試用例評審，可以讓參會人員在評審過程中思路更加清晰、明瞭。
（2）三方測試用例評審前（開發、測試、策劃），應當先行進行測試內部評審，內部評審後用例會相對未評審時更全面，也許可以通過補充的測試點當中聯想到更多的測試點並進行補充，以節省在三方評審會議的時間。
PS：標準的評審流程應當包括開發、測試、策劃、美術等，但應至少包括上述所提及的三方。
用例評審時：
（1）先行向評審參會人員講解用例編寫的結構與框架，讓大家清楚用例的基礎結構，便於在接下來的講解時能讓大家快速進入狀態聆聽評審。（通常只適應於系統或玩法，優化類需求無需講解）
（2）測試人員講解自行所編寫的測試用例時應當在這個過程中重點提及異常點、風險點的測試用例點，以補充可能在需求評審時漏掉的風險，開發、策劃可以通過測試人員用例編寫所提及的內容及時修復程式漏洞或設定漏洞。
（3）測試人員講解用例時應當主動告知開發、策劃等參會人員該系統可能存在的一些風險點、異常點，讓大家提前預警，有心理準備。
（4）測試人員在評審過程中針對其他人員所提及的用例內容，及時記錄或現場補充。
用例評審後：
（1）測試人員根據會議時的評審內容及時補充測試用例，完善測試用例。
（2）在測試過程中發現了Bug但確是用例中沒有編寫的用例點，應當及時補充至測試用例。
（3）當測試用例足夠完善且有空閒時間時重新梳理測試用例，以便其他人更好的閱讀理解，提高執行效率等。
（4）及時對測試用例進行維護，根據公司的專案以及管理工具，及時上傳測試用例，對用例進行備份，以防丟失。
用例評審與需求評審同樣重要，測試人員對於測試用例的維護也很有必要，在測試過程中、後續測試等，均會有更高的工作效率，也會提高其他測試同學交叉測試時對於測試用例的理解、如果有新人入職時也會有更好的上手空間，對外而言會顯得測試組內的基礎水平紮實，表明我們的專業能力。
6.3依賴技術人員因素
為何依賴技術人員因素？
正所謂人無完人，無論是開發、測試、還是策劃，人的能力總是有限的，隨著技術水平、工作年限、學習能力以及專案熟悉程度的各種因素影響，技術水平也會有所起伏，以測試舉例，如果測試人員的基礎功底不紮實或者沒有做到足夠的嚴謹，在外網上可能就會有Bug產生，當然了，誰又能保證自己所測試的內容是100%的完美呢？我們做不到完美，但可以無限接近於完美，開發與策劃也是如此，不斷提升自身的能力以及專案的理解程度，自然而然我們就會擁有更好的產品品質。
6.4測試應當儘早介入
為何測試需要儘早介入？
測試的儘早介入，是ISTQB中提倡的一個基本原則，遊戲測試人員與軟測人員大同小異，測試人員提前介入主要有以下幾個優點：
（1）提高遊戲測試中產品的測試品質
（2）提前發現需求設計缺陷以及開發風險，降低成本
（3）測試人員的提前介入可以加快測試進度以及專案進度的推動
（4）測試人員的介入可以提前給予建議性優化等內容以進行過程改進。
6.5熟悉遊戲各類機制
為何需要熟悉遊戲的各類機制？
在遊戲測試的行業中與軟體測試不同，遊戲中各類模組、系統之中或多或少都會存在著些許牽連，以和平精英為例，玩家使用槍械射擊敵方時敵方也會受擊並扣除一定的血量，如果對方有防彈衣時那麼就會存在一些互動，即槍械傷害與防彈衣防禦的公式計算，那麼測試槍械傷害的測試同學不僅僅要考慮到槍械本身的射擊傷害，當然也需要考慮在敵方擁有不同等級防彈衣時受到的傷害，模組與模組或系統與系統之間的牽連測試，我們也稱之為整合測試。
在遊戲測試的行業領域中，存在著太多的整合測試，無論是什麼型別的遊戲，都會存在整合測試，存在這些機制的同時，對技術人員更是一種考驗，無論是開發、測試、策劃、美術，都需要了解一定的遊戲機制，當對於遊戲有著一定程度的理解和熟悉程度時自然可以規避一些不必要的風險，從而預防Bug的產生。
看到這裡你是否已經知道了什麼是Bug，且也清楚如何更好避免Bug產生的方式了呢？相信閱讀此文章過後的你無論是從事遊戲測試還是軟體測試，都會對基礎知識或多或少有進一步的瞭解啦~
八、知識小課堂
問題一：我們公司的測試部門是按照提交Bug的數量以及嚴重程度來計算KPI的，如果我在需求評審階段就告知開發讓他們修復Bug，這樣我的業績可能就少了，我該如何做？
答： 即使公司有KPI標準，我們也應當在需求評審階段中提出相應的風險以及設計缺陷，告知策劃以及開發，讓他們提前避免。 無論是功能、效能、自動化測試，更多的價值並不是明面上的Bug，而是其他人沒有發現，你卻能發現的問題， 這可以充分的體現出你的能力，如果能發現一些其他測試、開發從來沒有聽說過的Bug，拋開測試部門不說，其他部門的同學一定會對你刮目相看。
問題二：如果專案有緊急的優化或程式碼層次改動，且改動層次較大，來不及進行三方用例評審該如何應對？
答： 有時候負責的系統、模組有緊急情況需要修改內容或新增內容，我們也需要進行用例評審，我們可以先行提供測試用例給到組內成員評審，在評審的過程中同時也進行測試用例的執行，當測試用例執行完成時，再通過測試組成員所提供的評審結果補充測試點進行測試，在執行測試的過程中也可以直接讓大家進行風險評估，提供可能出現的異常點，簡單梳理後執行測試，既節省時間又能達到效率。在度過緊急階段後，應當重新完善用例，組織三方評審會議重新評估風險點，以更全面的保證遊戲品質。
問題三：如果用例不全面未測試到，在外網出現了Bug，應當如何應對？
答： 當外網有Bug產生時應當先行判斷該Bug的嚴重程度、影響面等內容，來綜合判斷該問題的優先順序，根據該Bug的優先順序選擇對應的處理方式，如果有多條Bug出現，應按照優先順序進行修復，在發現Bug直至修復釋出的整個過程中，我們更值得注意，整個流程是為了解決問題，不應摻雜負面情緒或指責。
問題四：我是新入職公司參與專案的技術人員，對於遊戲的各方面都還不熟悉，我應當如何熟悉專案儘可能防止Bug的產生？
答： 如果是開發人員熟悉遊戲可以通過程式碼熟悉來了解遊戲，測試人員可以通過測試用例來進行了解，策劃可以通過設定表以及競品來熟悉遊戲，無論你的工種，都可以通過體驗產品來熟悉遊戲，多體驗，多瞭解遊戲中的邏輯，就可以更好的防止Bug的產生，開發可以在編碼上有更多的考慮，測試可以考慮到更多的異常點以及測試點，策劃也可以更加熟練的進行設定表設定等
好啦~以上就是本次文章分享的全部內容啦，你學會了嗎？希望能給大家帶來幫助哦！
