※ 引述《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)