想要一套完整的游戏测试用例_百度知道
想要一套完整的游戏测试用例
您的回答被采纳后将获得：
系统奖励20（财富值+经验值）+难题奖励10（财富值+经验值）+提问者悬赏5（财富值+经验值）测试用例是否应该包含所有的细节?_测试用例_领测软件测试网
测试用例是否应该包含所有的细节?
发表于：来源：作者：超越自我点击数：
测试用例写的太细化了，则适应不了系统的变更需求;写的太粗糙，则可操作性不强，太随意。，如果文档中的对操作步骤描述的过于具体，像下面这样： 01.在“用户名”项中输
　　写的太细化了，则适应不了系统的变更;写的太粗糙，则可操作性不强，太随意。，如果文档中的对操作步骤描述的过于具体，像下面这样：
　　01.在&用户名&项中输入&user&;
　　02.在&密码&项中输入&password&;
　　03.点击&确定&按钮。
　　这样的描述方式表面看起来可操作性似乎是增强了，任何人拿到这个文档都可以充当，检查一下这个功能是否存在。但是我们不要忘记，在过程中，变更的存在是必然的。一旦需求、设计或者应用程序中的某些细节发生了变化，比如&用户名&变成了&操作员&，&密码&变成了&口令&，&确定&变成了 &登录&，或者输入项所接受的数据类型发生了变化，那么同这部分内容相关的所有的都需要修改。否则，我们凭什么可以保证这些描述不同的说的是同一样东西?如果我们只有这么一个测试用例，也许一切都不是问题，但是对于一个业务复杂、功能完整的系统，如果按照这样的方法描述测试用例，最终要么产生大量的测试用例文档，要么产生过长的单个文档。无论是那一种，如果发生了类似于上面说的变化，维护文档都将变成一次地狱式的体验。这也是为什么在网络上频频出现的这个问题，而且每次出现都会受到测试同行们的关注的原因。
　　那么这个问题应该任何解决呢?测试用例是不是把所有的流程写出来就可以了呢?如何在减少测试用例文档中包含过多琐碎的细节的同时保证测试用例的可操作性呢?又有什么方法可以提高我们维护测试用例文档的效率呢?笔者的建议是：关注&测试思想&而不是关注操作步骤。要理解这个问题，首先要弄明白测试用例的作用。就像用例一样，测试用例并不是用来描述具体的实现的，而是着重描述处理问题的思路&&对于一项明确的测试内容进行测试的思路。作为测试用例的设计人员，如何理解基本流和备选流?如何深入分析并找到所有需要覆盖的路径和需要检查的特性?我们在测试用例中应该用容易理解的自然语言清晰的来描述我们将要如何进行测试，而不是简单的把在应用程序上如何操作的烦琐的步骤记录下来。把测试用例设计当成填写具体操作步骤的表格是人们对测试用例最大的误解。传统的测试用例文档编写有两种方式。一种是填写操作步骤列表：将在软件上进行的操作步骤一步一步详细的记录下来，包括所有被操作的项目和相应的值。另一种是填写测试矩阵：将被操作项作为矩阵中的一个字段，而矩阵中的一条条记录，则是这些字段的值。网络上对于这两种方式孰优孰劣的争论，将大家错误的引导向了两个极端：要么采用A，要么采用B。而大家却忽视了一点，对于工作方法的争论，本质上同工具的争论并不是一回事(例如曾经的VC、BCB之挣)。如果不同的方法各有优势，我们完全可以通过变通的方法，把优势的部分组合在一起来使用。操作步骤列表的优势在于对基本流和备选流进行分析后，它可以清晰的描述您的测试思路。而测试矩阵则更适合于用来存放测试数据，特别是那些需要人工赋予一个确定的值的特性。下面，我们来看一个例子，当然，这个例子同样是杜撰的。?需求名称：用户登录验证需求描述：用户登录验证是为了保证所有登录到系统中的用户，都是由系统管理员预先在系统中设定的。使用系统中不存在的用户名，或者用户名输入正确，但密码输入错误情况，都无法登录到系统中。当用户使用了不存在的用户名或错误的密码时，系统应分别给出适当的提示。如果用户连续三次无法使用正确的用户名和密码登录到系统，则系统应给出适当的提示，并退出当前程序。如果用户使用正确的用户名和密码登录到系统，则退出界面，转到系统主界面。对于用户登录界面和程序主界面，请参考相应的UI设计文档。
　　测试需求：
　　01.　检查能否使用正确的用户名和密码登录到系统;
　　02.　检查能否使用错误的用户名或密码登录到系统;
　　03.　检查使用错误的用户名和密码登录失败超过三次，是否会自动退出当前程序。
　　测试用例：
操作过程描述
输入用户名。
输入密码。
确认登录。
原文转自：
评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）前段时间参与了Flash游戏的功能测试，发现游戏测试的内容比较的繁多，因此总结一下测试用例的编写思路，便于以后能快速进行同类游戏的用例设计。
所测试的Flash游戏类似&雪地漂移上百层&这款游戏，先简介一下这款游戏的需求：这是一款考验快速反应的益智游戏，游戏的过程就是通过控制角色在空中左右平移吃掉屏幕中的上升道具来保证自己一直向上升，如果角色速度减到0然后滞空掉落，将显示角色所达到的最大高度以及得分。
1）首先是游戏初始界面
2）随后进入道具说明界面
3）游戏开始先滑入跑道获取起飞初速度
4）游戏当中左右平移操作
5）挑战失败后的成绩统计
游戏的安装、卸载、升级的功能不划为本次功能测试的讨论内容。
此款游戏的需求不算太复杂，既没有多种模式的选择（水果忍者游戏），也没有多种关卡设计（祖玛游戏），在测试时偏重操作性及数据正确性。进行功能测试用例编写之前，首先进行测试用例设计：
『首先是基本功能的验证』
测试用例首先应该对基本功能进行覆盖，基本功能就是能保证玩家能够进行一个完整的流程操作，即启动&开始&退出三个基本步骤，然后再根据每一步进行测试项分解：
每个测试项有相应的测试点，比如游戏启动测试项，其测试点根据图标、显示方式、启动时间、按键操作分类后进行测试内容细化：
其他的测试点的细则不一一列举，根据游戏中的实际情况进行细化。
『每个界面的测试』
&&&&&&&& 基本功能虽然能保证游戏的操作流程正常，但对于游戏内容的正确性是无法保证的，界面也是玩家在体验过程中会关注的内容，因此对于游戏内容的检查首先应该根据各个界面进行下手，其中每个界面的跳转路径测试，也保证除基本流程之外的分支流程能够正确，其测试项有：
『游戏元素的细分』
界面只是游戏内容的一小部分，实际上游戏内容远不止繁多的界面，通常还有角色人物、道具、音效、成绩、奖惩规则等元素。此款游戏没有生命值的需求，所以奖惩规则没有在测试设计中考虑，根据游戏元素整理的测试项如下：
『占用资源的关注』
游戏的资源占用也属于功能测试的重要内容，测试结果需要在测试报告中记录，通常都是记录游戏的CPU占用及内存消耗，需要注意的是这两项数值都是实时变化的，因此需要记录的数据需要进行筛选，选择重要的初始值和峰值进行记录。
如何才能得到这两类数据的峰值？这需要设计合理的测试场景：1）CPU占用理论上是游戏线程越多，读写数据操作越频繁，则CPU占用的数值就越高，因此CPU占用的峰值测试场景为玩家操作频繁的界面中。2）内存消耗则是根据游戏在运行时加载的资源多少来决定的，因此理论上玩家玩的时间越长，加载的界面、元素越多，内存的消耗就越大，因此峰值的测试场景需要尽量遍历所有界面、接触到所有道具，测试时间也需要在4个小时以上。
『异常场景设计』
异常场景的是对测试用例覆盖率最有效的补充，往往最容易暴露问题的就是异常的操作或环境。用例的设计需要考虑游戏与系统如何进行数据交互、游戏采用框架以及哪些数据需要跟其他软件进行传递的。
测试的Flash游戏运行在Linux环境，与底层系统的交互涉及到操作数据和玩家成绩：操作数据（角色在游戏中的左右移动）是通过pipe管道与底层系统进行交互，玩家成绩（最高高度和最大得分）的则是通过scroe.xml文件进行保存。因此异常场景的测试项有：
此款游戏的测试用例设计思路已经基本完成，然后就需要对每个测试项进行测试点的细化，最后执行测试进行功能验证了。
，在完成游戏功能测试之后，应该在公司内部或现网试运行阶段进行游戏体验，收集和筛选反馈建议，查看游戏哪些内容需要丰富以增加用户粘度、是否存在捷径可以刻意降低游戏难度、哪些元素缺少吸引需要去掉等。游戏不像商业软件，有特定的用户和明确的需求，游戏应该注重用户粘性，这样就需要考虑用户体验、游戏平衡、玩家成就感等内容，因此测试时也需要重点考虑这些。
阅读(...) 评论()什么样的测试用例是好的测试用例
- 游戏策划 - 云世界日志
当前位置：
&&>&&&&>&&&&>&&正文
什么样的测试用例是好的测试用例
20:20:43&&&&
评论(0)&&&&
阅读(1168)
　　1、用例覆盖程度
　　毫无疑问，这一点应该是最重要的，无需多说，覆盖率最大化是一套测试用例的最重要评价标准，如果漏测就杯具了。
　　2、用例是否已经达到工作量最小化
　　在满足用例覆盖程度最大化的前提下，应该尽量减小执行用例所需要的工作量。这些方面的方法有不少，如条件覆盖，分支覆盖，正交覆盖等方法。面对不同的测试对象，也有不同的方法来保证：对于网页背后的php逻辑，可以通过在网页上测试后，用一些工具比如xdebug来统计代码覆盖率;对于向外提供接口的server，采用的方式就是分析在外面暴露的接口设计用例，大致的通过接口参数来估计一下分支判断的情况。
　　3、用例的分类以及描述是否足够清晰
　　用例的分类，在这里是指相同类型的用例是否放在一起了。例如：接口类的用例，参数的取值范围是1-3，但是现在却传入4;数据类用例，状态机现在位于状态2，却要求状态跳转到无法到达的4;逻辑类用例，正常功能的产出等。将相同类型的用例放在一起，有助于理清思路，清楚了解用例设计是否完备。
　　用例的描述，是指描述的清晰程度是否能够形成文档。例如上面参数取值范围的例子，用例这样写：“传入错误的值”或者“传入非1-3的值”，明显没有写成“传入值4”有效。这与写程序一样，总是写闭区间的范围而不是开区间。
　　4、用例是否表明了测试目的
　　写明用例的测试目的，对文档的易于理解性和工作交接的好处不言而喻，现代软件工程不可能只有一个人在做事情，项目于人员的变动也是难免的。在过程中留下足够的信息，可以在后续工作提高很多效率。
　　5、测试用例的易于维护性
　　如果被测对象有所升级，测试用例的说明或者脚本是不是容易维护呢?例如在有状态机的情况下，测试用例之间是相互依赖的(即需要一定的执行顺序)，这样被依赖的用例修改后，后端不需要同步根据修改。而如果用例之间没有相互依赖关系(如用例是自己造的数据，不是依赖于前端的产出)，可能一旦有变化，就需要修改这两个。当然，这两种情况不能绝对的说哪种好，是需要看实际使用时候的情况进行取舍的。不过，通过一些系统性的工具支持，也会出现一种做法绝对性的好于另外一种的情况，情况很多，做法也有很多，在这里就不多说了。
游戏策划相关文章中国测试平台会员登录
一个菜鸟半年的游戏测试的工作心得
　　看了不少论坛，发现没有多少介绍游戏测试的。或许游戏测试这个职位并不受到广大群众的认可吧。小弟作为新进游戏测试半年的弱鸡，在这里抛砖引玉。请各位大神轻喷。在这里向大家介绍一下，游戏测试的基础，和我的一些心得体会。
　　了解测试基础之前，我们先来看看什么是游戏测试以及游戏测试的基本技能。
　　什么是游戏测试
　　有人把我们当成游戏体验员。也有人认为我们就是GM，是游戏里的托。也有人觉得我们一天到晚玩游戏还能拿工资，是件美差。其中的辛酸，也只有我们自己知道。做了半年的测试。我所认知的测试，就是保证产品质量。或者说保证游戏的质量。那么从哪几个方面保证呢？首先就是功能，兼容，性能。其次游戏的可玩性，是否易上手，都是我们需要考虑的。我们不仅要对游戏进行测试，保证它的功能。更要对游戏提出建议，来保证它的可玩性。
　　游戏测试的基本技能
　　一款游戏，首先，它得是一款软件，所以软测得一些技能我们也是需要了解的(测试方法、测试用例的设计方法)。
　　1)热爱游戏，玩过游戏。
　　首先你得喜欢游戏，玩过较多的游戏，才能快速的上手。了解游戏的机制，以及发现游戏中不合理的地方。当然，这个不合理也仅仅是对你个人而讲。
　　2)有相应的计算机基础
　　这个就不详细解释了。一个搞IT的连这都不会，也就呵呵了吧。
　　3)逻辑思维
　　有助于编写用例，进行测试工作。较强的逻辑思维，能够保证用力的覆盖率，最大程度上减少漏测。
　　如果只是做初级执行的话。其实有以上三点。基本就可以了。随着我们工作的深入，我们掌握的也会越来越多。
　　4)数据库
　　数据库的操作也算是基本的了。查看用户数据什么的，学会这个用起来还是蛮方便的，再也不用腆着脸去求开发了。
　　5)脚本语言
　　掌握一门语言总是好的。服务器性能什么的都会用到。我们都会有自己写脚本的那天。
　　6)Linux
　　我们终归是要要去做性能的。了解相应的Linux的知识，可以帮助我们做好性能，更能让我们看到服务器日志，一些常规的操作。报错。可以更加轻松的定位问题。
　　7)肯做事
　　这是最重要的一点。就算是才高八斗，学富五车。不做事，也是没用的。一定要肯做事，然后才是会做事。公司招人，最重要的是要你来做事。说句直白的话，前面技能要求一大堆，可是我招你进来，就是想你做事。不会的，咱可以学，公司可以培养。可是不做，就没办法了。
　　以上只是我的个人观点。游戏测试与基本技能说完了。我们看看现在国内游戏市场，测试的现状(大部分情况下)。
　　网游测试现状
　　1)缺少时间
　　测试团队介入较晚(代理游戏介入更晚)，很多都是策划和程
　　序已经实现了游戏的大部分基础功能后才开始组织测试，编写测试用
　　例的时间极为稀少。
　　解决方案：
　　我以为，在没有充足的时间去写用例的情况下。我们还是很有必要拆分一下测试点，做一个checklist。如果什么都没有的话，就会导致，我们重复的做无用功。没有逻辑，没有目的。
　　2)维护困难
　　网络游戏内容变动频繁，变动量大，随之而来的测试用例变动
　　也会频繁和巨大，因此许多团队放弃制作和更新测试用例。
　　解决方案：
　　时间充足的情况下还是更新维护的要好。毕竟用例是测试开展工作的核心。现在很多团队都在走敏捷开发的路线，人手不足的情况下还是做个checklist吧。
　　3)急于发现Bug
　　测试用例需要长期制作和维护才可体现其作用，而目前大多数
　　测试团队都急于找到Bug，当执行完一遍测试用例后发现没有多少新
　　Bug，从而开始怠慢测试用例的制作不更新。
　　解决方案：
　　这种情况我也遇到过。切忌心急。如果没有发现BUG，就仔细阅读需求，挖掘隐藏需求。累了就去休息休息。发散一下思维。
　　4)缺乏与业知识
　　不可否认的，目前游戏测试从业人员与业知识不够丰富，对于
　　测试用例的制作方法了解甚少。
　　解决方案：
　　这个是没办法的事。随着游戏测试人员需求量的增加，测试人员的门槛也越来越低。只能说，多做，多练，给予适当的培训。
　　测试准备期，怎么确定测试需要的工具，技术
　　1)首先，我们要提升自己的高度，以项目经理或者测试经理的角度来看这个问题。不能单纯的以测试的角度来看这个问题。如果单纯的以测试的角度看待这个问题，那么这个问题没有答案。
　　2)通过需求及技术的评审，来确定，测试需要的软硬件设备。包括，PC机，操作系统，所需软件，用例编写工具，BUG管理工具。
　　3)技术则需要测试通过与开发人员进行沟通，了解他们的开发语言。对于新人来讲，不做白盒和自动化的话，就主要了解一下实现逻辑，能够读懂代码是最好了。
　　4)对于新人来讲，性能不会那么快接触到。我到现在也只是初步接触到性能。服务端的性能需要写脚本去测试(我不太懂，不做深入解析)，客户端的性能就是查看流量，电量，CPU，内存等等，通过纵横对比的方式，来提出相应的优化方案。
　　关于测试的数据分析
　　提升自己的眼光。了解整个游戏的系统，清楚产品需求，知道开发工作情况为前提。从当前版本已知BUG，进行分析归类。通过分析BUG的分布及易发点，去了解到技术的薄弱点(易忽略点)，再和相关人员进行沟通，避免出现重复性BUG。对开发也是一种技术上的提升。
　　关于游戏与机型的适配。
　　关于适配这个问题。适配机型，一般在立项的时候就会确定下来。当然也有研发完成后，在根据实际情况来确定适配机型的。那么我们再来说说，RAM ROM CPU 分辨率 这些配置对游戏的影响。分辨率，一般都是界面显示的问题，UI，特效，动画。而RAM ROM CPU，则会影响到客户端性能，比如游戏卡，崩溃。所以这就要求我们需要在不同的机型，操作系统上，进行真机测试。
　　当然，我们这里讲的机型适配也可以叫做兼容性。机型适配只适合手游，那么页游，端游的兼容，就需要更换不同的浏览器，不同配置的机器，不同的操作系统。进行多次，重复的测试。
　　功能测试(functional test)
　　我做了半年的测试。接触到的也就是功能测试。兼容测试。客户端的性能也做过一些。兼容，我们上面已经讲过了。接下来我们讲讲功能。
　　刚进公司的时候，入手测试一个游戏。那个时候，策划是没有案子的。这种情况怎么测？整天问，问产品，问项目经理，问策划。有问题就问。曾经有个同学讲，策划没案子，他都是主观的跑的。你主观的跑，你怎么知道，这个功能是否符合策划的需求呢？又要怎么确定Bug呢？所以，没有案子的情况下，我们就要多问。不要觉得烦，也不要怕别人烦。这是你的工作。
　　有案子就不一样了。认真的看需求。不懂得就去问。我有的时候一个案子要看一两天，才开始写用例(虽然我现在用例写的很烂)。不要看过几次案子，就急着去写用例。一定要吃透，不仅要看到需求，更要通过需求，挖掘到隐藏需求，要看的远。看到与之交互的模块是否会有所变动。要考虑到，这个需求，是否存在漏洞，如果我是玩家，玩到这里会怎样。我们不仅要把自己当成测试，我们更是玩家。也需要和策划，和产品提出相应的合理化的建议。
　　当我们一切准备工作做好之后，可以和程序进行适当的沟通。这个功能，它实现的逻辑。这样有助于我们更好的开展测试工作。也能在发现Bug的时候，更准确的定位问题。
　　最后，就是按照用例，跑功能，进行测试了。当然，用例总会有漏掉的地方，有时候我们测试也不会完全按照用例上进行。但是，一定要保证，尽可能的覆盖。
　　测试用例(test case)
　　定义：测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
　　作用：
　　测试用例是为了有效的发现游戏中的缺陷而编写的包涵测试目的，测试步骤，期望测试结果的特定合集。正确认识和设计测试用例可以提高游戏的品质。便于测试质量的度量，增强测试质量的可管理性。
　　特性：
　　1、最有可能发现产品缺陷的
　　2、不是重复的，多余的
　　3、一组相似测试用例中效率最高的
　　4、操作简单，可执行性强
　　依据：
　　1)策划文档
　　2)版本更新文档
　　3)测试计划
　　4)测试方案
　　5)个人习惯
　　测试用例设计原则
　　1、测试用例的代表性：
　　能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
　　2、测试结果的可判定性：
　　即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
　　3、测试结果的可再现性：
　　即对同样的测试用例，系统的执行结果应当是相同的。
　　性能测试
　　性能测试，又分为服务器性能和客户端性能。服务器性能，我没有接触过。在这里就和大家讲讲客户端性能。
　　我们在手机上或者PC上，可以通过工具，或者debug看到，内存占用，耗电量，流量等。这个我们就要进行对比。
　　纵向对比产品之前的各种数据参数，横向对比其他的产品。这样对比，提出合理化的建议。对游戏进行优化。
　　数值测试
　　游戏，除了程序出问题。那么也就剩下策划了。我们不得不承认，做游戏，最坑的其实不是程序，是策划。需求变更，咱就不提了。一大堆的数据表。技能，装备，人物，只要是配的数据表的地方都要测试。
　　技能表，就要对照技能去一一测试。包括技能效果，伤害，人物特效等等。
　　人物，装备这些，就需要对照数据表，按着公式算。
　　不要嫌麻烦，这是必须的。
　　之前我测试过一次，140+的人物，先是算属性，之后算加成，然后逐一测试技能。看到数据表头都是大的。搞了一个周。
　　之上说的也都算很简单的了。只要做了，有点耐心，很快就会上手。
　　接下来我们说说目前兴起的云测。
　　云测试(Cloud Testing)
　　定义：
　　云测试，是基于云计算的一种新型测试方案。服务商提供多种平台，多种浏览器的平台，一般的用户在本地用Selenium把自动化测试脚本编写好，然后上传到他们网站，然后就可以在他们的平台上运行Selenium脚本。
　　之前我有用过testin。说实话，我对这个云测试，并不是太相信。云测上唯一值得欣赏的地方就是兼容，可是看了几次测试的结果的数据。我也表示不太敢相信。当然，我是用的免费的，可能付费的就不太一样。有兴趣的同学，还是可以试试的。
　　前面也讲了那么多。我再说一下怎样做好一个测试吧。
　　(以下纯属个人看法，轻喷)
　　1、首先的是爱好。
　　做了半年，说心里话，刚开始，才从学校出来，就是想混口饭吃，能拿到3K就行，现在我发现我已经喜欢上了这个职业。没错，是喜欢。
　　2、上进心
　　我们不可能做一辈子的黑盒，执行。我们必须要学习，要进步。不进步，则灭亡。
　　3、责任心
　　相信无论是老板，还是上司或者你，都会喜欢一个有担当的人。敢于负责，有责任心。
　　4、肯做事
　　交给你的事，要做，不要推卸，不要拖拉。
　　5、会做事
　　肯做事之后才是会做事。那么怎么才是会做事呢？我举个例子说明一下。在公司，很多情况下会出现。做事做到一半，项目经理或者老大，交给你个东西，去测一下。这个时候，就要搞清楚，事情的轻重缓急。优先处理比较急的。不要因为他是项目经理(老大)，就优先去做他给的任务。当然，若果是随手可以做的，就做一下。
　　6、坚持原则
　　一定要坚持自己的原则。存在重大问题，比如功能未实现，或者存在重大Bug(这个重大情况视具体情况而定)，严重影响用户体验的。一定要坚持，不允许发版本。当然，如果是老板或者项目经理要求放绿灯。那我们就放吧。
　　7、永远不要主观的去做判断。
　　8、永远不要带着情绪去开展你的工作。
　　最后。我再讲一下测试的时候需要注意的点。
　　这个需要注意的点，视具体情况而定。我从我的切身经历出发来谈。
　　1)功能
　　功能是否实现，是最基本的了。但是也要注意，交互的模块是否有变动，是否带来了Bug。
　　我自己的习惯就是，优先测试本次版本更新的东西。包括修复上个版本的Bug以及本次更新。然后发版本之后会把大致的基本流程再过一下。当然，只是刚上线没多久的时候。线上版本稳定之后，我就不会每次都去泡一下流程了。就是看看交互的会产生影响的模块。
　　2)资源配置
　　我们经常会出现数值，技能，骨骼的短缺，造成的BUG。在PC上模拟测试没问题。但是在客户端就会出问题。这种情况经常出现在刚上线的项目里。就像我上面讲的，尽可能的去跑。比如上次一个项目，更新后，半个小时内，很多玩家反应会卡死。可是我们在模拟器上怎么都发现不了。用手机试过之后，发现是少了一个骨骼。
　　3)消耗/获得
　　各种资源的消耗/获得，无论对于玩家还是我们来讲，这个点都是相当重要的。
　　我遇到过几个问题。
　　后端程序的请求没有即时的推送，导致前端不会即时刷新。这就会导致，我无论消耗还是获得，我的东西看起来就感觉没有减少/增加。
　　数据表更换，但是拿的还是之前的旧的表，就会出现，报错或者消耗/获得的不正确。
　　以上的三个问题，是我经常遇到的问题。这些问题多和程序沟通，就会了解到他们容易忽略的地方。测试的时候会有所针对。
　　第一次经历项目上线的时候很紧张，各种担心，漏测，出问题怎么办。在这里和新人讲一下，发版本后，无论出现什么问题，有多严重。第一时间，不要去自责，先去联系相关工作人员。赶快解决问题才是最重要的。以最快的速度解决问题，给予玩家相应的补偿。最大程度上减少损失。
　　总之。多和策划和程序沟通。不仅仅有利于自己的工作。也可以了解到他们的不足。会使自己更快的成长。
　　多做，多看，多学，多问。
　　愿与大家共同成长。
你可能喜欢的