相信绝大部分游戏产品都存在线上bug带来的苦恼。毫无疑问，bug对产品的危害很大，轻则导致流程中断，大量玩家流失，重则导致玩家被刷钱刷物品，严重影响产品的生命周期。可以说测试早已经是游戏研发过程中极为关键的一环，从需求到开发、测试再到线上，全流程几乎都能见到测试人员的身影。
我们在游戏测试上经过了十余年的不断沉淀，经受了倩女、逆水寒、天谕等多个大型MMORPG的整体研发过程的历练，期间踩过了无数的深坑，逐渐在自动测试、性能测试、白盒测试、功能测试、数值测试、工具平台开发等方面均积累了一定的经验。
借此机会，我们会在知乎上陆续推出相关主题的分享，例如如何建立自动化测试体系，怎么做到数值的正确性与合理性，白盒测试需要注意哪些事项，PVPPVE等模块的无数经典案例复盘，以及在保障产品质量的同时以什么样的形式来提升测试效率等等，敬请期待！
本篇文章将主要聊一聊针对玩家反馈的属性和技能异常问题，我们在进行分析和挖掘上所做的工作，帮助没有接触过战斗数值测试的同学简单理解战斗数值系统的构成，并提供一些属性和技能异常问题分析挖掘的思路。
假如你是一款线上运营中的游戏QA，设想某一天运维找到你反馈了以下几个问题：
1. 某顶尖战力玩家反馈打低战玩家伤害不高，甚至还没有打同战力的玩家的伤害高。
2. 玩家反馈用一个多段效果的技能打一个玩家，上一跳伤害还是1万8，下一跳伤害几乎同时的，却只有1万1，相差过大。
3. 我打别人的伤害怎么这么低，别人打我为什么这么高？
想必各类涉及到战斗的游戏，都或多或少收到过玩家此类的反馈，从反馈信息来看，简直像极了存在BUG。例如第三条，在一个PVP场景下DPS普遍过万的游戏内，玩家A打玩家B只有几十点伤害，看起来很离谱。如果是由于BUG造成，那么问题就很严重了，需要立即解决，否则会对玩家的体验和游戏的寿命造成极其不好的影响。
但是此类反馈往往仅有玩家的只言片语，好一些的会附带截图和视频信息。以这么少的信息，我们很难去分析到底是因为什么原因产生的问题。万一是被攻击的角色开了减伤呢？或者是玩法机制给了一些额外的BUFF呢（一些游戏里会给弱势方加一些保护性BUFF）？这些情况都仅仅是我们的猜测而已，并不能向玩家提供确凿的答复。但如果我们假设游戏中存在BUG，去游戏内反复尝试重现，对着一个庞大的战斗数值结算体系代码进行代码分析，这样的工作量无疑是巨大且极其低效的。于是我们就可能会陷入一个死胡同：玩家反馈的问题既不能证实，也不能证伪，于是不能向玩家提供一个准确的答复，从而造成极坏的舆论影响。
那么身为一个游戏测试，大家可以先思考一下，在自己的游戏中遇到此类反馈时，是否有手段来证实其是否存在BUG呢？如果毫无思绪，或者所在项目暂时没有手段可以证实或挖掘其中隐藏的问题，那么本篇文章或许能够为你提供一些思路。对于在研项目，如果没有这方面的准备，也可以尽早考虑应对措施。本文将讲述作者所在项目在属性和技能结算异常挖掘和分析上所做的工作。
为了便于没有战斗数值相关测试经验的同学阅读，在详细展开如何挖掘玩家战斗过程中的异常问题之前，先简要概括一下一个数值游戏战斗数值体系相关的内容。
所谓战斗数值，从本质上来讲是对玩家角色身上一系列战斗相关的变量（即玩家口中的属性）的运算，进而通过技能结算等途径对玩家产生直观外在表现的体验。例如玩家追求装备，其实是追求属性，而build出的角色属性，最终则是以技能效果的方式表现出来。从游戏开发角度来看，我们可以将游戏战斗数值的体系分为以下核心部分：
1. 属性的来源：
即玩家如何获得这些属性，如附魔，装备，基础属性等。
2. 属性的结算
即各个不同的来源的属性如何合并结算为玩家自身的属性，例如附魔，装备都以不同的方式提供了攻击属性，它们该如何合并到玩家角色身上成为最终的攻击。
3. 属性的功能和生效逻辑
即属性的效果功能，例如破防，暴击的生效逻辑，也就是通常玩家在玩游戏时乐于推导的公式的生效的部分。
4. 属性的设计和投放
除了属性的功能本身之外，各个部分属性的投放合理性也是战斗数值体系的关键内容之一。
以流程图进行概括如下：
这个结构基本可以概括大部分游戏的战斗数值体系结构，差异基本只在于其中不同部分的实现细节。在大概理解了一个游戏的战斗数值体系结构之后，我们就可以分析哪里可能存在什么样的问题，进而制订属性和技能结算异常分析挖掘的手段了。
后面我们将主要从以下几个方面进行叙述：
1. 属性异常分析
2. 技能结算异常分析
3. 一些其他扩展手段的思考
4. 一些体验上的问题
由之前叙述的战斗数值体系的结构可以看出，对于玩家来说，发现一个技能效果异常（直观上伤害过高，过低）的时候，其内部可能出现问题的原因是多样的：
1. 可能是属性部分的异常：属性的来源，属性的结算任何一个部分存在问题，都可能导致玩家角色身上的最终属性是异常的，从而导致技能效果异常。例如玩家常说的刷属性。
2. 可能是技能的结算的异常：属性的功能和技能结算的本身存在问题，从而导致技能效果异常。
在做整个异常分析的时候，这两步往往是不能混为一谈的，因为只有当我们确定玩家身上的属性是正确的时候，才能够有足够的理由去怀疑是技能结算的异常。
一，属性异常分析
在最初接到玩家举报属性异常的时候，我们游戏是没有任何手段去追溯玩家某一时刻的属性的。在那个时期，所能做的事情就是开一个号，对重点关注的玩家进行行为观察，同时在后台反复获取其属性，然后去再去分析其是否有异常高或者异常低的属性，如图：
这样的方法非常低效，很多时候需要等待玩家做一些需要的操作，比如想看玩家打战场时的属性，就得耐心等待玩家去打战场。正是由于没有其他方式去追溯玩家某一时刻的属性，这样的手段也是无奈之举。为了解决这样的困境，我们在游戏内做了一个玩家的属性监控LOG。为了尽可能不影响服务端性能，同时保证记录的有效性和时效性，我们制定的属性监控LOG规则如下：
1. 所有玩家每隔10分钟记录一次属性，同时记录BUFF和特效触发带来的临时属性。只做只读操作。
2. 可以通过GM指令添加重点关注玩家，重点关注玩家每隔1分钟记录一次属性。
从目前应用的成效来看，普通玩家每隔10分钟记录加上重点玩家每隔1分钟记录的频率是基本够用的，同时也不会对服务端性能造成太大的压力。
在有了log记录之后，我们基本可以做到追溯任意玩家某一时间的属性详情，再也不用苦哈哈地暗中观察玩家了。同时由于存在格式化的LOG记录，我们也做了针对LOG的自动化分析，可以对指定时间段，指定服务器，指定玩家等各类条件下属性情况进行自动化分析：
1. 结合游戏环境，设置理论上限，分析出超过理论上限的属性条目和玩家。
2. 记录临时BUFF，分析玩家在一些场景下是否存在不合理的BUFF，例如我们游戏曾经用该手段发现部分玩家在战场内卡出了副本里给的属性加成BUFF。
在有了自动化手段后，我们也可以周期性地执行分析脚本，做游戏内属性情况的整体回归。
二，技能结算异常分析
像开头提到的问题2，反馈的玩家在2:11:56秒跳了两跳雷神·千裂破，相差了7000多伤害，直觉上可能觉得这有问题。在过去，我们没有任何手段对这样的结果进行回溯分析，即便有了属性分析工具，也只能在获取攻防双方的属性之后去计算伤害的合理范围，如果伤害处于合理区间范围内，就只能马马虎虎认为是可能正确的，但是万一出现在合理区间内一直保持异常低值的BUG呢？我们将无从查证。
但现在我们已经可以拍着胸脯告诉玩家，这张图里的伤害没有任何问题。因为第一跳暴击触发了灵珑（被攻击玩家的职业）的春风技能修炼（受到暴击时提升20%物伤减免，持续5秒，CD20秒），同时由于第二跳时灵珑身上不再有定军，所以攻击方圣堂对处于定军状态的伤害加深失效了。并且，这个伤害计算的中间过程也是完全正确的。
从玩家贴的一张图来看，只能分析出定军没有了，但这也是一个可能性而已。那我们是怎么做到像上文一样笃定的呢？这是由于我们在玩家和玩家之间（我们的玩家更注重PVP）的技能结算上增加了对中间过程的监控，如下图所示：
我们会从攻击方释放技能时开始进行记录，包括攻击方的属性，攻击方的BUFF，防御方的属性，防御方的BUFF，攻击方所用的技能，以及技能修炼带来的技能修饰效果，同时还记录了中间过程中各类关键伤害修正比率（如受伤率，暴击，格挡）等。有了这样的LOG记录，我们就相当于有了玩家技能结算时的“时光机”，可以追溯到过去的时间，去查看玩家之间结算的详细信息。但是出于性能问题的考虑，这个结算信息也不是每个玩家都有记录的，我们游戏采取的是白名单机制，只对部分加入白名单的玩家进行记录，以及对某些开启场景全局白名单(例如一些赛事地图)的场景内所有的玩家都进行记录。
有了这样的LOG，当再有玩家反馈伤害异常的时候，只要他处于白名单内，我们就可以做到有据可循，明确查证问题并答复玩家。即便真的有BUG，也可以比较方便地去查证玩家是否恶意用了BUG牟利（例如赛事内通过卡BUG获利），进而对玩家进行一些处罚。
与属性异常分析相同，我们有了格式化的LOG之后，自然也可以付诸于自动化分析的手段来周期性地进行分析。理论上，记录了结算时攻击方和防御方的属性以及所用的技能信息，就可以计算出该技能的预期伤害范围，从而可以周期性自动化地去分析是否有异常伤害出现。
三，一起其他扩展手段的思考
其实如果想要去监控和挖掘属性，结算上的异常，我们目前所做的属性LOG和技能结算LOG是并不全面的。这是由于我们的游戏已经运营多年，后期增加此类的监控和信息记录难免会面临很多性能问题，从而不能做到很好很高效的覆盖检查。为了避免对现有代码有太多更改，造成额外的风险，有很多改动是不适合去做的。
但是对于一些性能无太大压力，或者在研的项目来说，如果能够提前考虑这一方面的事情，就可以做到非常多的事情。例如：
1. 结算流程在开发时就加入单元测试进行自检。由于结算流程比较复杂，存在非常多的中间过程，那么在结算流程中增加单元测试是可行的。我们曾经迭代整个结算流程，为了确保新结算流程和旧结算流程的结果一致，在灰度测试期也就是线上以旧结算流程运行的同时，也会跑一遍新结算流程，并对两者的结果进行比对，如果两者的结果存在差异，就说明新结算流程存在一些问题。
从某种程度上来讲，这就是一个自检过程。这样的自检仅在研发阶段会有一些工作量，其实对性能的影响可能并不会很大，完全可以通过开关控制，周期性地小规模跑一遍来对线上的结算流程进行自检，要比后期有问题了再排查要更加提前，且可靠的多。
2. 属性自身做一些报警。通过记录属性LOG、再利用LOG分析去挖掘属性异常还是偏滞后的，如果能在属性结算功能本身，根据一些场景，给绝不可能达到的上限等信息添加一些程序内的报警，就可以使这一步骤更加提前，例如在战场内的玩家绝对不能达到物伤加深50%，那么如果玩家在战场内达到了50%就直接报警，这要比后期进行LOG分析要快的多。
3. 玩家行为分析。无论我们已经做的，还是上述的一些设想。其实即便检查出有异常，我们也很难知晓玩家做了什么样的操作导致这样的异常，玩家历史的行为分析其实一直来说是一个亟待突破的一个点。如果能够利用丰富，有逻辑的LOG来创造一种玩家行为回溯的方式的话（极限一点就仿佛破案一般能够推出玩家任意时刻在做的事情），就不仅仅对于属性异常和结算异常有帮助，对于任何一种系统，玩法的异常尤其是疑难BUG的挖掘可能都是有帮助的。不过这条路要走清楚，可能真的需要很久。
四，一些体验向的问题
伤害异常，属性异常往往会使游戏面临很大的舆论压力。而且一些玩法机制可能会给部分玩家提供带节奏的便利。例如我们在战场内有载具，当玩家上载具的时候防御是极低的，这种时候就可能会有其他玩家打他的伤害特别高。也会有逆袭机制，可以给频繁死亡的玩家增加大量的攻击。当有玩家截图此类战斗信息发论坛说xxx伤害不正常的时候，对于舆论总会有或多或少的影响。于是我们也对战斗信息进行了丰富，当玩家处于载具、逆袭状态时，战斗信息里会直接在玩家名称后面标明玩家处于哪个载具，拥有几层逆袭。这样低成本的手段，无论对于玩家理解战斗信息，还是避免带节奏来说都是有益无害的。
另外，开头提到的顶尖战力玩家打低战力玩家伤害不高，后来经过检查，我们发现这个低战力玩家基本没有去堆PVE相关的属性，而PVP向的防御属性其实也已达到顶尖战力的水平，于是就出现了高战打低战不疼的体验感。这既是一个数值战力规划存有虚战的问题，也是一个信息展示的问题。
对于大多数游戏来说，综合战力并不能完全判断PVP战力和PVE战力，我们游戏这种单一战力的展示，对于顶尖战力玩家的体验也不是很好。所以我们也考虑着手做战力的进一步细化，将综合战力根据来源和用处的不同，分算为PVP攻击战力，PVP防御战力，PVE攻击战力，PVE防御战力。这个做法其实在很多游戏里已经存在了，例如剑网三，古剑奇谭网络版等。当对综合战力进行细化之后，就可以在一定程度上让玩家理解为什么低战力玩家和高战力玩家的防御能力差不多，这可能仅仅是因为他们的PVP防御战力是接近的。
以上就是我们项目在属性和技能结算异常挖掘和分析上所做的一些工作，希望能够为还没有着手做此类工作的项目提供一些思路，也希望能够抛砖引玉，获得更优更高效的手段和理念。
如果大家有什么想法和建议，欢迎在评论区和我们进行讨论！
9056
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
