移动游戏的测试再平衡策略

经常有小伙伴问我，一个测试人员如果端游测得好，是否也能测试好手游？从微观角度来看确实没什么问题，因为使用的测试方法，测试技术，测试思路几乎没有什么变化。但是从宏观角度来看，则因游戏整体的研发及运营模式发生了变化而导致测试策略会发生一些变更。

那么从端游时代到手游时代，发生了哪些变化呢？简单的来说就是一个字：快。无论是研发节奏还是上线后的运营节奏，都变快了。对于端游，更新一个版本可能要大半个月，更新一个资料片可能大半年甚至一年，这对于手游来说几乎是不敢想象的，很多手游也许都活不过半年。

具体到测试而言，在手游项目，留给测试的时间被大大压缩了，而且需求的变更频度也变大了，时间的不足与需求变更的频繁程度是一个很难调节和平衡的事情，会出现一些很难解决的事情，比如临近版本上线突然出现新需求，到底怎么处理？新需求不加到版本里可能会导致游戏体验下降或收入降低，加到版本里可能会因为测试不充分导致出现事故。从下面的图表，我们对端游项目和手游项目的简单流程做个对比，也许能窥出一二：
 

有问题发生，自然会有相应的解决方法。一个简单的平衡策略是加人或者延期，如下图：
 

这种方式比较粗暴，看似能够解决问题，实际则可能带来更大的问题。比如说增加人手，这个短期会有效果，但是同时也带来了成本增加以及管理复杂度提升的新问题。人员增加也会增加沟通的复杂度，进而提升了人员带来的不确定风险。

另一方式是版本延期，这点是最不靠谱的，影响的是上上下下整个环节的节奏。因为延期不仅仅会导致研发团队的任务调整，打乱研发节奏。更可能导致运营策略跟着调整，运营节奏也会被打乱。

那么有没有比较合适的方式来应对敏捷手游项目的测试问题呢？我想还是存在的，在这里我们可以根据以往的经验和项目实际情况，给出一个再平衡策略，以期能够给出一个相对靠谱的解决方案。首先我们来看下图：
 

通过这个简单图表来看，我们可以从七个方面来优化我们的工作，从而能够让我们应付快节奏下的需求变更与测试时间缩短带来的挑战。

1，合理的版本管理
 

上图是一个简单的分支和服务器对应关系，项目实际情况可能要复杂一些。

我们需要规划好各个分支版本，以及对应的测试服务器，确保我们要更新的内容是清晰明了的，而且对应的测试环境是无污染的环境，从而确保我们的测试有效且明确。

2，主动沟通

不要等待别人告知我们去测试什么，主动去了解版本内容，了解内容制作进度，避免出现信息孤岛的情况。我见过很多项目在版本发布前，突然发现某个需求进了版本但是没有被测试，或者某个需求不应该进这个版本但是进来了。这种情况是需要尽量避免的，这会导致工作出现无用功的状况，或者增加临时工作。

3，主动关注版本信息

对于某些程序员或者策划来说，他们总是出奇的自信，总觉得修改的内容很简单，无需测试，直接上线就好。实际线上的问题往往来源于这些没有经过测试的内容。

我们测试人员需要时刻关注版本信息动态，避免未经测试的内容出现在版本里，这些可以通过多查看svn日志，git日志等手段来解决。

4，多梳理游戏内容

游戏功能之间的耦合度比较高，二手游戏买卖平台往往一个功能的变更会引发另一个功能出现问题。所以我们测试人员需要多梳理游戏功能，熟悉功能之间的关联度，当需求变更时，我们能快速的对该功能进行测试，也能够及时测试关联功能，从而尽量提高测试的覆盖度，减少疏忽带来的风险。

5，预留时间管理

当我们做版本计划时，需要根据需求内容的多少，团队现有人力的工作效率，开发所需时间等内容作出一个综合判断，在做判断时，需要尽量流出一定的预留时间，来应对一些突发状况，从而确保版本能够稳妥地在合理的时间内完成。

6，关键点检查

很多时候，版本的迫切程度是超乎想象的，完整的跑一遍测试用例的时间可能都无法保证。那么我们就需要一份能够快速的被执行的关键检查点列表。当这份列表被细致的执行完毕之后，我们可以确保整体版本是稳定的且风险是可控的。

这个关键点列表需要跟随项目的进展不断的总结完善，不断的把核心点添加进去，把非必要的内容剔除。任何一次版本发布前，至少需要保证关键点被遍历一遍。

7，勤做总结

越是突发状况多的项目，越是需求变更频繁的项目，越需要勤总结。不确定性是风险的主要来源，勤总结则是降低不确定性的有效手段之一。

通过以上这些策略，我们尝试着在频繁地需求变更、时间不足与项目质量之间取得一种平衡。当然，这些努力并不是完整的，我们也需要根据项目实际情况，作出更多的尝试和变化，最终的目的还让我们项目的质量不断的提升，让项目可能存在的风险不断降低。