|
从测试的角度看：一个游戏的死亡 在进入互联网游戏行业以前是做制造业的质量信息系统，后来进入互联网游戏行业，开始担任游戏测试的职位。游戏测试，按照我个人的理解应该是对游戏质量的保证工作。测试不仅仅是挑错，而是再挑错的时候发现问题原因去帮助游戏研发这些前端去优化、减少犯错的几率。 参与的第一款游戏叫《QQ仙境》，这款游戏在2013年6月6日的时候已经停运了。其实早在2013年以前已经退出这款游戏的测试工作，因为整个测试组都发现这款游戏已经进入死亡期了。现在分析下这个游戏是怎么死的。 1.研发测试周期过长 早在公司于2008年就签订了这款韩国游戏的中国代理，相关资料在2008年已经开始往来。在我2010年8月进入这个游戏项目的时候，封测也进行了3次。按照生命周期和流程后面还有删档内测，不删档测试，公测这几个阶段。每阶段按照测试结果可能还有几次测试，如删档内测1、2、3这样的。按照之前的项目阶段时间，等公测阶段也要2年以后，整个游戏面向游戏玩家的测试就持续了4年，就算是端游这个时间也太长，测试次数也太多了。后来的实际情况也符合预计结果。 2.游戏版本反复 需要如此多的玩家测试，也有其内在原因，就是游戏背景和画面、UI布局等基本设定经过多个版本的大变化，每次变化都需要通过玩家测试验证市场接受程度。但是游戏本身的可消耗内容却没有对应的大变化。在封测阶段已经将角色等级上限开放到60级，但是在后续的内测版本中又改成45级上限，调整故事背景并将UI布局等翻新，新手引导和部分主线重做，让玩家对游戏的认知发生过大变化。 测试过程中对于需要回归测试的BUG和内容，出现策划需求变更、开发实现方式变更、内容去除等理由关闭。但是实际问题代码和功能并未完全，只是埋藏的更深了。 3.研发团队时常大换血 处于中国的测试组对于韩国的研发团队了解程度不是深，但是从游戏内容和脚本等渠道发现开发人员是经常有变化的。通过内部交流也确认了，韩方的制作人也换过一次，带来结果就是游戏全部UI重做。 对于测试遇到的问题就是，新的开发人员对于老开发人员留下的代码并不能马上熟练掌握，重复开发已有功能点产生冗余的代码，已修复的问题复现，低级BUG出现率增高。甚至出现同一个任务脚本ID对应新旧多个不同的任务，和预计取消的旧任务因害怕出现严重问题而保留等现象。 4.开发效率低 开发效率低指的是：（1）新增内容可消耗时间短（2）提交测试版本质量过低无法正常测试（3）运营和优化游戏性能等开发需求进度缓慢 （1）由于是代理项目，新内容的研发工作主要都是由韩国开发商负责。在频繁重做已有内容的情况下，新增内容相对也较少，内容可消耗时间也短。在根据变更内容做功能测试时候，新增测试内容变少。 （2）软件开发模式中有迭代模式，前提是迭代的部分是完整实现可测试的。但是如果迭代版本内容出现启动就崩溃等无法正常测试情况，返回开发验证、修复、重新提交、搭建测试环境这一个流程又花费更多时间，这种开发效率就变低了。 （3）在做游戏性能、网络通讯等专项测试后，每次优化结果都不明显。对于运营工具测试出现工具功能无效和工具工作效率低等现象。 5.游戏安全性低 安全性：（1）客户端/服务器通讯协议加密验证不完整，甚至出现明码，发送错误数据包能导致服务器宕机（2）反外挂能力低，通过直接修改内存等方式可以改变游戏客户端数值且服务器端无验证手段 其实从上面这些现象可以发现其实互相影响的，不稳定的团队导致开发低效问题多，拖慢游戏进度让测试阶段过长，反复修改已有内容和过长的测试阶段无收益让开发团队看不到希望开始流失或换人。 陷入恶性循环 从理论上说只要找到问题的原因，问题总能处理。测试的目的也是为了从问题现象找到问题产生的原因，从而去解决它。 按照本身作为运营商的测试团队角色，在如何帮助开发团队提高开发效率和质量入手是可执行性较高的方式。 测试提高开发效率的方法 1.功能测试：缩小问题代码的查找范围。功能测试是黑盒测试，出现问题现象的时候需要按照功能问题逆推代码实现流程和判断点，将可能出现问题的条件点罗列，并反复验证每个条件，尽可能定位到具体流程和判断条件，减少开发人员修复BUG的时间。 2.系统测试：将相同问题原因的现象整理为一个BUG单。在一个功能系统中出现的很多问题现象可能都是同一个原因导致，将同类原因导致的不同问题归正为一个BUG，方便开发人员确定问题和修复后自测。 3.问题改善方案风险分析：在确定问题原因和问题发生过程后，提供有效可行的改善方案，并将方案实现的难点和风险罗列，让开发人员自己参考选择。避免开发人员采取不可知的实现方法出现不可掌控的风险。 这些方法其实都是逆推、事倍功半的方法，毕竟游戏项目的进度由项目经理负责、开发实现由程序负责、玩法功能内容设计由策划负责、画面UI由美术负责、整体方向由制作人负责。测试发现问题也很难推动问题改善，代理游戏尤其明显。 在个人经验看来，一个健康的游戏项目在研发阶段，不管何种开发模式，都应该是有计划和节奏的。每个次迭代，每个功能瀑布后，每个敏捷版本，都有成果。或修复BUG，或提高性能，或改善安全性。过多的突发状况和临时处理方案，让游戏项目埋下病根，在不断损耗生命之后，就算有治病良药，也因为身体过于虚弱导致被过猛的药性提前死亡。 | 
发表于 2013-11-10 09:53:43
