2012年5月18日 星期五

Unity 3D品管測試流程揭密


作者:Thomas Petersen

距離上次我們貼Unity測試的文章已經有一陣子了, 我想要更新QA常見問答集裡面的資料, 這是QA裡面的第一篇, 我很快會在貼出第二篇關於內部工具, 周期與分析技術.

產品
我相信你知道Unity這套產品, 身為Unity的開發者, 你應該對產品的主要功能十分熟悉, 但從軟體測試員的角度, 有些功能你可以從來沒想過.

眼睛睜大一點 (觀察軟體運作狀況)
Unity是我用過的軟體裡面最可以測試的產品, 幾乎Unity 裡面所有的東西都可以拿來測試. Unity包含了大量的APIs profilers (側寫參數), logs...等等, 讓我們可以從code做很多事情, 包含了確認任何動作, 給予預期的結果. 除此之外 Unity在 核新部分只需要單次安裝, 在單一台電腦上, 所以執行自動化的硬體需求會很小.

所有的遊戲平台
有一點要先提醒你, Unity的核心功能就是讓遊戲撰寫支援多平台, 自然我們必須要測試這個功能, 這會讓測試設定變得相當複雜, 讓我們整個架構需求增加, 這樣我們才可以在測試的時候得到需要的資訊. 從最廣的觀點來看, 我們必須要同時涵蓋所有平台, 滿足廣泛的測試. 但還要告訴我們, 某些手機會產生某些問題, 或是不同瀏覽器, 不同作業系統或是特定的險哪會有問題...你應該懂我意思.

我們不會忘了Unity廣大用戶對我們的愛, 從很多方面來看, 你們就是Unity的骨幹, 讓論壇有了真正的價值. 回答問題, 測試東西. 我們很重視這些, 讓我們奉獻在這軟體上, 負責任, 幫助各位.

我們的策略:AAA
不! 這邊指的不是大製作, 而是自動化, 自動化, 自動化. 我們有可測試的產品, 有設備, 也需求, 當我們軟體只有單一周期, 就進到下一個軟體, 就不需要做到自動化了. 但是Unity是一套維持很多年的的軟體, 如果這樣的軟體還要反覆地手動測試, 一點道理也沒有.

善用社群
我們有大家, 你們對我們有很大幫助, 但我們還能做更多事. 我們可以用更多工具, 幫助你們測試自己的遊戲, 面對事實吧! 以為能做出一個很棒的特效, 適用於各種情況, 實際上這根本就不可能. 這些工具可能包含了對錯誤報告的整體檢視, 自動地找到重複的部份, 當你呈交錯誤, 就會整合到問答集裡面, 甚至還有發表的測試套件. 幫助各位也會幫助我們, 如果各位有回饋的話, 我們就能針對錯誤來修正.

好的內部報告
這是針對Unity研發團隊的報告. 我們必須要知道Unity各個部分的品質, 哪個部分比較好, 哪個部份有很多錯誤, 哪些用戶遇到很多問題. 關於這點用講得很容易, 在概念上也很容易做出怎樣類型的報告是您要的, 但是實際在操作的時候卻非常難! 讓我們必須要在不同工具之間都要用同樣的名詞, 持續地收集資料, 建立根據這些資料的報告. 我們目前在做的事是統一各個工具的專有名詞.

萬事皆人開始, 請來的人一定比我們厲害. 這些人才是做事的人, 當我在寫這篇文章的時候, Unity的QA團隊共有17為工程師與工讀生, 我們還在徵人!

我們在哪
目前測試團隊位於哥本哈根, 立陶宛的維爾紐斯與英國的布賴頓, 我們也在奧德賽徵募新血. 在哥本哈根, 我們主要關注在編輯器與核心, 因為這是開發者會接觸到的部份. 維爾紐斯大部分是負責手持與遊戲機, 布賴頓則負責網頁播放器. 我說大部分, 是因為常常每個人負責各分散的功能, 例如PS3的部份現在是在布賴頓測試.

如你看到的 Unity團對遍布全球, QA 團隊最棒的部份是, 我們會持續地與其他團隊溝通, 透過Skype 27個人會加入討論. 開會的時候研發團隊與支援團隊也會旁聽.

測試的規則
我們測試的時候有很明確的規則, 這讓我們知道招聘人員的目標, 但在實際測試的時候, 你必須要有比開發者更廣泛的視野. 做測試的軟體開發工程師, 是測試的工程師, 這些人一次地用工具工作, 架構與功能自動化. 他們的工作就是要找出改善整體工作流程的方法, 對每位在Unity研發的人員, 藉由建立build farm的自動化, 製作回歸套件避免錯誤(bug)發生. 同時也讓測試者與開發者都知道整個架構的使用, 這些都是AAA測試的骨架.

軟體測試工程師, 就是手冊測試員, 但這不是一個很好的稱呼, 除了找到如何適當地涵蓋一個功能外 這項工作還需要大量的技術知識, 這測試員還必須要對整體有了解, 他們也是新功能的首次使用者, 能在最早期的軟體開發階段提供意見, 讓我們再將軟體交給aplha用戶的時候能表現到最好, 這些人是內部回報策略的中堅份子.

QA工讀生花時間在看你上傳的錯誤, 然後試著重現每個錯誤, 接著會把這個錯誤回報給程式開發者 . 這些人對於您的錯誤回報扮演了重要地位! 如果他們無法找到錯誤如何發生, 他們會將問題丟給QA,然後問原提問者更多細節資訊. 這是Unity裡面新的做法, 我們是在2012年春天開始實施的, 對我們面對廣大 Unity進行回應是個很重要的部門.

社群
我們有全世界最棒的社群, 雖然這麼說有點大膽, 但我相信是這樣沒錯. 在我待過的公司裡面, 沒有一個公司的社群聚有如此大的影響力與衝擊力! 我之前在這部落格有說過同樣的話, 而這是我們非常重視的部份. 我們會使用社群做很多事情, 我舉幾個例子, 有時我會組成alpha測試群, 這名單會涵蓋了少數人, 也就是過去有給我們很多好意見的人士, 他們會比其他人早拿到軟體, 我們會諮詢這些人, 以確保我們能開發正確的新功能. 這些意見我們會拿來做為問題的參考以及用戶會如何使用.

社群也會提供錯誤回報給我們, 不管是在beta測試或是在正式版釋出以後. Beta test要花相當長的時間, 透過幾次的版本釋出. 我們會收集到大量的錯誤(bug) Beta測試員很會找錯誤, 給我們他們找到的錯誤檔案. 能找到錯誤當然很棒, 但要做為一個稱職的beta測試員, 你必須要持續地提供容易重現的錯物回報, 我們會在下集介紹更多關於這點.

最後, 我必須要強調, 當我們有問題時, beta測試組他們很樂意地協助. 最近有個超級大的案子, 他們很快在一個工作天內就回應了, 我們真的很感謝這樣的回應與參與感!

沒有留言: