本文将从笔者的角度出发，讲讲自己从日志小白一路了解与学习日志相关知识，然后如何在一众组内同事们的帮助下逐渐成长为能够利用日志做点什么的日志熟练工的历程，如果你现在也是刚入门或者某个节点有所疑惑，那就和我一起看下去叭
还记得刚进到项目组，我也是首次成为游戏测试，跟着大佬们开展功能测试遇到了一个bug，开心的告诉带自己的前辈，前辈说你开下bug单吧，顺便把日志（log）拿一下放到单子里。为此我也一脸懵过，从他们的语气里好像这是通识，虽然我不想承认我是真小白，但是师父，什么是日志啊？日志，换言之就是一个过程或者经历的记录。生活中的日志（即日记）一般需要包括的基本元素即为时间、什么人、做了什么事情、如何去做的、结果是什么等，而应用程序的日志可以简单地理解为使用固定的格式记录固定行为内容的数据。比如名为GameRewardLog，顾名思义就是记录比赛奖励的日志，假设具体内容如下：![]()
那么将这种固定的内容翻译为一段文字记录具体就是： 在2024年1月22日下午8点25分30秒玩家id为tpddf273f42983594411b63092c7ebc1aa7f的用户小明，在2001服务器的5f9a02df9cbd4109a8a645bbad6c3675房间中，名为306020007的比赛中获得了80金币和150经验，比赛前他拥有1380的金币和2850的经验，比赛后他的金币和经验分别变成了1460和3000。上述例子就是游戏内运营日志，我把其比作上学期间老师要求写的日志，有规范的要求，需要条理逻辑清晰，并且其他人能够较为容易的理解和明白，能够通过这一日志还原出一次完整的操作和事件（一条日志只讲一件事）。这也是QA在后续查找问题和开展工作重点关注的。还有一类日志是写给自己看的，内容记录比较零碎，格式没有固定要求，所以这类日志一般量大，内容比较随意，其他人读起来比较吃力，这类日志一般就是客户端和服务端程序写来自己做调试所用。这类日志对于初入门的你来说需要关注的是Error或者Exception的内容即可，比如在发现客户端明显异常时可以尝试在客户端日志中搜索以上两个关键词来定位了解下具体的抛错信息。知道日志长什么样以后，就需要知道怎么去拿到日志，客户端日志一般是放在对应应用程序项目的log文件路径下。同样地，本地的服务器日志也是位于本地服务器相关目录下的log文件夹之中。线上运营以后有统一的日志存储平台的话，就需要利用相应的查询平台才能够进行查询线上玩家日志了。 在分清楚日志相关分类后，需要知道的是我们的工作主要是围绕运营日志展开的，所以就需要先进一步简单了解运营日志相关的规则和内容。关于运营日志，从名字而言即可知道，主要用途是用于游戏上线运营后的监控与保障。所以这类日志是需要提供给各个不同的职能甚至是部门拿来解析与使用的，但每个项目可能实际情况会有所不同，那么怎么保证其能够满足各个部门的要求呢，所以一般就需要一些通用格式与内容的作为基础参考。
以下是笔者整理目前我们使用中的一些内容参考，可能不是非常全面准确：P1 日志的要求是所有手游在上线之前都必须记录的。![]()
![]()
日志的字段构成的基础格式：[logtime][operation],JSON，需要有日志输出时间和日志名，格式必须要是合法的json格式。 需要包含的最基本字段：唯一id（玩家相关应该有玩家唯一id）、服务器id了解了日志是什么以后，大家可以想象，游戏内包含的功能之多，每个功能都写日志，每个功能产生的行为又是五花八门，这里面所蕴含的信息量之大就可想而知了。对于已经处于运营期的项目来说，日志的体系肯定已经非常完善，需要做的可能更多的就是日志解析用以查找线上问题的工作了，但是项目完整的日志体系与日志规范不可能是上来就有的，这些也是伴随游戏开发上线运营，一步步地建立与完善的，那么接下来就以整个项目开发期结束到上线来讲讲作为功能QA的我们围绕运营日志的冰山一角都可以做什么吧。
根据部分重要节点结合某项目的里程碑情况简单地整理了时间线，总体的日志相关工作被我划分为日志规范、日志与投放、日志监控以及其他四大部分进行讲述，各项工作的具体情况也会分布在后续小章节中一一详细展开。日志规范这项工作的开展背景主要是针对项目研发过程中，测试组的人员也是不断在增加，每个组内成员的情况不同，对于日志这块的了解程度各不相同，但是组内日志测试的部分在刚开始的时候并没有具体的规范去指引大家在开展功能测试时应该以怎样的标准从各个环节去测试日志，因此日志测试并未得到重视，实际游戏内日志落地情况也是参差不齐。那么该如何整理日志的情况呢？（1）功能日志规范了解与整理（找病灶）
首先是拿到一份对外测试的日志，因为在正式运营时，很多本地测试的调试日志都会被剔除，真正保留下来的就都在这里面了，到线上这也是一系列日志工作的展开基础。一个功能的日志最后要记成运营日志是需要程序按照固定要求和格式写的，如果不详细的去review代码，还可以根据这份运营日志，结合策划之前给的日志需求以及平时测试的功能日志，排查出那些【日志需要但这份日志里没有包含在内】的内容，说明是程序记录不规范，从而去推动程序修改。其次就是从已有的运营日志中找找有没有明显不合理的记录，这部分就是参考了上述说的约定好的通用格式的要求，比如玩家唯一标志的字段应该全游戏都规范并统一，不可以一会儿是长字符串，一会儿是int数值这种。b.已有问题+调研他人分享经验，整理形成本项目的日志规范因为自己对于日志这块也是刚入门的小白，所以我在一些经验平台找了之前的经验分享进行了学习，再根据通用日志格式并结合项目组的实际情况整理出了组内的日志规范。然后根据项目实际情况针对具体问题做判断，比如外部资料里面的规范字段命名，项目内已有通用的就需要确认是否按照目前已有的继续进行，是的话就不用单独列出来。（2）功能日志规范组内同步（做科普）
那么当我已经搞明白相关的规范和要求以后，要如何传达给组内的同事们，让他们能够有所参考和有效执行呢？那就需要考虑两方面，一是引起重视，二是后续参考。引起重视我们主要采取的是类似讲课分享的形式，笔者是自己将自己学习到的内容结合组内的例子写了一个PPT，包含以下内容：c.目前已有日志，举例可优化的点（主要是资源项的变化）然后我们组内的分享会上，在主管安排下专门将相关规范以开会的形式为大家讲解并分享同步至组内所有成员。开会分享的目的是引起组内所有同学的重视，开始将这部分内容纳入到自己的日常测试中去。后续参考除了以上ppt以外，根据会上内容，将所有的注意项，分为【必要】和【推荐】类，列出每一项的明细写成文档放入到项目测试规范中。后续入组的新人也都会推荐其进行阅读。（3）功能日志规范执行(自查自纠)
a.组织并推进组内QA按照规范排查并整理自己负责的功能的日志问题这部分我主要是用开单的方式去推进，首先会开出一个问题排查的总单，然后在下面给所有QA开出字段，会在子单中写明要求：![]()
以自己的单子为例子列明相关记录，必须包含排查功能与日志情况，有问题的日志修改前后情况：
![]()
这样做的话可以从子单清楚知道对应QA目前的排查进度，哪怕没问题也标记进去，能够确切保证有去实实在在落实。再结合游戏内的现有功能也不用担心有遗漏。所有发现的问题，要求QA都开单关联自己的问题排查单子，以子单为载体记录个人排查进度，再在总单汇总项目整体的排查情况和进度，标明问题单号：![]()
这样所有人想要了解目前日志排查情况时，通过总单就可以一目了然。需要推动进度时也直接将该单子贴给主程让其帮助去推进，他们也可以从这个单子了解到目前的问题，而且所有问题放在明面上，别人一看——哦，问题还挺多，得重视一下了。我们也可以少费一些口舌~需求分析阶段即按照规范和建议思考，提前对需求文档进行确认是否包含了日志需求，日志需求是否合理。没有的QA需要及时和策划确认补上，不合理需要和策划沟通确认合理性。交付测试后需要注意日志格式是否符合要求，必要的字段是否包含，触发的逻辑和记录内容的正确性。第一项可能大家都能够根据规范和需求分析阶段确认的结果去保障没有问题，而后一项就需要对日志进行详细的触发和记录了，最好是能够写出详细的用例，这部分也是比较重要的，因为线上查找问题，统计数据都是依赖日志，日志本身记录就是错误的造成的麻烦就不是一点半点了。 也不要先入为主以为日志记录肯定是完善的，毕竟是人写的逻辑，不可能保证完全没问题。举个例子，策划需要统计线上玩家某功能的使用情况从而依赖这些数据去调整功能完善后续设计，测试玩家不同情况触发对应的操作，但是却发现当玩家因为离线触发时，日志未记录成功，而且某个进程服务器中的功能日志的id只有玩家前缀并没有完整的id。原因是程序在离线逻辑这块有点问题，没有进行传参。随着项目开发到达尾声，就需要考虑测试右移的问题了。最直接的就是线上出现投放问题，能够通过日志第一时间发现，这就是大家经常分享的日志监控工作。那么在做日志监控之前，目前的日志是否可以完全满足我们的监控需求呢？整理游戏中关于投放相关的日志和字段就成了日志监控之前的一项重要工作了。（1）确认各个功能的物品获取途径细则字段
首先是游戏内是否存在贵重物品无成本重复获取的情况，一是不合理（这类问题是因为功能设计之初数值策划未参与进来，所以一些合理性是单从系统策划的角度去看待的），二是这种可能会对后续监控造成一些误导。在排查过程中，发现某等级卡牌提升功能一开始是可以反复重置转化的，这部分和数值策划进行沟通后觉得没必要且不合理，所以也是开单找对应功能去掉了这部分的内容。在除了背包系统以外，有投放的功能本身也应该记录该功能投放的情况，也是为了后续对背包系统与功能本身两者的日志做审计。比如某功能玩法就缺少对应奖励发放的日志，所以对应功能除了功能保障的日志以外，缺少的投放相关的字段也是开单让其补充了。过长的日志是需要拆分的。例如结算会记录比赛的房间、对局的胜负、对局后的玩家局内数据、参与的具体玩家、还有一系列的投放等等，加起来能够四五行。日志过长不仅存储表单会很长，而且肉眼解读起来也是吃力，眼睛都看花了也找不到关键信息。于是也是推动程序将一条结算日志拆分为奖励投放和局内数据两条日志，然后通过uuid和room_id串联起来。（2）投放相关日志框架的整理与规范
笔者跟进的游戏有一个特点，所有的投放即使最后不进背包，也都需要经过背包，只是会自动转化为对应系统的物品，所以投放框架这块重点排查道具获取日志GetLog就可以。那么在本次排查中做了什么呢？首先是与数值策划确认投放计划。这个时候游戏内还未形成完整的数值布局，于是组内推动数值策划那边提供了一份初版的游戏内的数值投放计划。其中包括整体数值计划，以及整理所有有产出的功能。根据投放计划摸排产出日志。参考计划先大致列出了游戏内的投放框架，然后进入游戏内进行确认每个系统是否都有产出日志，另外就是需要思考后续监控或者投放的颗粒度。比如某系统有多处不同的产出，有每日任务和随机事件，这两者在GetLog的获取途径的字段是否做了细分，再反馈给策划，询问其投放计划是否需要细分。根据排查情况结合数值策划的反馈修改框架，并督促策划去细化其投放计划。第三是寻找程序面的统一接口人。那么日志层面是否已经达到要求，没达到要求（细化途径以及补充缺失日志）就需要开单给程序去做优化。为了提高这件事情的落实效率，建议最好能够找到一个程序专门协助自己去做这部分的完善，有利于排查工作一气呵成，避免不同功能再去一一沟通确认等繁琐环节。找到接口人以后就只需要将自己摸排好的情况直接分享给程序，程序再去一一对照代码确认修改即可。（3）投放日志的物品获取途径枚举排查
由于项目的开发期会涉及到很多内容的迭代，一些枚举已经失效废弃但是依然还占位，甚至还存在一些不明确的枚举途径，比如other、use这类，有的程序偷懒可能就直接不写明具体的途径而引用other，这样一来一旦某个途径有异常，通过日志难以找到具体功能，所以这部分的排查工作也作为日志投放框架排查的补充展开了。通过排查除了督促程序将不合理的内容修改以外，也和程序达成了约定，枚举的自增需要有规范。![]()
（4）与策划约定，制定并维护投放计划
因为需要经历开发期到后续上线运营，还会有功能迭代、新增、下线，数值修改等等情况，那么后续的投放如何管理，我们应该以何种方式去拿到一个“标准答案”，能够便于组内QA在每个版本去游戏内验证呢？所以早早地就与策划达成约定，将前文所说的投放计划形成规范，策划每个版本进行维护，然后建立了投放群，在每个版本稳定以后，会发动所有QA都进游戏内去验证投放的正确性，与投放计划不同的地方都会找数值策划一一去check，要么更新投放计划，要么开单修正投放错误，保证每处变动有人知有人晓，避免投放死角。![]()
日志监控算是测试右移的常规手段，那么作为尚未接触过这项工作的人，日志监控的介入都有哪些关键点或者事情需要注意的呢？（1）日志监控平台
日志监控根据各个项目的不同采取的方式都不一样，据我所知有的项目是自己开发了监控工具，有的项目是使用的现有的平台直接接入。（2）了解监控平台的配置方式以及配置规则
监控配置方式主要分为单日志监控与多日志监控的区别。单日志监控就是指针对单个日志做聚合，比如针对GetLog日志做监控，就是对该日志的各个字段进行过滤、分类然后求和、最大值、最小值、平均值等等。多日志监控的话一般是需要用到两条不同的日志做审计，比如审计玩家钻石消耗和玩家购买道具的钻石花费，玩家产生钻石购买行为时，货币变化日志money_update_log会产生一条日志记录变化数额和商店日志item_buy会记录购买具体道具花费的货币种类和具体数额，通过聚合这两者一天的总额进行审计保证数额对得上，就可以一定程度避免出现钻石实际没扣除但是道具购买成功的情况。在实际的配置落地时，监控不同的需求使用的配置规则也是各不相同，我总结为多个元素组合，包含了：单途径、多途径、单个道具、单类道具、单个玩家、全服玩家、时间长度、非道具投放的功能向等等。实际的监控就是这些不同元素的排列组合，举个例子：某个珍稀道具，单服每月投放一个，那么分类规则中就根据服务器id监控，过滤规则就是该道具的具体id，监控阈值为1即可，那么这里面就包含的是全途径、全服玩家、单个道具、每月的要素组合。至于非道具投放的功能向就是指一些和投放无关，但是需要有所限制的内容，比如某个玩法一个玩家每天只能参与5次，那么就需要聚合对应功能参与日志的打印次数，超过5次就可以直接触发报警。其次就是监控触发的步长和报警的实时性也需要格外注意的点，因为线上日志数量庞大，频繁的聚合可能会有压力，但是对于一些紧急且重要的内容又需要及时反馈，那么就需要根据具体的监控内容区分不同的情况制定合理的监控聚合步长和聚合报警频率相关的计划。（3）配置建立完整的各个功能的投放监控框架
日志监控的重要性也是强调了无数遍的。但是总会有一些问题是容易遗漏或者考虑遗漏的。所以对于监控需求的提取实际怎么做如何落地呢？主要是分为两步走：分为两部分，一是依赖之前整理的投放日志框架，将所有投放途径根据策划的投放计划每个道具设置总上限监控。二是调研已上线项目的经验，尽量去培养自己对于投放这块的敏感度，挖掘一些可能的监控点。别的项目遇到且分享的事故就是宝贵的信息来源，都是前人踩过的坑留下的“财富”。留意关于投放异常相关的刷类问题，整理出后续需要特别关注的内容。特别分享一个例子，就是项目监控落地前几天刚看到某游戏帮会结算奖励可以通过不断换帮会达到反复获取的bug分享，于是在本游戏内就做了相关配置，后面线上也的确出现了类似的玩家换帮会可以获取超计划的货币的问题，也与之前看到的游戏分享的刷奖很类似，并且线上报警第一时间就暴露了这个问题。虽然本游戏对应功能那边本身资源投放量特别小再加上换帮会的cd比较长，问题不是特别大。但是这也反映出来其他项目踩坑的例子分享会在潜意识里让我们对对应类的问题有一些防范意识以及提高了我们对这类问题的关注度。俗话说的好，百密终有一疏，智者千虑尚且必有一失，何况我这样一个小QA呢？所以在完成初步框架的搭建以后，发动各个功能的QA对自己的功能进行监控需求的提取就是关键一步了。初版的话是在对每个功能的监控进行完善时找各个QA确认核对。后续版本对新活动新功能的投放，在每个版本上线前一周我会在群里通知所有QA注意自己所负责功能的监控需求提取，然后在公共文档中创建常驻的页签用于监控需求的填写，为他们创建待办提醒他们，每一份监控需求在配置时会和他们共同核对一起思考是否存在遗漏或者不合理的地方，也就避免个人闭门造车的情况发生。除了参照策划的投放计划以外，其实有时候还可以多思考一些其他可能性。比如策划对于经验的投放是按照一周获取上限进行投放的，那可以问一下正常玩家一天能打多少把游戏最多是多少呢？一个玩家一天上下线几次才是合理的，大量玩家频繁登进登出会不会是在利用bug刷奖励呢？其实这些也都是一些可挖掘的监控需求。一个真实的例子，记得某地区上线时，额外在一周经验获取上限以外配置了一天的聚合，玩家一周获取虽未超过策划投放上线，但是一天把一周的投放获取完了，是不是也不正常呢？结果发现真的有玩家触发，拉了他们的日志发现匹配场次异常基本属于不眠不休深更半夜都在打比赛，这样的玩家就犹如机器人。通知策划后，组内意识到可能已经有按键精灵类的脚本在挂机刷资源，这种行为破坏了游戏内的生态。后续国服上线也是保留了对应的监控，这些触发监控的账号也都导出提供给违规小组进行检测，的确也证实十个里面有至少八个是属于异常行为并做出了相应处罚。其实日志相关的工作远远不止于此，还有很多这里没有写进来的内容，比如利用日志做数据分析以及实现自动化测试等等。也许讲得不是很全面，但还是希望读到这里的你能够和曾经的我读到其他前辈的分享一样有所收获，期待你成长为日志熟练工以后去探索更多的可能性。功能跟进之我见
复盘：别让你的经验白白浪费
游戏兼容性测试工作分享
