51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6626|回复: 19
打印 上一主题 下一主题

如何保证游戏质量? - 谈谈流程管理工具

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-7-16 20:37:49 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
规范化,在测试界工作两年,体会最深的是这个词。

测试部门,最重要的是什么?流程的规范化,管理工具的实用性,毕竟质量不是口头说出来的,是做出来的。

第一家公司是一家香港的公司,人数不多,但测试的流程很规范。需求,计划,用例,执行,报告。一切都集中在IBM的DOMINO平台中,开始用起来感觉不是很爽,但慢慢习惯,流程很清晰。

今年初到游戏公司工作,公司的测试管理工具是个人写的,分散而不集中,用起来很不顺手。

也许游戏的庞大性决定了他不能良好的管理,也许各部门的协作频繁造成了流程的冗长,但我觉得一个优秀的平台是协调测试工作的必要手段,也是控制整个质量的必要手段。

游戏测试开始受到重视,但有多少公司做到了整体控制,环环相扣呢?

学习,是必要的,请教各位前辈如何做好整个游戏的控制。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2008-7-17 15:57:46 | 只看该作者
这个标题是否可以理解为你认为需要一个严格的流程规范
就可以开发出一款好的游戏?

游戏软体不同于普通软件的
他的主观因素太多了

质量在游戏行业里的定义实在太广泛了,我们也可以理解为品质以及他的游戏内涵性,这些可能都可以算作质量

如果只是说流程的规范以及使用管理工具哪怕有需求跟踪也没用

因为游戏的需求变更实在是太频繁了……
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2008-8-4 22:26:32 | 只看该作者
因为游戏的需求变更实在是太频繁了……
真的吗?这个很头大的,意味着资源和精力的浪费,国外的更规范点吧....
回复 支持 反对

使用道具 举报

  • TA的每日心情
    郁闷
    2021-11-10 15:38
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    4#
    发表于 2008-8-5 13:38:10 | 只看该作者
    恩,同楼上的观点,策划们一天一个想法,策划案天天在变,最夸张的是,我写好的一份用例,在策划案在次变更后,等于白写,需要全部重写
    所以,基于以上的特性,我公司现在采用每一个节点制定一会测试需求文档,相关标准由相关负责人来添加,然后我们按着这个标准进行测试。
    大家都应该来讨论下,争取制定一套比较适合游戏使用的测试流程
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2008-8-12 09:56:06 | 只看该作者
    需求有变更是正常的.如果只是需求本身的问题,可以透过评审等过程加以监控.
    如果是后期需求的变更,在确认变更初期,需要相关责任人评估变更影响,划分严重和优先级,在不影响测试时间和版本质量的情况下做调整.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2008-8-12 10:49:43 | 只看该作者
    策划的心比16岁少女的心还多变。。。
    我先前还搞的用例什么的远远跟不上变更的脚本。。。
    一些设计案三天两头的推倒从来。。。真佩服这些人早干嘛去了。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2008-8-12 15:55:57 | 只看该作者
    哎,我发现我们公司的测试太不规范了,没有需求,拿来游戏就先上去冒下烟,三天测试完一个游戏的情况都存在.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2008-8-12 16:50:36 | 只看该作者
    我们公司的测试流程算十分规范了,游戏是很庞大的软件工程项目。而且十分复杂,每一个环节都不能出错.我们公司用的缺陷管理工具是TestTrackPro,既TTP。但好象国内的测试都不是很规范,至少我从我朋友得知的.他们也在其他的公司做测试。TTP的功能极其强大哈,把开发和质量检验紧密结合到一起,缺陷的跟踪十分精确。安装也方便,强烈推荐!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2008-8-18 10:30:51 | 只看该作者
    TestTrackPro貌似比较混乱,中文支持的不是很好.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2008-8-20 11:22:36 | 只看该作者
    就是因为需求变化频繁,更加需要一个好的流程管理工具。否则无意义的重复劳动会消耗大量的时间
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2008-8-21 14:30:04 | 只看该作者
    测试有个规范的管理更好把握主动,而不是任意的跟随其他的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2008-8-24 00:07:42 | 只看该作者
    本来想说点什么,但是发现也没有什么可说的。。。
    BTW: 测试用例当然要跟着design即时的更新。如果你的测试用例是一层不变的,那说明你还不够专业。而及时更新也只是你的份内事而已,所以请多干活少抱怨。
          
    而我的另外一个理念可能各位会丢鸡蛋上来。但是我不得不说。
    游戏测试员对游戏的了解程度应该是最资深,最到位的。所以在一个游戏公司里,任何一个游戏测试员的声音都是最权威的,而那些程序员或者美工,LD。。。。可能还有我们的游戏设计师 有时候基本都不玩游戏。

    做项目,游戏制作人最大,权利也最大。但他(她)跟多的是起着沟通调解和决断的作用。
    虽然一切有游戏设计师说了算,但是我敢说,再厉害的游戏设计师都有犯错误的时候,所谓旁观者清,当局者迷。
    当他们犯错误的时候,在你看来也就是写了一份狗P的文档。这个时候请有理有节的指出,当然在必要的时候甚至是可以挑战我们的designer大人。

    当然就单机游戏来说 (以下说的都是单机游戏)
    能够这样做的测试员在中国为数不多,因为一般的原创游戏都是放在国外本公司制作,而测试也只可能在本公司进行,或者外包。
    在中国设立的子公司是没有这种资格进行游戏的FULL TEST,就算要测,也只是测其中的一个小项目而已或者给你做一个移植项目,所有的测试用例或者游戏设计照搬照抄。而那些外包公司,当然不可能叫板designer。。。

    再罗嗦一句,一般一些资深的游戏设计师都是洋大人,而国人中资深的游戏设计师屈指可数。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2008-8-25 10:30:11 | 只看该作者
    楼上的观点相当有道理,当然我是做网游的,我来说说网游的情况:
    至少到目前为止,在我做过的公司里,对游戏了解最全面、最透彻的,往往都是测试部门的员工。往往策划在设计一个新的case的时候,会反复多次征求测试部门的意见。所谓的权威,不是你自己说你是你就是了,当你提出的意见往往能一语中的,或者是能说服策划,那么时间一长你说出来的话自然就有分量了。
    可能做网游的和做其他游戏的这点上有些不同吧,呵呵。至少我是一直叫板designer的,有些case还会给批到体无完肤甚至直接veto掉
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2008-8-26 11:12:47 | 只看该作者
    游戏测试产生的时间太短,各个公司重视程度高低不一,小的游戏公司更是没有测试流程可言。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2008-9-8 11:56:09 | 只看该作者
    我们公司策划和大爷一样,想什么时候变什么时候变想怎么变怎么变,我说变的快我多写几次用例也没什么,可恶的是变了你好歹告诉我你哪变了啊~!竟然要我追着问,不想干了~!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2008-9-8 13:54:46 | 只看该作者
    呵呵..我们公司好歹还让我听一下他们策划的变动....已经不错了...
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2008-9-9 09:40:11 | 只看该作者
    嘿嘿,变来变去,还不告诉你,说明你在策划眼里没分量.
    既然他们觉得你这个测试可有可无,自然需要你在后面追着.
    与其抱怨,不如想想怎么改变这种情况.
    光做功能测试他们不会把你当回事的.
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2021-11-10 15:38
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    18#
    发表于 2008-9-12 10:13:40 | 只看该作者
    原帖由 yeir86 于 2008-8-5 13:38 发表
    恩,同楼上的观点,策划们一天一个想法,策划案天天在变,最夸张的是,我写好的一份用例,在策划案在次变更后,等于白写,需要全部重写
    所以,基于以上的特性,我公司现在采用每一个节点制定一会测试需求文档,相关 ...



    我的错,忘了说了,我们公司采用敏捷开发方式进行开发
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2008-9-13 11:05:10 | 只看该作者
    既然是敏捷型开发,就更需要测试做前期大量的工作以做支持了.
    你们的测试代码框架是自己来写还是开发来写?你们如何驱动测试?测试过程是如何的?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2021-11-10 15:38
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    20#
    发表于 2008-9-17 14:42:47 | 只看该作者
    原帖由 takiro 于 2008-9-13 11:05 发表
    既然是敏捷型开发,就更需要测试做前期大量的工作以做支持了.
    你们的测试代码框架是自己来写还是开发来写?你们如何驱动测试?测试过程是如何的?



    我们有提出过白核测试的想法,但是领导没有给出正面回答,所以,一直没有做相关的测试,都是程序自己来做超简单的测试。
    我们现在的测试过程是这样的,因为是采用敏捷开发的方式,所以,我们每天生成一个版本,每天做日常测试,也就是冒烟测试,无崩溃的话生成日常测试版本,如果有新功能的添加,那么重点测试新功能的实现,然后伴随版本会有一份日常测试报告。
    我们工作以节点为单位,一个节点大概三周左右,也可能根据不同的时期进行时间方便的调整,节点开始前,会开节点计划会,然后确定本节点全组的工作任务,如有需要测试的任务,会先行通知我们测试部门,由于我们策划很懒,时常不更新策划文档(这不是批评是真的),所以,我们测试采用的应对办法是:自制测试任务表,先把测试任务写好,然后给相关负责策划,他们添加标准,我们按此标准测试。
    在性能测试方面,是由程序开发接口,我们测试来写自动化测试脚本,然后进行相应的性能测试
    不过,在沟通方面还是存在问题,策划和程序都是口头约定,然后没有一个人来告诉我们测试,我们现在的方式,就是每天我不停的去问,去沟通,不过,领导已经意识到这是个问题,正在想办法解决,所以呀,我也是来看看大家有什么好办法
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-23 13:27 , Processed in 0.082567 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表