📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）
📝 职场经验干货：
01 引言
接下来我会把游戏测试岗位分为初入、进阶、管理三个阶段，分别整理这些阶段应该重点关注哪些个人素质，以及我的一些成长建议。当然，正如开头这句话所表达的，工作的本质是价值交换，而职业生涯的本质是自我投资。我们每个人都是职业生涯的负责人和受益者，大家看这篇分享的时候，希望也能保持独立思考，构建属于自己的个人价值体系，而不是人言亦言，在他人描绘的框架下被动成长。
The only way to do great work is to love what you do.
成就一番伟业的唯一途径，就是热爱自己的事业。
—— Steve Jobs 史蒂夫·乔布斯
02 初入游戏测试，我们需要什么样的人
既然聊一个岗位的素质和成长，我们自然要从头说起。大家是否还记得，自己初入这个岗位，第一场面试时都被问了哪些问题？或者对于老司机读者，现在面试新人时，你固定会问的都是哪些问题？以我的个人习惯，除开面试者个人履历部分，或者说面试一位“白纸应届生”时，以下几个问题是必定会聊的：游戏经历、用例题、曾经遇到的问题、工作情景题。
我曾经写过一篇关于游戏测试面试的分享，主要是关于行为面试逻辑、常用面试技巧、面试官培养的方式，写一半了才发觉，如果使得部门统一成一种面试模式未必是件好事，大家考察的点都会相似，多轮面试就失去了多方面评估的意义。所以这里多提一句，希望大家还是能形成自己的“面试题库”，我们这次也不聊面试底层逻辑和技巧，单说下我面这些问题背后，想要了解候选人具备哪些素质。
1.游戏经历（热爱）
这个与其说是面试题，不如说是我习惯会先和候选人寒暄闲聊一阵，聊一聊他喜欢玩哪些游戏、最近在玩什么游戏。一方面是给面试热热身，候选人可能会紧张，聊点他感兴趣的缓解一下，我作为面试官上来就问专业性问题也比较干，了解候选人兴趣所在，引入后面几个问题也会丝滑一些。
另一方面，问题背后是在考察候选人是否热爱游戏，即是老板说的，他聊这些话题时是否眼里有光。公司的价值观将“热爱”列在第一，我也认为这是游戏测试优先需要的素质。作为产品质量管理的“执行者”和“守门员”，我们职责所在要接触很多产品差的一面，承受许多额外的压力，更要求我们有足够的责任心去做左移右移，这些都需要对游戏的热爱作为底层动力来源。更何况，兴趣是最好的老师，刚出校园的游戏测试，前两年要学习的东西可不少。
2.用例题（结构化思维）
找个刚才聊过两人都熟悉的游戏功能模块，让候选人设计用例。相信大家都理解面试问这个的目的，考察各种用例设计方法的运用、需求考虑的全面性、候选人细心程度、特殊操作引发bug敏感度等等，这些都是面试“白纸”时最基础的素质要求，我所期望优秀的新人，应该能在设计用例时体现出比较好的“结构化思维”。什么是结构化思维呢，就以本篇分享为例，我是先写大纲再去逐段扩充的，而分享的主要内容也是围绕在“三个工作阶段+每个阶段的素质&成长建议”这样的树状结构去聚合在一起。写用例也是同理，先从整个模块的设计大局考虑，细分模块，再去补充每个模块的细分功能，最终再去考虑一些操作细节、异常边界，这样事分巨细，才能做到有条理不容易遗漏，且后期方便维护补充。
写用例这个技能，绝对不是一朝一夕就能练成的，需要通过审视自己以前写的用例、Review他人写的用例，在工作中不断地练习积累。这里抛出一个问题：大家写的旧系统用例多久没去翻炒过了？针对用例的“结构化”而言，并不是说是总分的树状结构就可以了，我们还要注意调整叶子节点之间的关联性和流程性。我之前给组里定了一个“好用例”的通用标准，就是把用例抛给新人或者其他职能，如果他能顺利执行回归且没有太大的效率损失，那就是好用例。特别是执行效率，比如不应该重复准备前置测试环境，以执行用例集中多条距离较远的用例。这在用例设计初期很少考虑到，除了需要完整清晰的列出用例三要素，还需要在回归执行的过程中多次调整用例结构，多做过几次交叉测试才能意识到。
3.曾经遇到的问题（分析排错）
我会详细询问之前遇到过的游戏bug，或者工作学习中遇到的问题以及后续解决过程。除了考察候选人的表达能力之外，更重要的是挖掘他对问题的分析、联想、排错能力。没错，问题分析、经典bug、事故平台，这一连串名词肯定也闪现在了你的脑海中，不要觉得烦躁，在实际工作中，快速诊断定位问题，应该是QA“刷个人威望”，获得“靠谱成就”最直接的途径了。
举一个我们产品的例子，我们在24年参加了北美夏日游戏节（SGF）的线下展会，而在展会当天，凌晨一点多我接到了制作人的电话，说展会现场两台试玩机器，其中一台跑起来非常卡，急需解决。当时群里有三个QA醒着，这里大概复盘下我们的排查过程：
第一步是收集更多问题的信息：我们了解到现场是两台笔记本，外显到两台电视上做游戏演示，分别要到了笔记本的配置（i9+4090很高配的笔记本）、系统显示设置中输出截图、电视的分辨率情况（4K120Hz）；并且沟通要到一些定量的数据：因为主观描述有一定误导性，我们远程协助开启了游戏的帧率显示，并进局内分别要了两台设备的帧数，发现相差不多FPS都在150左右，但出问题的设备肉眼观感帧率是要低很多。
第二步临时补救和尝试复现：因为临近展会开场，我们先和营销确认现场有没有备用设备、更换电脑/电视/线材的可行性。因为游戏中显示帧数相近，且笔记本的配置都很高，初步排除掉游戏软体出问题，而是输出硬件的差异导致；现场两台设备一好一坏，天然形成了对照组，我们就要求两台笔记本互换输出电视试试看。我也起床拿笔记本，去客厅插电视模拟那边的使用环境，尝试复现问题；万幸是现场一顿操作后，反馈问题解决，两边显示效果一致了。
第三步是猜测与验证，在两边跨国沟通的这段时间里，QA在群里提出了以下几种可能导致问题的猜测：
①、其中一台笔记本输出设置不对（例如是用集显输出电视而不是独显模式，在后续要到游戏实际渲染帧数后得以排除）；
②、线材问题，因为是4K120Hz输出，对HDMI线材会有一定要求，可以考虑互换线材来确认；
③、电视画面设置问题，比如有的电视设置成了足球模式电影模式、画质增强等，会对输出画面进行二次处理；
④、电视画面输入端口确认，HDMI2.0和2.1，正好区分了4K60Hz和4K120Hz，会不会是有台电视插口插错了。
因为后面问题解决，展会试玩随即开始，我们无从得知到底是哪个原因导致的问题，群里讨论完快三点了，QA们穷尽可能性后也能睡个好觉。不过现在复盘，就整个问题的排查过程而言，其实是挺标准化的：从定性定量收集更多信息，到优先给出补救方案，同时尝试复现，再到原因的猜测与验证。其中原因猜测这块个人经验居多，但就整个排查流程而言，应该是每一个游戏测试都需要具备的专业素养。
4.工作情景题（原则底线）
这个问题就比较主观了，我经常会拿一些新人QA实际工作中遇到的比较棘手的问题来作为情景，看候选人在这种情况下会如何处理。比如难复现的bug开发一直不解决如何去推进、临上线加了额外需求但测试时间不足怎么办、模块间耦合导致的问题两边踢皮球甩锅该找谁解决。想考察的素质也五花八门，不过一般来说，我会特别重视候选人在回答过程中体现出的主动性、较真、或者说是质疑精神。作为QA，可不能被其他职能一两句话就打发走了，勇敢提出问题，穷尽问题的可能性，为问题后果做兜底，在保证这些原则底线的基础上，再具备一定的沟通技巧、产品意识，实际工作中处理这些问题就能称职且游刃有余了。
上面列举了在面试过程中常问问题和考察方向，也是作为初阶测试我所重视的个人素质体现。大家可能会发现，好像这都是些软性素质，在我日常80%的工作内容里很难体现出来呀。没错，这正是我在引言所说工作与个人成长之间的关系。我们初入测试80%的日常工作，比如跟进需求、编写用例、测试执行、跟进问题，都是在为项目创造价值，这也是公司支付我们薪酬的目的。而如何利用好剩余20%的时间（学到更多不会的东西，写分享做总结，复盘思考之前的工作，沉淀出属于自己的经验和方法论），这就是个人投资了。我时常在自己组里讲，工作中一定要重视这20%的内容，因为这些东西是可以在下一份工作面试时拿出来讲的，比起泛泛地说我之前在哪个项目测了哪些功能开了多少bug，这20%内容带来的个人投资收益要高许多。当然，如果能在实际工作中不断学习挑战新内容，把复盘、总结、分享作为日常工作收尾的一部分，在为项目创造价值的同时带来个人能力的成长，这就是公司和个人双赢的模式，也是我们职业生涯的终极追求。
对于这个阶段的游戏测试，我的发展建议是：重视工作中20%个人成长的时间，利用好现有岗位资源进行“寄生式成长”，即学会组织要求大家学会的事，做好称职工作先。我们部门有比较完善的新人培养体系，也有游戏测试的标准化知识库，基本涵盖了工作中需要涉及掌握的方方面面，学习并在自己工作中实际运用，相信大家很快就会跨过这个阶段，叩响进阶的大门。
Growth is the only evidence of life.
成长是生命存在的唯一证明。
—— John Henry Newman 约翰·亨利·纽曼
03 渐入佳境，擅长的人做擅长的事
接下来我们聊下游戏测试的进阶，如果按照公司对职级的定义，处于P3、P4这个职级的同学应该都属于是进阶了。对照专业发展通道页面对这两个职级的详细描述，我们可以看到，P3和P4的共性，就是已具备知识技能、有实践经验、能解决问题，这是与前面“初入”阶段最大的不同，而P3往P4走，更多是在项目经验的丰富程度、解决问题的复杂程度、以及最重要的——能否指导他人工作上。当然，公司对一个职级能力的概括，需要具备普适性，要适配大部分的技术岗位，未必能精准描述游戏测试所需的能力和素质，同时，公司的定义优先是对这个岗位所创造工作价值的考量，我们还是要形成属于自己的个人能力价值体系。
所以我认为，P3和P4职级，都可以算作游戏测试的进阶过程：当一个QA经历完上述的初入学习阶段，掌握他所应当具备的工作技能，完全胜任了日常工作，那就已经步入进阶了。而进阶的方向，对游戏测试而言绝非一条路子，我在这里概括了一些我所认为重要，且颇具共性的能力素质。
1.拥有正确的事故观
虽然挺不想把这个摆在第一位，但试问哪个游戏测试老司机没背过事故？游戏测试本职就是与错误打交道，我认为在职业生涯里，一帆风顺未必是好事，偶尔经历波折，在暴风雨下磨砺，会带来更大的成长。所谓正确的事故观，可以概括成九个字：“提前学，揽事情，重复盘。”
（1）提前学
最好的事故是什么？是尚未发生的事故，是提前发现解决避免了的事故。有的同学会说那这就不是事故，是BUG。不我的朋友，提前避免的事故级BUG，对QA来说是功绩，是可以在晋升答辩，或者面试时拿出来讲的东西。那么如何提前发现避免事故呢，我在前面提到，QA是一个要学会在错误中成长的岗位，这里的错误不仅仅是自己的，也包括别人的。我们部门的事故平台就是很好的案例陈列馆。QA对游戏BUG的敏感度是可以锻炼的，当你具备一定事故阅读储量后，工作中碰到一些类似的需求设计/BUG表现，脑海中能闪现出某某项目好像出过类似的事故，甚至能找到这条事故把报告链接甩给策划/程序来促使修改设计/解决BUG，那是真正的学以致用了。
（2）揽事情
危难当前，唯有责任。当事故发生的时候，QA切莫因为这个事故不是我测的内容就袖手旁观，甚至于多人之间踢皮球。在游戏测试十多年的生涯里，我见过事故发生时一个QA忙前忙后其他人看个热闹；也见过一方有难八方支援，多人协助分工，同时进行问题复现、内网Patch验证、跟进外服补偿。甚至有很多的事故，当时是由非本模块QA找出复现步骤的，可能是当局者迷旁观者清，更重要的是多一个人多一条思路，在事故面前QA是一个集体，而不是分谁背锅。另外，“揽事情”还有层含义是，进阶QA应当具备一定的决策意识。很多事故是有时效性的，在等待决策层了解情形作出应对方案的同时，事故也在不断的扩大造成更恶劣的影响。作为最了解功能细节的QA，应当自主决策优先控制事故进一步发展，如关闭功能开关、规避问题触发点、临时公告通知等等。当然，这更需要“提前学”来获得足够的事故阅历来支撑，正如前面P4职级定义的：“能够在作出决定的时候参考、应用自己在该领域过去的经验。”
（3）重复盘
既然说事故能让QA在错误中成长，那所谓成长就蕴含在事故结束之后复盘的过程之中。事故已经发生就不要再纠结，但这件事本身其实是很好的原材料（事故的损失是足够大的噱头，能发生到线上说明客观存在一些不足，后续深挖复盘也是组织的标准流程），如何通过复盘做出一道好菜（产出一篇部门分享，成为个人晋升答辩的材料，下次面试的吹嘘资本）就看个人的本事了。我还记得自己第一个线上一级事故，就是走的这个线路，因为有了后续的深入复盘和优化落地，这个事故才不是个人的“职业生涯污点”，而是可以写进简历的“过往项目经验”。
2.建立自己的专业壁垒
寻找自己擅长或者感兴趣的工作方向，突破成为自己的专业壁垒，这是我认为在进阶道路上，第二个必须具备的能力特征。我们对初入游戏测试的要求，是应学尽学，有部门整理过的系统知识体系，也有前人组织专门的培训，在工作中大多也会实操运用，所以称之为“寄生式成长”。然而在过了初入学习的阶段之后，在具备普适的知识以及得到足够的实践锻炼之后，应该要找到符合自己特长和兴趣的方向（也可能是工作安排被动擅长），不断深入突破，摘得前人没有收获过的成果。这些成果就会成为个人标签，大家在进行某些工作或者遇到某些问题时第一时间想到你，毫无疑问你已经进阶成要“被寄生”的前辈，甚至成为了某领域的专家。换到本文自我投资的立场，你现在的工作在创造价值的同时，还具备了一定的不可替代性（嗯你懂我意思吧）。那么想让自己“不可替代”，我的建议是：
（1）做别人没做过的，探索游戏测试的边界
我记得有好几次，在不同场和与不同的人，讨论过关于“QA工作范围”这个问题，起因大概都是测试本职工作忙不过来，加班加点的同时，又被上级/其他职能塞了感觉不该QA负责的工作内容。比如汇报管理其他职能工作进度，监督把控产品日常提交规范，与第三方部门协作开发内容的沟通等等。先除开本职工作爆单是管理的问题，我们仅讨论“QA工作范围”这件事。对于初阶QA，“这件事不该由QA去做”的想法，是很正常，且合理的，当前是要聚焦在本职工作上。但到了后续的阶段，老QA的第一反应不应该是圈地自固抗拒工作内容，而是要有以下两点思考：
①、做这件事能否为产品质量带来正向的影响；
②、做这件事的过程，以及预期取得的成果，是否有助于个人成长。
当然大的前提，还是要在合理的工作规划范围内，我们需要对当前所有工作内容的紧急重要程度，有所评估。
我们部门现在达成共识并在各组执行的许多测试工作，如资源检查、表检查、数值平衡、日志监控，以及一些测试左移右移工作，在十几年前，可能都不属于“QA工作范围”，或者压根没有考虑过该不该去做。但正是在这十来年项目经验积累，以及部门对个人能力的重视发展之中，我们验证了这些工作都是能够创造价值的（对产品和个人都如此）。也正是这些曾经“边界工作”的探索者，在不断突破与整理的过程中，成为了这些领域的“权威”，打造出属于自己的专业壁垒。
（2）同样的工作，做的比别人更好更系统
全新的工作内容，是需要有足够的时间和能力去探索的，不一定适合所有人。那对于大家都在做的工作，还有办法成为自己的工作壁垒么？答案是肯定的。大家回想下自己所在的组，有没有人用例写的特别好？有没有人对bug复现特别敏感？有没有人与策划关系融洽，经常就设计方面提前期建议？不同于其他技术岗位，一名游戏测试日常接触到的工作是比较多样化的，正因如此，不同性格/喜好的人，也能找到对应的工作往“好”去做。这里并不是希望大家把日常工作都要做的比别人好，那就变成内卷了。我们要的是找到自己擅长并且喜爱的工作类型：如果能在工作中获得正向的心流体验，擅长和喜爱是可以相互转化的，尝试番茄工作法，给日常工作设定一些小目标是比较好的方式。
这里提到的“更系统”，则是另一套做法。比如我们部门整理出的《标准化手册》，其实就是对日常工作进行系统梳理后的产物。这需要客观全面的分析一项工作的本质意义，工作发展演变的历程，不同项目间的差异，以及这项工作后续发展改进的方向。能把一项日常工作梳理成“白皮书”式的理论知识，前提肯定是对这项工作有足够的实践了解，并且做了充分的调研和思考。这里也不是要求大家为了进阶都去钻书袋子搞理论，“更系统”还有一层实践的含义：我们都知道一项工作是必要的，但工作的落地难免会遇到各式各样的问题，通过自己的努力解决这些问题，或者付出更多的思考，把这些过程都记录下来，也是一种“系统性优化”。
3.要引人注目，要建立个人影响力
我曾经开过一门关于软素质的培训课程，里面提到关于职级晋升，我们在评审答辩时会关注哪些点，其中就有“引人注目”。这是要求大家在工作时不要默默无闻，要主动展示自己的工作进度、遇到的问题和取得的成果。“经常晋升答辩的人都知道”，这三点正是大家准备材料时，每项“业务工作”要体现的内容，这种三点式结构的案例，最能证明一个人的能力和成长。我所期许的“进阶”游戏测试，并不需要等到写年终绩效、准备晋升材料时才重头整理，而是将这种记录并展示的习惯，融入到日常工作中；一方面给他人看到建立影响力，另一方面也是督促自己要关注个人成长。我在这里抛出几个问题方便自省：
①、有每天认真写日报吗？周报有没有提炼出想给主管展示的内容？
②、是否愿意在会议上主动发表意见？分享自己的观点或抛出更多问题？
③、有没有参与过组内或者部门的分享或者培训，其他组的同事/主管认识你吗？
提到“个人影响力”，相信大家都不陌生，部门在2022年有篇精品分享就是讲《内向的人如何扩大影响力》，里面整理了影响力的定义，如何扩大影响力以及大量的实践案例。其中对影响力的定义，即“对别人产生帮助的能力”，我深表赞同。这也是本节我先讲要“引人注目”的原因，只有把你拥有的经验、优秀的一面先主动展示出来，让你建立的“专业壁垒”被看到，才能够吸引到寻求引导帮助的人，进而对他人施加影响。从“擅长一项工作”，到“证明自己擅长一项工作”，再到“让大家都知道你擅长”，这应该是在工作中自我投资最直白的体现。到了“大家都知道”这一步，你收获的不仅仅是工作创造的价值，还有得到认证的职业自信，以及被你影响而建立起来的人脉资源。这些都将构成职业生涯中的一部分，在当前工作之后也能让你持续受益。
4.主动寻找和利用资源
现在回过头，审视下前面我对进阶该具备素质的列举，会发现其实每一项或多或少，我都整理了一些公司、部门中现有平台、分享文章的链接，以辅助说明这项能力的重要性。这便是我想说的最后一点，进阶游戏测试需要拥有主动寻找、利用已有的资源的意识和能力。因为到了这一步，你的工作要么已经初具前沿性，要么已经深入到他人所不能及的程度，站在主管或者组织的角度，已经很难“填鸭式投喂”资源了。也许在这个层级开展的工作，很难直接用其他项目/人的经验/思考来解决问题或应用实践；但用来打开眼界，开阔思路，或在自己处于职业瓶颈，感到方向性迷茫时用来寻找自己真正感兴趣的工作内容，是非常适合的。
除了最常见的培训课程、往期事故、分享文章这类参考性有形的资源，我再补充两种容易在工作中忽视的无形资源：
（1）部门的人脉地图
就像上文中“组织跨组交流”时提到的，雷火有这么多的项目，而每个项目又有这么多的QA，你认识其中多少人呢。作为进阶游戏测试，也作为这个庞大组织中的一份子，应该要了解雷火有哪些项目（特别是与你当前项目存在共性的），并了解雷火测试中心的组织架构（中台部门和负责工作、不同产品测试组、各类专项小组等等），进而认识一些与你工作性质相近的同事，平时可以聊聊各自工作遇到的问题，相互参考，很有可能你们会进化成下一个“专项小组”。这是“人脉”部分，关于“地图”部分，则是我的一个可操作性的建议：大家可以站在类似“猎头”的视角，用脑图给自己写一份地图，比如主框架是雷火测试中心的组织架构，继而延展到不同的产品项目/不同的人/不同的工作项，平时关注“部门特邀分享”、“专家茶话会”等活动，时常更新地图，把人脉资源也转化成“有形”的资源，在有需要的时候，可以“按图索骥”，找到能提供帮助的人或组织。
（2）上级的思维模式
没错，上级也是工作中能够主动去利用的无形资源，除了作为“可学习的对象”，更重要的是了解上级的思维模式。
首先，尝试寻找上级的行为准则，理解他做事情的方法论。每个人做事情的风格是一回事，但准则是另一回事，类似前文提到的“原则底线”，行为准则支撑了一个人开展工作的源动力和对工作目标的坚持程度。上级虽然未必会把自己的“原则底线”挂在嘴边，但肯定会体现在他日常工作里（如给组织制定目标、对下级的指导、突发决策优先级）。就比如我写这篇分享，每个章节其实都是我对不同阶段行为准则的阐述。了解上级的“做事方式”，也有助于你们之间的沟通，甚至可以提前预判上级的决策，更主动地开展工作。
其次，当上级给你布置一项工作任务时，多去思考这个活背后的根本需求是什么，而不是立即机械执行。就好比起本文讲面试那一节，我在设计面试问题的背后都是处于考察某一项具体能力。上级突然布置一项工作，肯定也是为了解决具体什么问题或者达成什么目标，有可能受限于上级的管理风格、沟通方式、自身的信息茧房，当前布置的具体工作不一定是达成目标的最佳路径，这就需要执行者站在更多执行经验的角度，去做二次沟通对齐需求。这套思考方式也不仅适用于上级安排任务，“如何分析用户的深层次需求，转变为有效的工具平台优化”，对于测试开发同学应该再熟悉不过了。
最后，俗话说得好，“屁股决定脑袋”，上级的决策过程、沟通方式以及问题解决策略，通常会有更高的视野。比如前面我提到，初阶的游戏测试应该聚焦在本职工作，进阶的游戏测试则要看到质量工作在整个产品周期里的作用，甚至在产品之外还要看到对个人能力的锻炼以及组织能力的发展。多站在这些角度思考，也有助于形成这样的“全局观”，这对后续晋升测试管理至关重要。
The art of leadership is saying no, not yes. It is very easy to say yes.
领导的艺术在于说不，而非说是。说是太容易了。
—— Tony Blair 托尼·布莱尔
04 所谓测试管理，在管理些什么
接下来我们聊聊测试管理，这是我认为游戏测试职业成长的第三个阶段，也是最漫长最值得学习的阶段，我自己也还在摸索学习的过程中。这个阶段不仅涉及具体游戏测试工作上的“管人管事”，背后的一些管理思维，更是能衍生到其他任何工作，甚至应用到日常生活之中，让人受益终身。其实在几年前，我也写过一篇这个方向的分享《游戏项目质量管理实践》，当时是站在对质量管理理论体系解读的视角，很柴很干，许多想法也是偏理想化。这几年工作中积累了更多的管理感悟，但也很难说正确与否，也许再过两年，看本篇分享还是会有很多“稚嫩”的地方。所以，我现在依然是以“学生”的身份在这里分享我的思考，做不到系统整理，肯定概括不了“测试管理”应该具备哪些素质，只能挑一些我认为重要的，所有晋升管理或者身负管理职责的游戏测试，都应该去思考到的东西。
1.我们还是在找问题
找问题，是测试这个工种的立身之本，贯穿整个职业生涯。从测试执行到测试管理，我们从找产品的问题，变成找组内问题、找项目问题。回到本节引言的前半句话：“领导的艺术在于说不”，这对游戏测试管理来说尤为贴切。在上一篇分享中，我把质量管理遇到的问题分为三类：产品质量、项目质量、人的质量。其中，寻找产品质量问题是游戏测试最基础也是最直接的工作，但作为测试管理，更要把工作重心放到识别项目和人的问题上来。而且，找自己组内的问题，相对还比较容易，因为我们在自己组内有主导权。去指出不同职能之间协作的问题，甚至是其他职能内部的问题，就没那么轻松了，正如引言的后半句：“说是太容易了”。我一直以来的理念，都是“悲观结果论”，即：一切事物如果不对其施加主观能动性，不作干预和引导，必定会往坏的一面去发展，这就需要测试管理有所作为，敢于“说不”。
而且指出问题只是开始，调动项目的资源，分析问题解决问题，才算是正式完成一项工作拿到成果。回想我自己刚晋升管理线的那几年，每年的工作汇报、绩效规划，都是围绕解决当前项目具体存在的问题为目标，这个习惯也一直持续到了现在。而真要指出并推动项目问题解决，这不仅需要“不计情面”，还要“有理有据”和一定的“威信力”、“执行力”。我一直认为测试管理就和项目管理（PM）一样，如果一直抱着“老好人”的心态，是做不好的。测试管理同时要具备“质量警察”的责任感，“不安现状”的意识，“揭开伤疤”的胆量，“跟进到底”的坚持，必要时更要充当“唱白脸”的角色，这些可以说都是逃避不掉的工作责任。举个例子，我很赞同一句话：“靠加班解决问题，是管理者的无能”。相信作为游戏测试大家都经历过测试时间被压缩最后不得不加班赶工的情况，测试管理万万不能一味“说是”，听之任之甚至认为这是理所应当的是常态的，而需要时刻警醒把这作为一个项目问题，时常思考寻找解决的可能性，这样才能保障项目质量长远发展。
2.从找问题到做项目
如果说上面“找问题”是测试管理的基础工作，那么“避免项目出问题”，则是测试管理对产品而言的核心价值。因为“找问题解决问题”，代表这些问题已经客观存在，对项目的进度、质量产生了实质影响。就同测试执行时常说的“测试左移”一样，我们作为测试管理，不能被动地等项目问题产生再去解决，而是应该通过提高对项目现状的观察，加以个人以往项目经历，从过往错误中汲取经验，用前瞻性视野规避潜在风险，“让项目在正确的方向上持续奔跑”。我将其称之为“做项目”的工作方式。
之前和朋友聊天，有一个观点我非常认同，领导或者说一个组织的管理，“可以不全能，但一定要全视”。同样的，游戏测试管理，可以不精通作为游戏测试的全部工作内容，但必须要有足够全的视野，知道游戏测试应该要做哪些工作。更大一层是，测试管理可以不会策划、程序、美术等职能的具体工作，但也要去做足够的了解，这样才能站在整个项目的角度，去提前发现问题，规避风险。
我们经常说，游戏测试是一个很吃经验的岗位，从具体工作内容的经验，到研发上线运营等阶段性经验，以及各种品类游戏项目的经验。测试管理这个阶段，更是要把个人经验最大地转化成项目价值。回想我刚进入现在项目的时候，除了前文提到的寻找解决当前问题之外，另一类付诸大量思考并指导后续工作的理念就是：“当前这个新项目，对比之前经历过的项目，缺了些什么，要如何去补足。”当然，除了自己之前经历的项目，也可以去和部门其他成熟项目作比较，更容易补齐当前工作的薄弱点。
具体而言，测试管理对产品而言的“核心价值”，其实就是在“全视了解”和“经验补足”的基础之上，建立各种项目过程里的流程规范（如版本概念、节点提交控制、事故复盘机制等等，具体可以参考我们部门的标准化工作手册），最终保证各类测试工作顺利执行，保障项目的最终质量。当然，流程规范不是死的，如何在建立流程的过程里，与项目成员相互调整不断融合，走拥有自己项目特色的规范化道路，才是一个好的测试管理真正能力的体现。
3.管理项目的质量预期
解决了问题，建立了流程，接下来我们聊聊项目的预期。何为质量预期，我的定义是：不同项目阶段，不同人（包括自己测试组员、合作策划程序等职能、制作人和主管），对项目产品质量好坏的判断标准，或者说是质量目标。前面说了，不同项目的流程规范不会是一成不变的，为了契合自己项目的特点都会有些微差异。质量预期也是如此，不同职能不同职级，在不同的项目节点，这个预期都应该是动态变化的，如何让这个波动的质量预期更加合理且符合当前实际，就是测试管理要去开展的工作。这也直接影响了其他项目关系人，对整个测试组最直接的评价依据。
接下来，就拿我们项目上线这段时间，我的一些工作来举例吧。从来没有哪个新项目的上线，是十拿九稳轻轻松松的，我们这次也不例外。同样是面临着无穷无尽的需求调整、极限压缩的测试回归时间、长期高强度加班的疲惫团队，我作为测试负责人开展的质量预期管理工作，可以说是本节前言思想的又一次践行，“多说不而非说是，说是太容易了。”
（1）管理测试组内预期，对混乱的工作优先级说不：
毫无疑问，项目上线这个阶段，游戏测试所要负责的工作内容，是所有职能中最多最杂的。经常一边自己规划的回归验证工作没做完，又要跟进一些必要的需求变更。更别提上线后，同时还有严重的线上客服反馈待处理，线上Patch修复要跟进，公告确认、exe集体测试、新版本测试工作等日常工作都要同步进行。经常会有游戏测试在这个阶段身陷工作量地狱，分不清哪些工作优先做哪些工作可以延后，又被各种人催活，加班到半夜不小心犯了错误，更是要情绪崩溃。
这就需要测试管理去做协调了，我在产品项目上线节点前一个月，到上线后的这一周里，分别拉整组开了多次会议，最主要的就是强调当前时间段QA最核心的工作是什么。比如在切上线分支到封包阶段，最核心的是完成需求收敛，确保版本改动能在封包前完成，防止回归时需求扩散；在封包到上线节点前，则是确保最后一轮主流程回归要完成，我的原则是“上线前的主流程回归相当于QA的底裤，不测完功能就相当于上线裸奔”，一旦影响到QA预留的这个工作量，就该出面去砍需求或者延期上线了；在上线之后，QA优先级最高的工作自然是跟进线上Patch，我在上线后就面向全项目制定了“Patch不过夜”的规则，一方面强调QA对Patch的跟进力度，另一方面则是加深各职能对“Patch”用途的规范化理解。
（2）管理合作方的预期，对不合理的Patch修改说不：
我们组有个固定传统，每周值班同学，需要挑部门事故平台上的两条事故，在组内周会上进行阅读学习，并拉整组衍生讨论。从中习得的一个经验就是：所有“线上Patch”都是有代价有风险的。代价是：Patch需要开发组花好几倍的时间去跟进验证一个改动，甚至这个改动可能只是临时性的，主干上还有额外的改法。风险是：Patch带来的影响通常只有这一名跟进QA来验证，缺乏长时间的、集体的回归测试进行保障。这一点在测试组内是达成了共识的，但对于项目里其他职能来说，也许就没有普及了，大家只知道：Patch是可以实时修改线上功能的，甚至还会有“这个很重要，紧急改，后续交给QA”的做法。
同样，这也是需要测试管理去矫正，要让全项目形成一致的“Patch观”，即Patch不是用来修bug，更不是用来改需求的，除非这个改动非上不可，不上产品会凉，不然就应该走正常的开发和修复流程，跟下个版本上线。很反直觉的是，我作为项目质量负责人，在产品刚上线的前几天里，大部分工作是在拦着一些bug fix Patch上线。比起Patch，我更多的是要求大家把时间花在找出问题漏到线上的原因，以及后续开发过程中如何避免，为此经常要和不同职能争执，不厌其烦，但很有必要。因为我知道如果放任所有修改去走Patch，一是整个团队的线上维护工作量加剧，大家疲于奔命，全天高强度高压力的状态下必然更容易出错；二是会让大家形成“Patch依赖”，下意识觉得我们可以先做个东西上线试试，不好再改，接着让项目的版本规划形同虚设，陷入“上个版本没做完——上线后疯狂调整——压缩下个版本的开发周期——下个版本没做完”的恶性循环。
（3）管理主管们的预期，对“好产品坏团队”说不：
上面说的Patch观，自然需要在全项目范围普及意识，但更重要的是得到“从上到下”的认同，这就需要大家去管理主管们包括制作人的预期了。这里的预期，具体是指对产品质量，和项目工作质量的态度，也就是本节标题所说的避免出现“好产品坏团队”的情况。我一直认为，好的团队比好的产品更重要，产品是否成功是有一定概率性的，更不要说当前产品的表现也只是整个产品周期中的一个版本。就比如我们项目刚上线这个阶段，我认为比起解决产品线上一些不重要的问题，建立规范的运营项目工作模式更加的重要，团队需要学习如何分优先级规范地处理线上问题，并且平衡下个版本的开发进度，让后续项目工作更有序地进行。
4.制定目标，管理和提供资源
前面几节内容，都是针对项目的工作，而最后这一节，我希望回到游戏测试管理真正“管理”的部分，即针对自己测试团队成长的管理。
提到团队管理，首先就是制定目标，有点老生常谈，但凡任意一本管理类书籍可能都是这么说，不过我依然觉得对一个团队的成长而言，制定目标是最重要的。我们需要重视每次一任务分配，每一次绩效制定，每一次整组的OKR规划，好的目标才会带来好的成长，这其实也是本篇分享的最终意义，正是给不同阶段的游戏测试制定目标。
有了目标后，再就是如何提供更多的资源，来促使大家达成目标。前文进阶阶段，我提到游戏测试需要去主动寻找和利用资源，而到了测试管理，则需要主动管理和提供资源。有许多的资源是这个位置才能接触和协调的到的，比如跨项目的协助、更多更广的人脉、人力上的调整，必要的指导能打开大家的思路，关键资源则是给目标提供更多的捷径。
再举个自己组内的例子，我们有个传统，是每个人都有定期的分享指标。先是每周周会的最后十分钟，会由值班同学提前准备并做组内分享，内容格式不限；再是每年，需要在前面周会对分享内容沉淀之后，系统性地整理两篇正式分享，并发表到部门的分享平台；最后，如果有实在难产的，我会给他指定一个话题，比如前文的“复盘”分享，恰好是组员写不出分享，我给了《复盘+》这本书和具体阅读分享目标后，自己再复盘写出来的。
也许是有传统师徒情结吧，回顾十多年的职业生涯里，比起各类产品上线，更让我骄傲的是自己团队带出来了多少以游戏测试为职业的朋友，或许大家目前在不同的公司，不同的项目，做着不同的工作，但毫无疑问大家都有着光明的未来。
05 写在最后
没想到能写这么长，看到这里的各位辛苦了，回顾本篇分享最初，也只是想和大家聊聊我觉得自己在职业发展上做的对的事情，夹带了许多主观私货，对这四句名人名言的理解，也仅代表个人观点。
最后，希望大家能平衡好工作和生活。工作是职业生涯的一个阶段，而职业生涯也只是生活的一部分。这篇分享标题纯粹是为吸引眼球，不是给大家制造焦虑的，即使多走了十年弯路，我们也还有一生的时间。这篇分享内容也仅是我工作上的心得，对于生活，我更推崇“Work hard，play harder！”年轻和身体都是革命的本钱，不能一味在工作上过度消耗，除了项目经验，陶冶情操、锻炼身体，也是一种原始积累。特别是我们做游戏项目，阶段性地忙闲交替，建议大家在热爱工作之余，再发展几项能锻炼身体的运动爱好。个人这两年一直在玩骑行和滑雪，在运动过程中即能很好地释放工作积攒的压力，同时又能锻炼心肺能力，不至于创业未半而中道崩殂，感兴趣的同学可以联系我，相信在这方面也能少走一年弯路。
最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
扫一扫
642
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
