游戏测试行业之殇——测试工程师如何挽救自己的职业技能

GameRes游资网授权发布 本来不想写这篇，然则近一两年来的面试过程还是深深的刺痛了笔者，也带给了笔者一些悲观情绪。在面试的过程中我们发现很多年轻的游戏测试工程师无论是工作技能还是思路都出现了下滑的趋势，都说后浪拍前浪，为何在游戏测试领域出现了相反的现象呢？我们不禁要思考，最近的游戏测试工程师到底是怎么了？抑或整个游戏测试环境到底怎么了？

我们尝试着从以下几个方面来分析一下，看看这种下滑趋势是如何发生的，以及在这种趋势下，对我们现在的测试工作有何影响。

正式开始之前笔者声明下，本文不会是一篇欢乐的文章，如若刺痛某些小伙伴或能带来一点点思考，幸甚之。欢迎拍砖吐槽，笔者仅仅希望能为游戏测试的发展发出一点点微薄之声，我笔写我心，仅此而已。

一、环境篇

人之本性之一，就是习惯把发生的问题归咎于外因而非内因，古今中外，概莫能外。从乌江边上一声长叹“此天之亡我，非战之罪”到《南征北战》中的著名台词“不是我们无能，而是共军太狡猾”，从国内的各种临时工到最近的大众的造假门，可窥一斑。既然如此，我们就从外因说起吧。

游戏测试环境确实发生了很大的变化，尤其是近两年移动游戏兴起，越来越多的微小型创业公司出现。时代和公司结构的变化直接影响了整个开发流程环境，而作为开发流程中的测试一环，也深受影响。这些影响至少体现在以下几点：

1）微小型公司难以招人，一方面是公司本身资金有限，提供的福利待遇与大型公司无法媲美，对人才的吸引力不高。另一方面是员工更倾向于受雇于大企业和知名企业，从而获得更多的报酬和培养机会。综合以上两点，微小型公司招聘测试工程师时面临着很多困境，迫于项目的紧迫性，有些时候不得不降低招聘标准。

2）降低招聘标准带来的影响并不可怕，可怕的是不培养。说到培养人才问题，笔者又是一声长叹。据笔者所知，很多公司内部根本没有培训这回事。当然对于这件事，企业本身存在着两难的困境，一个项目几个月就做完上线，根本不可能抽出时间去专门培养新人，几个月之后，公司能不能活着都很难说，时间和成本上根本不允许。另一方面，现在互联网行业人员流动太大，好不容易培养出来一批人才，转眼就走光了，没人愿意为他人作嫁衣裳，尤其是对微小型企业而言。我们常常说xx行业的黄埔军校，一般而言也都是大型企业才有这个实力。从企业的角度来看，直接招聘有经验的，来了立刻能干活的员工貌似是最优选择。

3）快餐化。某些团队为快餐化团队，基本无原创内容，换套美术资源就上线，在这样的团队中，抑制了测试人员的发挥空间，从侧面降低了测试人员的成长与发展。

4）认知固化。很多移动团队是从端游团队转型而来，整体的研发模式和流程都沿用端游的模式，思路和认知比较固化，没有针对移动游戏的特点作改变，从而导致测试人员无法针对手游的快速研发、快速迭代等特性做出调整，思路被局限，还在走老路。只是在做移动版的端游测试。

5）专业测试外包公司的出现。很多公司尤其是微小型公司更倾向于把测试工作外包给测试外包公司去做，一方面成本容易控制，另一方面也省却了内部人员培养管理等繁琐的事务。从而导致很多小公司内部的测试人员紧紧是做一些的验收或与外包公司对接等简单工作，这些人由于工作性质所限，自身的成长性被无形降低。

以上简单谈了谈外部环境因素导致的测试人员综合素质降低，一家之言，欢迎大家一起探讨。

二、内因篇

这部分我们主要谈谈一些导致游戏测试工程师能力降低的内在因素。

马克思曾经教导我们“事物的发展由内因决定，并受外因影响”。环境的变化固然带来了一些无法改变的影响，但笔者认为更重要的还是来源于我们自身的内在影响。让我们一起来看看内在的因素有哪些：

1）不恰当的认知和行为。很多游戏测试工程师认为游戏测试就是玩游戏，玩游戏玩的好就能把工作做好，甚至很多人在上班时间以体验游戏的名义玩非本项目的游戏。这种认知和行为笔者认为都是不太恰当的。首先游戏测试本身是软件测试的一个分类，属于一门严肃的工程类目，需要有严密的逻辑能力、工程思维和一定的技术能力来支撑，简单的玩游戏并非能把实际工作做好、做精。其次，在工作时间上网、玩游戏、看视频之类的，笔者还是不建议的。短时间调整下工作状态未尝不可，毕竟是游戏公司。长时间的则会严重影响工作效率，給自身和项目都带来不好的影响。

2）懒的去做。游戏测试比软件测试麻烦的地方就在于某个功能可能存在n多种可能性，毕竟不同的玩家存在着差异性选择，测试工程师的工作就是尽量全面覆盖所有可能存在的可能性。很多测试人员在测试过程中遇到这种复杂度比较高的功能时经常犯懒，本能的把某些可能性默认为永远不会出问题而忽略掉，那么这些被忽略的可能性往往就会到证一些线上事故。部分测试工程师不去思考怎样尽可能的创造测试环境，而是为功能本身的不可测试性寻找理由，这点是另人痛心疾首的。

3）固步自封。在这样一个终身学习的时代，很多人却拒绝学习，拒绝更新自己的知识，一直在吃老本。令笔者担忧的是这种老本还能够吃几年。笔者在面试过程中遇到了很多从业5-10年的游戏测试工程师，对测试流程之类还能顺利回答，然而当问到某些技术性问题时，且不说是多么高深的技术，就算是诸如怎么修改服务端数据、服务端与客户端的网络协议类型等此类问题，很多人还经常卡壳，甚至表示从来没接触过。。。这实在是hold不住啊。别张口就要一两万，我真心希望我能给你更高，但是关键是你自身掌握的技能和经验是否与你要的薪酬等价。

4）心浮气躁。很多测试人员过多的精力放何时涨工资、何时升职等问题上，而没有脚踏实地的去把负责的事情做好。个人认为，有所成就的人，在其光鲜背后，必定有很多不为人知的艰辛付出。任何公司的升职加薪都是建立在员工付出一定努力的基础之上。当一个人没有把本职工作做好时，上级是很难让你负责更重要的工作的，那也意味着离升职加薪距离还很远。所以奉劝各位不要舍本逐末，把精力和时间多放在提升自身技能上，把工作做好，馅饼自然就落下来了。哪怕公司不能满足你，市场也会满足你的。毕竟任何人的价值都是整个市场决定的，前提是你得有相应的价值。

5）漠视差距。很多测试工程师自以为工作做的挺好，我想这可能是很多小团队中的测试工程师的通病。因为他们只看到周围有数的几个人的工作，而看不到整个行业中技术变革的日新月异。据笔者观察和实际交流，在很多大厂商中，如BAT，测试技术已经有了很大的进步并且在不断进步之中，这种技术和方法上的差距已经另很多小团队望尘莫及了，如果我们看不到这点，而整天活在自我的幻境中，不去提升自己，我们终究会被这个时代抛弃。

6）不想也不去学编程。最后也谈谈一个在测试圈子经常被争论的内容，一个优秀的测试需要懂一门编程语言么？笔者认为并非是必要条件，毕竟很多优秀的测试人员不懂编程（笔者的团队中有非常多不懂编程的优秀测试工程师）。不过笔者还是劝各位学习一门语言，它本身也许并不能给你的实际工作带来什么帮助，但是在学习语言的过程中，你可能会接触到计算机方方面面的知识（操作系统，数据库，网络等），也能拓展看待问题的方法。当项目环境发生变更时，可能帮助大家很快的适应新的环境。

三、策略篇

我们主要谈谈在整体游戏测试工程师综合素质趋于下降的趋势下，处在中小公司的游戏测试的工程师们为了做好日常工作和管理工作，应该采取怎样的措施呢？在此笔者结合近两年来在不同的项目采取的实践，来谈一谈这个问题。

正式开始之前，继续解释一下，主要还是谈论在中小公司存在的问题。中小公司在资源投入上和知识沉淀上存在很多局限性，但是问题也是可解的，只要我们不断的努力寻求解决之道，努力结合公司实际情况不断改进，我相信在中小公司的测试工作都可以与BAT相媲美，无论是技术还是管理。毕竟，主席说过“星星之火，可以燎原”，微小的力量也许有一天也会发展成燎原之势。

好了，我们正式谈谈在中小公司可以采取的最佳实践有哪些？基本都是笔者经历过的几家公司不断总结实践而来，大家可以多多探讨，也许有更好的方式方法，一起来提升游戏测试工作。

1）把尽可能多的工作checklist化。


俗话说“好记性不如烂笔头”，一个游戏项目，研发领域各种各样的系统非常多再加上运营后各种各样的工作内容，单靠脑袋去记，很难避免遗忘，而任何遗忘都可能导致非常严重的事故。同样作为一些新人或者能力不够高的测试工程师，如何把工作做细致，尽可能的保证测试质量，各种检查内容checklist化是很好的一个解决方案。无需掌握太多技能和经验，一步一步自习按照检查列表走，就能保证不出问题。这也是一个放心让新手和经验不足的工程师承担更多工作和责任的有效机制。

2）培训培养。


在小公司搞培训培养很难，但是从投入产出比来讲，我们可以就适当的内容和技术进行一些培训，耗用尽量少的资源，来让团队的人员不断成长。这里的培训方式可以是多种多样的，不一定是指专门拿出时间来給大家讲课，可以以多种形式进行，比如就某项技术或流程写成文档，让大家在业余时间学习，比如安排一项特定的任务，让员工在实际工作中去应用学习等等。一味的只让员工工作，而不去培养他们，从长远看，反而是对公司不利的。员工不断的成长的同时也能为其工作岗位带来更大的价值，从而提升了团队的整体价值。

3）鼓励和帮助员工进行一些新技术和新方法的探索。


在工作中，有的员工可能对某项技术有兴趣，那么我们应该鼓励和支持这种探索学习，引导他们把探索的技术应用到实际工作中，甚至为他们提供一些专业的书籍或者不限于公司内部的培训机会。员工和公司都会在这种探索学习中受益。举两个实际的例子，一个是笔者之前服务的公司，笔者的一个同事对ruby很有兴趣，团队给予了很多技术和时间上的支持，从而完成了游戏后端的自动化测试框架。另一个例子是笔者现在服务的公司，某员工对自动化很感兴趣，笔者就跟她一起研究了基于python的selenium自动化测试，并为其在公司外联系了培训机构，利用业余时间参与学习。我们最终把该自动化测试框架推广到了实际工作中，一定程度上提升了web测试小组的工作效率。

4）专业小组。


在笔者其他文章中也提到过这种方式，在中小公司，测试的技术实力和沉淀都是有限的，那么面对某些专业的测试工作，我们可以临时抽调一些经验丰富的测试人员组成一个测试小组，对这些专业化的测试任务进行测试，从而尽可能的提升测试效率。这个小组的工作内容也在工作过程中持续总结积累，自身也在不断成长，一些东西可以文档化的积累下来。那么当我们再次面临这种专业化比较高的任务时，我们就可以从容的去应对。这种方式比较适合人手不够多的中小公司。

5）绩效考核方式的变革。


很多公司对测试人员的考核过多的集中在bug数量上，笔者个人认为这在中小公司是不适合的。在考核日常工作上，笔者认为bug数的考核已经不再适应当前环境和时代，笔者把这方面的考核变更为工作量与事故比这种方式，工作量高，事故低都会带来更大的比值结果，相对公平和有效一些。毕竟我们绩效考核的目的还是促进员工不断进步，而不是消极的去惩罚员工。另外，笔者把员工的个人成长也放到绩效考核占比之中，虽然一个季度很快就过去了，但是日积月累的不断成长，还是会在绩效考核中有所体现，从而給员工自身带来实实在在的好处。

6）事故总结。


尽量保持每周都进行事故总结，中小公司在这方面反而是有优势的，不用费尽力气组织n多人一起开会，随便找个会议室就解决了。出错不怕，人非圣贤，大家在工作中都会范错误，怕的是在同一个地方犯错，我们经常组织事故总结的目的就在于希望大家能不断总结经验教训，不断保持谨慎务实的工作态度，这样整个测试团队就会逐渐重视自身的问题，从而不断的改进自身，达到自我进化的目的。一些经验不足和能力不足的测试工程师也会在不断总结中受益。

就说这么多吧，可能小伙伴们也有很多更好更佳的实践和方法，欢迎大家一起探讨，感谢大家对笔者的支持。

相关阅读：一张图读懂游戏测试：游戏测试的日常与技能树分享