首先我认为游戏的平衡性是服务于有意义的选择（Meaningful Choice）的创造过程的。平衡性使得玩家对抗的游戏过程中，玩家的选择变得有意义，从而调动积极性并使游戏过程变得有趣，而非无聊。

从这个层面上讲，如果一个游戏中玩家在对抗中做出的选择都有意义，那可以认为算是平衡的游戏。但反过来讲则未必，如果对抗中出现了无意义的选择，那也可能是叙事表达需要/玩家特殊行为的后果/其他因素，游戏平衡性不佳只是其中一个可能的因素之一。

那什么是有意义的选择呢？

根据前Zynga首席设计师Brice Morrison在Gamasutra上的说法，有意义的选择通常需要有如下组成部分：

1. 存在感(Awareness) - 玩家需要意识到他们正在做出选择。
2. 玩法上的结果联系(Gameplay Consequences) – 选择必须在游戏玩法与艺术要求上能够产生影响和结果。
3. 提醒(Reminders) – 玩家在做出选择后必须被提醒他们做出了这个选择。
4. 永久性(Permanence) - 玩家在得知后果后，不能直接地从头再来重新做出选择。

我认为这个说法还需要有所补充，比如永久性并不是绝对的但要付出一定代价，比如存在符合这些定义但是依旧是无意义的选择。不过大体上是和我的观点相符，也具有一定的参考意义。

我们再来看看与竞技游戏更相关的说法。《英雄联盟》时任首席英雄设计师Andrei "Meddler" Van Roon曾在官方博客上发表过相关的概念解读。他指出“有意义的选择需要玩家对他们的决策所会导致的后果有充分的理解”，也补充了“选择的可执行性也很重要。如果三个选择中的两个只能被最好的万分之一玩家所执行，那也意味着它基本就是不可行的。”

为什么要让选择有意义呢？

在对抗游戏的过程中充斥着选择。Meddler举的例子有很多，其中包括了一次性选择和持续性选择，特定时间段的选择和全局可行的选择，战术选择与战略选择等等。

- 在选人阶段，我应该用一个璐璐那样的功能性中单还是一个劫那样的刺客？ 最理想的情况下选人阶段没有绝对的正确答案（这正是平衡性的关键），对个人而言任何选择都可行，但他们依旧有一个或者多个指导思想，比如“队伍缺啥？”，“我对啥熟悉？”。

- 在商店里，我应该把所有钱花掉买成小散件，还是攒着憋一个更大的大件？ 虽然LOL中物品的属性与金币价格呈现正相关，但是对特定英雄特定形式而言，不同属性依旧有实战价值的区别。因此玩家得以根据当前形势进行分析，得出特定的最优解，而非机械地按特定顺序出装。

- 在战斗中，我应该继续往前冲因为我感觉对方的支援要到了，还是往旁边走位一下因为对方看起来下一个QWER的CD要好了？ 这类即时性的战术选择往往需要很快的反应和判断，既可以产生对玩家游戏掌握程度的考量，作为选择的结果又能因此导向战局天平的倾斜。

其实反观另一个同类竞争者的作品——《Dota 2》，也在维持有意义的选择上进行着不懈的努力。7.0最新推出的“天赋树”系统取代黄点，就是为了避免后期点黄点成为无意义但是必须进行的操作，取而代之以一系列不存在绝对最优解的天赋选择，让玩家时时刻刻需要根据形势来选择适合自己的天赋。

我们再来从反面看看这个问题。与有意义的选择相对的，就是无意义的选择。完全无意义的选择其实很少，但真正关键的是这种选择是否符合游戏目的，是否符合玩家群体的需要。

80年代D&D系的《惊恐墓穴》(tomb of horrors)中有一个“死亡之箱”，一个房间中有三个并排的看起来像有宝藏的箱子，但打开任何一个都会导致机关触发角色死亡。三个并排箱子看似提供了可能充满了丰厚奖励的选择，但实际上这个选择从现在的角度来看属于都是不可行的伪选择。

《巫师》系列的很多对话都是多选一，但多数不会导致多深远的影响，那么是无意义的选择吗？ - 如果你喜欢剧情营造的代入感，那么它们就是有意义的，因为这些选项能够改变接下来几秒内你的角色的对话方式，从而提供掌控感并塑造角色性格。 - 如果你喜欢通关杀敌的快感，那么这些选择就是无意义的，它们大多数并不会改变你的对手以及你的状态。你甚至可能感到困惑，无聊。谁会去做无意义的事呢？ 但最关键的一点是，《巫师》系列不是所有对话都不会产生影响的。理论上玩家在没有通关过的情况下，是不清楚自己的选择究竟会不会产生影响的。也就是说，他们依然要承担这部分风险，直到做出选择后才知道自己到底有没有影响。

总的来说，选择的意义事实上能让玩家需要游戏信息利用进行形势估计和快速反应等，并以此做出决策往游戏目标推进，保证了玩家的参与感并维持了紧张程度。失去了意义的选择可能导致游戏无聊，玩家失去动力，产生不好的游戏体验。

平衡性与选择的意义是怎么挂钩的？

其实写到这里应该已经很清楚了，一定程度的平衡性是对抗类游戏中维持选择的意义所必须的。你一定希望在选人阶段选择任何段位平均胜率都高出其他人10%的英雄，你一定希望用一个能控能打能抗还没有操作难度的英雄，但如果这些就是你的选择了，你未必会觉得有趣。同样地，在面对这些英雄时，你多多少少会丧失动力，因为你的努力、你的选择在一定程度上未必能弥补英雄强度上的差距。

但平衡性不全是指英雄的胜率，英雄之间的差异性也很重要。游戏设计中最担心的事之一就是出现“全能”的定位。如果一个英雄在任何方面都不差，它的存在会掩盖其他英雄的闪光点，使其他英雄成为伪选择，这同样是对选择意义的破坏。

另一方面，平衡性的追求也存在边际效应。要知道玩家在英雄上的选择不完全是依靠胜率的，熟悉程度和独特玩法同样是影响玩家选择的关键因素。50%胜率但玩法无趣的英雄与48%的胜率但玩法有惊喜有可追求性的英雄相比，后者很多时候能够更胜一筹。

还要补充的一点是，虽然有意义的选择能使《英雄联盟》这类的对抗游戏变得更加耐玩，这也不是适用于所有游戏的概念。《Undertale》中充斥着无数的无意义选择，但它们反而帮助构建了这个游戏的艺术性——尤其是作者要传递要表达的，正是基于这个玩法之上。

参考：

Meaningful Choice in Games: Practical Guide & Case Studies

LoL Design Values: In-Depth with Meaningful Choices

游戏测试是怎样一个行业？我们邀请到了我们的游戏测试同事谈一谈这个话题，希望他的经验和看法能对大家有所帮助。

游戏质量与玩家的体验息息相关，作为QA（游戏测试工程师），通过严格的测试来保障游戏质量是QA的工作日常。既关注验证，也关注预防，涵盖游戏从研发初期到上线运营的全生命周期。面对质量问题，QA需要充分开发和利用各类工具来提高测试效率和准确性。

游戏从广义来讲也是一个计算机软件。计算机软件在研发过程中，不可避免的会引入各种各样的bug，而这些bug交到用户手里，有可能会引起或大或小的问题，咱们玩游戏的时候，也可能碰到过闪退或者卡顿。

相信大家都听说过计算机软件的bug造成严重事故的案例，在这里给大家举几个例子。电子计算机从发明至今，bug就一直伴随，1962年，美国发射水手一号火箭，升空6秒后，由于控制软件的bug造成爆炸。1994年，英国的军演中有一台运输直升机，它的导航系统出了bug，造成观看军演直升机的人群有20多人伤亡。飞机导航系统，已经是咱们日常能接触到软件里，对安全要求特别严苛的系统了，而bug依旧不可避免。

还有一个让人唏嘘的例子，80年代，加拿大的一家医疗器械公司做了一款X光刀，用聚焦X射线来切除人体器官。然而它的辐射计量控制软件里出了一个bug，导致了几千名病人都遭受了超量的X光射线的辐射，最终造成六人死亡。加拿大的医疗监管机构和美国的FBA对这件事情进行了调查，发现这个事故最终原因是由于写剂量控制软件的两个程序员造成的。

当然bug也有正面的作用。美剧里面有个机构叫疾病预防与控制中心，这个机构在美国是真实存在的，目的是预防疾病大规模传染。他们就曾经把暴雪的服务器数据copy过去，用来研究假如瘟疫爆发，应该怎么处理。

对游戏行业来说，bug一般不会造成玩家的直接伤害，而是摧残心理，导致游戏体验大打折扣。

网易游戏的研发历程中，也有被bug伤害的经历。早年的一款游戏出了一个收集书以获得稀有物品的新玩法，那时大家比较缺乏经验，没有设计物品掉落的上限，导致大量收集后，稀有的物品不再稀有。

发现这个问题之后，开发组就把掉落的概率改低了。网上指责开发组暗改概率，引起大范围讨论，使得当时游戏遭遇了重大危机，在线人数大幅跌落。这是游戏设计上的bug。

程序上会出现什么样的问题呢？

我们在游戏里做了一个新的副本，为了更有意思和新鲜感，副本里面的怪是随机出现的。刚开服的时候确实是随机的，但是玩了一会儿之后发现在进去之后，副本里只会出现一种怪。经过了很长时间调查，发现这是因为底层调用系统的错误导致的。由于我们的玩家数量多，这些隐藏很深的问题都必然会暴露出来。

千万DAU的手游，又会出现什么bug？

当时某产品有一个很火的主播，8万多个人邀请他加好友。这个主播一打开他的好友列表，我们服务器就直接死机了。其实我们的服务器配置都是不错的，但是为什么还是会死机呢？原因是太多人想加主播好友了，程序没办法响应这种级别的请求。后来为了避免这个问题，我们会把用户请求查询的数据限制一下。

之后我们建立了一个评价质量的体系，网易游戏已经达到了较高的品质要求。但即使这样的情况下，我们也出过很多问题。

因此，通过严格的测试来避免这些bug出现在玩家手里是十分有必要的。

我们是如何在游戏中去做这些测试，保证提供给玩家的游戏是高品质的呢？

最简单的东西叫做验证，看一看游戏开发者的想法和设计者的想法是不是一致，看跳转规则跟UI设计是否一样。现在市面上有各种各样的手机，游戏在不同的机子上运行会存在不同的问题，所以我们要去验证不同手机上的问题。

有时候我们手机游戏玩起来虽然没有什么bug，但是流畅性也是一个问题，在团战的时候会卡，或者完全在瞬移。我们把游戏的测试分成三个方面，第一方面最简单的验证就是流畅性。第二方面我们叫量化评估，看看它的量化指标有没有达到标准。第三点叫做建立标准。

我举一个例子，荒野行动市面上70%多的手机上都可以玩。这件事情是怎么样做到的？如果我们美术同学想表现一个非常炫酷的美术效果，我们游戏的画面会设计得非常精美。但如果玩家的手机性能不足，可能实际呈现出来的效果会变成幻灯片一样。所以我们在游戏研发初期就会去用假的模型测试一些场景，去看它的真实手机性能，根据这样的测试定下来美术制作的标准。

根据这样的标准，我们来制作游戏，可以避免非常多的返工。这些返工一方面会增加成本，另一方面会让我们错失市场的良机。其实一般的软件工程上也有这样的概念，软件中的问题我们越早去修复，越早去发现，修复的成本越低。所以预防永远是要优于验证的。网易游戏对品质要求非常高。一款产品从研发初期到研发后期一直要达到一个高标准，才会交付到玩家手里面去。

下面介绍一下我们做游戏测试用的一些工具。

手机测试有一个很大的问题：安卓手机市场碎片化非常严重。玩家的设备非常多，我们实验室里面采购了几千台手机，这么多的手机设备才能覆盖中国市场上一半多的玩家。

这是网易游戏的一个测试机架，在机架上放着不同的手机，我们可以在上面运行各种各样的测试，可以支持不同渠道的登录，同时也可以调动不同的游戏，包括同样一个游戏里面不同的玩法和各种各样的场景界面。这些测试都是靠自动化完成后生成结果，这样就可以花很少的人力去发现问题。

我们自己也研发了一套技术，实现自动化测试的功能。目前在和Google合作，用于全球安卓开发者使用的云测试环境中。

有的时候我们只是在游戏里面做一些小小的改动，也不需要写复杂的测试脚本。一些小工具可以提高人工测试效率。比如能够同时操纵多台设备，即使这些设备有不同的分辨率或者不同的长宽比，也可以去适配。

还有量化测试，如定义帧率发热等，这时候要借助各种各样的测试硬件。下图是一个测试手机帧率用的视频采集卡，及树莓派的设备。

有玩家提过商场人多，手机信号比较差。为了验证，我们可以带一个设备去商场里面采集真实的网络情况，然后拿到我们实验室的树莓派设备上进行回放。就可以在实验室里面模拟弱网络环境，然后在弱网络环境下去测试我们游戏的体验。

这幅图是一个高速摄像机，就是大家平时看慢镜头就是用这样的高速摄像机拍出的。我们用这些慢镜头来干什么？游戏中有一个东西叫反应灵敏度，我们用他们来测试点开一个界面的时候，是秒开还是非常迟钝。这些都是游戏体验中一些很细节的问题。

总而言之，做互联网产品，细节决定成败，关注游戏体验的各个细节，采用各种方式来保障游戏的质量，这就是我们QA的工作。

《Arena of Valor》（以下简称AoV）是由天美工作室群开发的5V5 MOBA手游，目前在海外超过85个国家和地区发行。

2018年，在第18届亚运会电竞表演赛上，中国队夺得雅加达亚运会电子体育竞技表演项目AOV冠军，这是亚运会历史上第一块属于电竞项目的金牌。

对MOBA游戏来说，英雄平衡性是保证游戏生命力的关键要素之一。英雄平衡性是什么？应该怎么做？

小北是来自天美AOV团队的一名游戏策划，今天他将从数值策划的角度，结合AoV英雄案例，与各位系统性地分享英雄平衡性的含义和设计思路。

玩过MOBA游戏的人都知道平衡很重要，而站在策划角度来看，如果今天要系统地讲下平衡性为什么重要，主要有两个原因：

1. MOBA品类的核心乐趣在于多变的英雄选择和战场变化。既然英雄就是组成多变乐趣的重要一环，那显然某一版本中如果存在某个英雄过强的情况，就很容易就会出现英雄的胜率和登场率双高的情况，从而导致多数玩家都会倾向于选择强势英雄，其余玩家要么就是因为打不过而被迫加入、要么就是因为版本的不平衡而快速流失。为了防止这种恶性循环，MOBA游戏的平衡性迭代都是快节奏的。左侧来自AOV中的截图是我们单个大版本中会进行的平衡性调整列表，可以看到总共有20多个英雄进行了平衡性的调试，当时游戏的实际更新频率是每两周一次，换算过来这20多个英雄的调试也就发生在两个月的时间内。

当然，根据游戏的不同，更新频率也需要考虑两个因素，如AOV两周一次的频率便是根据玩家对版本的适应周期，以及项目组本身所需要的研发与测试时长来决定的。

2. 平衡性可以被视为研发团队与玩家之间的一个长期约定。每个玩家在游戏中对某个英雄的长期游玩都是对游戏的一种投入。所以如果我们无视平衡性的调试，就会导致玩家被版本的强势或弱势英雄摧毁游戏体验。

换言之，我们希望长期让版本的平衡性保持在一个稳定的状态，确保玩家在我们游戏中的投入是持久和保值的。

目前市面上绝大多数MOBA品类的平衡性判断标准都是从胜率及登场率出发，而AOV也是如此。

最基础的判断是从数据层面，除开以英雄的胜率与登场率为主，在评判过程中我们也会纳入一些过程数据，包括英雄的禁用率、选择率，以及对局数据，如击杀、连续击杀等等。

其次是感受层面。随着玩家调研与反馈的增多，玩家的对抗体验感受也成为了我们进行平衡性调试的衡量重点。简而言之，英雄在数据层面的合理不代表拥有合格的对抗体验，而这普遍会反映在玩家感受层面的反馈。

接着则是水平差异带来的考量。这应该很好理解，不同段位的玩家和不同水平的玩家对于游戏的平衡性理解是存在差异的。比如某个英雄的技能是需要瞄准的射击技能，那么水平较低的玩家多数是点触操作，在面对一些高机动的目标时很难命中；再比如MOBA游戏中根据战场设计的策略差异，滚雪球、卡视野、打时间差，这些策略基本上都得是高段位的玩家才能够利用的，而在低段位的对局中，多数玩家只能进行平推或者抱团推，而这些策略、操作水平上的差异也就导致了玩家之间对平衡性的理解不同。

为了从水平差异角度来进行平衡性的衡量，我们进行了一项调研，左侧的图例中，我们将各段位玩家数与其对平衡性的敏感度做了调查，从图中可以看出，通常低段位的玩家因为水平有限，所以对平衡性的敏感度也比较低，通过练习来提高操作及意识水平对这类玩家的胜率影响远高于我们直接对英雄的平衡性进行调整。

而对于高段位的玩家群体而言，哪怕我们只是稍微调整了某个英雄的伤害数值，就可能导致这群玩家或者职业选手选择或者放弃这一英雄。所以将水平差异纳入平衡性衡量是我们需要寻找段位和敏感度的最佳的切入点，也就是大盘用户，比如白金、钻石段位，以及再往上的星耀、王者段位。

另外，由于职业选手以及KOL拥有着很高的传播力，很多玩家会通过比赛或者直播来了解游戏版本，所以我们也会在一定程度上关注这部分高端用户的反馈。

最后是地域差异的角度，比如港澳台、东南亚、欧美玩家在设备、网络以及游戏习惯上的差异。比如越南，多数用户由于机型设备的限制，有大几率会在团战的时候发生网络卡顿及操作延迟的情况，玩家只能进行平A操作，而这也意味着需要高操作、或者看重进场时机的刺客英雄在越南的胜率是整体偏低的。

反过来，在普攻和移速上具有一定优势的射手或者战士英雄的胜率则整体偏高。总体来说，虽然因为设备、网络或者习惯带来的地区差异很难在短期内解决，但是团队可以做到的是尽量保证每个地区，英雄胜率的上下限与强度都在可控的范围内。

综合上面我们所说的四个角度，我们就可以对平衡性的衡量标准达成一些共识。这也是我强烈建议一个MOBA游戏的平衡性团队需要制定的。只有团队成员都达成了共识，才能节省掉过多的会议与辩论，快速做出版本的平衡性调整。

而团队会希望在每次大版本更新之后，每个分路、职业的英雄，从强度到梯度都是有迭代的，让玩家感受到版本带来的变化，并重新投入到对不同英雄的探索中。而基于玩家侧的调研反馈，团队也在不断地对现有标准进行扩展。

1. 首先是基于公平性的共识，团队针对英雄的数据层面进行调整。在AOV这一游戏中，我们最基础的调整标准还是以胜率结合登场率的数据评价，团队内部达成的共识是一个常规英雄的可接受胜率范围大概在47%~53%之间浮动。而如果一个英雄比较冷门、或者只有少数高端玩家在使用，在英雄的登场率较低的情况下我们也会接受他的胜率比常规英雄略高。

另外，我们首先会对胜率及登场率出现双高的英雄进行削弱，而登场率略低的英雄团队对于英雄的胜率上限则会略微抬高；但如果登场率低到一定的界限，出于多样化的考虑，无论此英雄的胜率高低，我们都会进行调整，以确保这个英雄在玩法功能层面能够吸引到一定范围的玩家。

再来就是针对老英雄的关怀。从AOV来看，在版本迭代的过程中，团队对于新英雄的实际强度还是控制在合理范围内的，一个新英雄首周的胜率大概都是在45%-47%之间浮动。但由于每次新英雄登场、版本更新都伴随着新机制或者新功能的投放，玩家会天然地产生新英雄具有优势的感受。

再加上老英雄的机制相比于新英雄肯定是落后的，虽然团队会尝试通过一些数值的调整来增强老英雄，但即使在胜率上与新英雄持平，老英雄在对抗体验的层面或者是在功能玩法的层面，也是落后于新英雄的。所以团队针对老英雄的平衡性调整就包括在每两周或者每一个月的更新中，将老英雄在玩法、功能层面上的数据向新英雄对齐。

最后便是针对对抗体验，也就是我们前面提到过的由玩家感受层面所衍生出来的调整。

这类数据层面无问题，但是玩家反馈体验差的英雄主要有三种问题：

第一种就是使对手完全丧失对抗体验的设计。比如过长的控制链，它会让对手在被控制期间常见无法有效操作，甚至从满血到死无法反抗；还有就是特定机制的过度投放，尤其是机动性（位移）；传统的短腿法师或者射手在面对多位移刺客或者战士时，往往想打打不中、想跑跑不掉，就无法形成有效的对抗。

第二种是清晰度导致的问题。第一，技能特效看不清，例如图中英雄的技能冻结特效，如果放置在河道，因为都是蓝色，所以在实战中经常会出现对手没看见特效就被命中了。第二则是出现预警特效和实际特效不匹配的问题，它在对局中的具体表现是玩家觉得自己被秒得莫名其妙，从而得出对手英雄过于强势，需要削弱。但这种在团队实际研究过程中会发现是由于这一英雄攻击特效不清晰/明显，导致玩家在遭到伤害时没有意识到，从而没有进行相应地移动或者躲避操作。

第三种英雄战略层面上的问题。主要发生在一些功能性辅助英雄身上，他们的功能特色缺乏对应的克制位，所以导致对手玩家的对抗体验极差，这也是团队需要去关注的。

2. 第二是基于多样性共识进行的调整。我们在最开始就提过，MOBA游戏的核心乐趣就在于多样化的英雄选择和战局变化。即使玩家有自己的本命英雄、拿手英雄，但从游戏体验的角度来看，如果多数玩家的阵容处于长期固化的状态，对于玩家而言是会腻味的。所以我们会尽量考虑在每次平衡性调整中都加入新的英雄来优化玩家的体验。

再来，便是针对英雄进行个体/团队中的定位差异化调整。比如上图左侧这些英雄便是AOV中的法师英雄，可以看到每一个法师英雄都有它独属于的标签，团队需要尽量确保每个职业或位置上的英雄之间能够拉开足够大的差异，并且具有可玩性。

同理，这些英雄的团队定位也需要确保有各自的特色。例如MAX这个英雄，他在初始版本中的被动技能减疗效果是25%，但是我们考虑到这个英雄的特色便是减疗，并且在AOV中只有MAX有这个标签，所以在后续版本中将其被动技能的减疗效果提升到50%，确保玩家在面对治疗/回复能力强的团队时能意识到使用MAX作为克制位。

3. 最后，为了增加新鲜感，我们还会在版本中针对战场引导进行调整。比如在现有版本中，如果中路被蹭线的几率较大，导致中路能够拿到的经济变少、却又承担了打AOE输出，面临着钱少事多的窘境，那么团队就会针对性地在下一个版本进行整体调整，增加中路在决定战场胜负上的权重。

讲完理论，我们接下来就进入大家最关注的实践部分。下面我们将从一个英雄从无到有的过程，包括设计、调节、外网平衡三个阶段来进行案例分析。

• 基础数值-初始身板

这是AOV中一个战士的战斗力标准模板。先说下这个模板的由来。首先解释下概念。

第一列是有效生命，它是在计算英雄的生命值、护甲值与减伤后得出的，也就是一个英雄能够承担的最大物理伤害。

然后第二列是预期输出，打个比方，如果一个英雄的攻击力是100，而他每秒的输出是2.5倍攻击力，那么这个英雄的预期输出就约等于250。

再来就是第三列的预期击杀时间（time to kill，后面简称TTK），这里计算的是两个英雄对打时能够分出胜负的预估时间。这里要着重提一下，上图为一个标准的战士模板，预期TTK在前面单人对线期大概是10秒，而到了后期，考虑到团战等因素，我们的预期TTK就拉大到了15秒。

这么做的原因是在AOV之前的版本中，曾经遭遇过由于英雄后期TTK过短，导致脆皮角色对战时很容易出现互秒的情况，而这种没有反馈的击杀本质上就是糟糕的对抗体验。所以为了拉长后期TTK，团队曾针对英雄进行过后期TTK做过一轮放大。

最后一列是战斗力，顾名思义，是基于预期输出和有效生命所进行的乘积计算，代表了英雄在生存的空间内能打出的最高伤害值。

而在做完一个，攻防均衡的战士英雄模板后，我们就会着手进行拆分定位，比如更倾向于防守的坦克，或者是更倾向于输出的刺客和射手；而在定位拆分的基础上，我们同时会对成长做拆分，比如强势期在前期的英雄就会拉高前期数值，但是相应地成长性会有调低。最后还有战场的拆分，比如装备与英雄基础身板的伤害/生命加成比例。

• 基础数值-技能加成

在完成了英雄的基础身板设计后，我们就会开始考虑技能对英雄战斗力的放大。这里我放了一张技能加成结构的图，图中所展示的是技能基础值和装备加成在技能伤害中的比例。

通常来说，拥有高装备加成属于刺客或者滚雪球能力强的英雄。这类英雄如果能在前期拿到击杀或者是取得装备优势，对于装备的利用率会更大。而装备加成较低的便是辅助类英雄，这类英雄不承担吃经济的定位，但他们具有的是战略价值，我们会将辅助角色再前期的基础值提高，相应地在技能和装备加成上则会拉低。

这里有几个在评价英雄强弱时的关键数据需要我们重点关注。

第一是爆发伤害，英雄的一套技能打出的伤害数值以及爆发的窗口期长短。另外还要针对木桩的稳定伤害，这两者都是我们衡量一个角色输出能力的关键指标。

第二是生存放大，主要针对坦克或者是重装战士这类防守职业，会关注技能对这类英雄生存能力的放大。

第三个是控制/机动投放，这是一个比较难把握的关键点，我们在设计时只能先基于每个职业的标准角色所持的控制/技能技能数量，来对新英雄进行投放。虽然玩家普遍倾向于能秀、也就是机动性高的英雄，但是我们却需要在投放时把握好尺度，给新英雄投放过多的控制/机动技能会让老英雄处于尴尬的位置，整体的游戏环境也会变差。

第四是打击距离，它可以当做针对于控制/机动投放的一种对抗手段。如果一个英雄的机动性过高，我们会在它的身板，比如血量以及战斗距离上做衰减，确保没有位移技能的英雄对上这类英雄时能有生存空间。

• 基础数值衡量-定向对比法

当我们计算好了一个英雄的基础数值之后，我们就需要进行第一轮的平衡调整，确保这个新英雄不会过于过强（overpower，后面简称OP）。而在这里，我们最经常使用地、用于评价英雄的方法就是定向对比法。

拿法师英雄为例，分为输出型的炮台法师和控制型法师，而这两种定位的法师英雄在伤害值上就有不同的标准，比方说输出型的炮台法师场均伤害在6万左右，控制型法师则只在5万左右。而当一个控制型法师的场均伤害经测试达到了6万，也就是炮台法师的标准时，我们就会判定这个英雄是OP的。

而除了最常规的身板数值，我们会观察英雄在同职业、同分路英雄中的排位情况。包括输出能力、生存能力、发育速度的数据，确保英雄的整体强度在同职业或者同分路的类型英雄中处于正常水平。

再来，我们基于过去的经验，针对性地关注新英雄的关键数据，避免以前踩过的雷。比如对于刺客类英雄而言，爆发输出是关键点，一个刺客英雄的爆发伤害每增加3%，胜率就能加1%，而持续输出的影响则没那么大。所以我们在对刺客英雄进行设计与调整时，对爆发伤害就会着重关注。

但这里所说的种种调整策略，也只是在数值层面根据对比与过去经验进行微调，而实际上我们要考虑地还有英雄的对抗体验等因素，假如我们想提升某个英雄的人气或者削弱某个OP英雄时，单从数值入手做简单粗暴地拔高/拉低实际上不会起到很大的效果，需要考虑地还有更多。

• 复杂机制-功能类

而这就涉及到数值策划在工作中要面临的一个日常灵魂拷问。许多英雄设计师往往在第一版设计中会加入自己的很多创意，给英雄投放的技能都是功能向的，比隐身、霸气、不可选中等等。

这些功能相较于数值类的技能，都是不可量化的，而许多英雄设计师灵感一来、创意一个个地往新英雄身上塞，很容易导致OP。所以接下来我们就来看下如何衡量这些不可知、不可量化的功能向技能，确保英雄在游戏中整体是平衡的。

1. 删繁就简

首先来看下一个新英雄的第一版策划案。从图中的技能描述中，我们可以看到设计师的大体构思是设计一个双形态的射手/刺客。从左面的实际游戏画面中可以看到，这个英雄的远程普攻会在敌方身上留下血滴叠层，然后当英雄切换到近战状态后，可以将所有的血滴叠层消耗掉来造成一次高额的伤害。

但实际上，我们在看到这个英雄的第一版设计时，会发生里面有许多不可量化的功能向技能。比如被动技能中的隐身、获得真实视野、躲避指向攻击的功能。这些就是不好把握的，在我看来已经近似于无敌状态的加成。

再比如下一次位移之后附带普攻的技能描述，这会让英雄的整体爆发伤害变得很高，一次位移两次普攻的伤害再加上装备武器的加成，会让这个英雄的爆发伤害在刺客类英雄中都排到中上的位置，并且技能中还有沿途增加位移物理伤害的设计，所以从爆发伤害来看这个技能就是OP的。再加上这个英雄的大招机制是与地方换血，提升移速、攻速以及获得侦测视野的功能。所以接到初版策划案时，身为数值策划的我是一脸懵逼的。

在这种情况下，我们首先要做的就是与英雄的设计师进行沟通，第一个是理清对于设计师而言，这个英雄必须要保留的核心机制、定位是什么？拿这个案例中的英雄为例，设计师认为远程叠状态+近战爆发的机制，以及控制自身血量的二技能是他的核心机制。

所以在确定了这个英雄的核心玩法为控制血量之后，他的输出循环就很清晰了：远程耗血，对敌方造成伤害并叠加印记，近战可基于引进进行爆发输出与回血。当我们确定好英雄的核心机制后，再来看大招技能中关于“根据敌方血量判定获得攻速与移速的提升”的描述，这就是需要调整的一个点。无论是基于机制设计或是实战环境的考虑，英雄的定位是脆皮，远程耗血的设定使得他的血量控制一直很低，而且在实战中一般没有精力进行敌方血量的判断，所以我们将技能改成了根据自身血量获得移速提升。

接着就是对影响对抗体验、或者与英雄本身机制不相干的技能进行删减，比如被动技能中关于“自爆使敌方无法获得赏金”的描述。整体而言我们会聚焦于将英雄的核心机制进行优化，而对其他不好量化的功能型技能进行限制和删减。

而为了让新英雄兼具玩法机制上的独特性，同时又不影响平衡，我们需要在过程中与英雄的设计师进行及时的沟通，因为我们要做的是帮设计师理清思路、而非限制他们的思路，才能够实现新英雄在数值设计上的合理可控。

2. 控制技能的投放

第二个我们要讲的是控制技能的投放思路。在近期，我们就受到了玩家关于游戏中控制技能所造成的对抗体验较差，大量的点控和散控技能经常导致玩家的操作遭到干扰限制。基于这类问题，我们也对硬性控制技能的投放做了调整，变得更加谨慎。整体上的投放思路是基于击杀时间与职业特性来决定的。

基于击杀时间的考量是假设一个脆皮角色在对局中后期的击杀时间在3-5秒，我们就会保证他受到的控制技能效果大致在2秒左右，确保玩家有一定的逃生空间。而基于职业特性的考量则是对于能够在团战中切到后排的刺客类英雄，我们在硬控的投放上将进行限制，让这类具有爆发伤害的角色不会过于OP。

再来就是限制控制技能的射程、长度，比如稳定控制技能的射程一般不会超过射手的攻击距离，以免起手就能切入后排的技能存在；而限制控制链的长度就是基于一些玩家反馈在游戏中被连控的体验很差，我们所进行的一定调整。比如玩家被一个控制技能控制0.5秒，而后可以移动0.5秒，然后又被控制0.5秒，而在这间隔0.5秒的操作空间中，其实大多数玩家很难及时地做出反抗，很轻易就会被后续的控制技能命中。所以我们现在对于这类存在控制链的技能，会对中间给予敌方可反抗时间做优化，而如果可操作的间隔时间太短，我们会将整个控制链的时长视为控制技能的时长来进行衡量。

3. 机动技能的投放思路

这也是AOV在近期版本中所面临的一个问题，许多玩家都会反馈后排脆皮角色没有位移，对抗体验很差。而这类问题就与上面所说的控制技能投放比较相似，我们的思路还是基于职业特性来进行机动技能的投放。

我们对于控制、机动、爆发类技能的投放上限调整还是针对刺客类型的英雄，例如两段位移的距离是8米，那么我们在进行技能设计时会注意，只有具备超高机动性的刺客才可能在10米的距离迅速贴近后排的射手、法师类英雄。而针对后排英雄，我们则对加减速技能的覆盖率进行了扩大，提高他们面对刺客英雄时具备一定的操作空间。

整体而言，加减速技能与机动技能的投放是相当的。为了制衡机动性技能，对于机动性高的英雄，我们设定的血量便越低；而对于无位移的英雄，则会给到较远的技能射程，确保整体的对抗体验是相对可控的。

4. 命中难度预设

关于命中难度的设计，我们通过上图这个例子来说明。这是游戏中一个前摇时间最长、同时能够造成很高伤害的技能，但它的特点就是命中难度很高。技能从施法到出现预警大致需要0.2秒，而从预警到爆炸大致又有1秒的时长。

通常情况下，敌方玩家看到预警之后，会有0.2~0.3秒的时间做反应，然后还有1秒的时间进行走位。假如一个英雄的标准移速是400，1秒的走位空间大概就足够移动4米的距离。所以当这个技能出现在英雄脚下时，团队就会考虑玩家是否能够走出爆炸伤害的范围，在这个技能中，范围是2.5米的圆径，也就是说一般英雄，即使被套上了轻度的缓速技能，也有走出爆炸范围，躲避伤害的空间。

这里基本上就是我们对于高伤害的范围技能所进行的限制思路，我们会对每个技能的命中参数标准做基本的预设，然后根据伤害的高低，对于这类技能的命中难度进行预设。

• 其他功能机制的衡量

这里我们举一个辅助英雄的案例来看下。这个英雄的二技能是吸纳友方英雄，同时它也可以吸纳兵线和野怪，结合能够滚动长距离的大招机制，英雄就具备了偷塔、开团和撤退的功能，既可以吸纳友方英雄在团战中拉开距离，躲避伤害，也可以吸纳兵线到敌方塔下偷塔。

所以我们就会从这三个功能的角度进行考虑，首先偷塔的方向，敌方有多大的反应空间？当敌方看到英雄吸纳兵线时，猜测到他偷塔的意图后，便会开始移动，进行守塔，所以我们要考虑给到敌方反应并进行跑图的时间。甚至更极端一些，如果我们判定这个技能要偷塔实在太过容易，可能会加上全图预警，提示敌方尽快到塔下集合守塔。

除此之外，我们也发现这个技能的成功关键在于英雄吸纳兵线后的滚动速度，它决定了从英雄开始发动技能吸纳兵线，到他带兵冲到敌方塔下所需的时长。所以整体来看，滚动速度是衡量技能能否成功的关键参数。

再来就是撤退功能，在这点上我们主要考虑敌方能否通过输出伤害来迫使英雄放出队友，再一个是技能发动期间敌方能否追击上英雄，所以限制这一英雄的核心参数还是滚动效果，也就是滚动速度和最大距离。

我们通过这个案例可以发现，对于具备高功能性的英雄来说，常规的削弱伤害或者控制能力是不能用来衡量其技能强度的。就如这个英雄的平衡性、强度把控在于技能的滚动速度与最大距离。

最后再给大家总结一下个人在工作中总结的一些平衡性调整需要注意的小技巧。

• 1+1>2

第一点，我们在进行每一个版本中包括英雄、战场、装备等方面的平衡性调整时，主要的目标就是避免各个方向的调整互相叠加产生指数倍的效应。以上图中的英雄萝尔为例，左侧图显示的是她在一个版本更新后的胜率变化。

实际上在那次更新中，我们并没有对萝尔进行加强，这个英雄此前的胜率一直稳定在52%左右，处于健康的范围，但在更新过后便提升到了56%，所以我们针对性的做了一次回顾。

首先我们修复了英雄的一个技能丢失伤害的bug，但是基于我们预估的话，对其胜率的影响应该只有1-2%；第二个则是英雄的核心装备获得了加强；第三，当时的版本中增加了中路兵线的经济，而萝尔是一个发育型的英雄，中路经济的增加意味着萝尔的发育速度变快了。

当时为了弄清楚每项调整对于英雄胜率的影响，我们花费了很多时间。所以经过那次经验教训，我会建议在一次版本更新中谨慎进行多个维度的加强，否则一旦调整效果脱离了预期，很难快速地定位问题并进行解决。

• 体验服测试

第二点，我们在进行新英雄，或者新机制的调试时往往会通过体验服的数据来进行判断，但事实上，体验服的玩家基数与对局场次都是过小的，所以如果我们拉取体验服一个英雄的胜率情况，会发现由于胜率是一个0/1的数据集，输了是0，赢了是1，所以在对局场次不够的情况下，英雄的胜率波动会非常夸张。

所以我们首先会更多地关注一次调整对数据带来的波动性是相对可控的，比如我们将某个英雄的伤害提升了它100点，我们会关注这100点对总伤害的提升，并以此来预估相同比例的伤害提升在常规服会对胜率造成的波动。

第二则是尝试通过一些适当的手段来提高对比质量。比如当我们对一个冷门英雄进行调整后，我们希望玩家体验他，测试是否有BUG存在或者强度是否合理。这时我们会通过一些运营手段，比如投放皮肤来作为进行对局的奖励，以此来提高测试玩家的积极性。

最后还有一个需要注意的地方，体验服中OP的角色与装备需要尽快地处理。体验服作为我们进行测试的服务器，任何英雄/装备的单一变量都会对游戏中整体的英雄强度判断造成干扰，所以如果发现英雄/装备OP的情况，应当快速地进行屏蔽，解决问题后再进行投放测试。

• 膨胀幅度的控制

在AOV的迭代过程中，我们会希望保证整体的英雄强度、战场环境都是有序膨胀的，这就要求在每个版本的更新中尽量保证加强和削弱的幅度都是相对可控的。

首先我们会对每个职业的标杆英雄强度，比方说胜率进行关注，将一年之内整体英雄的战力膨胀控制在5%-10%之间。这也是吸取了从前的经验教训，因为某一英雄的过渡膨胀带动整体英雄的战力膨胀。

对单一英雄、装备的伤害加强都会带来连锁反应，直接的结果就是英雄在后期的伤害爆炸，团战的击杀时间缩短，许多玩家在团队中甚至没来得及反应就已经死亡。所以现在AOV会比较注重膨胀幅度的控制，确保整体游戏体验是良好的。

写在末尾的其实也是最重要的一点，就是加强团队在平衡性调整上的共识。

无论是策划内部对于平衡性的衡量原则与方式；还是与运营之间的沟通，让彼此理解调整背后的逻辑，这都影响到工作中的协作与效率。

此外，团队必须重视玩家意见，保持与玩家沟通，让大家了解英雄调整背后的思路。

以上就是我的分享，如果大家对MOBA英雄平衡性设计有任何想法，欢迎在评论区留言。我们期待与你交流！

来到游戏研发行业，

当你穿过满满当当的工位，

在无数让人望而脱发的文档、表格、

PPT、代码、美术/音频软件的屏幕旁边，

有时会发现这样扎眼的身影：

ta戴着耳机，明目张胆地玩着游戏，

象征意义上的掩体，就是ta单薄的身躯。

你佩服于ta豪放派的摸鱼作风，

直到ta突然放下设备，

打开测试用例进行检查和备注，

你才会意识到ta的真实身份，

竟是个游戏测试工程师！

“做游戏测试不就是天天打游戏？”

"好像只是点点点，so easy？！"

“带薪摸鱼肯定很爽！！”

是许多人对游戏测试的第一印象。

但事实上，游戏测试肩负着不轻的职责，

也需要培养专业的能力。

游戏测试，常被称为QA（Quality Asurance）

是游戏研发中必不可少的工序，

目的是通过严密的排查测试，

尽可能减少游戏中出现的bug，

确保所有功能模块符合预期，

使游戏以最好的质量和体验呈现在玩家面前。

因此，游戏测试的覆盖范围非常广泛，

通常包括各种数值配置、运营活动、设备兼容、皮肤特效...

还可被进一步分为功能、性能、自动化 ... 等测试类型，

测试点各不相同，但整体流程较为相似。

接下来我们以《王者荣耀》的皮肤测试为例，

了解大致的流程应当是怎样的！

游戏测试不是漫无目的地玩游戏。

为了确保测试严谨与效率，

流程的第一步通常是设计测试用例，

也就是根据各种策划或需求文档，

编写包含测试目标、测试环境、

测试步骤与预期结果等的规划，

大致相当于一张覆盖所有测试点的checklist，

逐项验收，排查潜在缺陷。

在《王者荣耀》的皮肤测试中，

用例通常是在各种特定条件下穿戴皮肤，

对英雄进行操作，

以发现皮肤设计、配置、表现中的错误，

对皮肤是否满足设计要求、质量是否达标做出评估。

皮肤测试主要包括三大类，

分别是功能测试、性能测试、打击感专项。

首先，功能测试是根据游戏设计，

预想玩家可能看见、听见的所有内容进行测试，

比如皮肤的动作、特效、音效等资源，

校验基础功能是否完整无误。

《王者荣耀》中拥有多种品级的皮肤，

比如勇者、史诗、传说等，

越高品级的皮肤，

其专属动作、定制背景、定制音效等特性也应当越多，

测试会据此验收，判断是否符合标准，

同时，功能测试中也常常会发现一些技术问题，

比如穿模、颜色过亮/过暗，甚至出现单一色块等，

这些问题都会通过提单，反馈给研发同学去修改优化。

除了这些能够肉眼发现的问题以外，

也有许多细节体验方面的问题，

相对不易察觉，

更考验测试者的细心与经验判断，

比如皮肤技能生效范围与特效范围是否一致，

动作、音效是否匹配，

也是功能测试需要去保障的范畴。

不限于局内表现，

任何皮肤的展示场合，

玩家能够触达的地方，

包括个人资料页、商城、大厅、

选将加载阶段、赛事系统与AR相机，

甚至是复杂的英雄交互过程，

比如鬼谷子、元歌等特殊英雄交互下的表现，

这些方方面面也是功能测试需要逐项覆盖的模块。

要确保测试结果的准确无遗，

不但依赖于专业规范的测试用例，

也同样依赖细心严谨的专业测试者。

能够准确辨别问题、反馈问题、沟通跟进，

也对从业者的开发理解和交流能力提出了较高要求。

当然，有时尽管测试者付出许多努力，

Bug 却在所难免，

这是因为在持续更新迭代的过程中，

偶尔会有已上线的皮肤资源出现问题，

比如音频缺失，特效出错。

《王者荣耀》中有着数以万计的音频资源

以及数量庞大的美术资源，

这些是难以通过手工测试去全部覆盖的，

因此，就需要搭建配套的自动化测试工具。

过去两年中，

《王者荣耀》就集中测试与开发团队的技术力量，

通过引擎工程、控件识别与点击、云真机、

图像对比识别、音频特征识别等技术，

建立起一套全量皮肤美术与音频资源的自动化测试工具，

与手工测试互补，尽可能避免bug的出现。

自动化测试与工具开发，

同样属于游戏测试行业的一个分支，

测试者需要掌握更多开发知识与技术，

能够读懂代码，搭建和优化自动化测试框架，

也是一个值得努力的兴趣方向。

其次是性能测试，

它是功能测试的一个延伸，

在确保功能正常使用的前提下，

寻找可优化的节点，

使游戏在设备上的表现更稳定、持久、流畅。

在皮肤的性能测试中，

可以简单理解为，

如何避免使用皮肤时，

出现卡顿等体验感受，

性能表现通常与资源占用率有关。

由于测试是最后一道验收环节，

反复修改与测试会对效率造成很大影响，

因此在美术制作后，合入版本前，

团队会启用静态资源扫描机制，

主要是解决美术占用较多资源的问题，

比如粒子特效用了固定数值的纹理等，

对此进行针对性优化。

这个环节不仅能保障皮肤不出现卡顿等情况，

也给美术同学预留了充分表达的空间，

做出让人眼前一亮的效果。

在每个版本上线前，

团队也会通过自动化测试工具，

对全量皮肤进行性能测试，

确定满足性能标准，才允许对玩家开放，

尤其是全新皮肤与优化皮肤。

最后是打击感专项测试。

打击感并非一个常规的测试环节，

而是过去两年中，

《王者荣耀》逐渐建立的新测试体系，

原因在于，皮肤体验总是受到最多关注，

而皮肤的建模、动画、特效、音效等设计，

都可能影响到皮肤的使用与打击感体验。

比如数值相同的情况下，

“鲁班七号·电玩小子”的双腿摆动角度较大，

跑动似乎更欢快活泼，

而“韩信·街头霸王”的模型少了外袍，

看起来似乎更轻盈利落。

团队希望探索在不影响平衡性的前提下，

尽可能为皮肤做出差异化的特色表现，

同时提供上乘的打击感，

确保玩家的良好体验。

打击感专项测试，

是综合各种因素的量化评估，

而如何从模糊的体验手感中提炼出具体的影响因素，

也是测试工程师专业敏锐度的一种体现。

游戏测试工程师看似是在“打游戏”

但其实有许多值得钻研的地方。

比如编写专业测试用例的逻辑能力，

定位体验缺陷、优化细节的洞察能力，

或是优化测试流程、提升效率的思维习惯...

尽可能保持不设限的认知格局，

方能在游戏测试的道路上走得更开阔长远。

相关阅读：

11月18日晚，在Unity线上技术大会游戏专场，《帕斯卡契约》的总导演兼美术总监丁成甲分享了他们的制作流程和思路。这款游戏是少有的单机手游，而且在前不久，它的销量超过了100万，实属难得。

《帕斯卡契约》身上有诸多的特殊性，它在手机平台做出了主机游戏的观感，甚至因此登上了苹果发布会，成为经典案例。但实际上它并没有硬堆品质，而是采用了很多取巧的方式，规避了过度的资源消耗。

从最开始，其研发团队Tipsworks只有10个人，到现在也维持在30人左右。这次分享最有意思的地方莫过于：在团队人手有限的情况下，如何发挥自己的长板规避短板，找准制作的思路，从而在移动端实现一个足够亮眼的效果。

以下为丁成甲的分享：

大家好，我是《帕斯卡契约》的总导演兼美术总监，负责项目里的剧情框架、游戏玩法还有美术表现。本期我会以游戏制作的角度来介绍一下《帕斯卡契约》的创作流程，展示一下在创作《帕斯卡契约》中，我们经历了哪些阶段？最后我会举一些游戏中的例子来解析一下美术表现与优化。

首先介绍一下我们的项目，《帕斯卡契约》是使用Unity来制作的一款动作角色扮演项目，最开始我们用的是Unity的5.6版本，后来到研发的最后一年我们升级到Unity 2018。我们从2016年开始研发，大概消耗了三年的研发周期，制作人员在第一年大概有10个人，一点一点扩大，到最后一年我们大概有30个人，整个项目95%的资源都是自己产出的。

这就是我们公司的一面墙，早期的时候我们会在墙上面去做很多的尝试，其实我们早期也没有太多的方向，当时做了非常多的风格尝试。

接着我在地方出了一个这样的小稿，这是一组黑暗中世纪题材的概念图。出了稿子以后，当时工作室里的每一个人看了稿子以后都觉得非常有兴趣，大家出乎意料的一致，觉得方向可以试一试。

确定了目标以后，我又继续做了一些人设的细化，那就有了现在这张图是有剑士，有女巫，有贵族，猎魔人，重甲骑士等风格。

但是因为我们当时就10个人左右的人力，决定还是把体量控制的小一点，我们商量了一下，觉得做一款中世纪题材的动作对战游戏，可能是一个比较保险的方案。

然后就到了我们项目开始定初期目标，这阶段我们觉得定的目标始终要量力而为，定一个可实际完成的体量，定一个可实现的玩法，而不是说我脑子里有非常多、非常赞的点子，但是实际制作的时候处处碰壁，结果你只能完成它的60%或者70%。所以我们考虑了很多，希望把制作体量控制在一个可掌控的范围之内，这是我们当时做的一个初期的联机对战Demo。

当时10个人花了一年，做了一个已经可以刷到手机上的联机对战模式，可以WiFi联机，就像《荣耀战魂》一样的PVP，但是当时确实游戏性和画面都没有调的很好，游戏内容略微有点单薄，所以我们决定加入一些PVE元素。

这是接下来为PVE模式出的一张场景设定，一个看起来有点诡异而破败的村庄。为此我们开始思考游戏的世界观和简单的一些故事。

当时我们做了一个所谓基地的PVE玩法，怪物不断从远方涌过来，玩家保护基地，需要不断的击杀怪物获得能量，然后用能量强化自身，不断的迎接下一波怪物。

这个PVE玩法现在看起来非常简单，但是对于当时来说，对我们来说确实意义非常重大，因为时候我们终于得到了一个像样的游戏框架，而且玩起来确实也蛮有趣，那给了我们前期非常大的信心，我们看到这一步了以后想想还不如把这块好好做一做。

有幸的是场景最后被保存了下来。这个场景现在是我们最终上线了以后，第一关海格姆的画面，基本保留了原来那块区域，然后在这个基础上又继续扩展了场景，这个时候我们目标就比较明确了，项目正式开始推动起来，就像滚雪球一样越滚越大。

关于世界观的包装，我觉得我们有一些自己的想法，特别是做一款手游，当游戏受到了体量的限制，我们不能去做地图很大的这种游戏，你就不可能让玩家随心所欲地去任何地方，那玩家一定会想为什么我去不了对面那座山，我过不了对面那个河，时候我们一定要给玩家一个合理的解释，让玩家觉得这是一个合理存在的世界。

所以我们的做法，我们在项目上的做法是在世界上当时加了一个设定，比如说这个世界失去了光明，只有在有光的地方才是人类正常可以活动的区域。

那么世界就需要一种发光体，可以让故事可以让剧情，还有整个世界聚焦，非常自然，我就设计了上面生物，它为世界带来光明，人们依附他而活，形成了这个世界观。

所以当时我们决定我们需要一个与世隔绝的被黑雾笼罩的世界。那这里生活的人们的故事以及发掘这背后的秘密自然就成了剧情核心。我们创建的场景就会是生活在世界里的人们的生态环境，同时也需要一个完整的故事链。

主线剧情就一点一点的，主要的人物一点一点的添加进来。然后世界观的设定又不断的完善，再回滚，在整个世界观里面不断的回滚，关卡设计也在不断的更新。最后我们得到了我们想要的故事体系和世界观。

当世界观设定好以后，我就希望世界中的一切体系，一些系统，包括玩法系统都是服务于世界观的。所以当时设计了理智系统，这是一个绝望失控的世界，每个人都有可能在崩溃的边缘，那么主角当然也不例外。他看见的所有的疯狂的事情，或者是这些疯狂会燃尽他的所有的理智，他可能时时刻刻都处在理性和非理性的边缘。

在混乱的世界中，当理智崩溃时会遇到什么？看见的是灵异的怪物，是发狂的boss，还是背叛的队友，这些都是通过游戏的理智系统所表现出来的。但是还是在一个统一的世界观之下，所以这是一个完整的包装，不是说把玩法还有美术，还有剧情全部拆开来处理。我们希望无时无刻的提醒玩家，你正处在一个疯狂的世界中。

画面设定与取巧。当时考虑到我们就这么点人力，还得想办法去节省资源和减少工作量。所以我们做的这个世界观的设定里，外面的世界都处在黑雾中，整个游戏都处在浓雾中，而且光源又很微弱，看不清远处，所以游戏的视距就不用开的很高，以及不用制作一些非常繁琐的细节，也让我们制作的实际体量确实小了很多。

关于上面这块怎么做，我会在后面的场景制作的一个环节里会具体去分析，下面这是我们的一个主角团。

在最开始做角色设计的时候，我们其实有考虑过很多问题，比如手机屏幕比较小，人物占比会比较少，所以在设计的时候会把比例稍微做的夸张一点，物件的厚度都做得比较敦实，没有特别细小的设计，基本上以体块为主，这样的话哪怕东西缩小了，在屏幕上并不是很大，你还是能感受到它的体积感和体块感。

下面这张图是基本的角色制作流程，比如从原画到高模，再到一个材质的绘制。

材质绘制流程上，开始会用painter来对材质进行一个写实的绘制，基本上是走PBR这套基本流程。

因为手机内存非常宝贵，贴图使用有限，我们主要还是把重点放在了材质的调节上，下面是游戏引擎里还原出来的一个实际效果。

在做的时候我们基本上是一个全尺寸贴图，会最终会根据游戏的内存来进行一个优化。

我们基本上贴图不会去专门去压缩，像diffuse和specular可能会看情况进行一些压缩，主要是看内存的盈余，我们深入的去研究了Unity的标准的standard的标准材质，而且Substance Painter和Unity也做了非常好的衔接，几乎一导出就可以只针对Unity5的当时的那个标准材质可以输出。

最终我们用到的贴图有三种，一种是Specular这种金属度或者是粗糙度，基本上是在阿尔法通道里去调整，整体来说用的是一个比较省资源的做法。

这是另一个角色，她的特色是攻击别人的时候，同时可以吸收别人的生命，存在身上的血瓶里，这个血瓶会根据它的自身的攻击，或者是对自身的回血上下浮动变化。

针对这个血瓶，当时我们是用Shader graph来实现效果，并且可以随着人物的位移，你可以看到液体在里面晃动，它基本上是可以保持水平面的一个移动。当然这只是做到一半，最终实际效果要比这个好一点。

这是我们的一个小罐。

主角团和boss我们基本上是使用了一个PBR的流程，但是因为主角或者是boss都是相对单数出现的，所以每个角色的材质球的数量控制可以控制的比较准，我们大概是做了3~4个，分为武器、服装、头头发和皮肤基本上分为这几个材质球。

而普通的怪物在一款ACT游戏里，可能会在一个场景里同时出现多个，所以基础用的材质相对比较简单。虽然说用的比较简单，但是我们还是跟boss是一个生产流程，是用Substance Painter里面来导出出来的传统，只不过说是材质球用的是比较一个传统的材质球，它的一些反射度或者什么，基本上用的是一些反射环境球来模拟的。

下面这是一个boss，游戏里会有非常多的这种非人性boss，给动作确实添了很多麻烦，我们角色有300多根的骨骼，不过是因为在特定战斗场景里只有主角和boss，所以这种消耗也是能消耗得起的，还能接受。

大型boss战我们使用的都是骨骼碰撞，会根据打击点的部位做出IK的受击反馈，比如说弱点受击判断。而小怪基本上使用的是胶囊体碰撞，这就是刚才说过的一个场景里，单个一个怪和很多很多怪，中间要做一个取舍。

然后是场景制作，这里我会举一个具体的例子，我们的阿达米亚的一个场景来解析一下它的制作流程。

从制作思路上来说，第一关结尾的时候，刚刚向玩家展现出了这么一个世界观，玩家刚刚知道头顶的那个大月亮其实是一个我们游戏里的一个巨像，在正对着你。

这一关就希望非常明确的让玩家知道这是一个什么样的世界，所以这一关的主题就是要玩家始终能看到巨像，希望达到的效果就是整个游玩过程中可以看到这个大家伙就一直在你身边行走。

大概确立了剧本以后，首先我会先出这样的一个概念设计图传达出大的思路方向，以及确立一些主要的特殊事件场景，因为当时第一关画面有点阴暗，那希望第二关可以明亮起来，但是又要有那种诡异孤寂的气氛。所以思路明确了以后，就用Unity的地形工具，以及简单的一些石块刷，快速出一个layout，这个主要是用来提供给策划，让他们明白整个关卡和气氛还有大的一些结构。

那关卡策划在看了layout以后和概设，他可能大概就明白了，像阿达米亚这样的一个场景，它是一个以悬崖为主题的场景，在接下来进入白盒阶段的时候，就不会因为理解错误而走偏方向。

为什么要做这一步？就是如果你直接让关卡来搭，很有可能会完全气氛上、剧情上，还有一些美术的结合，它不是能很好的结合在一起。所以一开始虽然是多做了一步，但是你只要传达出一个概念或者给出一点元素后，对后期来说其实是会省很多问题的。

到了这一步我们交给关卡设计师进入白盒阶段，在这个阶段就是不断的完善回滚，把角色放进去，不断的测试，不断的测试玩法、测试路线，待整个关卡验证完成以后，那开始用美术资源逐步的代替白盒。

这是一个当时做的关卡的白盒测试，主要是用来测试路线和场景比例，即使是这样，有时候还是会出现比例问题，白盒阶段要搭场景，记得一定要搭得宽大一点，可能会看起来有点空，但是随着中后期，你那些中景或者一些细节东西放进去以后，慢慢会变成一个比较舒适的比例。

我们在做帕斯卡的过程中，确实有好多次做白盒的时候感觉还行，但是小物件一添加后，几乎没有战斗空间，最后只能砍掉重来。所以这也是一个需要注意的点，希望大家引以为戒。

然后是场景的路线优化。在阶段我会要求关卡，策划同学特别注意，因为我们后面会用到剔除遮挡和视锥裁剪这两个东西，所以我们前期的时候规划的时候一定要特别注意，在路线设计的时候，要多转几个弯或者进入室内，或者是你让远处的视野里被一些巨大的物体遮挡住。所以游玩路线也会决定游戏后期的优化方不方便。这主要是控制视野内的模型面数与Draw call。

作为手机游戏在前期的时候规划路线的时候，确实应该要考虑到更多方面。这是刚才说的遮挡剔除。

比如说场景尽量减少出现一条又长又直的路，或者是视野范围特别宽广的地方，比如说像上图绿色的里面的露出，就是绿色部分里露出的远景，其实运算量还是能接受的。

更远处的景其实已经被其他远处的房子剔除掉了，基本上不会参与运算，那如果真的你有特别大的需求，要做一个大的这种大视野的场景，一般这种也是会专门去定制，比如说你要做一个特别大的塔，从底层到高层也都可以看得特别清楚，那你可能只是底层这一段会做的比较精细一点，上面可能也就是透掉了，或者是做简化处理。

然后说到场景材质这一块，场景材质我们基本上是用的Substance Designer来制作，整场景的材质球数量控制是相对比较严格的，基本上30~50之间，一个场景的所有的材质球，但是确实也造成了一些问题。

帕斯卡契约本身场景有一种材质重复度过高的问题，但这就是两边的一个取舍了，你是大的场景、内容，要么内存会爆，要么你就是在视觉上会做出一些妥协。

这是用Designer来做的一个砖墙的材质，那Designer的最大优势我觉得是可以快速的用连接节点这些，根据需求快速修改，快速迭代，效率会非常高，做出来的东西你也可以根据一些实际的需要进行修改和加工，非常节省成本。

尤其是当场景比较大，特别宏大，需要很多材质需要重复使用时，Designer 制作材质它可以重新采样，随机生成一道符合美术风格的新的材质，大大节省了时间成本和人力成本。

我们项目中其实并没有使用Unity的那套地表编辑器，主要是因为我们地表的场景有时候会达到3~4层，而且地表的面积相对也比较窄，用编辑器比较难处理，对后期优化也比较困难，不过是要看具体项目需求的。

如果是项目比较开阔，地图开阔或者平整的话，Unity的地图编辑器其实是相对非常成熟的。我们这里其实是做了一个材质球，通过一张MASK贴图来混合两种地表纹理，用顶点色其实也是可以达到相同的目的。

说到灯光这一块，场景制作的场景光照，整个游戏是使用了实时灯光加烘培，加light Probe。这三块那实时灯光这一块的话是角色和怪物的，还有场景里的实时灯光，这三块灯光其实是分开的。其实主要是为了方便调整场景的光线，整体场景用的是一盏mix灯，来提供整个场景的主光线，角色和怪物是用另一盏实时灯光来打整个人身上的明亮度和高光。

烘焙这一块我们主要使用的是混合灯光进行烘焙，模式使用的是Shadow Mask这种烘焙模式我们在用的时候有一个小小的问题，就是它暗部被覆盖的面积比较大时，高光会被这张MASK贴图盖住，会造成整个暗部比较平，针对问题我们使用了两种方法来解决。

一种是在材质上，在场景的本身材质上给一个环境反射贴图，让材质在暗部时看起来也会有高光和立体度。另一种是在一些非常特殊的情况下用的，在材质上模拟一个反向的光，就是让我们的程序员在材质里就写了一盏反向光，它是一些比较特殊的情况在用的。再加上人物走进阴影里的时候，自身会打开一盏点光源，我们在一些山洞里或者是洞穴里，或者是一些黑暗的建筑内部都会这样处理。

烘焙的时候可能有些注意的点就是尽可能减少lighting map张数来控制整体的Draw Call。比如说像我们项目，用了很非常多的预制组件，就是Prefab那是相同的模型和相同的材质，但是由于你不会被分布在两张不同的lighting map上，那它的Draw Call其实是不会合并的。

这也就是有一个非常大的矛盾点，如果你lighting map使用得过多，那Draw Call可能会多，但是如果你使用得少的话，你就要控制住lighting map的尺寸，否则阴影会很模糊。所以lighting map的UVS的分布，一个是会造成阴影模糊，一个是会造成内存增加，这两个是需要你在做项目的时候去进行一些取舍。

关于light Probe，主要我们是用来给一些动态物体附着光影，比如说角色、怪物还有一些可互动的机关，后来我们就发现场景里有一些特别小的物件，其实用烘焙的效果不是很好。

因为那个小物件本身UV就很小，你这张lighting map最后一压缩，那个UV会聚焦在几个像素点上，那个像素点如果你没有处理好的话可能就是黑片。但是如果完全不着色的话，这些物件在暗部和亮部的表现是完全一样的，那就非常奇怪，物体在暗部的时候可能会表现有点亮，它在亮部的时候可能又表现得非常暗。所以我们最后后期就改为使用light Probe进行着色，因为物件本身比较小，你放在那里，放在暗部里，本身会着一个比较暗色的，其实也看不大出来，反而会比你烘焙的效果更好一点。

打光这块，因为场景的重复度比较高，所以我们在制作的时候有一个概念，就是一定要用灯光来给玩家作为记忆点，这就造成了光对我们来说非常重要，使用相同的素材，要根据打光的不同，营造出不同的场景气氛，这点是对我们来说在整个制作场景中的一个难点。

说到整个游戏的阴影。游戏阴影这一块是分为角色阴影、场景阴影，还有一些其他动态阴影。用我们投影的方法其实也是一个较为通用的做法了，用专门的投影相机，按照光照方向给场景、角色拍一个剪影，拍到RT贴图上，再根据投影投射到地表上，这样做的话可以无论再多的怪和角色，那只产生一次Draw Call，超出主角的范围又可以不会被渲染，而且你可以根据这张RT贴图，这张RT贴图的格式设置，你可以做一些处理，还可以加一些抗锯齿什么的。

阴影，我们基本上用的就是传统的烘焙阴影，场景阴影，其他动态阴影，比如说像云雾投射下来的这些阴影，基本上是用跟角色一样的，是用RT贴图来实现的。

场景里的物件动画，像植被，还有飘着的旗子什么的这些，我们基本上是用顶点动画来完成的，相对来说比较省资源。除此之外，人走到草上把草压弯是以人物坐标与草的位置远近，程序控制，顶点偏移来实现的。

视距这块是如同前面所说，我们世界观的时候设计的比较讨巧，整个世界是处在黑雾之中，所以我们的这个游戏fog开得非常强。如图例所示，这几个红圈基本上几乎都是雾气了，你里面其实都可以不要有细节了。

那我们只要留下大石头的剪影，还有一些建筑的剪影，其他基本上能关的都关了，这样的话我们做起来其实就是把这些所有的物品进行分组，根据体量分组，越大的物体它的可视范围越远。

例如一些建筑剪影，或者一些造成整个场景的一些大石头，越小的物体它的格式范围越近，基本上参照这个规则，所有的物体会被分到不同的层里，然后去给每一层去做一个可视范围的设置，再加上LOD，这样可以大大的减少消耗。

其实像我们这样做了以后，LOD的工作量也就不是很大了，所以我们游戏里LOD用的并不是很多。

雾气这一块，雾气分为体积雾、定制雾片和基础雾。体积雾我们是用一些Shader模拟的，基本上就是传统God Rays的那种效果，然后定制雾片是用渲染粒子实现的，基本上是我们整个游戏里面的定制雾片，基本上是放到地上的一些模拟流动的云雾，靠近会消失，然后你用软粒子也不会出现硬边，一个比较方便的做法。

镜头调节这一块，因为游戏里的敌兵种类体型跨度都非常大，针对不同的体型和怪物，我们去做了一套专门调节镜头的工具，可以说每一种怪物你锁定他的时候都是专门独立去调节的，你在这个过程中还会去考虑这个怪物它的攻击方式。

比如说远程法师它的攻击抛物线比较高的话，我们镜头当时调的时候，距离和镜头的远近都会拉得相对比较宽一点。

在制作角色面部表情和口型动画上，我们简单的为角色设置了22个面部骨骼点来实现游戏中面部所需要的基础动画，口型和表情其实都是提前设置好的一段动画片段，然后会根据音频调用这些调用融合的这些片段。

对于Blend Tree这一块，对3D游戏来说，不管是手机模拟摇杆，还是手柄摇杆，其实玩家在操控这些角色移动的时候，都可以朝任意方向来进行移动，例如我们当时在设计维奥拉的时候，那锁定目标以后的移动方式，为了拉开和另一个角色泰伦斯的区别，我们大概设计了10种，前后左右、斜上斜下10个动画片段来做融合，这就是当时维奥拉的一个Blend Tree。

除了一般的走路位移动画之外，角色的攻击动画也占据了非常大的一部分资源，其中攻击和受击的逻辑判断非常重要，我们通过结合状态机的参数制，自定义曲线取值，让程序去分析当前的动画逻辑状态，实现角色在攻击动作时的一个目标的判断。

比如说武器判断，根据预定的攻击类型编号，然后去调取相应的攻击碰撞盒来实现这些做法。另外像攻击中是否可以转向，然后攻击碰撞打开的时机，还有连段判断等等，我们在项目制作中其实是花费了大量的时间来去调这些Curve的参数，这些调整的结果都直接影响了整个游戏的手感，特别像动作游戏，你这些手感的好坏其实都去拉这些曲线来实现。

我们整个游戏可能有非常多的工夫是在不停的去调整这些曲线上，然后我们整个角色是用了全身的IK系统，包括人物瞄准、脚步IK，然后收集IK的，比如说现在看到的这张图就是人物站在不同的地表上，脚部骨骼会做出一些变形。

关卡制作，我们在做关卡的时候，其实为敌兵制作了非常丰富的状态机机制，制作了若干种休息动画，隐藏的攻击动画，你会在整个游戏中看到有的怪物它隐藏在角落，在这偷袭你，这些其实都是专门定制的，然后怪物都会有视觉和听觉方向还有范围。

比如说像这张图里黄色的圈，就是一个听觉范围，红色的三角区是视觉范围，如果怪物在没有看见你的情况下，你慢走的话是不会惊醒他们的，但是如果你跑过去可能就会引发他们的攻击。

关卡中是采用了动态加载的方式加载怪物的，加载场景时会把这些怪物预先放到内存里，场景中放了很多点，然后又放了很多专门设置过的这种显示盒，就是这种绿色的盒子，只有角色进入这个绿色的盒子范围内的时候，绿盒子范围内的怪物才会被动态加载，这样的话可以比较稳妥的控制怪物的加载上线，而且也可以比较精确的控制，我想哪些怪显示，哪些怪不用显示。

最后谈一谈过场动画。说到过场动画一般是我跟编剧先聊，聊完确定了大概的剧情，然后先出一个故事板，把脑子里的想法一些画面先具像化，加上策划以及程序来一起推敲修改。

这个阶段主要是确定一些效果是否能实现，如果不行的话，那可能还要商量一个可行的方案，再不断的继续的去修改故事版。

当故事板确定了以后，我们会在max里面去做一个layout，这个主要是用来确认故事结构以及镜头的合理性。

这个阶段不会去加面部表情，加口型，而且会拿给配音去做参考，待他们把配音部分完成以后，那确认没有任何问题，才会继续添加表情和口型。

游戏中有一些比较复杂的过场动画，为了不占用过多的内存资源，我们自定义了一套及时加载系统，在演出完成后也可以立即释放出游戏内存。那根据预设的摄像机，调用角色ID以及相应的过场动画资源，那比如说场景风格，一些灯光和一些音效等等。同时程序也可以通过代码来控制美术的表现。

Unity的Timeline功能非常强大，早期的时候我们其实并没有使用，是用笨的办法，去实现游戏里的一些过场需求。那待Unity Timeline功能实现了以后，我们很早的就投入去使用这个东西，然后发现使用了以后确实非常棒，效率直线提升，而且我们结合了自身的项目，设计了一套状态控制器，可以通过判断当前操纵的角色，动态的调用相应的一些演出动画。

另外在一些简短的动画中GamePlay状态下，也可以做一些简单的一镜到底的方式。

以上就是我为大家带来的分享。其实我们并没有用一些特别复杂的，或者是自己自定义的功能，用的还是Unity本身的强大的那些功能。这些东西的怎么灵活运用？我想，透过我们这个项目、通过今天的分享，能给大家带来一些思考，谢谢！

就在前两天，天眼查突然放出了一个劲爆的新闻——“米哈游把B站给告了”。

实属稀奇。

要知道，以米哈游和B站的合作亲密度，已经到虽不是一家却胜似一家的程度。早在原神开服时，米哈游虽然靠着实力与底气拒绝了诸多应用平台不合理的抽成，但还是单独给B站了一个名为“世界树”的服务器，这足以说明B站和米哈游的关系之密切。

所以B站到底为什么会被米哈游告上法庭？当真是“侵害”了“作品信息网络传播权”吗？

首先这一连串的诉讼并不是凭空捏造，虽然尚且不知具体什么东西让关系紧密的商业伙伴闹上法庭，大动干戈；但是显然矛头直指那些泄露原神测试服内容的内鬼。

内鬼与游戏测试分不开关系，更进一步说内鬼其实就是拿着未公开游戏内容盈利的强盗。

原神继承了崩三的老传统，除开玩家平时游玩的正式服以外，还有包含下一个版本内容的测试服，在正式服更新之前会对地图、角色、数值等多方面的游戏内容进行多次的修改测试，在多次测试中作为开发的米哈游不仅会有专门的测试人员，还会在玩家群体中招募一些玩家来进行游戏的测试。

当然米哈游会在每个版本测试结束时给这些参与测试的游戏玩家发一些资源、抽卡道具，感谢玩家自发参与他们的测试；玩家获得了额外的奖励，米哈游收获了更“接地气”的修改建议，这本该是一件双赢的事情。

而不同于崩坏三是，原神测试服的内容是严格保密，要求玩家在参与测试服前签订保密协议的，所以即使参与了测试服，封测玩家也不能外泄刚刚“爽”过的游戏内容。

但遗憾的是，口头的警告，游戏内签署的保密协议好像并不能约束住所有玩家，无视这些保密协议的“内鬼”大有人在。

这些人与凭空说出真假不定消息的“舅舅党”不同，他们手中拿捏的是原神即将上线的游戏内容，这些内容并不会进行特大幅度的修改，也不能随意的延后或者提前，这也就导致原神直到现在仍然是“内鬼爆料什么，原神就更新什么”的尴尬局面。

内鬼的爆料对玩家来说是一把双刃剑，一来爆料的重头戏“角色”是玩家需要靠肝靠氪才能从蛋池中抽取的游戏内容，本身的数值强度、美术设计甚至是陪跑的其他角色都会影响到一部分玩家对蛋池的规划。

二来，这些爆料者并不会满足于爆料角色，他们还会对游戏内即将展开的游戏活动，或者即将更新的游戏剧情都逐一从安装包中拆出，用各种方式泄露到社交平台上，经过发酵与传播，让本来认真玩游戏的玩家被剧透一脸，不仅降低了玩家群体间对现有版本的热忱与讨论，还让许多路人玩家失去了对游戏新版本的期待。

为了折中这种局面，国内很多社交平台都将爆料内容独立出了游戏正常讨论的部分，NGA在原神版块中设置了独立的“幽夜净土”用于让部分玩家讨论游戏泄露出的游戏内容，贴吧则是有人创立的“原神内鬼吧”汇总起了这些鱼龙混杂的消息。

但无论是什么样的讨论都背离了米哈游一开始设置测试服的初衷，在大力的打击下，国内已经鲜少有内鬼曝光名不见经传的测试服内容了。除此之外米哈游还将测试服发往了海外，国外的强盗早对爆料测试服这种行为饥渴难耐，交到手上自然不会善罢甘休。

这也就导致泄密行为没有停下来，只是消息散出的地点从国内的各种社交平台、视频网站统一变成了外网的推特与综合信息的“内鬼网”。国内没有了爆料的始作俑者，但是传播内容的加害者却如雨后春笋般一茬又一茬地出现。

凭借着原神超高的人气与玩家对新角色、新地图的期待，这些动动手指就搬运至国内的二次传播者收获到了部分玩家的关注，更有甚者还会腆着脸参与原神举办的活动拿个一分二两。

很多人对爆料产生的收益也许并不了解，认为这是拆包者是为爱发电从游戏公司偷出游戏内容的“义贼”，但事实并非如此；在此之前外网有诸多爆料者曾规划路人关注、粉丝打赏逐一更新爆料原神内容的离谱操作，甚至因为利益相关不同的拆包团队还会互相打压，发布不同的内容让“同行”词穷。而其目的大概就在于，时不时插入在动态之中的广告也许早就让他们赚了个盆满钵满。

爆料者是从游戏公司内容的强盗，这一点不容置喙，而且不仅仅是米哈游频繁遭到内鬼的骚扰，诸多游戏厂商都遇到过这些泄露游戏内容的内鬼。

大名鼎鼎的育碧正是其中之一。

2011年在《孤岛危机2》即将发售前一月，国外论坛上出现了《孤岛危机2》的泄漏消息，甚至提供了下载链接，随后在国内论坛上遭遇了疯狂的转载，各大人气游戏论坛均放出《孤岛危机2》的泄露版安装程序。

泄露版的《孤岛危机2》容量接近6GB，内含完整单机流程和多人部分，并且单人关卡全部开启。这份偷跑已经非常接近正式零售版，而下载泄漏版的玩家如果开始通关，完全可以体验游戏90%以上的精华部分。

去年年底卡普空也曾遭到过内鬼的敲诈，有黑客封锁了卡普空服务器里1TB的资料并要求1100万的赎金。卡普空没有任人宰割，黑客看要不到赎金则是开始大范围的公开卡普空正在准备、制作的项目。

米哈游与B站的诉讼虽然尚未开始，但是在B站很多专门制作爆料内容的账号已经被封停；米哈游也开始选择在版本更新初期放出一些属于官方的“爆料内容”，这些消息对玩家，对厂商来说都是一件好事。

卡池不会一天就关闭，角色的强度不会随意修改，玩家有充足的时间体验所有的游戏内容再做自己的决定，而内鬼的出现一定会毁掉玩家对于游戏本真的热爱，让玩家对于新内容的期待烟消云散。

其中孰好孰坏，不言而喻。

随着项目开发的逐渐敏捷化，QA的职能早已不单单是曾经简单对功能的测试，在领域内测试左移和测试右移这两个概念被一再提及。实践了左移和右移的QA团队，在项目组内往往能够获得更大的主动权，产品的质量也更加有所保证。虽然项目本身可能更多采用敏捷的迭代增量型或适应型的开发模型，但是就具体功能而言，实际落地还是更多采用偏瀑布的预测型生命周期。测试左移和右移的基础概念便是在原本测试应有的阶段的左右延伸。

左移和右移实际上是两个挺大的领域，展开来其实都有挺多可讲的。对于右移而言，笔者个人的定义更多是采取措施稳定线上生态、主动控制、发现并规避问题。笔者所在的天谕测试组是我认为在右移方面做得很不错的团队，我们有非常多的工具在线上问题的预警上发挥了不小的作用。但正巧最近产品出现了几个刷类事故，有未测试充分导致的回档问题，也有线上潜伏了数年但是一直未被发现导致被利用损失惨重的问题，也让我有机会对右移在项目组内的实践重新产生了一些思考。

本文将主要介绍一下目前测试右移概念在组内的落地应用、一些还没有落地的构想以及有意向采取的行动。

稳定发布，类似灰度发布的概念，当新内容/新引擎上线时，先小范围测试，再全服覆盖的做法。在功能层面，采取开关的形式，在每段功能逻辑入口增加开关判断后续逻辑是否能走到，这样可以在上线新功能时先小范围测试，稳定后再修改全服的开关状态；在引擎层面，客户端方面采取的是同一个客户端同时存在两套或多套exe，每次启动时根据配置的概率有低概率启动更新的偏不稳定的exe，并收集这些玩家的客户端数据；概率文件可以在每次启动登录器时随时无感更新。服务端则是在引擎更新后，在小范围服务器优先发布，观察数周稳定后再推广至全服。

2.1 LOG监控

LOG是玩家行为最直观的记录体现，也是我们分析线上问题、进行数据统计等行为的最基础数据来源。QA职能掌握项目LOG的主动权是很有必要的。

据我所知，有些项目的LOG主要由UX或其他第三方部门处理，策划需要时提出需求，由平台方进行处理后生成报表。相对而言，天谕端游对玩家行为LOG建立了一套相对完善的体系，这边先对我们的工具做一个简单介绍。

首先我们建立了LOG的基础展示页面即数据中心，将存储进mongo db的日志数据以字段详细内容的形式展现出来，可以对几乎每一条敏感操作做非常详细的记录和操作较为简单的可视化查询，即使是不懂得使用SQL的非技术岗也能够从这个平台获取到信息，对平时的运维工作提供了很大的便利。

但是这种平台化的展示更多是针对微观的具体的数据，当想获取宏观的数据如统计类信息时，单纯的数据罗列会显得有些无力。

于是我们引入了第三方伏羲的数源平台，也就是针对技术岗人群可以直接对LOG进行SQL查询及脚本处理的平台。伏羲数源是在处理跨越时间较长、条件较明确的一次性需求时常用的平台。天谕的大部分LOG数据目前都寄存在伏羲的这个平台上，只要明确要查询的字段和条件，只需要简单的SQL语句便可以获得我们想要的结果。虽然从可视化的角度不及上面的工具，但是依然具有高度自由、门槛较低、查询范围较广等优点。

在此基础上，我们希望对SQL的结果能进行一些更复杂的脚本化处理，于是有了线上日志监控系统。该系统在获取db数据的同时还可以使用python脚本对数据进行个性化的处理，并且支持定时任务。这个平台是我们当前LOG自动化的基础，我们可以在写完针对某个系统的针对性监控脚本以后，让它定时执行并通过POPO（内部IM）机器人推送检查结果，确认这个周期内的数据是否存在异常，例如每两小时一次的洗属性的监控，就可以从洗炼次数（是否有异常突增）、洗出结果等多个层次供QA和策划确认是否可能存在异常。但是目前的缺陷在于这个平台的运行会消耗大量服务器资源，因此对CPU时间存在要求，很难处理大批量数据，目前而言支持的项目有限。

理想有效的LOG监控体系，应该符合以下的模型

测试部目前应该正在调研开发更通用的log监控平台，届时各个项目应该都会有更加深入的支持。

对于QA而言，在有便捷工具的情况下，需要做的就是确保LOG的实用性。一般而言，log需求通常由策划和QA发起，策划会关注核心的参与数据，而QA的角度应该更加微观，需要关注到更细节的操作层面。符合有效性的LOG，我最常用的自检标准是，如果功能上线以后，有玩家反馈自己在这个玩法里丢了道具，你能否通过这个系统及关联系统的LOG整理去详实的数据去证实/证伪他的言论。在这个证明流程中，需要时间、人物、状态、操作、关键项变化前后状态等，这些都是各个系统LOG的基本组成要素。

这边还有另一个问题，例如战斗结算，产生的LOG量可能相当巨大，基于现实原因，我们可能没法记录下每次伤害的结算信息，那么当玩家反馈“某玩家的伤害/防御有异常，他们是不是利用了BUG？”，如果没有足够的信息量，我们进行判断时往往会陷入被动。所以这边我们引入了重要度分级的概念。以我前面提到的战斗结算LOG为例，对于一般玩家，我们每10分钟记录一次玩家属性快照到数据库中，包括玩家在这个时间点身上的所有状态、所有属性。对于玩家反馈或者是系统监测到可能存在异常的玩家，这个频率可以在线实时提高到1分钟1次。对于重点监测的玩家，在提高频率的同时，还会为其设置技能结算白名单，在各类结算方法处判断参与结算的玩家是否在白名单中，如果在的话便记录下本次技能结算的详细数据到LOG中以供查询。白名单可以随时调整。通过这样的方法，既保证了LOG数据量不会过大，又能做到精准监控。

（之前也有一篇文章详细讲述了我们监控和挖掘属性问题的方法，有兴趣可以移步这边https://zhuanlan.zhihu.com/p/161045306）

2.2 舆论监控

舆论监控主要分为两块，一块是被动的由运营提交问题，一块是主动去各个渠道发现问题。

在运营提交问题愈发频繁的今天，如何处理运营问题本身也是一个问题。早期在运营BUG反馈群，运营可能在一个小时机关枪一样连续抛出十几个问题，其中有效的问题可能并不多，但是过多的问题会导致回应效率变低；早期我们曾做过一个运维BUG反馈平台，希望运维bug都提在这个平台上，我们方便处理和及时反馈。

但是在实践的过程中，运营迭代速度过快但流程没传承、大量外包运营无登陆权限、运营自己的网络访问限制等客观因素实际上阻碍了这个平台的有效性。

因此我们把POPO机器人和运营反馈BUG流程打通，运营提交BUG时增加一个关键词，我们就自动把提交内容收录到BUG反馈平台中，在处理完成后，由BUG反馈平台推送处理结果给运营，整个过程运营只需要接触POPO而无需接触其他平台，QA们有专门的平台处理线上问题，更加有条理性。

但是运维反馈bug依然存在一些问题，由于运营方面的多方位因素，对于拿不准的问题他们逐渐更偏向直接询问开发组，bug提交量近几年量级逐渐增加，除了提问类工单比例逐渐上升外，还有很多伪bug是玩家在诓客服想获取利益的；其中有些假bug往往处理起来需要耗费挺大的人力，有时候也挺为此头疼的……不过这倒是反向推动了不少系统log结构的完善，一方面足够完善、可读性强的LOG可以让运营人员自行筛选并解答玩家问题，另一方面也可以帮助我们拿到更多的事实依据，判别哪些问题是真实存在的BUG，避免后续人力的浪费。

至于另一方面，主动发现问题，曾经我们的习惯是版本发布后，由值班QA定期去贴吧、论坛、微博等渠道扫玩家言论，发现BUG或吐槽后给策划或技术开单处理。随着平台化的进步，现在的舆论监控主要由两部分组成，一部分是对游戏内的敏感言论做捕捉，另一部分是雷火渠道信息收集平台，主要用于监控各大平台（论坛、贴吧、taptap）的反馈，根据标题贴近BUG的程度计算风险系数并录入。

虽然舆情监控的的确确帮我们发现了不少隐藏BUG及疑难BUG复现的线索，但是在运营过程中可以发现，绝大部分少数人利用的危害比较大的BUG一般都不会通过游戏内渠道或公开渠道进行传播，很多都是通过公会QQ/微信群或YY群进行小范围传播，并且这种套路逐渐常态化，因此项目组内有人可以深入游戏生态，打入玩家内部依然是很重要的工作，当然最根本的还是完善面向数据的主动防御机制。

2.3 性能监控

即便有压测等环节，线上也经常会出现各种性能方面问题的意外情况。深度参与性能监控的流程和体系，有助于QA更深入了解系统瓶颈，对后续测试的思路拓宽和厘清侧重点帮助是很大的。

我们游戏对线上性能的监控需求改进动力来源于群战及各类复杂的PVP玩法或其他玩法。早期这类活动出现过不少性能问题，并且当时的性能监控比较被动，一般是当服务器负载高于某个阈值时，在服务端抛错群里抛出警告，然后由服务端手动连入线上服后台进行profile确认问题，这种做法往往响应较慢，容易错过关键时机，且只能由高权限服务端手动操作，生成的报告比较晦涩，整体参与度和实用性都不强。

现在线上的性能监控则主要通过SA那边维护的两套工具postman及monitor进行，postman以可视化的形式展现了线上服在各个时间段的服务端性能数据，并且可以就某一个具体的时段具体分析profile，让QA也能参与到线上性能的监控里来，并且能更方便地在生产环境找到性能瓶颈。Monitor则直观展现了各服的CPU、内存等基础性能状态。可以看到这两套工具都具有高度可视化的特征，在收到出现问题的推送时能够更快地确认问题。

这里再提一个例子，天谕端游前不久出过这样一个情况，部分服一直反应服务器一到某个时间点就很卡，邮件响应速度慢，或者读取角色速度慢等。但是我们调取了这些服的性能数据与其他服比较，发现并无明显异常，在玩家反馈的时间点监控服务端各个进程的CPU占用率，发现也非常稳定，mysql慢查询日志中也只有每天的计费扫描，并不会导致线上这种情况的产生。最后在引擎日志中，发现很多玩家的SQL队列非常长，有些队列已经排到了70多秒；我们从日志平台调取了玩家的操作序列，在这个服和其他服进行对比，发现相同的单次操作，在这个服写入需要1s，在其他服只需要0.1s，于是定位可能是硬盘写入性能问题。联系SA后得知其在近期的确更换了服务器的硬盘，后排查是SSD raid存在问题导致了写入卡顿，第二天更换硬盘后服务器状态即恢复正常。

这次事件后，我们注意到性能监控的指标事实上还存在不少缺失，例如这次dbmgr还存在不少性能相关的指标目前对我们QA甚至对开发而言还依然处于黑盒的状态，我们只能通过watcher的方式查看的数据，过于被动。针对这次问题，除了常规的服务端监控手段外，我们还额外增加了对dbmgr的监控，把sql运行超过一定时间的日志抓取出来并通过POPO报警，后续已经规划通过kibana等平台做成图表，以更直观的形式表现出来。

由于标准不一，设备各异，客户端的线上性能监控目前我们没有采取什么手段，更多的还是在内部机器上进行测试。也希望有这方面实践的项目组可以交流一下经验。

其实挺多的线上性能监控，看似是服务端或者是SA的问题，QA在处理起来可能会有比较无力的感觉，但性能问题的最终指向是线上功能及玩家体验受损，这与QA的职责是强相关的，QA除了具体分析问题原因外，能做的事情还有很多，包括但不限于前期预警方案的设计，监控系统有效性的保证，上线后的执行，出问题后的行为与场景分析等。

纵使监控做得再完备，第三方检查发现问题也总会存在延时。例如天谕端游在20年底出现的一起刷道具导致的回档事故，19：00问题出现，日志监控并未对这个活动写单独脚本，就算写了也是跟着统一配置半小时执行一次；舆论监控最早在19:20暴露问题，在此之前问题已经得到了大范围传播。因此如何控制风险、规避风险依然是重要的课题。

从游戏机制设计层面，老QA可能都知道几条耳熟能详的原则，比如：

1、 多人玩法注意负载均衡，时间上分批、空间上分地

2、 道具获取先扣除后增加、先设标记位后发奖

3、 低门槛非绑道具谨慎投放，如果必须投放一定考虑工作室影响

4、 活动投放道具尽量用宝箱道具，宝箱配置限定使用次数

……

类似的规则相信有经验的项目组都已经有挺多总结，遵守这些守则的确可以规避很多问题。但事实上根据实际的复杂情况，很多事故的产生并不是几条通用的守则可以覆盖的。因此要寻找更加通用的控制机制。

一种我认为比较可行并且在逐渐推广的是预测型控制机制，即当系统产生了策划配置的预期外的数值时，由游戏逻辑直接采取报警或切断措施。

举个例子，在天谕端游已经上线的系统内，副本首杀监测、数值结算异常监测便是报警类的风控机制。当新服某个副本第一次通关时，会收到报警信息；当玩家结算时发现某个属性过高或者打出了离谱的伤害时，服务端也会推送报警信息；当玩家在某个场景内保持无敌状态超过一定时间后，推送报警信息……

在上次回档事件后，另一步正打算做的机制是根据物品投放的系统来限制投放总量。策划对每个运营活动或新玩法在一个周期内针对每个基础产出道具限定一个警告数目和预期最高上限，当玩家在这个周期内通过此渠道获得的这个道具超出配置的报警数目后，向功能关联人员推送报警信息，超出最高上限后则直接拦截，并生成一个道具恢复指令供运营核实无误后快速恢复拦截的道具。

从可行性层面上，对于MMORPG类游戏而言，玩家获得物品投放的渠道最终都会归结于进包、发邮件等有限的渠道，所以控制起来相对轻松，具有一定的可行性；目前这个方案还在实现初期，如何协调玩家获得道具记录在不同周期需求下的存储方式和程序的运行效率还是一个问题，不过预期内这个系统能实现的话应该会是一个很好的防御手段，像本文开头所讲的两个BUG的例子也可以在这个系统下得到规避。

在这次事件的复盘会上，以及后续测试部的月会上，很多人都提到了一个其他游戏的做法，即把多刷出来的资源扣成负数，后续玩家获得这些道具时将其补充。这个做法的确是处理起来挺有效的做法，但是依然存在一些问题：无追责的贷款可能会降低玩家的活动参与意愿，如果玩家已经通过这个玩法获得了既有的数值收益，那么后续仅仅是扣除这部分数值奖励对他的惩罚也无足轻重了；不过这种业界常用的做法依然具有挺广阔的适用场景，已经在项目内推广使用了。

右移的最终目标，是希望技术层比业务层更快地获得异常反馈，以达到极速响应处理问题的效果；或是从业务实践层面出发反推开发层面，预先解决掉导致问题出现的种子。右移的实践除了表现在形式上的环节中QA自己的行动外，在内涵上更重要的是思维和氛围的营造，这部分的内容更多地会穿插在功能的设计期和开发期。质量保障从来不只是QA的工作，我们要做的是把保障质量的观念灌输到其他职能的脑海中，让他们主动来配合我们，让策划在设计时就有意识考虑到风险和备案，让技术更加注重代码上线后的各个维度的表现。有效右移体系的建设需要QA能够给出有说服力的架构体系思路或系统设计思维方式，且能够与项目的实际情况融合，这同时也可以帮助QA在组内构建更大的话语权和推动力，反推组内产品质量意识的提高。

当然，目前项目组的实践依然存在很多不足，希望能够与各位一起讨论交流，分享经验。

压力测试是，给游戏进程增加并发量，强制其在高负载下运行，并观察进程性能的测试；其中游戏进程包括服务器和客户端进程。当游戏负载过高导致性能不足时，会造成进程卡顿或崩溃，甚至引发逻辑漏洞造成产品损失。因此压力测试是游戏功能外放前非常重要的一个步骤，关系到玩家体验和游戏口碑。

此次我们请来了一名雷火资深QA，分享他的积累的压力测试心得，感兴趣的同学欢迎在评论区互动交流~

本篇文章我们将从压力测试的理论知识和实际执行两个方面来介绍

压力测试分为四种类型：服务器压力测试、客户端压力测试、第三方服务测试和云游戏测试。前两种分别针对游戏的服务器和客户端进程进行测试，第三方与云游戏主要测试游戏外服务。

由于游戏代码需要处理的数据量随人数增加，因此同一时刻参与人数较多的玩法和功能容易引起服务器负载过高，比如抢红包、登陆排队、多人战斗等。当服务器负载高时会严重影响玩家体验，甚至引发逻辑错误问题。参与人数较多的重要模块外放前，对其进行服务器压力测试是保证游戏口碑的必要步骤。

当同屏玩家数量较大，或者 UI 操作涉及的数据较多时，都可能引起客户端卡顿，需要模拟相应操作并进行客户端性能测试。具体玩家数量的阈值标准由游戏实际帧率情况决定。

游戏中的第三方服务是指，部分通用功能的实现通过调用第三方接口完成。

当云游戏平台压力过大时，可能造成排队资源无法释放、黑屏和连接服务器失败等问题。下图为云游戏压测时的客户端情况：

压力测试时，需要关注哪些游戏性能数据呢？有以下几个指标：

当游戏并发操作数量提升时，服务器和客户端的 CPU、内存、IO 和网络流量都会随之增加，也可能成为游戏进程的性能瓶颈，因此需要重点关注。

游戏 LOG 中存储了一些判断游戏性能的重要指标信息，压测中主要关注的包括：

• 游戏 LUA 内存：LUA 的 collectgarbage("count")返回结果，如果测试过程中持续增大则说明有泄漏风险。
• 游戏在线人数：也是重要的性能指标，因为当服务器压力过大时可能导致玩家异常掉线。
• 游戏 CPU：逻辑线程的 CPU 负载情况，数值越大则表示负载越高。
• 数据库待执行的查询请求数量：此数量如果一直增加，则说明当前游戏处理请求的能力跟不上请求产生速度，故请求会一直堆积；查询待执行越久则玩家等待越久，因此这个数量等于 0 或保持在较低数值（<10）比较理想。

案例分析：在压测某个数据库操作频繁的玩法时，需要测试服务器对数据库请求的极限处理能力，以便于调整玩法 CD。一般操作是，逐步缓慢增加测试的并发数量，以保持数据库 LOG 的待执行查询数量在刚好等于 0，但是再增加并发则要排队的状态。实际操作发现难度系数较大，于是反其道而行之：让请求堆积到一定数量之后停止脚本，再根据两条 LOG 之间的变化值除以时间间隔，计算得出当前机器每秒处理数据库请求数量的上限值。

• 游戏 DELAY：游戏逻辑推进时间落后真实时间的秒数，DELAY 数值越大说明进程越卡；或者 CPU 虽然已经达到 100%，但是 DELAY 一直保持较小（<1），则说明游戏可以承载当前的并发操作数量。

案例分析：
某次压测任务是，需要比较三种不同型号 CPU 处理游戏运算的性能情况。一开始的策略是，在每种型号的 CPU 上都跑相同并发数量的测试用例， 在没有 DELAY 的情况下比较 CPU 负载绝对值；但是测试结果与预期并不相符。经过分析发现，操作系统调度优化策略会导致在没有 DELAY 的情况下，CPU 负载绝对值高低并不能真实反映 CPU 性能。于是变更测试思路，改为测试在游戏出现DELAY 的情况下，比较相同时间和并发量时的 DELAY 增长幅度，最终测试结果符合预期，如图：

对于客户端而言，帧率是最重要的性能指标。研究表明人眼可视帧数不超过30 帧，因此当客户端帧率低于 30 帧时，则认为需要优化。

帧率记录最好可以覆盖多个变量，因为不同的机器配置、画面设置、可显示人数下，帧率会有比较大的差异。

真实体验也是非常重要的一环，某些问题不使用真实客户端体验可能会比较难以发现。

案例分析：在某游戏上线之前的一次登录模块压力测试中，服务器性能看起来非常良好，但是用客户端手动操作观察到，重登陆操作的队伍进度异常缓慢。分析服务器 LOG 发现，重登陆的次数远低于预期值。经过程序分析得知，是因为重登陆的请求都排队至同一个数据库连接导致。

压力测试中普遍使用机器人模拟真实玩家进行操作，主要有两种：服务器机器人和客户端机器人。

是一种没有客户端的机器人，但是服务器端和正常玩家无异，通过 PATCH 登陆流程中和客户端的交互部分创建。

服务器机器人的优点是：涉及的代码量比较少，维护方便；创建操作快捷方便，只需要一行指令；由于没有客户端，因此不需要额外的硬件资源。

相应的缺点是：

• 缺少服务器和客户端进行交互的 RPC 操作，使得服务器负载会低于真实情况。
• 无法估计服务器和客户端通信的网络流量负载。
• 只能通过服务器 AI 控制，对服务器性能有一定影响。

主要用途是：

• 客户端性能测试

涉及多玩家的外观测试，如玩家穿着特定材质时装、装备发光武器和挂饰等；或者涉及多玩家的 UI 界面性能测试。

• 服务器压力测试

多玩家参加的玩法。虽然服务器 AI 会占用服务器资源，但是由于 AI 一般运行在服务器负责逻辑计算的进程，因此可以用来压测其他服务器进程的性能，比如测试需要进行大量数据库操作的玩法。

首先客户端机器人为了性能考虑，删除了非常耗费资源的渲染相关代码；其次对产品代码进行了修改，让一个客户端机器人进程里可以同时存在多个主角对象。

客户端机器人的优点是：更加真实，因为所有的客户端服务器交互部分都得以保留；由于可以用客户端 AI 控制，因此不会影响服务器性能。

缺点是：改动的游戏代码比较多，需要一定维护成本；需要额外的硬件资源。客户端机器人目前主要用途是多人任务和战斗的服务器压力测试。

看到这里，相信大家对端游的压力测试已经有了一个基本的了解，接下来将为大家分享如何去进行压力测试及测试结果的分析。

完整的压力测试流程应该包括的步骤为：沟通需求、明确方案、执行测试和撰写报告。

在玩法或功能规划之初，对于符合压测条件的，由策划开单提出压测需求。

首先需要了解测试玩法或功能的预估并发数量。比如某个玩法策划预计全服参与人数是 2 万人，则实际测试时最好比预估人数再多一些，保留一些余量。

然后是确认操作成功的标识。比如测试的玩法预计 2 万玩家参加，但是由于脚本的原因使得实际参与人数不足 2 万，则对服务器的性能判断会有偏差；因此在这个例子中，需要和相关人员了解如何确认成功参加玩法的玩家数量，保证测试操作的数据量级有达到需求。

接下来是和策划程序沟通之后明确可能产生压力的操作，通常是会引起高并发量的玩家行为；比如抢红包玩法，当全服在线玩家同一时间点击红包时服务器压力较大。操作明确后则可以编写对应的测试脚本。

最后是和程序确认各种操作可能产生压力的进程是哪些，测试的时候则需要重点关注。

以mmo游戏为例，常见的需要进行压力测试的条件有以下这些 ：

客户端压力测试 ：

• 新场景的投放
• 现有场景的大量资源修改，比如氛围更换导致较多植被和建筑变化
• 可能占据 50%以上视野的新渲染类型，比如新时装材质、新天气或者新特效
• 涉及 50 人以上的新界面，如帮会联赛约战房间

服务器压力测试 ：

• 单个场景参与人数超过 50 的新玩法
• 涉及全服玩家、可能同时产生海量并发请求的操作；比如多人同时抢红包，或者对全服甚至所有服玩家进行信息同步的玩法

首先需要明确模拟玩家操作的途径，比如：

• 压测服务器时优先选择客户端机器人可以更为真实地模拟
• 压测客户端时优先选择方便创建的服务器机器人
• 压测第三方服务可以使用构造 HTTP 请求方式
  

然后是沟通测试涉及的数据需求，确定哪些数据会对玩法性能产生影响，比如等级修为高低、装备评分、帮会等级和成员数量等；

最后是确定需要模拟的行为模式，以便于编写测试脚本。比如模拟玩家战斗， 要明确具体的技能释放策略；比如压测聊天系统，则要了解发送的频率和长度等。

实际测试时，首先确认压力量级是不是达到了预期，然后查看游戏进程的性能，并进行采样分析，找到占比较高的模块后通知负责程序进行优化。优化完成后继续测试-采样-优化的步骤，直到游戏性能达到最佳状态。

压测第三方服务时要特别注意两点：首先需要和对方确认发送和接收的数量以保证一致，比如有网络问题导致发送到第三方的数据量降低，则会影响第三方对服务器性能的判断。其次是发送请求的游戏进程不能有延时，如果游戏进程比较卡，则发送的请求数量会偏少，进而影响第三方对于外网真实情况的预估。

最后是将测试流程和结果撰写报告，便于相关人员了解情况和日后复盘。

当压测发现游戏性能问题时，目前常用的工具有：LuaProfiler（游戏进程的 CPU 和内存分析）、Perf（Linux 进程的性能分析）、VTune（Windows 进程的性能分析）、ProfilerAnalyzer（客户端的 CPU 和GPU 性能分析）和LuaDump（游戏进程的 LUA 内存占用分析）。

LuaProfiler 是由本组程序开发的性能采样模块。主要思想是 HOOK 需要关注性能的函数，在函数开始时记录当前时间和内存信息，然后调用原函数，原函数执行完成后再记录当前时间和内存信息。如此可以计算得出调用这个函数花费的时间和内存，还可以知道在采样的一段时间之内调用此函数多少次。

将这些信息记录到文件并使用脚本进行分析，可以得到 CPU 和内存使用情况，生成下图所示的火焰图。其中纵轴表示调用堆栈关系；横轴表示资源占用情况，越宽则说明占用越多，存在优化可能性。

下图中 d()的宽度大，但是它直接耗用 CPU 的部分很少，同理 b()和 c()没有直接消耗 CPU。因此，如果要优化性能问题，首先应该处理顶层最宽的 g()， 其次是i()。另外从图中可知，a()有两个分支 b()和 h()，这表明a()里面可能有一个条件语句，而 b()分支消耗的 CPU 大大高于 h()。

(转自http://www.ruanyifeng.com/blog/2017/09/flame-graph.html）

Perf 是内置于 Linux 内核源码树中的性能剖析（profiling）工具。它基于事件采样原理，以性能事件为基础，支持针对处理器相关性能指标与操作系统相关性能指标的性能剖析。可用于性能瓶颈的查找与热点代码的定位。linux2.6 及后续版本都自带该工具， 几乎能够处理所有与性能相关的事件 。

（转自https://blog.csdn.net/chichi123137/article/details/80139237）

Perf 指令可以对服务器进程的 C++引擎层面采样，分析后生成如下所示火焰图：

VTune 可视化性能分析器（Intel VTune Performance Analyzer）是一个用于分析和优化程序性能的工具，作为 Intel 为开发者提供的专门针对寻找软硬件性能瓶颈的一款分析工具，它能确定程序的热点（hotspot），找到导致性能不理想的原 因 ， 从 而 让 开 发 者 据 此 对 程 序 进 行 优 化 。（ 转 自https://blog.csdn.net/WY_stutdy/article/details/79106501）

4.ProfilerAnalyzer

此工具将客户端性能的相关数据输出并可视化，便于直观查看当前 CPU 或GPU 时间占用多的模块：

5.LuaDump

LuaDump 指令将各个类里的所有 table 变量长度打印输出。当内存泄漏情况发生时，可以分别对比内存变化前后的输出，集中分析增长异常的变量再细致排查。

压力测试过程中，可能发现的问题分为：

在测试数据量较大或测试时间较长的情况下，可能会出现一些在功能测试时难以发现的报错和崩溃；出现后将报错堆栈或崩溃文件给程序进行修改，并配合重现和调试。

变量申请后没有正确释放则会造成内存泄漏问题，内存泄漏的进度在大多数情况下比较缓慢，因此较大的测试数据量和较长的测试时间是发现内存泄漏问题的关键。发现内存泄漏情况之后，用前面介绍的 LuaDump 工具进行内存分析，找到泄漏点再通知程序修改。

压测有可能发现性能不满足目标需求，此时可以有两种解决方案：优化代码或修改需求。

首先可以用之前介绍的 LuaProfiler、Perf、VTune 和 ProfilerAnalyzer 工具进行分析，找到当前占比较多的模块并通知程序修改。

案例分析：
某次客户端性能测试中发现，在某个 NPC 周围时客户端帧率平均值较低，借助常用的 VTune 和 ProfilerAnalyzer 客户端性能分析工具均未能准确定位到问题。经过仔细观察注意到，帧率呈现一定周期性变化规律；于是使用LuaProfiler 工具进行一段时间的采样分析发现，是由于 NPC 每隔几秒执行的冒泡代码会进行策划表改写操作导致。

其次可以和策划商量修改需求。

案例分析：
在一个类似 QQ 漂流瓶玩法的压测中，发现当未读瓶子数量足够巨大后，对瓶子数据进行匹配操作时服务器负载会比较高，于是与策划达成共识后决定牺牲一定随机性换取性能。优化前版本将所有待匹配漂流瓶存储在一个数组中，每次随机选择其中一个瓶子，并且需要依次移动之后的数据；优化后的算法为，将数据存储在 N 个数组中，每次随机抽取其中 1 个数组最后的数据。最终版本性能达到预期目标，外网运行情况良好。

比较常见的负载不均衡现象是，当一个玩法需要开启较多副本时，在多个进程上数量分布差异较大，导致副本多的进程延时较高，进而影响玩家体验。

常用的处理方式为，结合进程负载和同类型副本数量进行选择：创建副本前，首先判断进程上已有的同类型副本数量，排除超过阈值的进程；然后从剩下的进程中选择负载最低的进行创建，以实现负载均衡。

在说这个问题之前我们先看一下具体案例：

案例分析：

QA 需要打一个外网 PATCH，但是 PATCH 内容拷贝出错了没有复制完整，导致打到外网之后服务器开始大量报错，进而服务器卡住。玩家跨进程传送时，是将玩家数据先在一个进程销毁然后再在另一个进程创建，由于服务器太卡就导致玩家跨进程时掉线，并且同时数据也没有及时销毁。此时玩家重新登录，就在另外一个进程有了新数据，相当于同一个玩家在一个服务器有了两份数据，为各种不合理操作埋下伏笔。

此次事故的后续改进措施为：

• 所有 PATCH 改用提交 SVN 的方式传递，并优化 PATCH 工具直接对文件而非字符串操作，以彻底杜绝拷贝出错的可能性
• 优化游戏报错模块，重复报错只打印一次详细堆栈，减少服务器卡顿程度
• 增加超级 ADMIN 端口，服务器出现大量报错导致卡顿时，优先处理此端口指令以快速修正报错
• 服务器增加玩家唯一性判断，防止存在同一玩家的多个实例

从此案例得到的启发是，可以通过压力测试的方式增加游戏负载，并配合功能测试，以发现高负载情况下可能的游戏逻辑漏洞。

本次的端游压力测试分享就到这里啦，希望能给感兴趣的同学带来帮助~

游戏测试也就是我们俗称的QA，ta们是游戏上线前的守门员，我们今天邀请到了一位网易游戏雷火的游戏测试大大来和大家交流探讨一下游戏测试中的“探索式测试”。欢迎大家与我们探讨交流

开始讲解探索式测试之前，先来和大家谈谈传统软件测试。下图是一个最基本的测试流程1：

QA同学应该都很熟悉这个完美的流程，但是也不得不承认受限于现实工作中的各种状况，这个完美的流程只存在于理想中。我的上一份工作虽然也没法完全严格的按照这个流程来做，但是也算可以勉强坚持做到七八成的样子。

可是入职网易作为一名游戏QA之后，随着项目玩法功能的丰富，自己负责的模块越来越多，迭代也越来越频繁。为了适应游戏测试的工作节奏，我的工作习惯慢慢转变成了一种“不符合常规测试流程”的方式：

• 在项目初期，我不再花时间去做深入的测试分析，不再去写详尽的测试用例。
• 了解功能、测试设计、测试执行几乎变成了同时在进行。
• 测试重心会随着项目进程发生变化，比如项目前期我不再抓着一些细节BUG不放。

虽然这个方法不是那么的“光明正大”，但是最终的测试质量和测试效率倒是意外的不错。所以这两年间我在一种纠结的情绪中坚持使用并优化着这种测试方式。

几个月前了解到了“探索式测试”，惊喜的发现这个概念与我的测试方式有诸多相似之处。我开始查阅相关书籍和网上的资料，发现其中部分内容可能有些颠覆认知，部分内容可能有些难以理解，部分内容可能并不一定能直接应用到游戏测试中。为了能够更好地理解这个概念，看这些资料的时候我会不断的问自己一些为什么，然后再结合自己之前的经历与感悟回答自己的问题。

下面我把这些自问自答整理出来。如果你未接触过探索测试并且测试工作也遇到了瓶颈，希望这个文档可以带给你一些启发；如果你也像我一样误打误撞使用了探索式测试，希望这个文档可以帮你整理思路排除疑惑；如果你是一个熟练掌握探索式测试思维的老司机，希望可以一起进行探讨共同进步。

温馨提示1：为了提升阅读体验，建议不了解探索式测试概念的同学至少先看一下百度百科的词条介绍。

温馨提示2：探索式测试初看起来像是一个很玄学的概念，但我觉得其实它有很具象的内涵，建议配合自己的工作经历来看待它。

注1：为了方便展示我剔除掉了诸如用例评审或回归失败等情况的节点，以及其他职能工作的节点。

如果你去搜索探索式测试的概念，可以得到类似的答案——探索式测试是一种强调测试人员的主观能动性的测试思维，让测试人员可以同时设计测试和执行测试，测试人员通过测试来不断学习被测系统，同时把学习到的关于软件系统的更多信息通过综合的整理和分析，创造出更多关于测试的设计。下面针对这个定义，谈谈我的理解。

1.1怎么理解探索式测试是一种测试思维？

类似面向对象或面向过程的概念，它们本身并不是工具，而是作为思维模式来指导开发。同样探索式测试，它本身并不能直接拿来发现BUG。但是测试人员可以在各种软件的测试中通过这种思维模式的指导，选择合适的技术或工具，开展黑盒测试或者白盒测试，提高测试效率的同时确保软件有更高的质量。比如我会在探索式测试的过程中，学习各种玩法的用例设计方法来提升自己的用例场景覆盖率，也会麻烦测开同学或者程序同学帮我写一些GM命令或者小工具来提升测试效率。

1.2如何强调QA的主观能动性？

可以把传统测试比作跟团游：

我们的行程是预先设计好的，去哪些景点、每个景点玩什么项目、每个项目玩多久等等吃住行的细节都是固定的，甚至可能是风雨无阻的。不感兴趣的景点耗费了不少时间，感兴趣的景点反倒没有时间深度游玩，天气不好甚至还要硬着头皮出门。一趟旅行结束，可能只剩糟糕的体验。

相对的探索式测试就像是自由行：

旅行前——我们会预先确定目的地（待测试模块），也会提前做一下攻略（需求分析，了解竞品），预定酒店和车票（里程碑节点），但是攻略不会像跟团游那样精确到细枝末节（不需要完整的测试分析和用例）。

旅行中——我们在感兴趣的景点中可能会多做停留（重要功能或不稳定功能），不感兴趣的景点少做停留甚至砍掉（次要功能或稳定功能），具体娱乐项目或餐厅点单也可能是临时决定的（鼓励QA发挥主观能动性）。如果假期充足（上线期限）或者天气变化（开发进度受阻，需求变更），我们还可以改签酒店或者车票（重新安排测试计划）。

旅行后——我们会觉得这次旅行虽然带有小小的遗憾（测试不可能发现所有BUG），但是我们这次旅行的目的基本达到（排除了发布风险，确保了产品质量）。

越是有经验的测试人员使用探索式测试越能发挥更好的效果，因为他们清楚与其对着后面必然会被改的面目全非的设计文档编写详细的测试计划，不如省下时间轻装上路，在实际探索的过程中发挥自己的主观能动性，制定更符合当前情况的测试策略，让测试工作可以更贴合实际的开发工作。

1.3如何理解概念中软件学习、测试设计、测试执行“同时”进行？

去网上搜索“探索式测试”基本都可以看到上面这张图，其中学习、探索、测试三个步骤是“同时进行”的。但是依照我的理解这里并不是指真正的“同时”，只是相对传统软件测试而言这些步骤更像是并行的，分别从周期和流程两方面谈谈我的理解：

从周期上来讲，传统软件测试会在软件学习、测试设计、测试执行这三个阶段分别投入比较多的时间。而探索式测试并不要求测试人员在模块开发前就花大量时间完成全部内容的学习以及深入的测试设计，测试人员可以在模块中的每个功能点做好后只用很短时间就可以完成一轮软件学习、测试设计、测试执行。

从流程上来讲，传统软件测试中软件学习、测试设计、测试执行是分阶段顺序执行的。而使用探索式测试的测试人员，可以在学习待测试功能后直接去软件中通过实际操作来强化理解，也可以在执行过程中发现了用例设计之外的状况再去完善设计。在探索式测试中，学习、设计、执行三个步骤不再有明确的界限。

综上，对软件学习、测试设计、测试执行会在短时间内互相切换，这样快速的迭代起来，从宏观上看起来它们就像是“同时”在进行。

了解了探索式测试的概念，疑问反倒更多了：探索式测试看起来很随意？用例还要不要写？测试质量是否有保障？会不会很难应用到工作中？这一节会针对这些问题谈谈我的理解。

2.1 探索式测试、传统测试、即兴测试有什么关系？

传统测试——测试人员按照软件测试流程，按部就班的做测试工作。

优点：这个测试流程很完美，如果执行下来可以确保不出大差错。

缺点：需要相应的开发流程制定与执行，否则直接生硬套上的传统测试流程并不能很好的执行下去，质量得不到保障的同时QA同学也容易感受到挫败。

即兴测试——是指没有准备、随性而发的BUG搜索过程。

优点：没有门槛，谁都可以去做这个事情，有时还会打破测试人员的固有思维，发现测试死角的BUG。

缺点：缺乏测试理论的支持和明确的目标，导致发现BUG的效率并不高。而且往往因为随性而发，就算发现了BUG也很难复现。一次测试过后，可能不会产出可以留存下来的经验。

关于探索式测试，我觉得与其说是一种全新的思维方式，更像是传统测试和即兴测试按一定比例混合而成，而且QA同学可以根据实际情况充分发挥自己的主观能动性去调整这个比例。

比如在做冒烟测试的时候，我会先“随性”的去尝试各种方法使用这个功能，在这个过程中发现BUG，同时学习了解需求文档中可能并未说明的内容。但是这种“随性”是依赖于测试技术以及测试直觉的，避免漫无目的的浪费时间；是会先进行设计再去执行的，避免发现BUG又无法复现的尴尬。

相应的，功能稳定后的探索式测试中传统测试的比例就会提高了。

探索式测试，在我看来保留了测试技术支持的同时又可以充分发挥测试人员的主观能动性，让QA的测试工作可以更柔软的贴合现实中的开发过程，让测试质量得到保障的同时测试过程也更有乐趣。

2.2 前面提到，探索式测试不在测试初期花时间去做完整的测试分析或写详尽的测试用例。那么完整的测试用例是否还有必要？

先说答案，在我看来完整的测试用例很重要、很重要、很重要。

游戏软件并不是那种交付完了就完事儿的软件，测试工作基本会覆盖游戏的全生命周期。这个生命周期中玩法会迭代，人员会变动，甚至作为模块负责人的我们自己也可能会忘记细枝末节的功能。这种时候原始需求文档是必然靠不住的，零散的需求单也难以整理，最可靠的还是QA产出的完整的测试用例。既然完整的测试用例很重要，那么这份用例怎么来呢？

上文提到，探索式测试会让QA可以在很短的时间内就完成一轮软件学习、测试设计、测试执行，每一轮的测试设计过程就会有用例产出，最终整个大的模块测试完成时，完整的用例设计也就完成了1。

注1：这个具体操作见下文讲解。

2.3 模块处于不同的阶段时，探索式测试的重点有何不同？

关于这个问题的答案，《探索式软件测试》一书的作者给出了很好的解答，结合我的理解整理如下：

早期开发阶段，探索式测试的目标应该是为了“发现设计缺陷”，“发现被误用的设计”以及“发现与用户使用逻辑的矛盾”。这些目标让探索式测试更注重于把事情做成而不是以某种独特的方式做事情。

对于游戏开发初期，给出一个可供体验的demo是首要任务，玩法调优、配置铺量、美术资源都不是必要的。这个阶段QA的探索式测试像是一次“开荒”，在全新的玩法中趟出一条通畅的主流程。这个过程中QA不必花心思设计太过细节的测试方案1，如“玩法奖励是否合理”，“武器是否穿模”或者“每日任务的难度是否过大”这些后期方便调整的问题。省下的精力除了确保玩法的完整和通畅，还应该更多的思考如“玩法是否考虑了奖励投放”，“是否留有根据不同主角体型调整武器尺寸的字段”或者“每日任务是否考虑了刷新时间设置”这些可能对未来功能完善造成影响的隐患。

后期开发阶段，探索式测试的目标应该是为了“确保产品功能可以正常工作”，“确保用户数据的安全性”，“确保完工的软件符合要求”，“确保功能满足适用的范围”以及“确认以前的缺陷不再重现”。这些目标让探索式测试更注重于以一种特定方式来探索某一个特定的功能。

对于游戏开发后期，上线就是最终目标了。QA同学需要在原来探索的主流程上针对分支再开展深入探索。此外兼容性测试、压力测试、性能测试等也需要提上日程了，当然最后的回归测试也不能少。确保最终上线时玩法的质量没有致命问题的前提下，细节问题尽可能的少。

注1：这里并不是鼓励QA同学无视细节BUG，而是要视项目进度来调节测试的颗粒度。我个人认为，前期提的一些细节BUG对于产品最终质量并不会起到太大作用：一方面这些细节问题的复现场景可能会在后续玩法迭代中被删掉；另一方面前期项目开发目标是“能玩”而不是“好玩”，太多的细节BUG会阻碍开发同学的进度，也会让开发同学觉得QA同学与他们的目标不一致导致不愉快的合作关系。建议QA同学根据项目进度调整测试的颗粒度，前期将时间更多的用来思考潜在的隐患，避免后期铺量后会造成隐患扩散引发更多的BUG，后期再将注意力转移到探索细节问题上。

2.4 上面提到需要将一个大的模块拆成小的功能点进行探索式测试，这个如何进行？

这个问题涉及到两个点“如何拆分”以及“拆分后如何进行探索式测试”。

如何拆分：

拆分细的功能点可以简化分配测试资源和跟踪测试进度的难度，这个方法其实在传统测试中也会用到，每个QA同学应该都有自己的习惯，这里讲一下我的方法，供大家参考。

进行模块拆分时，我的原则是“保证拆分后的功能点仍然完整的前提下，尽可能的独立”。以主角动作为例：

一方面要确保待测试的功能是完整的。比如跳跃功能需要包含跳跃UI交互、主角动作资源、以及程序功能支持。我会等相关需求都完成后再进行测试，这样可以让我的探索过程不至于因为功能未实现受到阻碍，影响测试效率。当然 “跳跃UI可以点击”也是一个功能，但是它缺少实际的测试意义，也没有太多可测试的内容，我会放在跳跃功能中一并测试节约时间。

另一方面要确保待测试功能是独立的。比如“跑步中跳跃”，我会先分别对独立的跑步功能和跳跃功能进行测试。这样可以让我学习了解功能的难度更低，也可以让测试设计与执行更容易开展。（关于功能点之间交互情况的测试会在下一个问题中讲解。）

拆分后如何进行探索式测试：

与传统测试相同的部分是都会从用户使用角度出发设计基本的测试场景。但是，不同点在于，探索式测试不要求测试人员一次性设计出尽可能多的测试场景（我一般会准备两三个最基础的测试场景就开始动手执行）。那么如何确保最终测试设计的覆盖率？我觉得很重要的一个点是探索式测试强调测试人员及时处理“反馈”，并以此做出下一步探索的计划。还是以跳跃这个功能为例：

我设计的第一个基础的测试场景就是“点击跳跃UI，主角播放跳跃动作”。如果发现主角并没有正常播放跳跃动作，那么就需要针对这个“反馈”开始“探索”背后的原因。我会怀疑是不是这个体型的动作资源缺失，是不是主角有什么特殊状态，是不是受到当前地形的影响等等。基于这些怀疑，一方面我可能需要向开发人员请教相关设计以及排查手段，根据他们的“反馈”加深对软件的学习；另一方面我还会补充设计如“不同体型跳跃”，“定身状态下跳跃”，“水中跳跃”这些测试场景。

当上面的问题解决后，再检查当前已有的测试设计是否还有遗漏，基于检查结果的“反馈”去设计新的测试场景如“连续快速点击跳跃UI”或者“跳跃的高度”。如此形成学习、设计、执行的快速迭代，逐步覆盖对跳跃功能进行“探索”，直至评估自己的测试设计已经覆盖全面。

2.5 仅对单一功能进行测试，会容易漏掉功能间交互时才会表现出来的BUG，探索式测试如何覆盖不同功能之间交互的情况？

回答这个问题，还是接着上面跳跃功能的例子讲讲我一般是怎么做的：

第一点，之前的探索中肯定会发现一些与其他功能交互的情况，如“跑步+跳跃”。这类测试设计可以在上一步想到的时候就记录下来，然后在测试模块间关联情况时进行执行。

第二点，需要结合自己对游戏的理解以及测试的经验进行测试设计，如思考是否可以和游戏内的重要模块进行交叉测试，针对战斗模块就可以设计“跳跃+受击”或者“跳跃+使用技能”的测试场景。

第三点，保持交流沟通，学习其他QA同学的分享或者向开发同学请教设计意图与代码实现，他们的讲解或者提醒也会成为重要的测试线索。

第四点，可以依靠听起来有点玄学的“测试直觉”，比如我觉得跳跃动作一定可以通过某种方式卡死，那么我就会开始设计各种场景去尝试达到这个目标。这个方法虽然不一定百分百会奏效，但是也不会让我空手而归，就算不能达到“动作卡死”这个目标，也会在这个过程中发现其他问题。

总结一下，个人觉得功能间交互的探索方式与单一功能本质是类似的，也是需要依据各种“反馈”作为探索的灵感来源。但是随着功能交互的复杂度提升，要求测试人员将自己的各种测试技能发挥到极致。测试人员需要不断丰富自己的测试经验、保持交流沟通、磨练自己的测试直觉，才能在更复杂的情况中探索的更深远。

2.6 部分资料中提到探索式测试模式下测试人员的设计可以写的笼统一些，方便测试人员在执行的时候留下更多自由发挥的空间，使用稍有变化的测试路径可能会发现一些遗漏的BUG。这么说测试设计是不是不用涉及太多细节？

我个人并不赞同这种说法，原因有两点：

首先，我认为探索式测试只是不强制要求测试人员在测试执行前就绞尽脑汁去做高覆盖率的测试设计，但是测试人员需要在测试的过程中基于反馈逐步完善测试设计。

其次，探索式测试确实鼓励测试人员在执行的时候跳出原有的测试设计去探索新的测试路径。但是探索式测试也要求测试人员避免测试工作的“健忘性”，及时将新探索的路径记录下来，否则这次探索可能就会变成无法复刻的即兴测试。

所以说，并不是说为了发现更多的BUG，所以故意把测试用例写的笼统一些。而是要在确保用例设计尽可能完善的前提下，还保持这探索精神去探索更多的测试路径。

补充说明：我自己确实会用一种“笼统”的用例写法，在不降低覆盖率的情况下减少用例的体量以及日常执行的负担，就是在用例备注中列出所有可能的选项，然后在每次执行时轮流使用不同的选项，达到一段时间内全覆盖的效果。如：任务确实会因为主角体型导致一些问题1，但是如果用例根据不同体型的主角分别写一遍会显得很冗余，执行起来也比较耗时，最重要的是这类问题出现的概率可能并不高。那么我会在用例中备注写明“请在任务执行中随机变化体型进行测试”，或者“日常测试执行注意轮流使用不同体型测试”，甚至可以注明“日常测试中单号日期用男号，双号日期用女号”。

注1：如“对话镜头高度没有适配”，“主角被地形卡住”等。

2.7 定义中提到探索式测试中测试工作是和软件学习同时进行的，那么最初需求文档出来后软件还未开发前，没有待测试的软件探索式测试是否就无法开展？QA是否还需要深入分析了解需求文档？

先说答案，深入的需求分析很重要、很重要、很重要。

需求阶段发现的BUG是极具价值的，可以避免后面项目开发走弯路，节省一系列的开发成本，这是不争的事实。既然有很高的价值，那就有必要去做。不过这么做的话是否和探索式测试理论矛盾呢？

翻阅的资料中并没有明确探讨过这个问题，不过可以说说我的方式供大家参考：

一方面，需求分析的时候我会在脑内模拟软件的实现，并设计并执行用例，思考逻辑矛盾的地方。

另一方面，现在游戏行业完全创新的玩法并不是很常见，竞品中可能就已经包含了需求文档中的部分内容。所以如果需要进行软件的学习，竞品就是一个不错的选择。

当然，上面的过程是在探索式测试思维的指导下进行的。

2.8 看起来探索式测试有点随性，与QA严谨的态度不太相符，实际使用中是否有效果？能否很好的确保产品质量？

先谈一下我自己的实际数据，去年初到目前近两年的时间内，我关闭的需求单总数是组内正职功能测试人员平均数的1.86倍，新建BUG数是组内正职功能测试人员平均数的1.56倍。测试质量和测试进度得到了一起合作的其他职能同学的认可，在几次对内对外测试中我负责的模块没有出现严重问题。当然这个数据不只是探索式测试的功劳，还与工作安排技巧和交流沟通技巧有关。这里只谈一下关于探索式测试带给我比较直观的感受吧。

首先，探索式测试优化了我写用例的时间消耗。第一，把完整详细的用例设计工作后移，可以让我在前期有更多时间进行实际的测试工作。第二，开发过程中模块调整必然会连带着需要调整用例结构甚至删除用例，探索式测试可以很大程度上规避这种情况造成的时间成本浪费。

其次，看我的数据会发现BUG单的倍率是低于需求单的。如2.4中介绍，不同时期的测试重点不同，前期我并不会花时间去挖掘细节的BUG。相应的，省下的时间我用来思考潜在的隐患，避免后期铺量后会造成隐患扩散引发更多的BUG1。因此，这样既减少了前期开的BUG数量，也可以减少后期开发产生的BUG数量。此外除了节省自己的时间，也可以节省一起合作的开发同学的时间。还可以避免因为一些琐碎的BUG影响我与开发同学之间的合作关系。

第三，探索式测试是一种小步快走的测试模式，在敏捷开发的大环境中，QA可以更快的响应开发工作，并且有更多时间进行实际的测试工作，最大可能避免需求单的积压，可以跟上快速且并发的开发节奏，不至于让测试工作成为项目开发的瓶颈。

第四，探索测试中一个重要环节就是“软件学习”，这一点鼓励QA与开发同学保持沟通，除了让QA可以更深入的了游戏功能外，还可以提升QA与开发同学配合的默契度。这个默契度在我看来是很宝贵的，让我和一起合作的开发同学们可以更高效的工作，工作效率甚至可能会高于由各种强力人士组成的临时团队。

最后，探索式测试可以充分发挥QA的主观能动性，依赖QA的测试经验以及测试直觉。在每一轮的学习、设计、执行中去更有风险的方向探索，发现更有价值的BUG。因为每一轮的探索周期比较短，QA的努力可以很快的得到反馈，激励自己不断提升测试能力，让下一轮的探索更深入、更快速。

2.9开展探索式测试的门槛会不会很高？

虽然可能之前没有了解过这个概念，但是看到前面的内容，你可能会发现自己已经在不知不觉中或多或少的使用了这种测试思维。就像前面说的探索式测试只是一种思维，在我看来入门难度并不高，但是难度在于怎么做好，探索式测试的效果非常依赖测试人员的能力。测试人员的测试设计能力、问题分析能力、时间安排能力、沟通表达能力等等都会影响到探索式测试的效果。如果你是测试新人，那么我有这几点建议：

首先，建议熟练掌握更多的测试技能。对于一个新的玩法，条件反射的就会清楚这类玩法需要考虑哪些测试点，坑点一般会埋在哪里，什么时候需要开展性能测试、兼容性测试。长此以往，测试直觉就会越来越准，能够快速决定出探索方向，减少无用的探索。

其次，建议合理安排自己的工作时间。把工作合理拆分，然后利用探索式测试小步快走的特性填充碎片化的工作时间，这样才能充分发挥探索式测试提升效率的特性。

最后，建议提升自己的沟通技巧。无论探索式测试“学习”“设计”“执行”中哪一步，我们都不可避免的要频繁与一起合作的同学们进行沟通，掌握良好的沟通技巧是必不可少的。

不过技能不纯熟也没关系，探索式测试鼓励测试人员边学习边测试，如果过程中发现自己不太会处理反馈那就去学习如何分析问题，如果过程中发现与开发同学合作不愉快那就去学习沟通技巧。所以在我看来，只要你能设计出一条测试路径并保持探索精神，那么就可以愉快的出发了。

2.10 如果是有一定经验的QA同学，打算开始或者已经开始了探索式测试，需要注意哪些问题？

首先，要避免漫无目的或重复的测试工作。起初有的时候我会在自己设计好的测试场景中兜兜转转很久但是一无所获，最终就会变成在游戏中漫无目的乱点。意识到这个问题后，我做了几件事情：

第一，我会按照2.3中说的分析当前的测试重心应该是什么，再按照2.4中说的方式拆分功能降低测试设计的难度，最后再按照2.5中说的逐步掌控整个模块的测试工作。

第二，当面对一个玩法无从下手的时候，可以先尝试从玩家角度出发设计探索的主要路径。如果是时间线性的玩法（如打副本），那就思考玩家的常规操作流程。如果是基础功能的玩法（如技能），那就思考玩家的使用场景。然后再在此基础上进行更深入的探索。

第三，这种情况目前我还是无法完全避免，但是现在它对我来说就是一个信号，告诉我要停下来，分析是测试方向不正确还是测试方法不正确，然后重新调整我的计划。

其次，要让自己的探索过程留下痕迹。我之前有一段时间负责游戏内十来个战斗单位的测试工作，包括他们的“模型”、“动作”、“培养”、“技能”等，其中技能测试是最复杂的部分，要考虑“主动还是被动”、“是否有CD”、“单体还是AOE”、“伤害技能还是加血技能”、“音效”、“特效”等等因素。工作中我发现虽然测试过好几个技能有了一定的测试经验，但是当开始一个新技能的测试时还是会漏掉一些边边角角的测试点。另外因为这种游戏内单位数量较多，还分配给了组内其他几个QA同学一起测试，他们的测试设计中也包含了我一直都没有考虑到的情况。

为了解决这个问题，我开始总结Chesklist，比如对于技能，测试工作都需要关注技能的“数值”、“效果”、“培养”、“特效”、“音效”等情况，那么我们就可以针对这些测试点做一份技能的Checklist。再和其他QA同学一起评审完善这份Checklist，之后当一个新的技能需要测试时，我只要依照这份Checklist就能基本完成主要的测试工作，省下的时间就能去更好的探索这个技能独有的一些细节。除Chesklist外，各种坑点总结与测试技术分享对我们这种团队测试的模式来说同样很重要，这些经过提炼记录下来的文字就像是地图，把一个QA的探索经验变成团队的探索经验，再在团队探索经验的支持下让每个QA可以探索的更深入。

最后，要让探索式测试把自己的测试工作变得不无聊。我听到过一些QA同学抱怨测试工作很无聊，也有一些其他职能或者行业外的同学问我测试工作是不是很枯燥。当我还是一个测试萌新的时候，发现一个BUG就会让我很有成就感，但是渐渐的测单子、开BUG变成了平淡的日常工作。为了让工作有一些乐趣，我开始将注意力转向测试工作中一些更有创造性的事情上：如何做出更明智的测试决策、设计性价比更高的测试方案、应用新的测试技术或概念。恰巧探索式测试的短周期特性可以更快的反馈出自己的成长与不足，让我有动力去做下一轮探索。

2.11 探索式测试与自动化测试或者AI测试的关系？

探索式测试是测试思维，而自动化或者AI是测试工具，是两类概念，所以并不存在冲突。这两方面我都不是专家，简单谈谈我的理解：

先说自动化测试，自动化测试主要负责的是“测试执行”这个步骤。但是自动化维护成本较高，对于处于频繁迭代中的模块来说性价比不高。另外，让自动化脚本包含更复杂的执行步骤以及更全面的期望检查也需要测试人员投入更多的精力。但是编写检查基础流程的自动化脚本相对来说成本较低，再配合资源检查脚本可以很好的帮助QA同学排除掉那些低价值又反复出现的BUG带来的干扰，让QA同学可以有更多精力去设计更多有价值的测试场景。

至于AI，现在使用AI玩游戏已经是一件很常见的事情了，但这都是在让AI在游戏中找到“一种获胜”的方式。如果应用到测试工作中，首先需要让AI可以找到尽可能多的测试路径，目前已经有一些软件训练AI通过识别UI并进行点击，去探索不同功能界面之间切换的测试路径（我们的伏羲也在做相关的工作），但是对于复杂的游戏操作，如何更有策略的探索尽可能多的测试路径还是一件比较困难的事情。另外，我看到过一些视频中AI最终学会的是使用BUG来通关，这说明教会AI判断各种游戏表现是不是BUG显然要比教会AI什么是胜利困难很多，目前最常见的做法是在AI探索测试路径的过程中收集软件的报错，此外利用语音识别以及图像识别也可以让AI判断一些简单的表现是否正确，但是更复杂的情况仍然需要更多的研究。

虽然可能还很遥远，但是我对技术改变测试的前景还是很看好的，也欢迎各位大佬来一起探讨。另外，教会机器如何探索测试前，我们测试人员也可以先强化一下自身的学习。

这一节主要讲讲我自己对于探索式测试的理解，以及我自己是如何在测试工作中使用探索式测试的。

3.1 作为游戏QA，我对探索式测试的理解

常规软件的开发一般是基于甲方的需求或者市场的需求进行设计开发的，更像是满足用户需求的“工具”，从一开始它的设计目的就比较明确。游戏软件的设计则是在对市场口味的揣测过程中进行的，这个设计目的并不是很明晰，比起“工具”游戏更像是一件“工艺品”，在这件“艺术品”的打磨过程中对设计频繁的推翻再重建是在所难免的。需求的频繁迭代、需求单描述的不完善、开发流程的不理想、测试时间的不断压缩，这些都是我在游戏工作中的日常。我面对的第一个问题就是游戏测试工作开展的大环境并不理想。

作为QA大家应该清楚就算是一款功能简单的软件我们也很难列举出全部可能的执行路径，更不要说一款包含五花八门玩法的游戏了，可能的路径几乎可以说是无限多的。每一条路径上都可能埋着BUG，所以一款游戏的BUG是不可能被全部发现的。如果可以在游戏上线前排除掉所有可能会造成严重影响BUG的前提下，修复了尽可能多的细节BUG，那么可以认为这款游戏的测试质量已经是很不错的了。那么如何在“有限”的时间内，从“无限”的路径中选取有价值的路径来执行，这就是我面对的第二个问题了。

结合我的感受，探索式测试可以很好的解决了我在游戏测试中遇到的上面两个问题：

一方面，探索式测试在我看来是一种很务实的测试思维：它不鼓励直接硬套传统测试流程直接到开发流程上，导致测试工作难以开展。它也不是即兴测试，让测试工作变的漫无目的且没什么技术含量。它没有回避软件开发中流程中的“不理想”，而是鼓励QA同学积极面对这些“不理想”，充分发挥自己的主观能动性在有限的时间内，对这些“不理想”做出最优的决策1。

另一方面，探索式测试小步快走的模式也很贴合我们很多项目采用的敏捷开发模式。它让QA可以更好地为软件开发助力，而不是成为软件开发的阻力。同时也可以避免QA为了配合敏捷开发而造成过多的测试成本浪费。我想部分QA同学和我一样会不自觉的被“逼”上探索式测试这条道路，也是因为它与敏捷开发的契合特性。

在我看来，探索式测试解决的是“测试工作”的问题，而不是“测试技术”的问题。 “测试技术”的问题还是需要靠各种技能和工具来解决，不过这个过程可以在探索式测试思维的指导下进行。

注1：这里我要表明立场，面对不合理的流程，QA有责任也有义务去推动优化这个流程，不能听之任之，逆来顺受。流程本身的BUG，不仅不利于测试工作的开展，也不利于产品的健康发展。

3.2 下面讲讲我自己在工作中开展探索式测试的方式。

这算是对全文的总结，也是我目前的工作方式。

首先，需求文档出来后，我会在三方会议之前把文档分析一遍，当然是用探索式测试的思维指导来进行分析的，同时也就在思维导图上划分好了用例的大概框架。这么做一来可以充分发现需求中的潜在问题，也可以让三方会议的效率更高一些。

（这部分涉及到：2.7中提到的文档分析方式。）

之后，来到开发初期，这段时间我会去熟悉竞品（实际体验或者云体验），了解这类玩法玩家可能会在哪部分重度体验，哪些地方逻辑复杂或容易出现BUG，这都是后续开展探索式测试的方向。此外，还需要关注开发进度，与开发同学沟通，尽可能分段提交功能，让我可以更早的介入测试，这样可以降低测试难度，也会缩短整个开发周期。当然，这段时间还要安排好其他模块的测试工作。

（这部分涉及到：2.7中提到的文档分析方式的延伸；2.5中提到的拆分功能点的部分操作。）

接下来，游戏功能开始一个接一个的不断完成，我也在“学习”“设计”“执行”循环中跟进完成我的测试工作。此时测试重点在于“发现设计缺陷”，“发现被误用的设计”以及“发现与用户使用逻辑的矛盾”。测试工作先从拆分后的独立功能开始，之后再考虑这些功能间的交互情况。

（这部分涉及到：2.3中提到的项目前期的测试重点；2.4中提到的模块拆分测试；2.5中提到的模块间关联测试；需要关注2.10中提到的注意事项；需要借助如2.11中提到的资源检查、自动化等工具避免低价值又反复出现的BUG带来的干扰。）

来到开发中后期，开始玩法细节打磨。这时依然是使用小步快走的探索式测试跟进每一次改动。这期间测试重点转向“确保产品功能可以正常工作”，“确保用户数据的安全性”，“确保完工的软件符合要求”，“确保功能满足适用的范围”以及“确认以前的缺陷不再重现”。这时除了关注模块本身，还需要将探索的范围进一步扩大，更多的考虑这个模块与游戏其他功能间交互的情况。

（这部分涉及到：2.3中提到的项目后期的测试重点；2.5中提到的模块间关联测试的延伸；需要关注2.10中提到的注意事项；需要借助如2.11中提到的资源检查、自动化等工具避免低价值又反复出现的BUG带来的干扰。）

功能完成后，就可以开始把思维导图上的用例搬运到平台上了，这部分工作我有时会自己来做，有时也会安排给我们可爱的新人来做，这个工作对于新人来说是学习测试设计与用例编写的好机会。

（这部分涉及到：2.2中提到的用例编写的重要性。）

到这里，本文就差不多结束了，写这篇文章的目的主要为了分享一下我关于探索式测试的理解。探索式测试除了指导QA对待测试软件探索外，也在指导QA对自身潜力的探索，鼓励QA“不择手段”的去把测试工作做得更好，无论是学习测试理论也好，开发测试工具也好，包括整理这篇文章的过程中我又有了新的收获，也希望这篇文章能给你带来一点帮助。如果大家关于测试方法有什么自己的观点欢迎一起讨论。