硬实力+软实力！2023功能测试进阶之路！

作为一名游戏功能测试，偶尔和朋友聊起工作，他们会说：“你这个工作好呀，平时玩玩游戏，一边玩一边就把工作做了”；有时为了避免别人这样理解，我干脆说自己是搞游戏开发的，这个时候又有人会说：“就是写代码是吧，你的发量看起来还不错呀！”，这些时候我往往也很无奈，因为之前很多时候其实自己也说不清楚，作为功能测试，到底具备了哪些专业能力。

　　功能测试的从业门槛貌似很低，好像谁都可以来应聘这个岗位，但我心里知道，并不是谁都可以把这份工作做好。那么功能测试到底需要具备哪些能力，凭什么可以把这份工作做好？这个问题曾困扰了我很多年，直到我来到网易，通过不断向身边同事学习，阅读优秀同事的分享文章，通过自己工作中和业余时间的不断探索和思考，我好像有那么一点开窍了，借此分享下自己对功能测试岗位的理解，以及如何让自己成为一名更优秀的游戏测试。

　　作为一名从业多年的功能测试，我认为想做好功能测试，要从硬实力和软实力两个方向来做好自己，才能保持稳定发挥，处理好日常的功能测试工作。

　　一、关于硬实力

　　记得工作两三年的时候，曾经有其他行业的同学问过我，做游戏测试难不难啊？都需要会些什么呀？我还清楚的记得当时是怎么回答他的，现在想想也很好笑：做测试不难啊，只要你爱玩游戏，会用电脑就行了。现在如果还有人这样问我，我肯定会耐心的跟他讲讲，我认为的作为游戏功能测试，需要具备哪些能力：

　　1.编写测试用例

　　编写测试用例应该算的上是测试人员入门的一项基本功，但同时也是贯穿整个职业生涯的一项重要能力，它就好比学武功时的扎马步，把基本功练的越扎实，后续才会越发的得心应手，把测试用例写的越好，不仅可以提升我们的测试质量，也可以节省测试时间，提高我们的测试效率，而且有助于提升我们的测试思维，并有利于与其他同事间协同合作。

　　但我们通常在编写测试用例的时候会遇到两个大的问题，一是时间成本，这个问题可能在已上线项目中更为明显，由于快速的版本迭代开发，很多时候留给测试人员的时间其实并不多，很多人都不止跟进一个功能，毫不夸张的说，上线项目几乎所有的 QA 都经历过连功能的测试时间都要靠挤的情况，那么针对这个问题，作为功能测试我们应该怎么办呢？

　　我建议可以从以下几个方面入手：

　　首先要做的是协调沟通。我们可以先和项目经理以及相关责任人一起沟通一下，确认功能的发布时间、优先级等，看能不能为测试用例的编写争取更充分的时间；

　　其次就是自身工作轻重分明。梳理下自己当前手头上的工作，避重就轻，看是否有些工作可以适当往后放一放，给当前优先级更高的功能留出较为充分的编写用例时间；

　　最后就是用例的精简浓缩。如果前面两点都不能确保有充足的时间来编写测试用例，那么就不要执着于编写测试用例了，可以结合功能文档加上自己对版本内容的理解以及部分自己的经验，输出一份脑图，列出比较重要的测试点。

　　下图是我认为最重要的三大要素，首先我们需要做到确保流程的完整性而不过分在意细节，其次就是数值相关内容是一定要重视的测试点，最后就是玩家参加活动或参与功能引发数据变化的存储，正常和异常情况都需要考虑到。

编辑

　　还想强调一点就是，不论是测试用例还是测试要点，做好用例/测试要点的自我 Review。考虑到时间成本的问题，用例评审基本就不用想了，个人建议是养成自我 Review 的习惯，每次编写完后再抽出点零碎时间，从头到尾看一遍自己写的内容，很多时候其实都能再发现一些遗漏的重要测试点，毕竟我们一次性就把用例写的很完美的可能性还是很小的。

　　编写测试用例第二个大问题就是维护成本，这个问题可能在游戏研发的各个阶段都比较常见，未上线的项目很多功能或玩法都是需要策划不断去斟酌和打磨，所以很有可能一个功能从最开始规划出来，到最终上线，中间改过N多个版本，甚至是已经开发并测试完成，都有可能出现推翻性的改动。已上线或即将上线的项目，通过内测或线上反馈情况，以及版本的不断迭代和更新，各个功能都有可能会有较大的优化或迭代。这种情况下测试用例的维护成本显然是个很大的问题。面对这种情况也不是完全没办法。

　　首先我们要认真做好需求分析，尽可能的减少需求漏洞，从而减少后续功能的改动，比如在做短期活动的时候，我每次都会在三方功能会上提出来，活动结束后如何对玩家未消耗完的道具/货币处理，是系统自动回收还是玩家主动分解？避免策划因没考虑到该情况，开发过程中再去改需求，导致我们要对已写好的用例进行维护；其次在编写测试用例的时候，关于模块的拆分要尽可能的清晰和独立，例如很多新人比较喜欢这样写用例：

编辑

　　如果此时策划说要改一下玩法规则或完成条件或者参与方式等等，那么维护测试用例的话，就需要在上面活动流程里，不断的改来改去，很可能改了这一条还漏了那一条。但如果我们可以把活动流程拆分的更详细一些，比如“参与活动”、“活动规则”、“活动结算”、“活动投放”，划分模块更清晰一些，那么当遇到需求改动时，我们就可以更快更好的去修改相关模块的用例；最后根据“时间管理-重要紧急四象限”原则，用例的维护属于重要非紧急事务，不要过分的执着于维护用例，考虑到改动影响的范围，改动留给我们的测试时间，我们可以酌情考虑用例维护的范围，或者记录下来需求改动的内容，事后再去找时间维护用例，甚至一些影响很小的改动不需要我们去维护用例。

　　2.Bug跟踪能力

　　bug跟踪能力是作为游戏测试最重要的能力之一，很多人在工作中觉得发现了 bug就完成了工作的一半，剩下的一半就是等开发人员改好bug后验证一下就OK了，其实不然。从发现bug，提交bug，定位bug原因，跟进和推动 bug的修复到最后bug的验证，这是一条完整的闭环，每一步都是对我们个人能力的考验。

编辑

　　你是否有想过为什么有些bug别人就能发现，自己却发现不了呢？为什么别人跟进的bug修复效率特别高，而自己跟进的bug却越改越烂呢？让我们从每一步都来看一下，如何才能让自己更好地进行bug跟踪。

　　(1) 发现bug

　　首先我们需要熟悉功能设定。在仔细阅读功能文档的基础上，深入了解功能设定，做好文档分析，这有助于我们更好的完成测试用例的设计、测试环境的准备、测试数据的补充等等，例如当我要测试一个和其他玩家进行战力对比的功能时，熟悉了功能设定后可以很清楚的了解到，哪些养成数据需要在战力对比时进行展示，那么我肯定不会简单的使用gm指令直接升上来角色数据，因为这种数据很多系统和养成玩法都还没有开放，肯定会遗漏一些养成系统数据的对比测试点，这个时候就需要模拟线上头部玩家数据，确保尽可能的覆盖到游戏内所有对战力有影响的功能点；

　　其次我们应严格执行用例。我们需要在测试过程中，保证用例完整的执行，同时可以在测试的过程中及时对用例进行查漏补缺，尽可能的提高我们的测试覆盖度，更好的发现bug。有些人可能在工作了一段时间后变得消极怠慢，不愿去严格的执行用例，有些人可能由于时间很紧急，抱有侥幸心理而跳过一些用例的执行，不管是偷懒还是侥幸心理，未覆盖到的测试点往往在上线后可能带来严重的bug，这种情况是不可取的。

　　(2) 提交bug

　　提交bug时我们应尽可能地规范化。规范化的提交 bug 有助于开发人员更好的理解bug进而更快地修复bug，还可以让我们在bug修复之后更清晰的进行验证，避免时间原因而忘记当时bug出现的环境、条件和表现等重要信息。

　　(3) 定位bug

　　定位bug能力在社招面试时经常会被提起，因为定位bug能力可以很好的体现一位QA的问题分析能力、问题定位能力以及逻辑推理能力等，是一个人工作能力和经验的体现。良好的定位bug能力不仅可以让我们能清楚bug产生的原因，从而举一反三，发现其他潜在bug，也可以给我们和开发人员提供良好的沟通保障，还能很大程度上提高bug的修复速度，从而提高我们的测试效率。下面我想就如何快速精准地定位bug原因讲一讲我的看法和经验。

　　首先详细的记录测试步骤、测试环境、测试数据以及测试结果是我们定位bug原因的必要条件，不管你再怎么有经验有能力，如果缺乏这些信息，那么将很难定位原因甚至无法定位，尤其是一些复现步骤复杂的bug和偶现bug。所以当遇到问题时我们要尽可能的回忆下完整的操作步骤，必要时可以截图、录屏，理清测试环境中的一些重要因素和数据，因为在定位到具体原因之前，任何一个环境因素和测试中的数据都有可能是突破点，以及根据测试结果的一些表现，进行推理和分析。

　　其次，我们需要借助log或调试信息来定位bug原因。比较常用如：在测试内容的代码逻辑中打印输出一些关键参数；不懂代码也没有关系，开发人员一般也会对部分关键参数记录log；我们还可以借助协议测试平台来查看一些操作的过程中客户端发送和接收的信息，以此来分析是服务端传递的数据有误还是客户端本身的问题；还可以通过一些线上的log来尝试复现玩家遇到的bug，从而帮助我们快速的定位 bug 原因，通过分析玩家的行为log数据，可以确定出现问题的前后玩家都进行了哪些操作，从而缩小范围，加上对玩家这些行为数据的分析，来尝试猜测 bug出现的原因，从而最终实现对线上bug的复现以及定位bug的原因，总之我们需要不断提升自身能力的同时，学会借助一些数据和工具，来帮助我们快速精准的定位 bug 原因。

　　最后，通过经验的积累进行合理猜想，例如在某游戏中出现的一个事故，一些养成系统升级时不扣除消耗材料，通过观察我们发现，这些升级材料在背包中占用了两个格子，且整理背包时明显符合合并规则却不会合并，猜测大概率是道具本身出现了异常才导致的升级不扣除材料，再进一步分析这些材料发现，受影响的功能的升级材料都有在当天开启的新玩法中投放，进而猜测是该功能产出的材料出现了异常，通过进一步的沟通，新玩法属于跨服活动，本次功能上线对该玩法获得的道具进行了逻辑改动，禁止跨服状态下该玩法获得的奖励道具放入仓库，至此我们通过一步又一步的猜想和推理大致可以定位到，由于修改了跨服状态下获得道具禁止放入仓库，导致了道具异常，进而引发了后续问题。当然，我们不是毫无根据的胡乱猜想，我们可以通过与开发人员沟通，来了解功能的实现逻辑，这将有助于我们在遇到问题时对bug原因进行合理的推断和猜想。我们还可以通过对以往遇到过的类似问题进行归纳总结，从而当再遇到相似问题时给我们灵感来推断和猜想。还可以通过向其他同事学习阅读一些经典bug的分享，学习总结经典bug的原因，从而在遇到相似问题时，大胆的猜想其原因。

　　(4) 跟进和推动bug的修复

　　这一点其实最能体现的是我们的主观能动性，我放在后面的软实力里面来讲。

　　(5) Bug的验证

　　想必很多人都经历过由于bug修复时的改动，虽然问题点本身验证ok了，但在发布到线上后某些其他相关内容出现了问题。当我们提交的bug被修复后，可能很多人验证时只是对bug本身进行了简单的验证，稍微好一点的可能会想一下是否对其他相关功能造成了影响。这里我想讲一下我对bug验证的理解。

　　首先，bug本身的验证肯定是必要的，但所谓的bug本身的验证有些人也未必做的是全面的。举个简单的例子，游戏内某功能界面，当打开界面的瞬间快速点击关闭按钮的位置，导致界面未加载完成就被关掉了，再次打开界面会出现界面错乱。那么当这个bug修复好之后，是不是有些人就只是简单验证下同样的复现步骤，还会不会出现界面错乱就结束了。但考虑到问题的原因是界面加载未完成导致的，我可能还会去验证下打开界面的时候恰好断线重连，打开界面的时候恰好切场景，打开界面的时候恰好自动寻路完成与npc进行了交互等等，同时还可能会想到其他界面的加载是否存在类似问题。所以bug本身的验证并不仅限于复现步骤中操作的验证，要有一定的延伸和类比。

　　其次，耦合功能的验证，游戏作为大型复杂的软件，其中耦合的功能是非常多的，可能功能逻辑有关联，可能是一些通用的接口或界面，还可能是一些底层的逻辑修改等等。

　　这里我比较推荐的验证方式有三点，一是和开发人员沟通，咨询当前修改可能影响到的功能模块和相关逻辑，从而进行有效的针对性的验证；二是深度体验游戏，只有对游戏内各玩法、各功能模块很熟悉，才能更为清晰的了解模块间的关联，进而在验证 bug 的时候才会想到可能影响到的相关内容，减少耦合功能的漏测；三是和组内同事沟通，尤其是一些通用接口和模块的调用，相关QA会更清楚是否有关联，可以在组内群里发送相关改动信息，提醒可能会用到该模块的同事对相关内容进行及时的回归，从而减少耦合功能的漏测。以上这些只能是尽可能的减少由于bug修复的改动带来的其他问题漏测，更为全面精确的验证，感兴趣的同学可以去了解下精准化测试。

　　最后是 bug 修复后，对整体功能影响的验证，例如测试副本时，设计上是boss 每隔一段时间增加一层增伤buff，但由于有bug导致增伤buff的层数不叠加。那么在bug修复好之后，我们需要对副本通关的可行性，通关难度等再次进行验证。这一点想说的是，有些bug是对功能的完整性或部分流程有很大影响的，那么当这些bug被修复验证ok后，整个功能的完整性或部分流程是有待进一步验证的。这就需要我们熟悉功能设计，清楚的分析每个问题对整体的影响，理清楚功能中各处逻辑间的关联性，从而在验证bug时对流程中其他关联内容进行及时有效的验证。

　　总之，bug 跟踪能力是功能测试非常重要的能力之一，我们需要不断提升自身能力，不断总结积累，积极分享、交流和学习，不断尝试去使用更多的平台和工具，从而不断提高我们 bug 跟踪效率和质量，以此来保障我们的版本质量。

　　3.风险意识

　　作为软件测试，尤其是游戏测试，需要具备很强的风险意识，可能由于我们忽略了某一处风险，就造成公司巨大的财产损失，这种案例在游戏行业也时有发生，那么我们应该如何提升自己的风险意识呢？以及我们又该如何规避风险呢？下面就我个人的经验和理解讲一下我的想法：

　　(1) 提升风险意识

　　关于提升风险意识，我觉得可以从以下几点出发：

　　① 对游戏玩法和玩家行为进行深入了解。要想发现潜在风险并提出风险，我们必须对玩法进行深入的分析，对玩家的行为习惯进行了解，才能结合玩家可能存在的行为和游戏玩法，发现可能存在的问题。例如我们都知道很多的游戏内是存在工作室的，那么如果我们的游戏玩法中设计的是一个日常参加活动能够获得可交易道具，我们肯定要规避一个工作室刷道具获利并扰乱游戏内经济的风险。我们还可以通过游戏论坛，一些社交软件等方式来了解玩家的行为，从而更好的结合游戏玩法设计，提前发现并提出风险。

　　② 学习和熟悉开发流程，这一点主要是想帮助我们来规避发布风险。例如在开发过程中可能会先开发核心玩法和功能，然后再逐步完善其他内容，那么当测试时间并不是那么充裕的时候，我们可以根据程序的开发流程，采用测试左移策略，在他们提交完核心玩法和功能后，提前介入通过接口测试，先测完核心逻辑，避免时间不足造成的无法按预定日期发布。再例如在三方功能会时，策划想要通过某种方式实现某种表现，但该方式可能比较占用内存，可能容易产生冗余数据，又可能涉及到数据同步刷新频率问题导致有数据同步延迟的风险。如果我们熟悉这些开发逻辑，就可以跟策划讲清楚，同时和程序沟通出一个更好的实现方式，同样满足策划需求的表现。这就需要我们在日常工作中，不断学习和熟悉一些常用功能逻辑的实现方式，一些数据的同步、刷新逻辑等等，从而在遇到类似问题时，及时提出风险并加以改进。

　　③加强自身工作经验的总结及与同事间的分享学习，同样的问题别的项目出过了，那么当自己的测试工作遇到类似情景时，就要考虑是否也存在该风险。另外我们还可以关注同行业信息，一方面从其他游戏发生的严重事故中吸取经验教训，另一方面实时掌握最新的测试理论和方法，从而多方面地提升自己的风险意识。

(2) 规避风险

关于如何规避风险，我觉得可以从以下几点来考虑：

① 从需求上规避。很多时候策划提出的方案是存在一定风险的，这就需要我们对游戏和相关机制比较熟悉，及早提出风险，给出替代方案。例如我们都知道跨服的时候发生数据变化在数据存储上容易出问题，那么在策划设计跨服活动时，对于一些道具的获得和扣除我们可以提出建议回本服结算，从而规避跨服数据存储的风险。

② 消除协作风险。我们可以通过分析平时合作的程序、策划当前的工作内容是否很多，平时是否存在爱拖拉的习惯，以往产生的bug数量、频繁程度，来决策测试哪些人的功能时需要特别注意多沟通多催促开发进度，测试哪些人的功能时需要投入更多精力，例如：某个策划经常在配表的时候喜欢复制粘贴，导致不同行的数据中经常出现字段配置重复的情况，那么测试他所跟进的功能时，可能就需要规划好，腾出时间来写好表检查，或者人肉查看相关配置，以确保配置的准确性。

③ 充分的测试计划和及时的汇报沟通，消除发布风险。测试过程中可能会有很多影响因素造成我们不能按时完成测试按时发布，例如提测版本质量太差、开发过程中的一些需求变更和新增需求、需要跨部门协作测试但对方配合不积极等等，针对此类问题我们需要提前预估风险并做好测试计划，针对一些存在影响测试进度的问题要积极主动的协调沟通，并及时汇报给各部门领导，遇到问题解决问题，减少外在因素对测试进度的影响。

④ Log的预埋。几乎每个功能都会存在一些重要的操作、重要数据的变更，以及一些容易引起玩家误解的行为，建议做好log记录，不仅可以监控一些重要数据是否发生异常变化，还可以在玩家反馈问题是进行查证确认，还可以在发生问题后对玩家的数据进行梳理，方便做部分回档处理，还可以帮助我们分析玩家行为，复现一些不太容易复现的bug。

⑤ 日志监控。有了Log的预埋还远远不够，我们还需要做好日志的监控，在监控日志的基础上，我们有必要针对一些异常情况抛出告警，以便我们能够及时精准地知晓线上的异常情况。一般来讲我们可以从三方面来考虑日志的告警：一是独立日志告警，例如我们在监控副本通关时间的Log 时，可以设定通关时间期望的最小值，当线上出现通关时间小于这个最小值时进行告警，进而在出现告警时再去分析在该情况下是否存在bug；二是关联日志告警，例如我们可以通过关联玩家的充值和消费Log来监控玩家消费情况是否超过充值额度一定的比例范围，进而在出现告警时及时进一步分析该玩家是否存在买金、利用漏洞非法获利等问题；三是数据统计告警，例如针对游戏内某个全服限制型投放，玩家总获取量的统计设定告警，再例如针对游戏内一些特殊投放，玩家获得的综合概率统计设定告警等，进而在出现告警时及时进一步分析投放总量是否有误，投放概率是否错误。

⑥ 做好功能开关。功能开关可以在我们线上发生事故的时候，实时关闭功能，快速响应并停止问题的扩展，及时止损。是可能潜在的事故风险发生时的一手重要保障。

⑦ 灰度发布。根据功能本身的特性，部分功能可以选择灰度发布，灰度发布可以将潜在问题在小范围暴露出来，灰度发布后我们关注聚焦的范围可以缩小在灰度服，当线上出现问题是，影响范围小，处理成本低，是规避风险的一个比较好的策略。

⑧ 做好事故预案。当我们前面的几步都已经做的很好了，也同样难以避免完全不出问题，那么对于一些比较重要的功能，如跨服PVP，全服赛事等等，针对可能存在的风险点提前做好事故预案，万一线上发生了事故，可以从容面对，方便我们对事故做处理。最大程度减少由于事故的发生对活动/比赛造成的影响。

其实除了上面提到的三个重要的硬实力外，游戏测试需要具备的硬实力还有很多，例如兼容性测试，性能测试，协议测试，数据库相关知识、网络基础知识等等，总之，当我们测试不同的功能时，都有可能会用到一些特定的硬实力。

虽然你可能不熟悉兼容性测试，但你需要知道在新项目上线或已上线项目发布资料片前，要提前和专项测试组约好时间做兼容性测试；虽然你可能不太会做性能测试，但你需要知道在测大型多人活动时找相关测开同事沟通好需求，做一下性能测试；虽然你可能并不太会做接口测试，但你需要学会用协议测试平台对一些重要接口进行验证……总之我们需要全方面熟悉测试工作内容的每一项内容，利用好各种平台和工具，同时充分发挥不同同事的长处，协同合作，尽可能的提高测试覆盖度，保障版本质量。

二、关于软实力

除了硬实力之外，作为游戏测试还需要具备一些软实力，以便我们与其他团队成员合作，推动测试工作的顺利进行，在同等硬实力的条件下，不同软实力的人会展现出不同的工作效率和结果，相比于硬实力，可以通过系统的学习在相对短的时间内得以提升，软实力就没那么好改变了，需要我们长期有意识的去坚持，养成良好的习惯才能得以提升，以下软实力是个人认为在功能测试中非常重要的。

1.沟通能力

沟通能力在测试工作中乃至几乎所有工作中，都是非常重要的。我们是一个团队，我们有共处的同事，我们有不同的职能部门需要协同合作，那么沟通能力就好比我们之间的桥梁，如何做到精准高效的沟通，让彼此的需求和意愿完美的相互传递，将很大程度上影响我们工作的效率和结果。对于 QA 岗位日常的沟通工作，我个人认为存在一些特有的问题需要我们注意：

（1）跨职能沟通需要使用简单易懂的语言

在进行沟通时，我们需要使用简单易懂的语言，尽量避免使用一些过于专业的术语或引起歧义的词汇，尤其是和不同职能部门的同事沟通时，有些人在沟通时可能觉得某个术语是QA最基本的知识，但可能你沟通的对象并不是QA，对QA的知识一无所知。简单易懂的语言才能确保所表达的内容或观点能够被理解，同时，我们还需要注意语气和表情的影响，以确保我们的表达方式是尊重和友善的。

（2）规避冲突，减少无效沟通

在沟通时我们要尽可能的保持冷静，在多聆听、换位思考的基础上优先表达出已经明白了对方的观点，然后再去表达自己的观点和意见，当出现意见不一致时，能够保持客观的态度，耐心的表达不同意见的原因和可能造成的后果，而不是发生语言冲突，浪费沟通时间，进而造成一次无效的沟通。

（3）学会控场，提高会议效率

在很多的会议中，经常会遇到这种现象，本来很短时间就能够完成的会议，偏偏最后开了很长时间，同时参会人员并没有觉得因为会议时间的延长而获得更多有用的信息。这种情况下，往往就需要我们学会控场能力，尽可能地减少偏离会议主题的沟通和讨论，减少本来无需在会议中讨论的过于细节的问题。作为QA相信大家更多的是在三方功能会时被这个问题困扰过，那么不妨尝试下这样做：首先自己要清楚会议的主题是什么，要解决什么问题或达成什么沟通共识，哪些是可以留到会后私下去沟通的细节问题；其次在沟通中要时刻记得主题，不要跑偏或被带跑偏话题；最后是在别人偏离主题或过于细节的讨论时，找到合适的切入点，大胆的指出问题并纠正会议方向，主动控场，减少冗余沟通，拒绝偏离会议的主轨道。

最后，在结束对话之前，总结讨论的要点，以确保双方都真正理解了彼此的观点和意见，确认达成的共识，而不是自以为彼此都理解了。这种情况也是很常见的，例如：在三方功能会上，策划表达了功能的需求，可能QA和开发人员理解的并不一样，但又没有总结讲出各自的理解，心里默认以为需求很简单，理解起来也很容易，大家应该理解都一样的，但等功能提测的时候才发现，原来其中存在很大的歧义，最终交付的结果也和策划需求偏离很大。

2.积极主动性

功能测试是一个需要团队协作的岗位，如果缺乏了积极主动性，一个人即使能力再强，也只能是被动的去执行工作，被动的去等待提测，被动的去等待 bug 修复等等，当你什么都很被动的时候，那么你的测试效率一定会降低，测试进度一定不会很顺畅，测试质量也一定不会太理想。那么我们应该如何充分发挥主观能动性，让自己在工作中变得积极主动起来呢？我建议可以从以下几点入手：

首先，明确目标，大到跟进一个大型的功能，小到及时跟进一个细节优化，我们在工作中如果缺乏积极主动性，可以先问问自己，我当前工作的目标是什么，什么时候上线，倒推出我应该什么时候完成用例的编写，什么时候完成测试，什么时候进行回归，通过一点一点的拆解，来明确各阶段的小目标。总之，只有当你清楚自己的目标是什么，才会想办法去实现它。

其次，有了目标我们就要制定好计划去做，一个比较周全的计划肯定是会考虑到其中遇到阻塞的问题时要如何去做，这就可以促使我们在达成目标的过程中，积极主动的去逐个推进并排除掉阻塞问题，最终达成目标。

再次，合适的反馈。一名只会反馈的员工不一定是优秀的员工，但一名优秀的员工一定懂得合适的反馈，这里的反馈包括向上反馈（让领导及时的知道你做了什么，做的怎么样，有没有遇到什么问题，如何解决的），正向反馈（自己所做的事获得认可），每个人都希望自己是被认可的，我们可以通过向上反馈或日常同事间的积极交流，得到一些正向反馈，从而激发自己的积极性，要懂得邀功，主动邀功，合理的邀功。

从另一个角度来讲，我们需要打破边界思维，可能有些时候我们的思想过于局限，只看到眼前的这点事，缺乏对全局的思考。例如，有些人发现bug后就只会提交bug，然后就不管不顾，想着反正自己已经发现bug也提交了，最后如果功能不能及时上线，我就说是开发人员没有及时修复问题导致的。殊不知，当这类问题多次出现在你身上时，那么就是需要你反省一下自己了。为什么别人跟进的功能可以在上线前很稳定，从容不迫的去进行回归，为什么别人跟进的功能可以及时测完按时上线，为什么总是自己跟进的功能在发布的前一天手忙脚乱，功能还很不稳定。这就是在硬实力里面，关于bug跟踪能力里我提到的，跟进和推动bug的修复能力。整个开发流程与测试流程都是环环相扣的，当某一个环节的进度你不去跟进，不去推动时，那么造成的直接后果就是整体流程滞后。

打破边界思维还有另一种理解。职场升职法则之一，只有先做更高职级的事，才能晋升成为更高的职级，只有你打开格局打破职级边界，做了更高职级的事，表现出了具备更高职级的能力，才可以让公司放心的给你晋升。总之，工作中保持较高的积极主动性，可以帮你更好地完成任务，提高工作效率，增强团队合作能力，提高自我价值感。我们应会主动寻找机会来提高自己的技能和知识，并愿意承担更多的责任，使整个团队更加成功。

3.创新能力

《软件测试的艺术》一书中有个观点我非常认同：“软件测试是一项极富创造性、极具智力挑战性的工作。”，我认为游戏这类特殊的软件，其复杂度高于常规软件的几十倍几百倍，测试这样一款软件所需要的创造性也同样远远超过开发该软件所需的创造性。如果将游戏测试比作画画，那么硬实力就是我们画画所需要的画功，创新能力就是我们天马行空的思维在画功的基础上，创作出来的一幅绝美画作。那么创新能力究竟对于功能测试有哪些帮助呢，我认为比较重要的有以下几个方面：

（1）推动测试流程的改进

和所有行业一样，测试行业也是一个不断发展和变化的领域，需要我们不断探索新的测试方法和工具，如果作为测试，缺乏创新能力，就会陷入固定的测试模式，无法适应新的测试需求和挑战。而拥有创新能力的人可以不断尝试新的测试方法和工具，推动测试流程的改进和优化，提高测试效率和质量。现在越来越多的公司开始采用敏捷测试方法，对测试工作提出了更高的要求，越来越多的公司开始要求“降本增效”，越来越多的竞品在比拼“产品质量”，如果我们缺乏创新能力，就无法适应敏捷测试的工作流程和要求，而如果我们拥有创新能力，可以通过探索新的敏捷测试方法和工具，提高测试效率和质量，从而推动测试流程的改进和优化。

（2）发现潜在的问题

功能测试的目的之一就是发现潜在问题，确保版本的质量和稳定性，如果我们缺乏创新能力，就可能无法发现一些隐蔽的问题，从而导致版本发布后出现严重的事故，而拥有创新能力的测试工程师们，往往可以通过运用创新思维，设计新的测试方案，发现一些难以察觉的问题。例如有些同事在测试一些复杂功能时，为了验证各处接口传输参数的正确性，为了定位bug的原因，使用协议测试平台来监控一些重要操作时的接口数据，我认为这就是一种创新，可能这位同事他本身的技术能力还达不到做接口测试的水平，但他可以合理利用工具，探索新的有效的方式方法来验证潜在问题，这就是创新。

（3）提高测试效率

创新能力可以帮助我们提高测试效率。随着游戏产品规模的增加，手机游戏已不再是N年前那种简单的玩法了，测试的方法也在不断更新，同样测试工作的复杂度也在不断增加。如果游戏测试缺乏创新能力，就可能无法有效应对测试工作的复杂性，从而导致测试效率低下，测试质量堪忧。这就需要我们具备创新能力，通过不断探索新的测试方法和工具，提高测试效率，减少测试成本，从而更好地保障版本质量，甚至加速版本的发布速率。

例如，在资料片大版本更新前，我们可以运用自动化测试工具和脚本，对版本内大部分较为稳定的功能进行回归测试，提高测试效率。

再例如我们雷火近几年推出的协议测试平台，代码染色平台，我认为这些都属于创新，虽然这些测试理论本身不是我们探索发明的，但将其工具化、平台化，也大大提高了协议测试的覆盖度，降低了代码染色的门槛。我们需要紧跟时代步伐，力争熟悉并掌握最前沿的技术，探索利用AI技术在日常工作中的应用来提高测试效率，提升版本质量。就如网易的价值观一样，从0到1是创新，从1到1.1也是。

总之在日常工作中，我们要善于、敢于在现有的基础上，探索新的思路、新的方法、新的技术，创新出有利于提高测试效率或提高测试覆盖度等任何有助于提高版本最终质量的方法或工具。

4.学习能力

学习是一个人学习和掌握新知识、新技能方面的途径方法，在这个各方面技术都飞速发展的现代社会，学习能力毋庸置疑是一项非常重要的能力。为什么我觉得学习能力是游戏测试岗位很重要的一个软实力呢，可能针对一些传统行业，技术的革新速度，方式方法的更新速度并没有那么快，但对于游戏乃至整个软件行业却是另一番景象：

首先，游戏测试是一个非常复杂和多样化的领域，我们需要不断学习和掌握新的测试技术、工具和方法，才能得以适应不断变化的产品需求，测试需求。例如，应对越来越多的公司实行的敏捷开发，测试左移从某个时间开始就成为了一项重要的测试方案。只有不断学习新的方式方法，才能更好地协同开发团队。此外，随着云计算、大数据、人工智能等科技的迅速发展，作为游戏测试，我们也需要不断学习新的测试技术和方法，例如云端测试、性能测试、安全测试等，以适应不断变化的测试需求。当然一个人的精力是有限的，但是即使你没有精通这些测试方法，但至少需要不断学习来了解、熟悉进而深入的理解其必要性。

其次，学习能力也是游戏测试提高工作效率和质量的重要因素。我们需要不断学习和掌握新的测试工具和方法，以提高测试效率和质量。例如“精准化测试”相关内容，在读到相关分享之前我确实没有接触到过这个概念，虽然也曾经因为未能做到精准化测试而导致的线上bug，也会因此头疼如何才能避免此类问题，但在知道这个概念之前，我是不知道如何才能避免此类问题的，但当读完相关分享之后，我们就能够有思路有方向，打破这个魔咒，通过精准化测试来避免一处改动而带来的测试内容遗漏造成的线上问题这类的bug。

此外，好的学习能力还可以帮助我们更好地应对工作中的挑战和问题，在日常工作中我们或多或少都会遇到一些问题，如测试环境的搭建、测试用例的设计、bug 原因分析等等，只有具备良好的学习能力，才能及时学习和掌握解决问题的方法和技巧，从而提高自身解决问题的能力和效率。

了解了学习能力对于我们测试来说的重要性和必要性之后，我们应该如何具备良好的学习能力呢，以下是我的个人建议：

（1）保持好奇心和探索精神

作为测试人员，我们应该时刻保持对新技术、新方法的好奇心，积极探索学习，不断掌握新的测试知识和技能。

（2）投入时间和精力

我们每个人都应该投入一定的时间和精力去学习，充分利用学习资源与环境，如经验分享平台、沙龙等，不要只把学习挂在嘴上，要有所投入才能有所收获。

（3）制定学习计划

如果不知道自己的学习方向，个人建议可以根据每一年的绩效中，主管指出的自己的不足之处，制定一个长期目标，拆分成几个短期目标，在业余时间学习或者与同事之间的交流等，通过学习来不断弥补自己的不足之处，消灭短板。

（4）实践和应用

我们需要将学习到的知识与技能应用到实际工作中来，让学习给我们带来实际工作效率的提升，从中收获成就感，从而反向推动我们学习的动力。这一点我深有体会，在上一家公司的时候，大家绝大部分人的日常测试工作就是点点点，那个时候自己是有学习代码的兴趣的，但由于环境氛围的原因，自己也不知道如何在实际工作中来应用，所以虽然偶尔的会去学习，但代码能力基本毫无提升。来到网易之后，有提供好的表检查框架让我可以轻松入门编写表检查脚本，看到很多优秀的同事都在通过看代码来分析bug原因，做代码review，这些都敦促我不断的尝试阅读代码、分析代码，从而让自己的代码能力有一定的提升。这就是学习和实践应用相结合的重要性。

三、结语

其实，不论是黑盒测试还是白盒测试，亦或是自动化测试，我们每位同事都是一名功能测试，有些人在工作生涯中变得越来越优秀，学会了通过代码review来更深入直观的检查代码逻辑的漏洞，学会了通过自动化来替代大量重复的工作内容来节省时间，学会了通过表检查来代替人肉检查配置上的错误，学会用借代码染色来检验测试的覆盖度并发现遗漏的测试点等等，通过学习多种多样的测试手段，来辅助功能测试，提升测试效率，提高测试覆盖度，最终实现我们的共同目标，提升版本的最终质量。

记得《探索式软件测试》一书中写到的“人类并不完美，难免会犯错误，那么由人类创造或发明的软件，自然也继承了这个特性”，软件如此，所以衍生出了软件测试这个岗位，那么软件测试亦是如此，既然是由人来完成的，那么我们谁也不能保证自己测试过的内容就是完美的，也就是我们谁也不能保证我们的测试内容没有遗漏的，但只要我们努力探索，不断提高自身的软实力和硬实力，我相信，我们每一个人都可以成为一名优秀的功能测试。

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：