游戏内短期活动的测试思考

软件测试面试刷题，这个小程序（永久刷题），靠它可以快速找到工作！https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502​编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502

短期活动具有投放频率高、规划开发周期短、测试时间短等特点，在各种因素的作用下，测试时间尤为容易被压缩。与大型玩法相比，短期活动或者复用活动往往被大家“轻视”，看似简单的短期活动反而成了基础问题的高发地带。这篇文章给出了一份完整的短期活动测试指南，希望大家能快速上手此类活动的测试。

01 背景

基本上所有的游戏都会在各个更新节点放出一些短期活动，如节日活动、主题月活动、某某功能预热活动等，它们在拉收、提高玩家活跃度、拉高在线时长、促进社交等方面往往会发挥不错的作用。短期活动一般都具有放出频率高、开发周期短，玩法和数值规划时间短以及测试时间短等特点，很少留有时间允许我们先在部分服灰度测试再全服发布的，而且短期活动一般是受众面比较广，玩家参与度比较高的。所以这些看似简单的活动，想要更好地保证版本质量，还是需要费一些心思的。

从我自己所经历项目的开发流程来看，作为QA参与到流程中来基本都是阅读文档、三方功能会、提测、回归。那我们就需要在开发流程中测试介入的每个节点步步为营，才能更好地保证最终版本质量。

开发流程中的测试工作

02 需求阶段

1. 明确需求

拿到功能文档后多读几遍，尽可能的找到不明确的需求，相关log的需求（log必须有，短期活动经常出现玩家理解偏差的“bug”），在功能会的时候讨论清楚，避免开发过程中由于这些原因导致提测时间延迟甚至提测后程序再返工的情况，如果没有召开功能会，那么就提早在功能群里进行沟通。

在功能文档中，只要你觉得有歧义之处，就一定要提出来并按照自己的理解表述一遍。不要担心啰嗦，因为程序的理解不一定和你理解的完全一样，这样可以避免大家自以为对需求都很清楚，结果提测后却发现并不是想象的那样。这种事情在很多项目中都发生过。如果你的理解是错的，那只需要在测试过程中再确认一下需求就好；但如果程序的理解是错的，而你又没有提前表述出来，那就可能导致程序返工，如此一来，本身就不富裕的时间又被白白浪费了。

2.规避风险

对策划文档中可能存在的风险点、体验感不好的需求点（舆论风险），在需求分析阶段也要明确地提出来，有的人可能会问，如何get风险点呢？我觉得有三种途径可以帮助我们更好地get到风险点：

（1） 逻辑分析规避风险

例如某节日活动为5人组队进行副本打怪，然后会对通关时间有一个个人的排行榜，那么这时候就需要考虑到，既然是5人组队副本，就一定会出现5人通关时间都一样的情况，但会被系统随机排名为第一、第二、……第五名，如果前5名奖励不一样，玩家肯定会觉得很不公平。所以建议排行榜奖励，每5个排名的奖励为一档，或者5的x倍排名奖励为一档，每一档内的奖励是完全一样的。

（2） 多与其他同事沟通交流，通过历史经验和教训规避风险

其实大部分测试组都是会有组内的一些分享的，不论是经验的分享还是事故的分享，往往能够让我们少踩坑，多一些测试思路或方法，举一反三，降低潜在的风险。

（3） 多体验版本内容，站在玩家的角度上规避舆论风险

比如天谕新出的家园（不是短期活动，只是作为一个例子），在家园场景内无法进行任何组队相关的操作，玩家的体验感很不好。站在玩家的角度看，在家园场景里进行各种操作的同时，拉别人入队和申请进别人队伍去参与活动，应该是非常常规的操作，这种限制就应该尽早提出来，规避舆论风险。

03 开发阶段

在这个阶段，需求已经明确了，能想到的风险点已经规避了，功能还未开发完成，不管你是不是在这个时间段有其他的事情在忙，都要抽出一点时间来为后续的测试阶段做一些准备，这样可以有效地提升测试效率，确保版本质量。

1.编写测试要点

短期活动一般留给QA的时间确实很少，加上每个人手上一般也不止在跟进一个功能，所以有些人喜欢在功能提测前完全不管不顾，等到功能提测后开始手忙脚乱地进行测试，想到哪测到哪，最终版本质量差强人意。

这就要求我们在功能提测前，根据需求文档提前写好测试要点，由于时间问题，这里并不一定要写很完整的测试用例，但至少包括一些重要的测试点，如参与条件、道具投放、参与次数与获奖次数限制、数据存储、重要接口。一些特殊情况如断线、弱网、功能交叉等，活动相关配表的一些重要字段，也是比较重要的测试点。由于活动类型太多，这里就不一一列举测试要点了，总之重要的测试点一定要提前列出来。这样在功能提测后，可以尽快地完成测试并能够保证尽可能少地漏掉测试点（如果你非要说完全没有时间写什么测试要点，那么在测试时对照需求文档逐一测试也是一个可行的方法，但不建议走到这一步）。

2.测试前的准备

我们可以提前准备测试环境和数据，一般来说这一步可能不会占用太多时间可以不需要提前准备。但也存在个别活动的特殊性，比如活动存在外部链接跳转，可能就需要提前准备好安卓、windows、ios等不同环境，比如活动会分不同难度，可能就需要提前准备好不同战力段的外网数据等，具体也要根据玩法的设计情况而定。另外，越是大型的游戏，版本内功能的耦合性就越强，使用线上备份库中的成熟角色数据进行测试，可以有效地规避一些耦合性功能间隐藏的bug。如果是新建的角色，直接用指令升级后就去参加活动，很多功能和玩法都还没有解锁，即使存在功能耦合上的bug也无法发现。

测试环境及数据准备

04 测试阶段

如果前面两个阶段已经准备得很充分，那么其实测试阶段相对来说就会变得容易很多，基本上就是对前面规划的具体执行。当然，也不排除我们临时想到一些之前漏掉的测试点或需求上的缺陷。由于测试时间有限，我个人的习惯是按照以下原则：

1 轻重有度

至少我经历过的几款上线项目来讲，这种短期活动能给到开发的时间都不会特别充裕，所以最终提测的版本可想而知相对那些不断打磨反复修改的大系统或大功能，或多或少在质量方面会有更多的欠缺。那么在测试过程中，最好是先把控整体流程，先保证玩法从头跑起来，能跑到结尾进行结算或奖励发放，然后再根据时间去逐步扣细节进行测试。这样至少可以避免上线后出什么大的问题，一些小的细节问题其实或多或少都会带到线上，那么就像时间管理四象限法则一样，我们需要根据问题的轻重缓急来逐个测试和跟进解决，最大程度上降低玩法上线后的风险和负面影响。

时间管理四象限法则

2 及时沟通

当功能提测后，我们要积极主动地沟通，适时地提醒督促相关人员及时处理bug，必要时积极主动配合bug的复现以及日志的抓取，并在bug处理后及时验证，如果条件允许，在功能排除了严重bug后可以邀请对应策划进行一两次体验，避免漏掉一些需求或存在某些理解错误的需求。及时汇报测试进度，必要时可以向领导反映，调度人手，加快进度。

3 重视玩家体验感

由于这类活动参与的玩家比较多，所以需要尽可能地保证玩家参与活动时的体验感，才能更好地达到放出活动的目的，这就需要在测试的过程中，多以玩家的角度去思考，我是从以下几点出发进行考虑的：

（1）入手

这类短期活动大部分都是玩家之前没有玩过的，所以一定要尽可能降低玩家的理解成本，活动时间、活动入口、活动玩法以及奖励从何得知？在测试的过程中，我们不能以一个已知的心态去看，感觉入口很明显呀，玩法很简单呀。而是要从玩家的角度出发，活动开启是否有系统公告？活动入口在一级界面二级界面还是藏得更深？入口是否有红点？如果是组队玩法是否提供了快捷组队、喊人拉人等便捷操作？玩法是否有强引导或弱引导？活动是否有玩法说明且说明是否详细而不啰嗦？

（2）时效

活动的时间范围或者说玩家能够得到收益的时间范围，一定要尽可能明显，比如道具使用的期限，某些活动兑换的截止日期等。因为是短期活动，如果是需要玩家手动获取的收益在截止时间点之前忘记获取了，是否有自动发放。不同的项目基本也都确实出现过由于玩家对活动时间不清楚，导致那些需要主动获取的收益未拿到而引起的负面舆论，所以这方面尽量做得明显一些，或者说做得活一点，到期是否要自动发放，如果设计者已经考虑到了还好，但很多时候这都是需要在测试过程中QA考虑到并提出来的。

（3）道具投放与回收

对于道具的投放以及已投放道具的回收，也是需要考虑得更全面一些。一般来讲，活动道具肯定是通过相匹配的活动进行投放，但有些时候由于活动数量有限，投放的数量达不到标准，很多策划喜欢把活动相关道具放在日常活动中进行投放，这就要求我们提前做好配表检查和测试，避免出现活动本身已经结束了，但玩家仍能继续获得相关道具，活动没了却让玩家获得一些已过期的道具，这其实很影响体验感。已经投放的道具在活动结束后，或自动分解回收，或需要玩家主动分解，或自动回收后给玩家自动发放对应的其他道具或货币，都是需要重点进行测试的，稍出差错可能就需要扫档补偿，比较费时费力还不讨好。

（4）集中

有不少的活动可能设计成在特定的时间点开启或者可以无限次尝试，这就必须要考虑到参与活动玩家数的量级，就拿4月份天谕的龙魂昭世活动举例，每半点在世界特定地图刷出一个boss，参与攻击boss则可以拿到奖励，并且在规定时间内杀死boss可以拿到最高奖励，出现了有些服务器参与的玩家特别多，基本boss出生10秒左右就死了，导致很多的玩家还没来得及跑到boss点就结束了，而有的服务器玩家比较少，导致活动时间结束了boss也没有被击杀。在天龙八部手游中，有个活动是以玩家组队进特定副本参与的形式，在活动期间内可以无限次尝试，但只能拿到成绩最好的一次奖励，由于服务器端副本创建后需要有一定的时间才能释放，导致了活动开启第一天副本创建数量达到上限，后面玩家一直无法创建副本从而无法参与活动的情况。

举这两个例子其实都是想说，测试的过程中不仅要保证功能本身的逻辑完整性，还需要以实际的线上数据为基础，考虑到线上的实际情景，并不一定说玩法给玩家的自由度越高越好，也不一定所有服的情况都是相同的。其实不仅仅是上面举例的两种设计方法，也有可能很多其他的设计方法在上线后也会衍生出各种各样的问题，这就需要我们在测试的过程中，尽可能多的去考虑到线上的实际情况，从而提前把问题列出来，把风险控制到最低。

（5）数值体验

关于测试过程中对于数值的体验感，上面也提到过了，一是尽量以线上玩家的角色数据来进行测试，可以发现一些数值设计上不太平衡的地方；二是根据自己平时线上游戏过程中的体验以及日常其他玩法的投放数值，对当前所测试的活动奖励的投放提出一些自己的感受；三是由于这类活动一般参与门槛相对会比较低，所以对于活动投放的奖励能否赠送、能否交易、次数限制、跨天次数刷新等可能对数值平衡造成比较严重影响的地方，提前沟通，重点测试，把控风险。

（6）资源验证

可以说基本上每次出的这类新玩法都是有新的资源同步更新放出，虽然可能大部分时候，资源问题并不对功能逻辑造成影响，但这一块也是很多人容易忽略的地方，本能地认为在自己的一部测试机上看到的是正常的，肯定其他设备环境下也是正常的。我们做不到对特别多设备的适配，但最好是对安卓、ios、PC三种环境都进行一下测试。由于安卓、ios、PC环境的不同，分辨率不同、不同系统对游戏引擎的支持程度不一样、不同的打包方式等各种差异性，都有可能导致资源在一类设备上显示正常，但在另一类设备上却显示异常。

4 开关和log验证

几乎所有的防刷类型文章中都会提到开关的重要性，尤其是在这类短期活动中，各方面投入的时间都比较赶的情况下，潜在的风险相对还是比较高的。开关是在风险发生时，能够大事化小，及时有效地防止问题扩散的利器，所以也是测试重点之一的。

log的作用：

1）通过log可以设置一些预警，线上万一发生异常，可以在第一时间检测到。

2）在发生事故的情况下，能够精准地对玩家数据进行扫档，方便善后处理。

3） 短期活动一般玩家参与时间短，对部分设计或奖励获取方面存疑或上报bug，有了log，我们可以更好定位玩家描述是否属实，是否真的存在问题。

4）通过活动log可以更好地统计玩家的参与度，可供运营和策划统计不同类型活动的参与情况，及时调整活动方向。

05 总结复盘

对于线上出过问题的地方，发生后要及时反思，举一反三，并及时分享到组内或经验分享平台，可以一定程度避免后续类似活动再去踩坑。例如，某活动奖励投放价值超出预期，是否可以通过对掉落相关的配表做价值检查来进行规避。

对于测试过程中或者上线后遇到的一些重要问题，可以完善测试用例或测试要点，形成活动与用例匹配的文档或测试说明，方便后续参考，或者在一些情况下，可以针对活动的某些重要配表，挖掘表检查需求，编写相关的表检查脚本，这样如果活动复用，不论是对后续的测试过程，测试覆盖度，还是重要测试点排查，都形成了一定的保障。

06 活动复用

如上面所说，一些好的习惯和流程是可以为后续的活动复用提供方便的，但我还是想把活动的复用单独拿出来提一下。一般来说，强烈不建议复用之前已经开过的活动，如果一定要复用，建议导入一两个外网库来搭建测试环境，使用线上备份库中的成熟角色数据来进行测试，有助于发现隐藏的问题点。关于复用活动重开，除了活动本身的测试外，我这边简要总结几个重要的测试点：1.玩家身上获取奖励对应标记的清除；2.活动相关排行榜（如果有）的清除；3.所有活动相关道具的替换；4.所有和活动时间相关配置检查以及版本内测试；5.优化改动（如果有）的模块及所有关联的模块重点测试。

复开活动排雷

07 引申话题

除了上面说到的问题外，几乎所有我经历过的项目，这种短期的活动都很少会进行压力测试、兼容性测试等专项测试，一方面是开发节奏快，时间上基本是不允许的，另一方面是很多专项测试相对比较耗时间且相比之下收益低，也就是所谓的性价比低，说到底还是时间的问题。其实作为QA大家都知道，一个功能从设计起到敲定了上线时间止，总的时间是固定的，中间任何一个环节发生点什么意外情况占用了时间，其实都是在压缩测试的时间，所以，测试的话语权就尤为重要了。一个功能是否达到了上线标准，QA给出的风险等级的高低，是否真正能够决定该功能要不要上线？这是个值得思考的问题。

08 总结

短期活动几乎在所有游戏中都是必不可少的一部分，时间问题，有些点也没有说得过于详细和深入，总之对于短期活动的测试，除了功能本身的测试外，玩家体验感的测试也是尤为重要的。其实上面提到的很多方面，在其他功能的测试上也都是很有必要的，只是针对短期活动，各方面时间都不太充裕的情况下，更需要尽量做到有计划有节奏地去介入测试，希望可以通过本篇文章的分享让大家以后在此类活动的测试中能够快速上手，尽可能全面地进行测试，少留坑点，更好地把控版本质量。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

​​​软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。