发布新日志

  • [论坛] 胡侃游戏自动化测试(一)

    2008-10-21 22:54:25

    本文出自开水泡泡的51Testing软件测试博客,转载请保留出处及链接:http://www.51testing.com/?138935

    申明一下,只是在这里抛砖引玉,各位如果有好的方法和建议,欢迎指正。

    首先,据我了解,国内的游戏(MMORPG)行业(国外的我不知道哈),几乎还没有比较成功的游戏自动化测试体系,或许是我孤陋寡闻吧!有少数公司在做,但是效果都不很明显,结合我自己的做的一些经历和实际操作,小小的说说自己的想法。

    1.目前市面上的一些测试工具如:lr,wr,qtp什么的不适合做游戏自动化测试,至少我没找到合适方法。个人理解是因为这个工具实际是通过简单录制或定制一些行为来实现自动化测试的,做游戏自动化测试,这些工具有几个重大缺点:

         部署成本高:

         自动化体系在server端很难部署,定制行为的时候几乎不能调用到游戏的接口,无法获得游戏实际运行的信息,预期结果不方便定制。如果是通过简单录制回放的话,效率不如手动操作好,对一些繁琐的行为,几乎是不现实的,而且这些工具对tcp/ip协议支持不如http协议好,有兴趣的同学可以去研究研究。

         效果差强人意:

         我之前用lr做了一下游戏自动化,不到一周我就放弃了,后来招了一个lr的新人,我在百般劝说下,他都没放弃游戏lr的自动化测试,结果3天不到,他也放弃了!游戏自动化测试本质目的是提高测试效率,用lr反而降低了测试效率,那么我们还用lr来干什么呢?这里我也不多说原因了,到后面我会提一下另一种方法的,主要说另一种方法的优势,而这种方法的优势恰好是这些工具的劣势。

    2.几乎所有的游戏在前期架构设计上就没考虑到游戏自动化测试的需求,所以在游戏后期介入自动化测试几乎是不现实的。

    3.公司没有足够的人力物力,或者说项目组就没有意识到自动化测试的意义,所以也无法开展。

    4.测试自身的能力,很多(现在不是几乎了,有的游戏公司的测试还是很nb的)测试自身能力不足,或者接触不到游戏代码或其他需求无法满足,导致无法进行自动化测试。

     

    预告以下:胡侃游戏自动化测试(二) 主要说说游戏自动化测试对游戏架构设计的需求

  • [论坛] 测试阶段总结

    2007-08-30 15:23:04

      最近公司的进度很紧,产品修改也比较频繁.这段时间一直忙于测试,看着每天的Bug不断的增加和修正,真是痛并快乐着,痛苦是因为Bug旧的去了,新的又来!快乐是看着Bug逐步减少,把这些天的工作总结一下。

    1、测试要参与到开发过程中去
      这款游戏已经持续开发3年多时间了,n次跳票,终于看到一点希望了.为了进一步完善游戏,这阶段任务繁忙和人手不足,因此测试一直拖后,因此当进行集中测试的时候才发现问题集中爆发,然而项目时间却越来越进.因此感觉更加的繁忙,于是又去催促开发尽快修正.但是由于前期的过程就没有经过充分验证,导致修复bug的时候产生恶性循环,旧的去了,新的来了.一切都变的不可控起来.因为你永远不知道接下来会有什么问题出现.另外由于很多功能和修订,都是早期积累下来的,已经搁置了很长的时间,而且由于真个项目不规范,导致开发员再次进入修改的时候,往往需要花费大量的学习成本,造成Bug的修复周期延长了很多或引起更多的新问题。

      建议当准备新的调整的时候后,测试人员要充分参与进去,明确共同的目标,降低因为沟通不当引起的不必要的成本.

    2、缺陷管理工具要体现出他的作用

      公司只是使用一个BM(一个bug管理工具,原名Bug Manager),作为缺陷的跟踪和管理工具,但是,效果很不理想.虽然部门制定制度,但是却没有人推动制度的执行,反馈问题有的同事就直接口头交流,有的邮件,有的BM
    导致各组独立为战,其实项目组从来都不清楚目前项目质量情况,只知道目前这个进入了测试,那个功能也进入了测试,但是质量呢?所以项目组永远无法根据目前游戏的质量来做出决策.

    3、测试要有计划,有步骤的进行

        由于项目时间很紧,为了确保能按时完成工作进度,有的小组就将测试过程也给简化了.什么测试分析,什么测试计划,全都见鬼去吧!当测试人员最后发测试结果的时候,大家都兴奋了好一阵子:哇,0bug!难道是因为时间紧,项目质量迅速提高!经验告诉我,这不正常,当版本发布以后,噩梦开始了,今天客服说这个有问题,明天又出了那个能刷东西的问题.直到项目组忍无可忍.....

        后来通过分析,才发现为了赶时间,没有任何准备,就直接执行测试,导致测试非常盲目,没有目标,没有重点.该测的点都没有覆盖到.更不要说风险评估了!

        所以:三思而后行,一定要有目的,有计划,按步骤的工作,当然,视具体情况可以适当调整.

    4.测试不要对项目进度负责

        测试部门又可以说是质量部门,项目进度依赖于产品质量,项目进度应该根据质量情况而调整,而不是因为项目进度,对质量标准进行调整.在这次改版过程中,这个问题体现得尤为突出.为了版本计划,粗暴的压缩测试时间,导致最后版本放出去后,玩家怨声载道.....

        我们的职责是:发现问题,督促问题解决!是为了证明产品是有问题的,而不是为了证明产品是正确的,进度以来质量,而不是质量依赖进度.

    5、开发和测试最好不同步

      游戏的核心系统,家族系统开发量大,测试压力也大.当时为了争取时间,开发和测试全部留下来加班,开发写完测试进行测试,然后开发等着,等发现问题了,开发又修改,测试又等着,如此循环,结果第二天整个功能组没有一个清醒的人来上班.而其他系统又严重依赖这个系统,导致整个游戏因为家族系统无法开展工作,项目严重delay.

       建议:合理安排开发和测试时间,最好不要撞车.


    6、交叉测试的重要性

      我们最初安排测试的时候,是某个测试人员只测试其中一个功能,另外的测试人员测试另一功能,过了几天后发现,每个测试人员的Bug检测数量都下降了,原来,测试人员对自己部分已经发现不出来缺陷了,后来采用了交叉测试的方式,就是测试人员交换测试工作,结果不同的人从不同的角度进行测试,结果一些缺陷又发现了,因此交叉测试很重要。

    7、测试需要不断调整测试方法

       测试对象都具有免疫能力.一般来说,随着测试工作的进行,bug会越来越少,但是千万不要以为就没有bug了.要永远记住,没有bug的软件是不存在的.这个时候需要调整测试方法和策略.这个过程中,经验就体现出他的价值来了.如果你有经验当然好,但是如果是新手的话,就需要多想别人请教,交流.不断的调整测试的策略、流程,多总结和借鉴别人的测试经验,会更好的提高测试质量。

    8.沟通和熟悉业务.

        和开发人员的沟通很重要.你必须要很熟悉业务对象,否则你很难和开发人员沟通.无法沟通就无法开展工作.到最后最严重的情况可能是:你反馈一个问题,开发人员看都不看就回给你说不是问题.....因为你不熟悉业务对象,开发人员已经对你失去了信任.

Open Toolbar