如何保证游戏质量？ - 谈谈流程管理工具
规范化，在测试界工作两年，体会最深的是这个词。测试部门，最重要的是什么？流程的规范化，管理工具的实用性，毕竟质量不是口头说出来的，是做出来的。
第一家公司是一家香港的公司，人数不多，但测试的流程很规范。需求，计划，用例，执行，报告。一切都集中在IBM的DOMINO平台中，开始用起来感觉不是很爽，但慢慢习惯，流程很清晰。
今年初到游戏公司工作，公司的测试管理工具是个人写的，分散而不集中，用起来很不顺手。
也许游戏的庞大性决定了他不能良好的管理，也许各部门的协作频繁造成了流程的冗长，但我觉得一个优秀的平台是协调测试工作的必要手段，也是控制整个质量的必要手段。
游戏测试开始受到重视，但有多少公司做到了整体控制，环环相扣呢？
学习，是必要的，请教各位前辈如何做好整个游戏的控制。 这个标题是否可以理解为你认为需要一个严格的流程规范
就可以开发出一款好的游戏？
游戏软体不同于普通软件的
他的主观因素太多了
质量在游戏行业里的定义实在太广泛了，我们也可以理解为品质以及他的游戏内涵性，这些可能都可以算作质量
如果只是说流程的规范以及使用管理工具哪怕有需求跟踪也没用
因为游戏的需求变更实在是太频繁了…… 因为游戏的需求变更实在是太频繁了……
真的吗?这个很头大的,意味着资源和精力的浪费,国外的更规范点吧.... 恩，同楼上的观点，策划们一天一个想法，策划案天天在变，最夸张的是，我写好的一份用例，在策划案在次变更后，等于白写，需要全部重写
所以，基于以上的特性，我公司现在采用每一个节点制定一会测试需求文档，相关标准由相关负责人来添加，然后我们按着这个标准进行测试。
大家都应该来讨论下，争取制定一套比较适合游戏使用的测试流程 需求有变更是正常的.如果只是需求本身的问题,可以透过评审等过程加以监控.
如果是后期需求的变更,在确认变更初期,需要相关责任人评估变更影响,划分严重和优先级,在不影响测试时间和版本质量的情况下做调整. 策划的心比16岁少女的心还多变。。。
我先前还搞的用例什么的远远跟不上变更的脚本。。。
一些设计案三天两头的推倒从来。。。真佩服这些人早干嘛去了。。。 哎,我发现我们公司的测试太不规范了,没有需求,拿来游戏就先上去冒下烟,三天测试完一个游戏的情况都存在. 我们公司的测试流程算十分规范了,游戏是很庞大的软件工程项目。而且十分复杂,每一个环节都不能出错.我们公司用的缺陷管理工具是TestTrackPro,既TTP。但好象国内的测试都不是很规范,至少我从我朋友得知的.他们也在其他的公司做测试。TTP的功能极其强大哈,把开发和质量检验紧密结合到一起,缺陷的跟踪十分精确。安装也方便,强烈推荐! TestTrackPro貌似比较混乱,中文支持的不是很好. 就是因为需求变化频繁，更加需要一个好的流程管理工具。否则无意义的重复劳动会消耗大量的时间 测试有个规范的管理更好把握主动，而不是任意的跟随其他的。 本来想说点什么，但是发现也没有什么可说的。。。
BTW： 测试用例当然要跟着design即时的更新。如果你的测试用例是一层不变的，那说明你还不够专业。而及时更新也只是你的份内事而已，所以请多干活少抱怨。
而我的另外一个理念可能各位会丢鸡蛋上来。但是我不得不说。
游戏测试员对游戏的了解程度应该是最资深，最到位的。所以在一个游戏公司里，任何一个游戏测试员的声音都是最权威的，而那些程序员或者美工，LD。。。。可能还有我们的游戏设计师 有时候基本都不玩游戏。
做项目，游戏制作人最大，权利也最大。但他（她）跟多的是起着沟通调解和决断的作用。
虽然一切有游戏设计师说了算，但是我敢说，再厉害的游戏设计师都有犯错误的时候，所谓旁观者清，当局者迷。
当他们犯错误的时候，在你看来也就是写了一份狗P的文档。这个时候请有理有节的指出，当然在必要的时候甚至是可以挑战我们的designer大人。
当然就单机游戏来说 （以下说的都是单机游戏）
能够这样做的测试员在中国为数不多，因为一般的原创游戏都是放在国外本公司制作，而测试也只可能在本公司进行，或者外包。
在中国设立的子公司是没有这种资格进行游戏的FULL TEST，就算要测，也只是测其中的一个小项目而已或者给你做一个移植项目，所有的测试用例或者游戏设计照搬照抄。而那些外包公司，当然不可能叫板designer。。。
再罗嗦一句，一般一些资深的游戏设计师都是洋大人，而国人中资深的游戏设计师屈指可数。 楼上的观点相当有道理，当然我是做网游的，我来说说网游的情况：
至少到目前为止，在我做过的公司里，对游戏了解最全面、最透彻的，往往都是测试部门的员工。往往策划在设计一个新的case的时候，会反复多次征求测试部门的意见。所谓的权威，不是你自己说你是你就是了，当你提出的意见往往能一语中的，或者是能说服策划，那么时间一长你说出来的话自然就有分量了。
可能做网游的和做其他游戏的这点上有些不同吧，呵呵。至少我是一直叫板designer的，有些case还会给批到体无完肤甚至直接veto掉 游戏测试产生的时间太短，各个公司重视程度高低不一，小的游戏公司更是没有测试流程可言。。。 我们公司策划和大爷一样，想什么时候变什么时候变想怎么变怎么变，我说变的快我多写几次用例也没什么，可恶的是变了你好歹告诉我你哪变了啊~！竟然要我追着问，不想干了~！ 呵呵..我们公司好歹还让我听一下他们策划的变动....已经不错了... 嘿嘿,变来变去,还不告诉你,说明你在策划眼里没分量.
既然他们觉得你这个测试可有可无,自然需要你在后面追着.
与其抱怨,不如想想怎么改变这种情况.
光做功能测试他们不会把你当回事的. 原帖由 yeir86 于 2008-8-5 13:38 发表 http://bbs.51testing.com/images/common/back.gif
恩，同楼上的观点，策划们一天一个想法，策划案天天在变，最夸张的是，我写好的一份用例，在策划案在次变更后，等于白写，需要全部重写
所以，基于以上的特性，我公司现在采用每一个节点制定一会测试需求文档，相关 ...
我的错，忘了说了，我们公司采用敏捷开发方式进行开发 既然是敏捷型开发,就更需要测试做前期大量的工作以做支持了.
你们的测试代码框架是自己来写还是开发来写?你们如何驱动测试?测试过程是如何的? 原帖由 takiro 于 2008-9-13 11:05 发表 http://bbs.51testing.com/images/common/back.gif
既然是敏捷型开发,就更需要测试做前期大量的工作以做支持了.
你们的测试代码框架是自己来写还是开发来写?你们如何驱动测试?测试过程是如何的?
我们有提出过白核测试的想法，但是领导没有给出正面回答，所以，一直没有做相关的测试，都是程序自己来做超简单的测试。
我们现在的测试过程是这样的，因为是采用敏捷开发的方式，所以，我们每天生成一个版本，每天做日常测试，也就是冒烟测试，无崩溃的话生成日常测试版本，如果有新功能的添加，那么重点测试新功能的实现，然后伴随版本会有一份日常测试报告。
我们工作以节点为单位，一个节点大概三周左右，也可能根据不同的时期进行时间方便的调整，节点开始前，会开节点计划会，然后确定本节点全组的工作任务，如有需要测试的任务，会先行通知我们测试部门，由于我们策划很懒，时常不更新策划文档（这不是批评是真的），所以，我们测试采用的应对办法是：自制测试任务表，先把测试任务写好，然后给相关负责策划，他们添加标准，我们按此标准测试。
在性能测试方面，是由程序开发接口，我们测试来写自动化测试脚本，然后进行相应的性能测试
不过，在沟通方面还是存在问题，策划和程序都是口头约定，然后没有一个人来告诉我们测试，我们现在的方式，就是每天我不停的去问，去沟通，不过，领导已经意识到这是个问题，正在想办法解决，所以呀，我也是来看看大家有什么好办法
页:
[1]
