作者：Thomas Petersen
到了介紹測試Unity的第二篇. 如圖前一篇提到的, 我們有軟體測試工程師跟研發團隊很緊密合作, 建立高品質的Unity軟體功能. 測試的軟體開發工程師與軟體測試工程師一起合作, 提高測試度與製作工具, 架構用來測試Unity. 在本教學裡面我要講更多細節:
手動測試
任何結構的手動測試的努力都是為了整個管理系統, 通常會用的工具是表格, 但如果有很多人參與的話, 你就必須要有真正個工具來執行這項工作. 在測試過很多不同產品後, 我們決定用QMetry. 就像我在前一篇提到的, 手動測試主要就是要找到如何涵蓋區域並回報研發團隊整個狀態, 這主要是跟檢視與回饋有關. 利用QMetry這類的工具, 可以幫助我們追蹤兩者. 在同一的地方, 我們可以整理測試需求, 整理新的測試週期, 追蹤產品的缺陷, 放到bug追蹤清單裡, 產生整個Unity各部分的報表, 以及哪種類型的bug.
除了非常結構性的測試, 我們也使用大量的探測型的測試, 找尋新功能的bug. 這其實是一種藝術, 它會攻擊軟體然後找到bug, 不是每個人都具有有效執行這項任務的能力. 而這具有項技能具有很高的價值, 探測性測試最極端的例子是臭蟲大掃除(bug bash) 也就是研發團隊的所有成員大家分組盡可能地找到所有的bug, 找到最多bug的團隊會給予好料, 好吃好喝的獎勵!
還值得一提的是我們在bugtracker (FogBugz) 與source control system (Mercurial)整合的很好. 也就是我們可以從bug回報中追蹤需要修正得源碼, 這讓我們可以知道在不同版本的Unity裡, 可以驗證哪些修正, 我們也可以持續地建版, 然後測試每日的版本.
自動化
大部分我們現在做的測試都是自動化的. 若是回歸測試(regression testing) , 我們有不同的架構, 能幫助我們產生不同類型的測試. 如果是小的, 獨立的Unity Runtime測試, 我們有Runtime Test Framework架構. 有了這個架構, 我們可以產生非常小的, 又快速的東西來執行測試, 針對Unity裡面特定的目標來測試. 它能夠對我們所有的目標執行測試案件, 所以其中單一的測試案件可以在多個支援的平台上確認. 這項功能具有極大的價值, 只需要施展很小力氣就能得到廣泛的涵蓋性. 也這樣才可以讓所有需要植入介面在所有平台上變得可能, 讓我們可以用相同的方式與所有平台的版本溝通.
再者, 這個架構就像測試沙包一樣(sandbox)很容易使用, 也不容易產生很笨的東西. 對於大型測試 我們有Integration Test Framework. 有了這個架構我們可以產生測試案例的更大視野, 通常會要花較久的時間執行, 且具有更廣泛的涵蓋性. 例如: 建立一個資產包(assetbundle), 設定webserver與佈署assetbundle, 啟動Unity, 建立一個玩家, 下載資產包...等等. Integration Test Framework並不是一開始就有多個目標執行, 所以就必須要多做一些工作才能使用一個測試案例在不同的平台上.
而且, 架構並不如Runtime Test Framework那樣的具有sandbox的特質, 所以它更容易做一些像是讓處理狀態卡住(processes hang) ,忘記釋放分享的資源, 這也就是大自由度與彈性所會遇到的代價. 在最高的層級, 我們有回歸的rig (regression rig) ,很簡單地說, 這個東西可以執行一組預先錄製的webplayer遊戲, 在任何給予的變化組(changeset) ,有效地給我們接近即時的整體概念了解, 以最新的程式碼來說, 我們破壞現有的遊戲到怎樣的程度. 除此之外, 這個rig可以剖析某功能, 可以準確地指出哪個改變組(changeset)造成了回歸問題, 因為它會自動追蹤變化. 很顯然地, 還有很多細節可以談這個rig是怎樣運作的, 我想之後再寫一篇!
現今大部分的測試案件都是由開發者撰寫的每個功能, 這是很不錯的現象. 當我開始找尋適當員工來做QA時, 還有更多的測試碼直接由開發者撰寫, 他們也要確認整個套件運作在一起能夠正常運作, 而這個測試寫在最適合的架構上面.
工具
工具對於有效的開發部門的效率非常重要. 我們有個3個在QA的程式開發員的小團隊, 主要專注在工具與架構開發上, 我們稱這些人為Callstack Analyzer. 這個工具可以從每個當機回報(crash reports)中擷取出callstacks, 每次Unity當機時, 就會出現一個對話框, 希望你輸入資訊關於你目前在做什麼, 然後傳送你的工作專案與callstack. 接著我們就會分析這個callstack. 將其分成片段, 可能是Unity, Mono, windows OS, Mac OS等等, 接著我們批配每個片段與其他我們有的callstacks.然後, 我們會找到這些裡面特定部位堆疊裡具有重複性的, 然後開始研究這些東西. 這也就是剛剛說輸入的資訊可以幫助我們的! 因為這些callstack本身很難給我們個方向去探究問題, 一個具有20個重複的callstack與一個可重現的bug回報是個很大的陷阱. 所以請記得在當機的時候按下那個按鈕, 即使你不想填入任何當機資訊, 即使是callbacl本身對我們來說也具有很大的價值!
我們還有很多工具, 例如處理bug的工具, 這些工具在我們的伺服器裡面. 還有能夠追蹤我們測試專案的工具, 進行code涵蓋率分析, 產生cyclomatic complexity的報告...等等的. 都是我們經常會用到的工具組, 讓我們得到當前開發階段Unity的整體概況.
我答應各位我會在第二篇談bug reporter, 但我想我必須留到第三篇再講了...
[相關文章]
沒有留言:
張貼留言