我自己认识的游戏测试

飘渺的风

做了1年的游戏测试，我的游戏测试主要集中在了脚本检查和功能验证

     测试按阶段分第一当然是需求分析，在游戏里需求就是策划提供的策划案，策划的想法全部在策划案中能体现出来，一个好的策划案能完整的体现出策划的要求，游戏中的模块功能会在策划案中完全体现。分析，是要求从测试的角度去看文档，策划给出了流程和数据不一定是正确的，程序是否能实现也是得考虑的，策划案中的内容是否和已经存在的内容有冲突。
   
     用例设计，用例的设计是建立在对策划案分析的基础上的~！我不知道别人怎么设计用例的，我把以前的行业软件测试用例做了稍微的更改，用例中只列出需要测试时注意的测试点，针对测试点来设计测试用例，而一个个的测试点，就又是行业软件中的一些控件的测试用例类似，如：文本框，按钮，连接，滚动条等等。

    通过测试（冒烟测试），当程序提供游戏服务器后，首先得确认这个游戏服务器以及客户端更新是正确的，是可以稳定运行的。下来需要对被测试的模块做一次试运行，说白了就是按照策划的要求，一点不错的执行一次。当这次过程没有错误的时候，才能开始执行我们前面编写的测试用例。

    用例执行与BUG提交，游戏过程中可能会出现一系列的问题，或者会出现一些让你不能确定的问题（这样描写可能大家不理解，就是说游戏中策划要求是过程A但程序做成过程B但是最终结果一样）这里需要的是沟通，和程序和策划去沟通，去了解策划是否能够接受这样的效果或者说程序是否能改良代码来尽量满足策划要求。而不是死板的提交一份BUG单了事。

    BUG跟踪，BUG没有大小只有优先级（我是这样认为了，或许不对吧!）任何一个BUG单都必须走向关闭。游戏中的功能错误是不允许的，但是游戏中的细节也很重要，如：任务中的描述内容，就不应该出现错别字，并且任务描述的场景应该和游戏场景结合。

    发布前集成环境测试，在游戏发布前，我们会做一次公司内部参与的试玩活动，看看大家对这个游戏的那些地方还有需要调整的地方。

    之前说了脚本的测试，这里我简单说下，我们使用的是LUA脚本，因为LUA调用的是游戏中的接口函数，所以只能在游戏环境中测试。具体怎么搞参照白盒测试方法。
     
    乱七八糟说了一堆大家别骂啊！

hejuan_xx

游戏测试虽说可以天天玩游戏 刚开始觉得还可以 但时间长了 。。。。
    兴趣就没了 一个月就玩这一个 哎

nicoku

-。-
LZ不是做网络游戏的测试吧？
每周更新两次
每次决定上线前一天的下午才封版给测试环境
连测试用例都没时间写的。。。
郁闷的飘过

skykklove

  好贴再顶一下

jlsv

如果有很明显的文字错误的话， 对于一个玩家来说会怎样想呢？

多碰上几次的话，或者再碰上了其他问题，后果就很可能是失去了这个客户，因为别人觉得连这么简单的东西都做错， 这个游戏也不会有多好，更不用讲像楼上说的那个问题了。

nawentibao

文字类错误？具体一些来说，是“语言类错误”

可不要小看了，这类测试是很重要的~~~
也许你认为文字类错误只是检查有没有错别字，没有技术可言，一点也不重要。
但无论你功能性测试是多么的完美，如果文字描述、语言修饰没有做好，玩家不能很有效的了解并参加你的功能。
注重这些语言类的错误，是让你更以一颗做产品的心，都做好每一个功能。

这一点我深深体会，之前我负责测的一个活动，需要打NPC产品一些道具，文字说是没有写的清晰，没有解释清楚道具的用途、来源、作用、时效等，以致于活动一开始，N多的玩家问的最多的就是这个道具。以致于客服电话此起彼伏，总之，加大的客服的压力，增加了玩家参与活动的难度，也许会有玩家因此而离开游戏。

总之，做好文字指引，提高游戏易用性，做好产品化，以一个颗产品的心去对待任何一个功能。

xuelove

写的还不错~
最近做测试总有些感想，文字类错误真的重要吗？需要和功能测试放在一起这么早测吗？
我觉得测试的目的就是不希望一些潜在的BUG被玩家先发现及使用到而造成玩家的流失，但是又有多少玩家会为了文字类的错误去放弃一个已经开始玩了的游戏呢，10万玩家里有10个？在我看来1个都不会（单纯的自我认为）
只要文字类错误不影游戏响正常的功能，不影响玩家玩游戏正常的流程（任务解释之类的），我觉得完全可以在所有测试结束后再去做，因为测他只不过为了加大测试的覆盖率而已，没什么实际的用途
好多问题都让人好迷茫~好想想通又无从下手…………

skykklove

谢谢分享