一、什么是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的產生，開發可以在編碼上有更多的考慮，測驗可以考慮到更多的例外點以及測驗點，策劃也可以更加熟練的進行配置表配置等
??
??
??好啦~以上就是本次文章分享的全部內容啦，你學會了嗎？希望能給大家帶來幫助哦！
????
??
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/154639.html
標籤：java