※ 引述《ledia (下班後才下棋)》之銘言： : 難得看到這麼精彩的討論, 而我非常同意 TonyQ 的看法 : 特別同意 : 1. unit test 不是各處都適用 : 2. unit test 不是萬靈丹, 他只是用來取代人類重覆同一個動作容易出錯的特性 : 3. unit test 視需求再配合其他的 QA 機制 各位可以往後翻 #1FmwBE2i (Soft_Job) 這篇真的講得不錯.解開了我多年的疑惑. 所以我把我的文章重新撰寫讓他清楚了點. 最近剛好給了品質管理的talk.可以補充從遊戲軟體製作方向來看軟體品質的想法. 有幾種情況 不可測 ( 這裡的不可測指得是 我們 "很難" 由 單元/白箱測試得到它應該要有的好處 ) 而這幾種情形剛好就是遊戲軟體特別之處. 第一種不可測情況是規格一直改的情形. 這裡的"一直改"指的是 還沒完成就改 的情形. 原本預估系統要做一個禮拜,可是在第三天就改規格.(而不是完成系統之後一直改) 這種情形的試圖測試都是浪費. 因為規格變動,測試也要跟著動.測試的變動反而會變成災難. (原本的測試就是為了要降低程式改動的side effect,現在反而成為來源) 這種情形也就是需求根本就不確定的狀況. 我們可以說這不是測試的問題,是談需求的人做的不好. 但實務上底層的軟體工人依然要在這樣嚴苛的環境進行工作. 這也是為什麼很多軟體工人不喜歡測試的原因. 因為環境就不允許. 也就是說這種情形是 產品存在設計問題.(產品本身就"不對",而不是實作的不對). (這種想法類似 網創開發 會建議不要過分開發, 先用快速的方法證實真的有賺頭後,再進一步談程式架構設計) 不論每個系統多麼"正確",結局都會是悲劇,還是要重新設計. 也只有黑箱找得出這種設計問題. 這種情形首要之務是 提早黑箱/規格產生/驗證的制度化. 1.提早黑箱 提早整合 在企劃端就快速使用工具(勞作,動畫軟體)驗證設計問題. 2.規格產生制度化 把時間投入在規格的討論與產生上. 從遊戲產品來講 就是 讓企劃(設計)產出就是好玩的. 減少因為設計不良而導致的重新設計及實作. 3.驗證的制度化 讓黑箱能夠科學地找到設計問題的真正來源, 並且針對問題來重新設計(而不是全盤盲目亂改) 第二種不可測的情形是系統本身就不可測. 譬如說表現性的系統(如介面)只有美/醜,沒有正確/錯誤. 以動畫系統來說 有時動的 好不好 這個"規格"就很難量化. 整個遊戲系統就是一個 完整的可獨立表現的系統. 站在接觸使用者(玩家)的第一線. 我這裡要談的是 依據開發中不同種類的模組建立 測試的先後順序. 那些必須仰賴其他系統才能發揮(驗證)其功能的 核心模組 就非常有測試的需求. 因為那些核心模組無法獨立運作, 不透過測試不知道修改之後 其他的系統是否依然運作正確. 反之,週邊的輔助程式不要花太多時間測試.不要為了測試而測試. 第三種不可測的情形是程式本身就寫的太爛,導致不可測. 首要之務是透過教育與監督讓軟體工人他們寫出可以測試的程式碼與邏輯. 先把一些愚蠢不該犯的問題釐清.架構作好.再談其他問題. (這點有點像是要健身,先從好的生活習慣做起) 好code本身就不會有太多的問題,清楚,好改,也好測. 最後一種不可測的情形是一次性的產品. 依照經驗幾乎每次規格都不同一定會重寫的程式. 我就是在說遊戲產品. 事實上根據經驗,一個上線遊戲產品的生命幾乎只有1~2年, 就算長賣,也不會一連改好幾年,多半都是修修bug調整參數平衡度. (魔獸世界這種一套十年的產品是非常少見,請不要拿來當特例) 新產品都極有可能套用不同的引擎,函式庫,甚至語言.所以都是重寫. 能夠留下來的珍寶 都是 開發觀念與團隊經驗. (譬如早期directx每年一改版就不相容就是經典. 逼著新產品重複的東西一定要重寫.) -- "May the Balance be with U"(願平衡與你同在) 視窗介面遊戲設計教學，討論，分享。歡迎來信。 視窗程式設計（Windows CLR Form）遊戲架構設計（Game Application Framework） 遊戲工具設計（Game App. Tool Design ） 電腦圖學架構及研究（Computer Graphics） --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 1.164.81.16 ※ 編輯: NDark 來自: 1.164.81.16 (05/27 22:58) ※ 編輯: NDark 來自: 1.164.62.147 (07/17 21:50)