游戏测试员攻略：如何提高测试工作的效率？

曾被很多次问到，怎样提高测试工作的效率？实话实说，我自己也是只有一些零零散散的思路，并没有一个可以解释的很完善的方法论。

先考虑三个问题：

第一个问题：在游戏公司里目前常用的测试方法有哪些？

其实在大部分游戏公司内部的测试都挺常规的，延续软件测试的方法，对着需求写测试用例，然后逐条测试，并没有什么特别的地方。这里说说我们公司的做法。

组织结构上：

我们把功能测试与专项测试分离，项目组的测试人员只针对游戏功能进行测试，相对比较常规，把功能逻辑覆盖全了就可以。

专项测试放到一个叫做支撑组的测试小组负责，对接每个项目的性能测试、弱网测试、压力测试、sdk测试等等非常规功能内容。

这样做的初衷是让专业的人做专业的事，而且不同的组织会在自己的小领域内越挖越深。当然我们也希望能够有全能型人才，但是毕竟可遇不可求。所以我们退而求其次，让不同的人负责不同的专一内容，避免事务太繁杂导致的杂而不精。

我想，这也是一种保证效率的侧面方式。

项目阶段上：

在项目的不同阶段，可能我们采取的策略稍有不同。

在研发初期阶段：我们只关注功能能够跑通，因为很多核心逻辑和美术资源后期都会调整，花费太多精力在周边事务上得不偿失。

在研发中期阶段：我们会把重心放在功能逻辑细节上，当然测的时间长了，可能会出现一些思维定式的情况，所以我会定期安排做交叉测试。另外就是，我们在测试过程中，如果发现任何地方不恰当，一定不要放过，如果你自己觉得都有问题，那么就一定存在问题，没必要等到让玩家去反馈出来。这个阶段我们也会安排一到两次的公司全员体验，会设定一些发现bug或建议最多的奖励，激励大家多发现问题，外部人员的体验会发现很多问题，因为在一个项目久了，很多东西我们自己习惯了，但是作为纯玩家角度来看可能还存在很多UE和逻辑问题。

在研发后期阶段：我们会放一部分精力在客户端性能、弱网、适配和服务器压力测试上，我们需要让尽可能多的设备和不同网络环境下都能良好的获得游戏体验。在这个阶段，如果有资源，可以找小渠道导入一部分用户来做一轮真实玩家测试。另外，现在有很多云测平台，可以花点钱让他们帮忙做适配方向的测试。

以上所有阶段，测试人员都是需要做 冒烟->详细测试->回归测试等常规流程的。而且需要关注每个重点功能可能存在的风险点，有必要可以头脑风暴一下。

第二个问题：哪些是高效率的？有什么技术门槛吗？哪些是有针对性的？

高效

这个确实不好谈，毕竟每个公司提供的测试资源、资源质量都不太一样，通用的方法大概有以下几点：

1，做好沟通，盯紧需求：游戏的需求变更频率简直可以用恐怖来形容。任何需求的变更都需要及时的沟通，确保不要出现信息孤岛的情况。不怕需求变，就怕变更后不知道，从而导致漏测的情况。

2，做好测试规划：来什么测什么，显然是不科学的。我记得小学学过一篇统筹方法的课文，在同样的时间内最大化工作量，做好统筹还是很有必要的。尤其是你的测试团队人员比较多的情况下。

3，一定要做交叉测试：上面也说了，时间久了，人会出现思维定式，要想早点发现bug，一定要有不同的思维出现。

4，做好跟进工作。在别的文章中也提到过，发现bug仅仅是测试工作的开始。bug提了，还要跟进，避免一个问题被拖的时间太久，这样最终会导致项目的整体延期。

技术门槛

做好游戏测试工作还是有一定技术门槛的

1，玩游戏的门槛，我们怎么定性一个bug，一方面是与需求不符，这个大家都能够理解。另一方面偏主观，那就是与常识相违背。这个主观的常识问题，就需要我们玩大量的游戏才能体会的到。好与坏，美与丑，是需要有对比的。

2，计算机知识，测试时不可能什么都求助于程序人员，那对程序员的打扰就太多了，会降低他们的效率。比如要测试一个游戏活动，那就需要改时间，改配置，来达到各种条件，这就需要我们掌握一定的linux命令（大部分游戏服务器都是linux系统的前提下）；比如要调整玩家数据，那就需要我们掌握数据库知识（目前比较流行的是redis+mongo 或 mysql），能够调整一些玩家数据以达到测试条件；比如我们要测试接口，那就需要我们掌握一些脚本知识，能够通过脚本向服务器发送请求并查看结果。等等吧，还有很多，遇到哪些层面的测试，可能就需要掌握哪些层面的知识。测试一般都是要了解很多技术知识，但是也不可能什么都精通，精一知多就是挺好的状态了。

哪些是有针对性的？

参照上面一段的例子，比如性能、弱网、数据库、压力、接口等等测试都是相当有针对性的。

第三个问题：对于测试来说，有哪些基本法？

在我看来，就一条：认真负责、勤学心细。

测试过程：持续优化

测试过程的优化问题，也可以看作是提升测试效率的一个零散的点。

想到这个问题，还是因为这两天抽时间优化前段时间用python写的一个分析统计项目工作量的脚本时想到的。

最初的这个python脚本，我只是按照想法直接实现了一版，并没考虑太多结构上的东西，能跑出结果来就挺满意，中间还解决了邮件发送图片的问题，当时觉得还是挺有意思的一件事。

But, 在实际使用的这段时间，我发现项目每进一个新人，我都要改动代码中非常多的地方，痛苦不堪。于是被迫重新优化一下原来的脚本，当我回过头去看我最初写的那个版本，代码烂的简直是一坨屎。


于是花了一些时间，重新调整结构，把人员变量抽离出来，这样项目新加人的时候，只需要增加新的变量就好了，不用调整太多代码。完成这个版本后，觉得已经很好了。

但是，又过了几天，我回过头再去看调整后的代码时，发现，还是一坨屎。。。


虽然添加人员方便了很多，但是代码明显存在很多冗余的地方，这样当我们查看具体逻辑时，还是显得很混乱。于是，我又抽时间优化了一版，把可复用的内容都抽象出来，让代码逻辑上更清晰一些。

整个过程，脚本代码从一千多行优化到只有六百多行，可见，最初版本的代码简直不忍直视。

通过修改这个脚本的过程，带给我的感触就是，很多事情，做完了并不意味着是一种良好的状态。当我们在过程之中遇到问题时，还是要尝试去优化以前的内容。优化也并不意味着是一次完结的事情，可能要反复很多次，总会有更优的解决方案出现。

实例化到我们日常的测试过中，会有很多类似的问题。

比如我们测试一个功能时，发现了很多bug，以为测试全面了。但是当我们静下心来再次回顾这个功能时，往往还是能够发现很多以前没有测试到的地方。

同样写用例也是如此，哪怕功能需求没变更，等我们写完之后，再去回顾通篇用例时，还是能够发现遗漏或冗余的地方。

同样的情况可能会出现在我们日常工作中的很多地方，测试的过程是个持续优化的过程，通过不断的优化和迭代，可以使得我们的测试工作越来越优秀。

最后，补充说明一点，有些事情需要慎重考虑，三思而后行，不适用迭代方式，比如某些决策类行为。有些事情可以通过不断的迭代来做好，先把事情做完，解决当前面对的问题，再考虑后续的优化，比如日常具体的执行类事务。大家还是要根据实际情况来权衡。

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