曾被很多次问到，怎样提高测试工作的效率？实话实说，我自己也是只有一些零零散散的思路，并没有一个可以解释的很完善的方法论。
　　先考虑两个问题：
　　第一个问题：在游戏公司里目前常用的测试方法有哪些?
　　其实在大部分游戏公司内部的测试都挺常规的，延续软件测试的方法，对着需求写测试用例 ，然后逐条测试，并没有什么特别的地方。这里说说我们公司的做法。
　　组织结构上：
　　我们把功能测试与专项测试分离，项目组的测试人员只针对游戏功能进行测试，相对比较常规，把功能逻辑覆盖全了可以。
　　专项测试放到一个叫做支撑组的测试小组负责，对接每个项目的 性能 测试、弱网测试、压力测试、sdk测试等等非常规功能内容。
　　这样做的初衷是让专业的人做专业的事，而且不同的组织会在自己的小领域内越挖越深。当然我们也希望能够有全能型人才，但是毕竟可遇不可求。所以我们退而求其次，让不同的人负责不同的专一内容，避免事务太繁杂导致的杂而不精。
　　我想，这也是一种保证效率的侧面方式。
　　项目阶段上：
　　在项目的不同阶段，可能我们采取的策略稍有不同。
　　在研发初期阶段：我们只关注功能能够跑通，因为很多核心逻辑和美术资源后期都会调整，花费太多精力在周边事务上得不偿失。
　　在研发中期阶段：我们会把重心放在功能逻辑细节上，当然测的时间长了，可能会出现一些思维定式的情况，所以我会定期安排做交叉测试。另外是，我们在测试过程中，如果发现任何地方不恰当，一定不要放过，如果你自己觉得都有问题，那么一定存在问题，没必要等到让玩家去反馈出来。这个阶段我们也会安排一到两次的公司全员体验，会设定一些发现 bug 或建议多的奖励，激励大家多发现问题，外部人员的体验会发现很多问题，因为在一个项目久了，很多东西我们自己习惯了，但是作为纯玩家角度来看可能还存在很多UE和逻辑问题。
　　在研发后期阶段：我们会放一部分精力在客户端性能、弱网、适配和 服务器 压力测试上，我们需要让尽可能多的设备和不同网络环境下都能良好的获得游戏体验。在这个阶段，如果有资源，可以找小渠道导入一部分用户来做一轮真实玩家测试。另外，现在有很多云测平台，可以花点钱让他们帮忙做适配方向的测试。
　　以上所有阶段，测试人员都是需要做冒烟->详细测试-> 回归 测试等常规流程的。而且需要关注每个重点功能可能存在的风险点，有必要可以头脑风暴一下。
　　第二个问题：哪些是高效率的?有什么技术门槛吗?哪些是有针对性的?
　　高效
　　这个确实不好谈，毕竟每个公司提供的测试资源、资源质量都不太一样，通用的方法大概有以下几点：
　　1，做好沟通，盯紧需求：游戏的需求变更频率简直可以用恐怖来形容。任何需求的变更都需要及时的沟通，确保不要出现信息孤岛的情况。不怕需求变，怕变更后不知道，从而导致漏测的情况。
　　2，做好测试规划：来什么测什么，显然是不科学的。我记得小学学过一篇统筹方法的课文，在同样的时间内大化工作量，做好统筹还是很有必要的。尤其是你的测试团队人员比较多的情况下。
　　3，一定要做交叉测试：上面也说了，时间久了，人会出现思维定式，要想早点发现bug，一定要有不同的思维出现。
　　4，做好跟进工作。在别的文章中也提到过，发现bug仅仅是测试工作的开始。bug提了，还要跟进，避免一个问题被拖的时间太久，这样终会导致项目的整体延期。
　　技术门槛
　　做好游戏测试工作还是有一定技术门槛的
　　1，玩游戏的门槛，我们怎么定性一个bug，一方面是与需求不符，这个大家都能够理解。另一方面偏主观，那是与常识相违背。这个主观的常识问题，需要我们玩大量的游戏才能体会的到。好与坏，美与丑，是需要有对比的。
　　2，计算机知识，测试时不可能什么都求助于程序人员，那对程序员的打扰太多了，会降低他们的效率。比如要测试一个游戏活动，那需要改时间，改配置，来达到各种条件，这需要我们掌握一定的 linux 命令(大部分游戏服务器都是 linux 系统的前提下);比如要调整玩家数据，那需要我们掌握 数据库 知识(目前比较流行的是redis+mongo或 mysql )，能够调整一些玩家数据以达到测试条件;比如我们要测试接口，那需要我们掌握一些脚本知识，能够通过脚本向服务器发送请求并查看结果。等等吧，还有很多，遇到哪些层面的测试，可能需要掌握哪些层面的知识。测试一般都是要了解很多技术知识，但是也不可能什么都精通，精一知多是挺好的状态了。