bug总数过1000

发布新日志

  • 从他人身上学习到的

    2010-12-22 20:24:17

            公司策划人员中除了主策划外,质量最高的就是数值策划amin,然后是脚本策划ayi,之后是agu,abo,最后是asheng,虽然到公司不久,但是与个人各类工作的配合中,也逐渐发现个人的长处和短处。

            amin综合能力排第一,不但精通各类游戏,而且对于数值方面有很高的造诣,脚本编写对他来说也是soeasy!做事情的态度方面也无话可说。是难得的一个人才,功能完成后完善度高。ayi,脚本方面应用的很熟练,对于游戏的理解力,以及把控能力上稍逊于amin。设计方案时偶尔会带有个人习惯,偶尔性格执拗点。但是和各方的协调能力还不错,尤其是编写脚本,设计案的完善程度,细节处置还不错。agu是个喜欢钻研游戏方案的人,在各类功能的设计上总是有自己的理解,但是功能设计案的条理性有待加强,另外做事情的态度上,不是向以上两位那样会有精益求精的追求。所以基本上功能的细节方面值得商讨的地方很多。abo是个不错的新手,做事情很认真,目前不足是,设计方案的编写上。对于功能和要达到的目标把握的不是很清晰。但是作为新手已经很不错了。

           我应该向以上各位学习的,amin做事情考虑要全面,ayi脚本编写能力,agu对游戏的钻研心,另外加上他对ps的应用,abo做事的认真程度。团队的气氛比较好,大家的心态也挺好的。

           另外就是项目管理上的一点问题,节点和节点目标不清楚,功能完成度的要求不明确。另外从这几次的设计案未审核就制作,最后导致做出来的效果并不如人意上,这两点还是可以改善的。当然可能为了做些计划和目标是要耗费时间和人力的,同时做用例审核也是耗费时间和人力的,但是只要大的东西时敲定的,大家目标明确,那么最终各自安排的优先级和完成度就能够得到保证。

     

     

  • 游戏副本测试

    2010-12-13 22:43:12

    • 基本流程
      • 副本的开启
        • 参与副本的各类条件
          • 人物(队长,队员,族长族员,帮主,帮众其他条件)
          • 时间
          • 地点
        • 副本次数限制(每日次数)
        • 触发机制(指定的时间开启,指定的道具开启,指定的人开启等)
      • 副本流程
        • 副本内的各类操作
          • 允许的
          • 不允许的——返回的提示
            • PK限制——不允许PK
            • 组队限制——不允许组队,系统自动组队
            • 使用道具限制——不能使用传送符
          • 阵营判断
          • 死亡复活判断
          • 离线处理
        • npc与player对战
        • player与player对战
        • 其他形式——答题,竞猜,过关
      • 副本的关闭
        • npc与player对战
          • 关卡难度
          • 关卡形式
        • player对战类型副本
          • 以胜负判定 
          • 以时间判定(未决出胜负时判定)
      • 奖励
        • 副本过程中的直接奖励
        • 副本结束时结算的奖励
  • 游戏界面验收

    2010-07-30 11:13:36

  • 离职——思考

    2010-02-23 12:00:31

            今天办完手续就正式离职了,心里空空的,这是第一份工作,希望不是最后一份。测试这个行业自己还是很喜欢的,不管别人认为测试的技术含量不高,还是测试的薪酬低。都不能动摇我对这个工作的热爱。它曾让我感到自己的价值,让我感受到充实、快乐。所以我爱测试。

            短暂离开,还是会思考和关注。毕竟还未达成自己的目标。

            希望我谨记自己最初的梦想,在自己能够做的范围内,不断的进步。

  • 软件测试的目的以及ALAC中的Pareto 80/20原则

    2007-09-09 22:28:54

    软件测试是为了尽快、尽早的将软件产品或软件系统中存在的问题找出来,并促使程序员尽快解决问题,最终及时的向客户提供高质量的软件产品。零缺陷(Zero bug)是一种理想,足够好(good-enough)是测试的原则。

    ALAC,是act-like-a-customer的简写。基于客户使用产品的知识开发出来的测试方法。它的出发点是著名的80-20原则。用到软件测试中可以概括为两条:

    • 一个软件产品或系统中全部功能的20%是常用功能,用户的80%的时间都是在使用这20%的功能,而软件产品或系统中剩下的80%的功能不是经常使用的功能,用户使用的比较少,只有20%时间在使用剩下的80%的功能。
    • 测试发现的所有错误的80%很可能都集中在这20%的程序模块中,另外20%的错误很可能集中在80%的程序模块中。
  • 前段时间所学所用

    2007-04-14 10:28:07

        主要学习python语言,进行一些简单的统计工作.因为项目接近尾声,所以前段时间比较闲,就跟着自己的师傅(自己拜的程序的师傅)学习了python的一些基础知识,后来也编了几个短小的程序,这些程序都是用来搜索整理文件用的.开发库里面东西很多,但是从来都没有系统的说明和整理,我负责的几个功能文件特别杂乱,每次出现bug查找起来都是相当的困难,主要是看代码的名称又不知道到底是作什么,师傅他自己写的东西回头来看都不晓得写什么了.因为这个所以我就专门学了下整理了一些文件,以便后面修改时方便查找,另外如果新人接手的话也很快就能熟悉.才来公司的时候,看着一堆文件都不晓得干什么用,带我的测试师傅,忙的不可开交,只是文件我用到了才会去问.基于这一点才整理这些东西的.另外部门里面文挡,案例的管理不是很规范,几个交流平台造成了很多东西找来找去的现象.特别是测试案例,我们有用WIKI和VSS,有时候干脆发信.汗!老大好象也看到了这一点,前段时间派另外个老员工去其他分工司学习案例去了,估计回来就要全面整理,规划到一个平台了.

        自己现在案例覆盖面上面已经有了很大的进步,按照案例执行后的功能出bug的几率都比较小.很多时候写完了我都是要让策划,程序,测试内部看一下,目前做案例评审没有标准,案例都没有规范的格式,所以很少开展.大家交流的时候都会用邮件告之我案例哪些地方有出处.然后我修改后再次发信.策划案有很多不全的地方,我制作案例的过程中也会给策划提出若干疑问,觉得这个是必要的.不是说测试就只管测,如果没有判断策划案正确与否合理与否的能力,估计就只有等到功能做出来,测试过程中才发现了.那个时候再提过去让修改,很多时候可能都存在直接将策划案推翻的情况,这来回之间浪费了多少人力物力,然后开发的时间也跟着浪费了.

       总之功能测试方面案例的学习就告一段落.后面就要开展配置管理的学习.多学习了解一下总是会有好处的.

Open Toolbar