游戏测试有别于其他软件测试的一点，就是迭代周期快且需求变化大。在这样的前提下，如何把握有限的时间，着重测试每个版本的重要内容，保证版本的基本质量？一般来说，再按部就班的进行测试用例的执行，可能就行不通了，所以需要提炼测试要点。
1、测试要点和测试用例的差异
首先让我们看一张对比图：
毫无疑问，测试用例的切面精准度更为准确、颗粒度更小、用例覆盖率更高，对于问题的定位更加准确，但是执行一次用例需要耗费的时间更长。另外，当需求发生变化的时候，测试用例比测试要点更容易受到影响，需要更新的条目可能更多。
所以，测试要点更关注重要测试点和风险点，测试用例是在测试要点的基础上的延伸。
2、冒烟测试的重要性
冒烟测试这个名词本来是源自硬件行业，当硬件组件得到修复后直接对其通电，如果没有出现冒烟的情况，则证明通过测试。
那么在软件行业里，冒烟测试就是对测试要点的高度总结和概括。这也是测试集的最小单位。如果冒烟测试不能获得通过，那么证明这个版本存在无法通过的重大问题。
在游戏行业里来说，需要尽早确定并编写冒烟测试用例。一般来说，在测试人员介入到项目之后，首先的工作就是要对游戏功能进行拆解，并提炼出冒烟测试用例，进而根据不同阶段的版本改进，不断的修正冒烟测试用例。
那是不是冒烟测试越早进行越好呢？这是不一定的。一般在我们获得开发给到的版本的最开始和最终阶段，都要进行冒烟测试。最开始阶段的测试，是为了保证版本的基本质量符合测试条件；最终阶段的测试，是为了保证版本已经具备上线的基本条件。
3、功能模块的划分和测试要点的生成
我们以游戏里常见的问卷答题为例，简单介绍一下两种基本的功能划分方法，通过这两种方法，可以大致将游戏版本进行拆解，并得到尽量准确的测试要点。
第一种是环环相扣法，也就是按照待测试功能的游戏玩法，自上而下的一步一步拆解。
第二种是盲人摸象法，也就是不考虑待测试功能的玩法，只从不同测试角度去考虑测试点。
当然，两种方法各有优势。环环相扣法是从玩家操作流程入手，更能从用户角度发现一些易用性和合理性上的缺陷；盲人摸象法则将更多精力放在后端和关联测试项上面。有时候我们也会结合两种方法一起设计测试要点。
4、版本迭代期间的要点编写
不同的版本迭代周期，我们有着不同的要点编写方法。
在项目尚未上线的时候，我们有较为充分的时间准备要点或是用例。所以在这个阶段，我们需要针对每个功能策划案，展开策划需求讨论会，一方面是直接从策划案里寻找漏洞，在功能设计初期就避免一些风险点，另一方面是尽早接触功能设计过程，熟悉功能玩法，这样可以更准确的找到测试要点。
而在游戏上线运营之后，除了日常的版本测试工作外，还有大量的玩家问题反馈和临时需求需要处理，这时候时间就非常有限了。再加上部分功能可能也不再有策划案作为指导，所以需要我们发挥自己的沟通能力和组织能力，聚集大家的力量，寻求策划和开发的帮助，一起来完成测试要点的编写，会更全面、更稳妥一些。
5、冒烟测试工作量和工作效率的取舍
在项目上线之前，我们总是有很多时间来完善测试用例并加以执行。但是在项目上线后，除了常规的测试工作外，完善冒烟测试用例并持续执行是更好的选择。
但是冒烟测试用例的条目也不是一成不变的。
以我个人的习惯，我会有两种执行方式。在时间充裕的情况下，会完整执行一遍冒烟测试，来决定该版本是否符合上线更新的标准。但是如果时间不多，我会从已有的冒烟测试用例中抽选一部分，再结合本次版本重点功能的用例，把用例里面最重点的测试case抽出来，两部分合在一起形成新的冒烟测试用例，进行执行。
不过，这两种方法也不能完全保证版本质量的百分百安全。因为毕竟冒烟测试针对的就是最核心的模块，并不能确保版本所有功能的正确性。另外，从冒烟测试用例里抽样测试这个动作本身就具有一定风险。
所以建议是提前准备两套冒烟用例，一套我称之为完整版冒烟测试用例，一套称为核心版冒烟测试用例，提前把整个游戏最核心的内容挑选出来，这部分内容是无论时间如何紧迫都必须测试通过的（当然，并不一定非得弄两套，可以通过优先级进行区分，如核心冒烟测试用例标位为最高等级，其他标为次优先级，根据实际情况选择执行）。这样可以在一定程度上提高版本质量。