浅谈游戏的测试（二）

qyb

前一篇文章的最后，我提到了让测试尽早加入到游戏的开发，我想也许有必要花点篇幅来说明一下我这么说的理由并追加一些其他的内容，特此开启这份补充版。

好的，为什么我们要提前测试，什么叫提前测试。也许很多人都觉得测试就是拿起一个游戏玩，然后一路打过去，不断给程序找麻烦那么简单。事实上，有没有人想过，当你没提出一个Bug时，程序会怎么想？你告诉程序，这个游戏的攻击规则太简单了，没有挑战性。我相信程序肯定会告诉你，该Bug建议忽略，的确，太晚了，修改太费事费力。

学过一点软件工程的都知道，过去国外很多软件都是开发后发觉不符合预期或者用户要求再返工，导致成本很高，浪费很多时间。国内也面临这个问题。等到游戏已经拿出手的时候再从根本上指出一些原则问题，美工、程序和策划都会觉得很棘手，重做没时间，不重做问题也许确实很严重。而作为一个已经上手的测试，相信确实每个人都会有很多行之有效、给游戏添彩想法。这里不谈内部沟通上的障碍和其他客观因素，我肯定，如果这些想法能早一些传达到策划或者程序，美工那里，一切都会大有不同，这么形容吧——在建成大厦前改变图纸比推倒重建有价值得多。这也是为什么我说，测试必须在游戏开发的早期介入的原因。

我们举些简单的例子，某个我参与过的游戏的道具栏原先设计为一页最多28个空位可存放道具，一开始的限制，诸如没有买到背包，决定了只能存放这一页，满了就提示道具已满。一个道具一个坑，获得同样的道具同样占一个道具空格，也就是说最多能放28个道具。但是很快我在策划案中看到其中很多任务需要大量的任务道具，数目从2到14不等，很显然，玩家在游戏初期会面临一个道具空间捉襟见肘的困境。当时道具系统刚刚开始确立，如果这时候开始修改，大约也就是几天的功夫就能完成，不幸的是我的建议没有被采纳，最后，实际游戏后，一切都摆在眼前后，试玩的老总提出了同样的问题，很明显，这一次非改不可。最后导致的结果就是原先的开发全部白费，后面还要花同样的时间重新做一个新的。这不能不说是一件令人扼腕的事情。同样我们也可能在数值等我前一篇文章提到过的地方发现一些问题，一些操作的改良建议？一些错字？总结出意见一并提出，有些方面不像数值或者系统设计问题那么至关重要，但是早喝水总比脱水后补充有效。

作为有经验的测试，面对不成熟的策划更是如此，更多更早的建议可以有效缩短修改的时间，也是给你后期测试省力。
当然了，真的到了后期测试，最好别再提出诸如“我要武器能在砍死一百只猪后从小刀进化成杀猪刀”这样的意见，也许看上去很简单，但是修改起来很复杂。其他一些更明显的就不提了。记录下你的意见，但不要强求别人修改才是明智的选择。

好的，下面我们再拔高一点，能给策划更多建议么，一个好测试，绝对不仅仅是测试。现在你的策划开始工作了，你能给他些什么建议？不才才疏学浅，能做的大概也就是就一些小小的细节做些加强。比如，寒冷地区人口中的白气，子弹发射后的旋转，地面上奔跑后扬起的尘烟（区分雪地和沙地等地形的区别），也许看上去都很简单，不过确实策划中时常会遇见这些细节被忽略的情形，相信我，特别是那些专注于技术，痴迷于系统的策划，很容易忽略细节。

就细节上我们再跨出去一步，我们问：“为什么这个村子没有井，附近也没有河，居民喝什么？”，“没有农田的村子，居民吃什么？”“村子里的花瓶的花附近有么？”“村长的家和一般村民会不会有不同，哪里？城市农村的家中摆设是不是应该有差别？”“这个村子卖的食物和道具和其地理位置有关联会不会更有趣？逼真？”“生命系怪物在地下迷宫关着，出口封闭，他们靠什么为生？”“魔法发射没有冷却时间，那么这个世界剑士如何抗衡法师？”并不见得所有这些问题都必须有一个答案，但是，想过没做过和没想过没做过，毕竟是有区别的。

现在谈谈一个人的定位，擅长什么？不擅长什么？我的专长是文字，逻辑，合理性分析还有各种知识，当策划信誓旦旦地提出“斯巴达人学习了古罗马方阵”时，我可以告诉他“亲爱的，希腊兴盛于罗马之前”，又比如当某人指出“弩弓好似古代的突击步枪”时，我会在桌子下面给他一脚，然后告诉他，“朋友，你最好先看看突击步枪和一般弩弓的简介”。
这里谈到了知识，知识的积累很重要，我看到的很多策划偏重于技术，认为知识不实在，都是可有可无的，不幸的是，刚才我举的例子却都是真实的。其他好似“骑兵分重甲和重装，重装偏重攻击”这样奇怪说法，又好似“骑射不需要怎么学”这样的特异论调都是在一次讨论中截录的。也许这些是很有趣的新思路，但是就我判断都是谬误，如果依照这样的知识去策划游戏，那很明显会贻害玩家。（注，骑兵过去用什么武器都差不多，什么叫重装？中世纪有这个说法么？又好象骑射，我们知道击中移动的物体很难，而双方都在移动中，一边骑马一边还要射出箭自然更难命中，如果说是胡乱射击，用箭矢的数量取胜，那我想骑射这技能人人都会了，也不是什么少数民族的专长了）我没有刻意去评判什么，也许我的见解也有误差，但是我觉得策划有必要提高一些知识的积累，如果做不到，测试给他们补充。

知识同样提高了测试，不，是游戏的深度，很多人对游戏的文化底蕴津津乐道，什么是底蕴，哪里来的？知识、细节。衣——当时人穿什么款式，重什么色调，不同的人穿什么。防具是什么，锁子甲还是铁叶甲，或者板甲，鳞甲？食，他们吃什么，烹调方式有哪些，和民族文化关系，和地理位置关系？住，什么房子，拱形顶？木石泥草砖瓦？城市里的卫生设施如何，有没有喷泉？行，道路沙路，泥路，石路？下面铺了什么没有，是不是和罗马一样有排水沟？有没有人维护？有没有驿站？上述各点各地有什么区别，为什么？等等，累积就是底蕴。

最后这里稍微聊聊我们需要什么样的能力，测试注重观察力，合理化的能力，但是我认为要想给策划提供更多援助，必须提高创造力，Keep Healthy；从他人那里获得灵感；包括我们的先祖的智慧，观察细微的不同，；记录每个想法，尝试着将不同的东西联系在一起（我们要知道，古代和现代很多发明仅仅是改良，好像飞行器的某些原理回旋镖就应用到了，而具有形态和功能上作用的坦克在公元前亚述就发明过，改良和联系也是很重要的）；思索每一个不经意的错误；凡是想想前因后果，多一些思考而不是单纯接受；做没做过的事情；然后你就更容易想出没想过的。

其他一些能力，好像细心，耐心，热心，虚心等等，在我另一篇文章里提到过，不一一细表。可能你看到这里已经觉得枯燥了，但是我仍要多嘴2句，“给出评论，但不要轻易下定论”和“游戏，是给玩家设计的，不是取悦你自己”。


QYB IDEADS FOR GAMES……





补充，关于测试的Bug表示，新人可能缺乏概念，或许有说明一下的价值。Bug包含的要素并不固定，一般由序号、发现时间、状态（依旧未解决？解决？等），结束时间、问题描述、类型（音乐、逻辑、文字、画面等）、优先度（或者说严重程度）、描述、修改意见等组成（程序反馈等别人填写的不计）。如果有条件，贴一张Bug相关的图片不失为一个好方法。
目前测试的报告发送有很多形式，有些公司Bug各自独立，发现一个填写一份报告发送，这样比较节省时间，但是Bug太多时收藏总结不易；而我以前的公司把游戏测试完毕，Bug汇总在一个文档里发送，这样便于管理Bug单。我现在的做法是Bug发现后马上MSN程序，以便及时修改，然后把全部Bug填写在一个单子里，一起发送以免遗漏。
关于描述，有经验的测试容易发现Bug出现的原因（当然，看多了），不行就尽量描述清楚，注意语言的组织。修改意见方面，也就是一个Solution，你能给得出自然更好，不然就归纳下这个应该由策划协作还是美工协作或者是程序单独处理，当你在策划、美工、程序方面有一点理解的前提下，可以适当在修改意见里加上一些建设性的意见。上面的知识很有用，不用很精，但只要有一些基础知识测试中就能感觉到不同了，平时应多加积累。另，游戏也可以多玩，这个，我没做到。懒了~~~~~~~~~~

　　　　　　　　　　　　　　[本贴由 御灵 于 2008-1-18 19:17:51 进行了编辑]

qyb

前一篇文章的最后，我提到了让测试尽早加入到游戏的开发，我想也许有必要花点篇幅来说明一下我这么说的理由并追加一些其他的内容，特此开启这份补充版。

好的，为什么我们要提前测试，什么叫提前测试。也许很多人都觉得测试就是拿起一个游戏玩，然后一路打过去，不断给程序找麻烦那么简单。事实上，有没有人想过，当你没提出一个Bug时，程序会怎么想？你告诉程序，这个游戏的攻击规则太简单了，没有挑战性。我相信程序肯定会告诉你，该Bug建议忽略，的确，太晚了，修改太费事费力。

学过一点软件工程的都知道，过去国外很多软件都是开发后发觉不符合预期或者用户要求再返工，导致成本很高，浪费很多时间。国内也面临这个问题。等到游戏已经拿出手的时候再从根本上指出一些原则问题，美工、程序和策划都会觉得很棘手，重做没时间，不重做问题也许确实很严重。而作为一个已经上手的测试，相信确实每个人都会有很多行之有效、给游戏添彩想法。这里不谈内部沟通上的障碍和其他客观因素，我肯定，如果这些想法能早一些传达到策划或者程序，美工那里，一切都会大有不同，这么形容吧——在建成大厦前改变图纸比推倒重建有价值得多。这也是为什么我说，测试必须在游戏开发的早期介入的原因。

我们举些简单的例子，某个我参与过的游戏的道具栏原先设计为一页最多28个空位可存放道具，一开始的限制，诸如没有买到背包，决定了只能存放这一页，满了就提示道具已满。一个道具一个坑，获得同样的道具同样占一个道具空格，也就是说最多能放28个道具。但是很快我在策划案中看到其中很多任务需要大量的任务道具，数目从2到14不等，很显然，玩家在游戏初期会面临一个道具空间捉襟见肘的困境。当时道具系统刚刚开始确立，如果这时候开始修改，大约也就是几天的功夫就能完成，不幸的是我的建议没有被采纳，最后，实际游戏后，一切都摆在眼前后，试玩的老总提出了同样的问题，很明显，这一次非改不可。最后导致的结果就是原先的开发全部白费，后面还要花同样的时间重新做一个新的。这不能不说是一件令人扼腕的事情。同样我们也可能在数值等我前一篇文章提到过的地方发现一些问题，一些操作的改良建议？一些错字？总结出意见一并提出，有些方面不像数值或者系统设计问题那么至关重要，但是早喝水总比脱水后补充有效。

作为有经验的测试，面对不成熟的策划更是如此，更多更早的建议可以有效缩短修改的时间，也是给你后期测试省力。
当然了，真的到了后期测试，最好别再提出诸如“我要武器能在砍死一百只猪后从小刀进化成杀猪刀”这样的意见，也许看上去很简单，但是修改起来很复杂。其他一些更明显的就不提了。记录下你的意见，但不要强求别人修改才是明智的选择。

好的，下面我们再拔高一点，能给策划更多建议么，一个好测试，绝对不仅仅是测试。现在你的策划开始工作了，你能给他些什么建议？不才才疏学浅，能做的大概也就是就一些小小的细节做些加强。比如，寒冷地区人口中的白气，子弹发射后的旋转，地面上奔跑后扬起的尘烟（区分雪地和沙地等地形的区别），也许看上去都很简单，不过确实策划中时常会遇见这些细节被忽略的情形，相信我，特别是那些专注于技术，痴迷于系统的策划，很容易忽略细节。

就细节上我们再跨出去一步，我们问：“为什么这个村子没有井，附近也没有河，居民喝什么？”，“没有农田的村子，居民吃什么？”“村子里的花瓶的花附近有么？”“村长的家和一般村民会不会有不同，哪里？城市农村的家中摆设是不是应该有差别？”“这个村子卖的食物和道具和其地理位置有关联会不会更有趣？逼真？”“生命系怪物在地下迷宫关着，出口封闭，他们靠什么为生？”“魔法发射没有冷却时间，那么这个世界剑士如何抗衡法师？”并不见得所有这些问题都必须有一个答案，但是，想过没做过和没想过没做过，毕竟是有区别的。

现在谈谈一个人的定位，擅长什么？不擅长什么？我的专长是文字，逻辑，合理性分析还有各种知识，当策划信誓旦旦地提出“斯巴达人学习了古罗马方阵”时，我可以告诉他“亲爱的，希腊兴盛于罗马之前”，又比如当某人指出“弩弓好似古代的突击步枪”时，我会在桌子下面给他一脚，然后告诉他，“朋友，你最好先看看突击步枪和一般弩弓的简介”。
这里谈到了知识，知识的积累很重要，我看到的很多策划偏重于技术，认为知识不实在，都是可有可无的，不幸的是，刚才我举的例子却都是真实的。其他好似“骑兵分重甲和重装，重装偏重攻击”这样奇怪说法，又好似“骑射不需要怎么学”这样的特异论调都是在一次讨论中截录的。也许这些是很有趣的新思路，但是就我判断都是谬误，如果依照这样的知识去策划游戏，那很明显会贻害玩家。（注，骑兵过去用什么武器都差不多，什么叫重装？中世纪有这个说法么？又好象骑射，我们知道击中移动的物体很难，而双方都在移动中，一边骑马一边还要射出箭自然更难命中，如果说是胡乱射击，用箭矢的数量取胜，那我想骑射这技能人人都会了，也不是什么少数民族的专长了）我没有刻意去评判什么，也许我的见解也有误差，但是我觉得策划有必要提高一些知识的积累，如果做不到，测试给他们补充。

知识同样提高了测试，不，是游戏的深度，很多人对游戏的文化底蕴津津乐道，什么是底蕴，哪里来的？知识、细节。衣——当时人穿什么款式，重什么色调，不同的人穿什么。防具是什么，锁子甲还是铁叶甲，或者板甲，鳞甲？食，他们吃什么，烹调方式有哪些，和民族文化关系，和地理位置关系？住，什么房子，拱形顶？木石泥草砖瓦？城市里的卫生设施如何，有没有喷泉？行，道路沙路，泥路，石路？下面铺了什么没有，是不是和罗马一样有排水沟？有没有人维护？有没有驿站？上述各点各地有什么区别，为什么？等等，累积就是底蕴。

最后这里稍微聊聊我们需要什么样的能力，测试注重观察力，合理化的能力，但是我认为要想给策划提供更多援助，必须提高创造力，Keep Healthy；从他人那里获得灵感；包括我们的先祖的智慧，观察细微的不同，；记录每个想法，尝试着将不同的东西联系在一起（我们要知道，古代和现代很多发明仅仅是改良，好像飞行器的某些原理回旋镖就应用到了，而具有形态和功能上作用的坦克在公元前亚述就发明过，改良和联系也是很重要的）；思索每一个不经意的错误；凡是想想前因后果，多一些思考而不是单纯接受；做没做过的事情；然后你就更容易想出没想过的。

其他一些能力，好像细心，耐心，热心，虚心等等，在我另一篇文章里提到过，不一一细表。可能你看到这里已经觉得枯燥了，但是我仍要多嘴2句，“给出评论，但不要轻易下定论”和“游戏，是给玩家设计的，不是取悦你自己”。


QYB IDEADS FOR GAMES……





补充，关于测试的Bug表示，新人可能缺乏概念，或许有说明一下的价值。Bug包含的要素并不固定，一般由序号、发现时间、状态（依旧未解决？解决？等），结束时间、问题描述、类型（音乐、逻辑、文字、画面等）、优先度（或者说严重程度）、描述、修改意见等组成（程序反馈等别人填写的不计）。如果有条件，贴一张Bug相关的图片不失为一个好方法。
目前测试的报告发送有很多形式，有些公司Bug各自独立，发现一个填写一份报告发送，这样比较节省时间，但是Bug太多时收藏总结不易；而我以前的公司把游戏测试完毕，Bug汇总在一个文档里发送，这样便于管理Bug单。我现在的做法是Bug发现后马上MSN程序，以便及时修改，然后把全部Bug填写在一个单子里，一起发送以免遗漏。
关于描述，有经验的测试容易发现Bug出现的原因（当然，看多了），不行就尽量描述清楚，注意语言的组织。修改意见方面，也就是一个Solution，你能给得出自然更好，不然就归纳下这个应该由策划协作还是美工协作或者是程序单独处理，当你在策划、美工、程序方面有一点理解的前提下，可以适当在修改意见里加上一些建设性的意见。上面的知识很有用，不用很精，但只要有一些基础知识测试中就能感觉到不同了，平时应多加积累。另，游戏也可以多玩，这个，我没做到。懒了~~~~~~~~~~

　　　　　　　　　　　　　　[本贴由 御灵 于 2008-1-18 19:17:51 进行了编辑]

影北山人

挑别人毛病容易，挑自己毛病。。。难！  所以我觉得找别人给你测试效果会好很多哟~自己往往会顺理成章忽略掉很多东西 -v -||||
楼主辛苦了~~【上茶】

回转寿司

以下引用qyb于2008-1-10 10:41:18的发言：

就细节上我们再跨出去一步，我们问：“为什么这个村子没有井，附近也没有河，居民喝什么？”，“没有农田的村子，居民吃什么？”“村子里的花瓶的花附近有么？”“村长的家和一般村民会不会有不同，哪里？城市农村的家中摆设是不是应该有差别？”“这个村子卖的食物和道具和其地理位置有关联会不会更有趣？逼真？”“生命系怪物在地下迷宫关着，出口封闭，他们靠什么为生？”“魔法发射没有冷却时间，那么这个世界剑士如何抗衡法师？”

话说我在做囧魂时就为要不要在每户人家设一个厕所伤过脑筋……= =

小叽

楼主建议你先学学《软件工程导论》。

御灵

发布完毕。
http://rpg.blue/web/htm/art573.htm
vip+1