GameLook報道/本稿件基於日本遊戲開發者大會CEDEC 2020第一天發表的與《如龍7 光與暗的去向》(下文簡稱《如龍7》)的調試相關的演講“集結瞭《如龍》工作室的QA工程技術的全自動找BUG系統”進行報道。
這次演講由世嘉的QA工程師阪上直樹和Build工程師粉川貴至帶來。
讓人想要擁抱Bug的系統
演講以阪上先生向開發者們的提問:“各位喜歡Bug嗎?”開場。緊接著他展示瞭如龍工作室各部作品中Bug的數量。隨著遊戲規模變大,其中的Bug數也相應增多。
而使用瞭全自動找Bug系統的《如龍7》,一共發現瞭25000個Bug。雖然這個數據會讓人擔心遊戲的質量,但事實上遊戲中發現的Bug數越多,其質量反而會相應提高。
Bug是開發者心中永遠的痛。但據阪上先生所說,如果開發者們將這篇演講聽到最後的話,“會變得想要擁抱Bug”。
在說明自動找Bug系統使用的方法之前,先讓說明一下手動找Bug的流程吧。流程以發現Bug的工作開始,將這個Bug報告上去之後需要確認其再現性,如果真的是Bug的話,就需要制作Bug票(將Bug的數據和問題點總和起來的一個任務)。
接下來要看Bug票來判斷這究竟是一個現在就會對開發產生影響的Bug還是延後也沒關系的Bug,並決定處理這個Bug的人選。之後單獨在這個人的環境中重現這個Bug並處理它,在確認瞭處理步驟,並由QA團隊再次確認無誤之後,才能在大家的數據中處理這個Bug。
而《如龍》團隊的目標,就是讓這整個過程完全自動化。如果不提升調試(debug)工作的效率的話,最壞的結果可能導致遊戲延期,當然這個系統也能縮短工作本身的時間。於是,抱著不想在“角色模型穿墻”、“進行對話時遊戲閃退”這類低級Bug上花費人手的總體目標,《如龍》團隊開始瞭調試工作的自動化。
首先,為瞭發現Bug,需要搭建一個自動測試環境。他們在開發者們的PC上安裝瞭自動測試系統,要求開發者們在每天結束開發回家之前開啟客戶端。隻要開啟,這個測試環境就會自動展開,直到第二天開發者回到公司,它都會一直自動搜索Bug。
開發者們可能會比較擔心返回公司時能否立刻回到之前的工作環境中。由於在打開客戶端時已經對當時的環境進行瞭備份,因此隻要關掉客戶端就能立刻返回之前的狀態。
【測試環境搭建的自動化】自動測試
回家之前打開各臺PC上的自動測試客戶端從設定文件(Excel)中生成ini取得最新Build自動啟動遊戲(ini文件的腳本/條件)
在這個環境中被自動測試的文件也是由環境自動調用的。號稱“不管在哪都能replay”的本系統,不僅能記錄手動操作,也能夠生成用於自動測試的文件。這個環境不僅能夠讓沒有編程知識的人使用,也能夠很方便地在之後補足條件。
使用本系統之後,不僅能夠更容易發現“昨天還是正常的,今天就突然出Bug瞭”的enbug(degrade),也能完成“是否多次通關瞭主線劇情”、“是否有忘記處理的東西”、“道具是否正常收集”之類需要正確性的測試。特別是《如龍7》中還有擁有收集要素的“江湖寶貝”這一玩法。
【測試制作/運行的自動化】
不管在哪都能replay的系統
用於自動制作/運行測試的系統
用腳本記錄並重現手動遊玩,將之用在replay上
就算沒有編程知識也可以制作自動測試
用於replay的腳本由Python采集
今後可以改變條件或者重復處理之後可以與畫像認識和機械學習進行連攜
此外,迷你遊戲中的Bug、穿模之後角色從地板掉下去等等隨機發生的Bug也更容易找到瞭。但玩家的操作介於正確的動作和隨機的操作之間。這樣的玩家操作目前還很難檢測,《如龍》團隊也正在做這方面的研究。
如果設想玩家單純隻是在推進主線,這樣找Bug自然很容易,但玩家在推進主線的過程中難免會分心去做其他事。《如龍》團隊也展示瞭能夠嘗試其他可能的系統,比如能夠將自動測試用的操作細分開然後集中到服務器中,在一定時間模仿其他自動測試操作的系統或者完全朝著別的目的地前進的系統等等。但這些也仍在研究階段,還沒有投入實際使用。
演講中也展示瞭系統實際自動調試的樣子,畫面中展示出瞭春日一番在停車場的柵欄和欄桿之間像舔一樣來回走動的樣子。同時,場景探索和戰鬥中用到的改變場景的按鍵操作的方法也發生瞭改變。這些也會根據情況自動切換。
當然,測試環境不僅僅隻有開發者們的PC,《如龍》團隊還準備瞭24小時不間斷進行測試遊玩的PC。24小時不間斷運行是為瞭將數量龐大的支線任務全部清光,並且對那些耗時的東西進行自動測試。這些PC24小時中不斷自動接受著“下次是這個測試”、“這臺PC正在用所以接下來用這個”的命令。都在全負荷運行中。
【測試案例設定的自動化】在Jenkins上測試sub scenario
自動測試客戶端和Jenkins 的分別使用
自動測試客戶端
對於使用者(協助測試者)來說便於使用
使用者能夠明白客戶端在PC上正處在運行狀態
正確進行啟動前和結束後的處理
運用開發時的空閑時間
從Jenkins開始實行
對於自動測試的管理者來說更容易處理
能夠控制更加復雜的自動測試
以24小時不間斷運行為前提進行運用
當然,自動測試時,如果不能發現Bug就一點意義也沒有。(這一系統中)Bug的檢查是全自動的,還會將Bug分門別類進行報告。將手動測試和自動測試進行對比的話,《如龍6命之詩。》中自動測試發現的Bug占全部的約18%,效率提高瞭的《如龍7》中這一比例上升到瞭約68%。雖然比例的提高是因為其中也包含瞭重復的內容,但重復的報告也是很有價值的數據。
此外,最開始的手動文件制作以及測試計劃制作確實難以自動化,但其後關於Bug探索的工程幾乎全部是自動進行的。
找到Bug之後,自動分析、報告!
接下來是Bug報告的自動化。在發現瞭Bug或是類似Bug的內容時,系統會自動將日志、截屏、視頻以及用於重新自動測試的數據送到合適的地方。必要的信息也會全部自動輸入並登錄到Bug票上。
不過,手動測試引起的Bug會被作為“Bug”票來處理,但自動測試發生的Bug以及類似Bug的內容則會被當作“錯誤報告”票來處理。這樣就不會出現去詢問自動報告這種沒有意義的失誤瞭。
為瞭自動確認自動發現的Bug的再現性,也會自動開始自動測試遊玩。自動確認過Bug 的再現性之後,得到瞭確認的Bug票上會加上“會自動再現”的信息。即使它再現之後沒有變成錯誤,也能夠調查出其原因。
演講中也展示瞭自動檢查Bug並自動再現的視頻。視頻中系統檢測到瞭隨機做出動作的春日一番在與韓俊基(ハン・ジュンギ)對話的過程中發生的錯誤。在自動確認再現性時,系統讓主角在韓俊基的前面以同樣的操作進行瞭移動,稍稍等待之後與韓俊基對話,果然又檢測到同樣的錯誤。這是因為在檢測到錯誤的瞬間沒有記錄到按鍵的操作。為瞭解決這個問題,系統讓玩家經過一定時間之後才能按下確定鍵。
這樣,Bug的報告流程就成功完全自動化瞭。
接下來是Bug分類的自動化。具體來說就是自動判斷Bug 的優先度和重要度。優先度高的Bug對很多地方都會產生影響,需要盡早處理。而重要度則是指對遊戲的影響,比如有的Bug會讓遊戲強制結束。
錯字漏字或記載錯誤之類看起來不影響遊戲的運行,重要度不高。但是,《如龍》系列中存在著很多現實中存在的商品,這些東西如果出現錯別字就很要緊瞭。
Bug優先度的自動判斷是看錯誤的重復數。錯誤信息的內容重復得越多,影響范圍也就更廣。重要度得判斷則是由錯誤判定的種類決定的。
負責處理Bug的人選也是自動決定的。《如龍》團隊在此之前在摸索用機械學習來判斷合適的負責者的辦法,但最後覺得還是無法順利運用,因此也就沒有投入實際使用。
他們采用瞭一種更加簡單的方法,在Bug最多的種類的Bug修正負責人與錯誤信息直接連接起來。這些人大多是原本就負責制作這一部分的員工,當然也有並非如此的情況。
這樣Bug分類就成功自動化瞭。
Bug處理本身還是要手動
接下來他們的目標是,自動修正Bug。負責人要修正發生的Bug,首先要在自己的環境中對這個Bug進行確認。因為這時使用的確認文件是在自動再現Bug時由重新播放文件自動生成的,所以能夠在自己的環境中再現。
雖然程序的修正最後還是要手動處理,但其後反映到遊戲本身是自動的。此外,Bug被修正並且也反映到瞭遊戲之中後,將Bug票的數據發送給QA團隊,變為等待確認狀態的過程也是自動的,因此QA團隊立刻就能進行修正確認。
雖然處理Bug的“調試”和將數據發送到遊戲中的“提交”是手動的,但整個修正流程中的那些麻煩的部分還是被自動化瞭。
最後則是Bug 的修正確認。首先要仔細確認有沒有因為這個Bug的修正產生新的Bug(enbug)。enbug的確認也會進行自動測試,自動檢測有沒有enbug的發生。
在接下來的修正確認中,對於成為瞭等待確認狀態的Bug票,需要再次使用在Bug的自動再現確認中使用過的重新播放數據。這時如果發生瞭錯誤,就自動結束這個確認過程。如果又發生瞭Bug,則自動返回之前的狀態。
此外,在自動檢測出的Bug的報告中,也會有重復內容。如果沒有成為修正確認完成狀態,但也沒有重復出現同一錯誤報告的情況下,也將之當作確認完成來處理。因為這些Bug可以被認為是“不會再發生的Bug”,因此可以被視作已經自動完成修正瞭。
最後,演講者以剛才提到的春日一番與韓俊基的對話為例,展示瞭自動進行修正確認的視頻。這次他仔細展示瞭與韓俊基的對話日志,而完全沒有檢測出Bug瞭。雖然看著可能會想“是這個嗎?”但正如前文提到的,這個全自動找Bug系統,能夠全自動處理這種簡單的Bug。
《如龍》系列作品已經采用瞭很多類似的系統,這些系統的細節也一直在優化,能夠自動處理的任務也越來越多。在23個Bug處理的工程中,有20個工程是全自動完成的。這20個工程全自動處理掉的Bug數共達到瞭250個,雖然看起來不多,但不管是哪個錯誤都是全自動處理的。
將自動處理的Bug票積分化統計之後,可以看到,(《如龍7》的)的工作時間比起《如龍 維新》減少瞭一半。如同當初的目標一樣實現瞭工作的效率化。今後的課題是上文提到過的完全再現玩家動作。
阪上先生總結道:“全自動找Bug系統是將遊戲開發中的麻煩事自動化的起始線。”以此結束瞭這篇演講。
《如龍》系列,是能夠在相對短時間內連續制作出超大作的系列。他們是如何做到這樣在短時間內不斷推出完成度很高的新作的呢?從這篇演講中可以窺見一二。自動化做到這種程度,或許將程序的修正也能夠自動化……嗎!?
文章來源:GameLook.com.cn
暫無評論
要發表評論,您必須先 登入