一名测开的任务升级攻略
随着如今游戏更新周期内容越来越多和玩家对游戏的质量要求越来越高，测试开发需要完成的测试任务越来越多样，也要用更多方法来增加测试经验，提高测试的效率和全面 性。本文将会围绕着“通过任务获取经验”这一点展开，从任务需求、任务准备和任务执行出发，来说明测开如何效率地完成手上的任务以及通过任务获得经验成长。
在游戏中，领取任务的第一时间肯定是要查看任务描述，看看这个任务究竟需要我们做什么。 对应到实际的工作中，我们也需要在接手的时候第一时间判断任务的详细信息： 任务类型和目的 ，是做一个性能测试？还是写一个自动化脚本？还是去做一次概率测试？还是要去做一个辅助大家测试的工具？等等等等，不管是什么样子的任务，明确需求和目的总是很关键的。
在接触到任务的时候除了要获取基本的任务信息，往往还会查看任务的具体说明。这一点和我们的任务还挺类似，从需求单的描述上只能获取大致信息，具体的 细节需求往往需要沟通获得 。比如在做压测的时候常常会遇到这种情况，任务单子不能把所有的步骤都包含进来（一是很多地方在初期不会考虑这么细，二是有些内容可能也需要大家一起商量来决定如何做），这时候就是需要我们去沟通来确认更多的需求和步骤。 用 可视化 的手段来沟通是一个高效的方法。心理学家帕维奥提出长时记忆中的 双重编码理论 （Dual Coding Theory），主要指出人类大脑处理信息的方式有两种：一种是基于 语言 的符号系统，另一种是基于 图像 的非语言系统；同时以视觉形式和语言形式呈现信息能够增强记忆和识别。以性能测试为例子，在进行测试结果的反馈时，仅仅用文字说明性能变化是比较难以量化的，但是一张性能数据的图片再加上部分箭头、圆圈、配合文字说明等提示，就能很好向对方说明测试流程和测试结果，也方便对方进行判断。 适当的提问 亦是沟通的有效手段。提问可以快速了解对方的需求，不同的提问方式可以应对不同的场景，通过对方的回答可以快速了解他们的需求和目标。 开放式提问 ，当目标不明确时进行开放式的提问，即不设限制让对方回答。开放式的提问可以获取大量信息，当然也有可能偏离主题，在处理信息的时候需要进行辨别或者引导。引导式提问 ，如果对方提供的信息不全面，难以确定要如何展开这个任务时，可以在配合一些引导性的提问，多问一些为什么找到更深层次的需求。封闭提问 ，如果目标明确只是需要确认细节，则可以选择封闭式的提问方法，封闭问题的答案往往都是有预设的，类似选择题，这种提问方法获取到的信息快速且明确。沟通结束以后可以把自己获得的信息总结一下发给对方，对齐目标，避免在沟通过程中双方在语言的理解上产生了歧义而导致后续的任务方向跑偏了。
按照任务主次划分，任务可以分成主线任务和支线任务。主线任务一般和游戏的整个世界观有联系，讲述了整个游戏的剧情走向；支线任务可能关注某个剧情支线或者某个系统；在某些条件下还可能突然接到奇遇任务。
对于我们来说，因为所处的角色和位置不同，每个人的主线任务都是不一样的，找到并认清自己的主线任务是很关键的。主线任务一般都是有价值的、可以进行深入研究的任务，根据复杂度和难度不同可能会持续几个月到一两年不等，认清自己的主线任务也代表着明确了自己在近期的一个工作方向和发展目标。 和游戏不同，我们的主线任务并不是一成不变的，往往会随着项目的需求、个人的规划和团队的规划而发生变化。虽然主线任务难度、方向各异，但它无疑是我们在最近一段时间工作的重心 。如果发现了自己更有兴趣或者更擅长的任务，可以和主管或者导师商量着在整个产品的测试质量不被影响的前提下，更换主线任务。但是频繁的更换主线任务会造成所有方向都只是略懂皮毛难以深入，是不可取的。 无论主线任务是什么，它都很容易帮助大家在工作中树立起自己的人设、提高自己的 不可或缺性和竞争力 。 支线任务相对主线任务而言，持续时间较短、整体难度也不会特别高，也会和整个测试任务挂钩。比如负责接入某个平台、负责一个月的性能测试任务、给现有的某个平台或者工具增加一个新的功能、完善一下之前的自动化脚本等等，它往往是依据我们的主线任务经历而产生的，就像是主线任务的分支。 支线任务能够帮助我们快速积累经验 ，提高某一方面的测试能力 。 游戏中的奇遇任务可能在路上走着走着突然就出现在了我们的任务栏里，而现实中的奇遇任务可能是突然弹出的抖动窗口、右下角突然出现了被@的消息、或者是策划程序直接冲向了你的工位。虽然不知道是惊喜任务还是惊吓任务，但肯定都是突发的、紧急的 事件。 主线任务重要、奇遇任务紧急、分支任务做起来又快又有收获，当我们的任务面板里面有十几个任务，并且每个任务都有非做不可的理由而时，到底该如何取舍？ 人类的大脑接近于“伪多线程” ，在做任务的时候同一时间只能专注于一件事情上。因此在多任务并行的时候，这么多任务到底先做哪一个？笔者早期时经常陷入一种困境：觉得自己做了很多任务，大部分的精力都花在了分支任务和奇遇任务上，任务做了一箩筐但是在最后在绩效总结的时却发现主线任务基本没有推进、或者是一直在任务表层徘徊深入不下去，现在想想大概就是“忙碌但是划水”的状态。这里有一个问题就是把任务的主次顺序安排错了，仅仅是把一些简单的任务排在了前面，本意是想留出大片的时间做主线，结果这些任务是做不完的，那么就更没有时间去做主线了。 任务的主次排序可以采用类似四象限矩阵 的方法，将任务分为线上紧急、线上不紧急、非线上紧急、非线上不紧急四个类别来对任务进行大致分类，厘清处理任务的先后顺序。主线任务一般会在线上紧急和非线上紧急这两个象限中，根据我们的排序无论如何都不会把主线任务放在最后，这样就不会出现主线任务推进不下去的问题啦。
线上紧急的四象限矩 阵
除了对任务的进行顺序排期之外，每天的工作时间 也可以进行节奏化的调整。《睡眠革命》一书中的昼夜节律图显示，人体的灵敏度、反应速度等都会随着时间而变化的，因此一天中不同时间段的工作效率也是不同的 。寻找一天的最优时间，在这段时间内，人们的精力更加集中，更擅长过滤各种干扰因素。而困难的任务往往会需要更集中的注意力、更长的时间以及消耗更多的精力，把困难、重要的任务放在最优时间段内去解决可以避免精力错位。每个人的最优时间不尽相同，在正确的时间去做正确的事情 ，就可以让工作效率大大up。 在明确任务之后、执行任务之前，我们通常需要查找相关攻略以帮助我们更好地通关任务。 类比到工作中，我们也需要掌握一些技术和方法来应对不同的挑战和任务。 就像攻略中的技巧可以帮助我们战胜困难，工作中的技术和方法也可以帮助我们提高工作效率和解决问题。 如果需要专业的技术知识，除了国内的几个技术博客外，也可以去GitHub 上进行搜索。GitHub 是一个面向开源及私有软件项目的托管平台，简单说，GitHub就是一个源代码版本管理工具，上面有很多开源的项目和工具、甚至一些大厂的项目也在上面开源，当然也有很多学习资源在上面。 awesome系列 就是收集的学习、工具、书籍类相关的项目。项目包含平台类、编程语言、前端开发、后端开发、大数据、计算机理论、游戏开发、网络、 测试 等相关集合。 有些时候我们的任务是创新向的找不到可以借鉴的文章和项目，就像是在首通副本时也没有现成的攻略可以参考，那么一切就需要自己去探索了。虽然探索的方向各不一样，但是有些分析问题和解决问题 的方法手段是可以使用的。分析问题的常用方法有： 5wh分析法 ，即what（对象，也就是问题是什么，就是上文提到的任务需求是什么）、where（地点是什么）、when（时间）、why（原因）、who（人员，解决问题的主题）、how（方法）等六个方面提出问题去思考。 鱼骨图分析法 ，这是一种发现问题“根本原因（透过现象看本质）”的方法。鱼头处一般就是我们遇到的问题，产生问题的大要因是骨干，骨干上可以挖掘小要因，如此一层层挖掘分析下去，可以直接找到问题的解决办法或者梳理好行动的步骤。
服务器压测门槛高问题鱼骨图示例
逻辑树 ，就像是平时写的思维导图一样。初始节点就是我们遇到的问题，然后把子问题分层罗列，从最高层开始逐步向下扩展。逻辑树的作用是可以帮助我们理清思路，不进行重复和无关的思考。 MECE ，意思是相互独立、完全穷尽。这个方法主张把一个大的问题进行不重叠（独立性）、不遗漏（完整性）的划分（比如把人分成男人和女人是符合这一方法的，而分成男人女人和婴儿就是有重复的）。划分的结果就是把问题拆成小问题，让我们更容易理解问题、解决问题。 除了掌握上述方法以外，分析问题过程中的一个关键是不要偏见，不要过度自信，不要闭门造车，一定要基于获取到的真实信息出发，用上面的方法来分析问题。否则可能会陷入：先提出假设，并通过这些手段来证明假设的歧路上了。 问题分析完成后，再选择一个合理的方案变成攻略 。在分析问题的途中，往往会产生一些备选方案。针对这些备选方案也不要掺入主观的判断，可以尝试从时间、成本、数量、质量 四个维度来决策；并从方案的执行时期、收益和投入 这几个方向再次对方案进行评估。经过筛选、评估后的方法，保留下来和大家一起讨论或者通过提前假设的方法来做最后的决定。走到这一步的时候，我们基本上就已经有了明确的解题思路了， 问题也就基本明了，再配合上有规划的解题步骤，一个首通副本的思路就此产生。攻略的产生并不代表问题迎刃而解，它最终还需要在实际的任务中实践、打磨、验证才可以变成一篇完整的攻略。 熟练使用工具可以提高效率、简化操作步骤和减少出错的概率，更可以在一些专业的领域发挥巨大的作用。这里列举了一些日常工作的通用工具 ： Everything ：Windows系统的搜索引擎，可以快速索引到电脑上的文件。找东西非常方便，只要记住关键词就可以和通配符一起使用。Mac上也有类似的工具，如Find Any File for Mac或者ProFind。二者都可以实时进行文件的精准搜索、查找任何文件包括隐藏文件等等。 Xmind类思维导图工具 ：这类工具支持各种各样的思维导图，包括中心思想导图、组织结构图、树状图、流程图、鱼骨图等等，方便快速建立层次关系、构建思维导图。可以帮助我们梳理思维、和他人沟通。drawio ：是一个开源绘图工具，支持云端在线编辑以及各个系统的安装版本。用于创建各种类型的图表，图形和流程图。软件免费且模版多、图形多，允许多个用户同时编辑，很适合在做工具的进行灵感整理、布局设计、工作计划等等。 压缩工具Bandizip ：有免费和收费版本，免费版本的功能就非常强大了。它的特点在于压缩、解压速度快；可以直接查看压缩包的文件内；支持压缩格式多等。 除了这些工具外，还有一些专业性的工具。比如可以用postman，apifox 进行接口测试；AssetStudio 是一款可以反解压unity的assetbundle包的工具，在查找资源表现异常的时候可以提供帮助；quickbms 可以提取bank文件内的音频，在音频分析检查的时候可能用得上。 通过选择合适的工具、学习和熟练掌握工具的使用技巧，可以提高工作效率，简化操作步骤，快速达到任务的要求和目标。 如果有需求但是并没有现成工具，或者更多的情况是现有的工具不能很好的满足我们定制化的测试需求，那么这时候就需要打造自己的工具来实现任务目标了。 工具可大可小、可精致可简陋，相比于拥有一套完整的装备来说，自己手动打造一套定制装备的过程更加珍贵；相比熟练使用各种工具，拥有自己打造工具的能力是更重要的。在真正动手打造工具前，可以判断一下工具的重要性、投入精力和产出回报 等等，或者是在平时组会上、工作群里展示下工具的demo，让大家一起判断一下工具是否有实现的必要性。 待阅读完攻略、打造好装备，就可以开始打Boss了（开始干活）。干活才是整个任务的核心部分，前面的分析任务、阅读攻略都是前期的准备工作，虽然这些步骤可以提高我们完成任务的效率或者说提高任务的完成度，但是这一切还都是在纸上谈兵，只有真正的去任务里走一走，才能够清楚自己的实力，真正地磨砺自己。 干活的秘诀就是先动起来，再考虑细节和优化 ，无论是写代码还是写文章，先让自己看到一定的成果，后面就可以慢慢坚持下去，不然很容易陷入前期准备时间过长、后期真正行动的时间太短的困扰中。时间管理领域有个“帕金森法则 ”也是说的类似的事情：工作会不断膨胀，直到填满截止日期前的全部时间。到了该做任务的阶段，不如先迈开腿走下去，一边走一边再思考怎么把任务做得完美。 大家常说万事开头难，如果不知道该如何来开这个头，不如尝试一下耳熟能详的番茄工作法 ，一般将25分钟作为一个单位，中间不中断，专注某个目标地工作，结束以后奖励自己几分钟的休息时间，然后重复这个循环。单个循环的时间并不长，执行起来比较容易，很容易就成为了迈开腿的第一步，等到真正开了头，后面跟进的工作就没有这么难了。 任务间隙过程中，做好记录，具体可以在每次休息间隙记录当前进度和思路，将笔记、任务和时间追踪结合起来建立工作流 ，这种方法有助于促进对自己所思所想进行追踪和反思。也可以避免因为有些更紧急的任务打断当前工作流程以后需要再次经历一次开头难的过程，能够快速恢复当前的工作状态。 之后依旧是先完成功能再进行优化，先去抓核心、抓重点，先去完成，之后再去考虑完美 。细节和优化不是多几行代码少几行代码，往往需要整体的协调和妥协，如果开展的太早会浪费大量的精力在细节表现或者优化上，等到做具体工作的时候就发现初期的优化和实际的工作开展发生了冲突无法使用。特别如今很多面向接口的编程只要接口不变动，总有优化的机会。做任务的时候推荐先完成deadline的压力，精益求精可以是无止境的。比如笔者之前在写一个数据展示的前端页面的时候完全没有接触过vue，基本上是在组里框架的基础上去网上各种搜数据展示、图标展示的形式先把整个页面拼接完了。然后在写页面的同时去学习vue的知识，等知识学习完以后反过来再对页面做了一次优化。 对于任务来说，一个任务并不是一块密不透风的铁板，而是由许许多多的小任务组成的。任务解构的方法可以参考项目管理中的WBS 方法，大致来说就是把一个大任务分成一项项工作，然后再把一项项的工作分配到每个人的日常活动中，直到分解不下去。最后以树状形式进行表达，从树根到树叶，将整个错综复杂的结构梳理成一级级一节节的工作节点。
性能监控页面的任务解构
从杭州出发，一口气骑行到西藏是不可能的，但是如果把这段路程进行拆分每天骑行几十公里并且安排好每天落脚休息的地方，那么从杭州骑行到西藏也不是一个不可能的任务。把一整个大任务分成一段段的小任务，中间再配以任务的衔接，比直接闷头出发更容易到达目的地。 任务分解以后，我们提前可以得知哪些任务难度高、哪些任务难度低可以合并处理。这样子在较难的任务遇到问题需要延期时，也可以在其他任务上加快进度补回来，或者是可预期时间的延期。这样一来也给整个任务的进度管理提供了不少帮助。顺便提一句这样在做任务的报告的时候，也能很清晰的告诉大家目前任务的进度大概进行到了什么程度、遇到了什么困难大概预期什么时候可以完成等等。 像上文提到的不同任务之间因为紧急程度、重要程度的不同可以进行顺序安排和具体时间的规划一样。每个小任务之间的难易程度、先后顺序也是不一样，也可以根据它们的特性来对任务进行安排和工作计划的指定。经过规划的任务在合理程度和进行效率上都会有较大的提升。 除了自己的代码、工具可以优化以外，整个做任务的流程也是可以优化的。 记录一下整个任务中各个部分的耗时 （比如环境准备、查找资料、写代码、调整某个bug等等各自的耗时是多少），像做性能优化的时候，程序往往拿最耗时的函数开刀一样，在做任务的时候记录下耗时最高的部分是什么，再做一些原因分析看看是必要的还是非必要的，是否有优化的空间；再者看一下是否有反复重复操作的部分和一些可以不必要的部分；以及看看任务流程中断都是什么原因。这些都是可以优化的地方。 往往这样从上到下分析下来，非必要的步骤可以抛弃，可优化的步骤尝试做成脚本或者工具来辅助提升效率。 做完一个任务之后，肯定是有经验收获的，从专业技术方面讲，一是掌握了相关方向的核心知识和技能，另外代码能力也得到了锻炼和提升。越过专业技术来说，一项复杂的任务还可以锻炼很多非技术性的能力，比如沟通能力、对自身能力的信心增加、提高自身影响力、对时间管理能力等。英国管理学大师查尔斯·汉迪查尔斯·汉迪说过：“成年人最重要的学习资源是自身的经验 ”。我们可以做的就是充分利用自己的经验，从经验中再学习成长。 任务、经验、成长是一个循环：完成一个任务--反思复盘获取经验--归纳概括变成技能--在任务中使用技能--继续反思复盘不断优化技能。整个循环中比较关键的步骤如下几步： 不管是成功和失败的任务都可以进行复盘 ，做完任务以后可以从这个任务出发，对任务或者任务中的问题进行观察，观察它的要素，并看看各个要素之间的相互作用和因果关系 （可以考虑用上面的鱼骨图、逻辑图等方法），看明白是如何一步步造成了这个问题。这样子在下次遇到类似事情的时候，大概率就可以避免再次掉坑里了。 大多任务都有共通性，一个任务的经验经过归纳概念化后可以应用到同一类事情上面来，达到举一反三、层次拔高、横向扩展的效果。把经验概念化 以后，经验就变成了一项技能。在后续工作中，即使是没有做过的任务，也可以用到之前工作中提炼出来的技能。 在新的任务，多使用之前的技能、然后测试下技能的使用效果如何。经过不断使用和测试，我们就可以判定这个技能的适用范围、效果、以及技能的消耗时间等等。久而久之，这项技能也会慢慢升级，技能的形式会提升、消耗时间会变短、技能的释放时机会更加合适，技能获得的效果也更加显著。 假如我们在任务过程中发现了重复犯错、陷入重复劳动、发现成长几乎停滞的情况，常见的原因是上述的循环断裂了，可能其中几步关键步骤被跳过了。比如跳过了观察和反思，直接进行归纳总结到的技能就会有失偏颇；或者跳过了归纳概括步骤，经验无法转化成技能在后续任务中使用，也就无法得到升级技能的机会了。 在反复参加任务不断获取经验升级技能的循环中，做好每一次的 工作总结 有着重要的意义。工作总结是对当前任务的全面回顾、检查、分析、从理论认知的高度概括经验教训，以明确努力方向并对今后的工作予以帮助。常言道好记性不如烂笔头，结束后把整个流程和结果做一个总结，总结的内容最好可以变成文字或者图形保存下来。任务的总结就像是一个副本的通关攻略一样，也让我们从参考他人攻略转变成了自己产出攻略的人。 可能单子刚刚完成时觉得这个下了功夫的工作内容已经深深地刻在了自己的脑海里不可能轻易抹除了。事实是如果有半年不再接触相关领域的需求，快速索引这部分记忆和知识的能力就丢失了。总结文档可以帮助我们在需要相关经验的时候快速回忆起来整个任务中的关键点。 通过攻略把自己所做过的工作内容做一个清晰的梳理，让他人也可以看清楚自己在这项任务中付出的努力和产生的价值。在他人需要相关领域信息时，攻略也可以提供一些专业的指导。 在攻略中有好的成绩，也会有失误的经验教训，及时总结有助于以后的工作中扬长避短、克服缺点避免在以后重蹈覆辙，也可以帮助他人躲避掉入同一个陷阱中的风险。同时攻略中数据的记录也可以为后续的工作做准备甚至可以给他人的工作提供帮助。像是在压测或者性能优化这一块经常会需要之前版本的数据作为对比，此时保存的数据可以提供快速的对比结果。 写任务攻略的时候，可以参考SCQA工具梳理出来四大模块：Situation（情景）、Complication（冲突）、Question（问题）和Answer（答案） 。总结时要客观，避免太谦虚和太夸大自己的工作，同时不要只记录自己解决了什么问题而不记录目前还有什么问题，以及内容要有细节，不要只是泛泛而谈解决了什么问题，做出来了什么东西，可能大家在看攻略的时候更想看的是遇到了什么问题，究竟是如何解决的。 测开具体做些什么这个问题是面试的时候被面试的同学提问最多的问题了，没有之一。在我的理解里，我们作为测试开发，首先是一个测试其次再是一个开发。作为测试，说明了我们的工作主基调依然是对游戏产品的内容、质量、安全进行保障；而作为一个开发，我们可以使用开发的手段来服务于测试。 上面有提到过，在任务结束后进行总结可以明确自己的努力方向。 通过任务，我们渐渐可以明白测开究竟是要做什么， 以及自己的发展方向在哪里。 整体来说，测开的发展依然是围绕着提供更高效率的测试过程、更严谨的测试结果、更丰富的测试手段展开。 无论大家的前进方向如何，保障产品的质量永远是我们的出发点和目标。 最后的最后想说升级虽然有方法，但是没有太多的捷径可以走，唯有老老实实的打怪升级、获取经验才是升级的长久方法。希望大家的升级之路都顺顺利利！
从小白开始和日志打交道的那些事
功能跟进之我见
都看到这里了，点个赞再走吧~
