以笔者所在项目为例，在项目初期我们也遇到了上文所说的各种困境，后来我们做了很多努力和探索，终于让项目逐步走上正轨，基本规避了大部分问题，那么我们是怎么做的呢？

笔者总结了下，基本可以用下面的12字真言概括，即：做减法、改思想、定流程、常总结。

我们通过实际例子来详细描述下12字真言，以及我们通过这么做取得了哪些效果。

一：做减法。为什么做减法？作为测试本身来讲，做减法是痛苦的，意味着某些更稳妥或从前被验证过有效的测试流程要做改变，也意味着保证品质的难度增加。然而为了整体项目的进度我们不得不这么做。那么我们怎么做才能在做减法的同时做好品质保证呢？

1.1，抛弃不必要的流程：

1.1.1）砍掉回归测试的大部分内容。如果我们按照传统的方式做测试，我们至少要做详细的回归测试，而实际项目版本更新速度是1周更新1版，时间根本来不及，只能砍，但是怎么保证品质呢？在做减法的基础上做加法，更加细化版本上线前的checklist检查，基本做到类似回归的概念，但是时间会减少很多。砍多加少，整体上是做减法。

1.1.2）砍掉不必要的测试用例评审。用例评审继续做，但是只做重点功能的用例评审，非重点功能用例不再评审。

1.1.3）砍掉会议中的无效时间。会议需要谁谁参加，只讨论必要内容，非群体沟通私下进行。

1.2，分拆功能测试与非功能测试。

项目组测试只测试游戏功能本身，其他的类似sdk测试，性能测试等统一放到平台组去做，让专业的人做专业的事，提升效率。项目中的测试人员减少了，但是更加专注于版本功能本身，从而也有利于保证质量本身。

1.3，灵活的集中测试。

举个实际例子，比如app提交审核前的检查，放到项目里做可能会耗费较长时间才能做完，而且鉴于测试人员的经验，还可能会发生遗漏现象。我们的办法是临时抽调几个对app审核非常熟悉的人，大家坐在会议室里，快速的把检查点做完。即能保证质量也能提升效率。

二：改思想：思维不改变，则执行无效率。

2.1，拒绝等待。

2.1.1）以前经常遇到某项工作没开始是因为等别人的结果，这种理由经常让人无可奈何。我们怎么做的呢？在每日进度核对（这个流程我们后面会讲）上，我们详细的核对每项任务开始结束时间，如有有必须等上一项任务完成才能开始的情况出现，我们会安排新的任务来填充这段等待时间。以此来保证工作饱和度。

2.1.2）另一个层面，敏捷项目，测试是不能等开发都开发完毕打好包后再开始测试的，而是任何一个功能开发完毕，甚至一个功能中某个阶段开发完毕，我们立刻更新资源到本地，然后立刻开始测试，尽量保证测试与开发同步进行。

2.1.3）坚决不等，我们测试要催促开发按时或提前提交代码，让我们能尽早开始测试工作。

2.2，少抱怨，多思考。

这里不是说不能抱怨，在我们的团队中我们甚至鼓励相互吐槽，目的是让大家尽可能从多方面得到反馈，哪些地方做的不好要及时改进，我们这种抱怨可以说是正方向的激励方式，大家关注的不再是抱怨本身，而是工作出了问题，怎么能第一时间得到反馈，怎么能想办法把问题解决掉，从而以后不再范同样的错误。

2.3，随时沟通。

当然这一项也可以归并到拒绝等待里面，单拿出来说是笔者个人认为再敏捷项目，沟通变得比以往更重要。我们项目中会提倡随时沟通的概念，有问题不要发邮件，或者聊天软件留言，尽量找到责任人工位，随时当面沟通，提升沟通效率和信息准确性。最怕的就是大家坐的很近还要通过邮件你来我往的沟通，不仅浪费大量时间，还会再沟通过程中降低信息的准确性。

2.4，抛弃内网bug数量的概念。

笔者经历过很多公司，很多项目中的测试管理者非常重视内网bug提报的数量，如果时间充裕的话，我觉得没什么问题，但是再敏捷项目，这可能成为项目的一个阻力。我个人认为提报bug很重要，但是比数量则失去了其本身的意义。在敏捷项目由于各种条件限制，我们把指标更换为外网事故数量。以此来衡量测试对项目质量保证工作的好坏。注意此处外网事故指的是通过现有技术手段能够测出来而没有测出来的bug。

三：定流程：

3.1，优化流程，并坚决执行。

不合适的流程一定要优化，还是说个项目真实实践流程改进的例子，之前项目任务不拆分，每周一大家开个会定下本周做什么就完事了，结果经常出现功能延期，版本无法定期或足量上线的情况。大家很郁闷，因为没法定量，很难确定到底是哪个环节出问题，等知道哪个环节出问题，再做调整时间上也来不及了。痛定思痛我们仔细分析讨论后，逐步把所有当周任务都拆分到每人每天工作量的细度，并每天下班前一起核对当天的完成量，这样我们能及时了解到版本进度，一旦出了问题，也可以及时协调资源来弥补。这个流程实施后，基本杜绝了版本延期的风险。

3.2，及时反馈，随时改进。

流程不是一成不变的，要根据实际工作情况及时调整改进。还是举个实际例子。我们的测试绩效考核内容变更过好几次。因为每个项目工作内容不大一样，而且由于我们分拆功能测试和平台测试，导致工作差异进一步扩大。所以我们前前后后根据实际情况调整了好几次绩效考核方案。最后调整到考核方案基本能跟实际工作内容相匹配。

四：常总结：

4.1，不在同一个地方失败2次。

我们经常会发现同一个bug会在不同的版本中出现，弄的大家挺没有面子。我们发现这个问题后，做了2个措施，让这种情况大大的降低了。一是我们每周组织一次测试部门与运营部门的事故核对会议，通过相互监督促进测试人员更加谨慎小心。二是我们开发了一套外网事故数据系统，将以往的各种外网事故数据都上传到数据系统中，让各个项目都能借鉴，尽量规避相同的问题再次出现。

游戏测试工程师之殇(三)－策略篇

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

三，策略篇

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

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

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

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

02）培训培养。

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

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

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

04）专业小组。

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

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

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

06）事故总结。

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