前言
个人认为，qa的终极目标是保证自己负责的需求功能模块上线后无bug。然而实际的生产环境中，总是或多或少的出现一些严重程度不一的线上bug，我们如何避免呢？同时，在测试环境下如何做到侧无遗漏，对于自己的测试质量充满自信呢？
分析
简单的总结分析出现线上bug的成因：
- 生产环境与开发、测试环境存在一些差异
这里所提到的差异，指的是玩家身上数据的多样性。每个玩家的游戏数据都不相同，QA在测试工作开展时无法模拟每一种玩家携带数据的情况。
举个bug例子：
玩家A是游戏大佬，背包内存放着稀有道具孽火结晶，其在结束一场活动副本玩法后，玩家A发现背包内的孽火结晶丢失了。
QA在测试环境中使用的账号并不会携带所有已投放的道具，这便造成了上述所说的差异之一。
这时，就会有人说那我们每次测试前将背包内塞满已投放的道具不就行了。说的很有道理，不过换个角度想想：如果我们的游戏内容非常庞大、不仅有道具、还有时装、坐骑、家具等等，按照这个说法我们继续发散思维，那岂不是像滚雪球一样，需要添加的东西越来越多呢。
我们再深入思考，这仅仅是物品上的差异，mmorpg游戏玩家角色数值的差异呢，卡牌游戏玩家卡牌的养成数据差异呢？ - QA对功能实现理解的不够透彻，导致测试深度过浅
QA在功能完成后，需要对程序的实现逻辑进行了解。在不看代码的基础上，我们可以根据程序的逻辑上的一些关键点，进行用例的设计补充或者修改，这样才能提高测试的深度，而不是只简单的设计客户端上我们能够看到的功能测试用例。
举个例子：
现在有一个排行榜，新老玩家都能查看，需求评审会议定下的规则是：15分钟上传一次玩家数据，1小时刷新一次玩家排行榜。
这时，不了解程序实现逻辑的话，我们可能关注点会着重于刷新以及排行榜上的内容显示、以及新老玩家这几个点。如果只是这样设计用例的话，远远还不够。
了解程序逻辑之后，得知有一个实现流程为：新玩家进入游戏时，程序代码便开始走入上述的规则。此时我们便开始思考，如果玩家第一次进入游戏处于新手流程阶段且还未取名并在这期间停留了15分钟以上未操作游戏，那么会怎么样。于是我们将其纳入在功能开发完成前就写好的测试用例中。
ps：该情况最后的结果便是，玩家接着操作游戏至取名结束，进入游戏查看榜单时会发现自己的游戏名字变成了自己的游戏ID；又因为1小时刷新一次排行榜，所以如果玩家是取完名字一小时后才查看的榜单，根本不会发现这个bug。
这一点，我们很容易的就看的出来。如果我们不提前了解程序逻辑，我们是不会知道上传数据的流程点，进而导致测试的深度不够。
当然，了解程序逻辑的还有一个好处便是，方便我们对功能的接口进行测试。这点暂时在这先不细说，后续开新随笔再聊 - 需求文档分析做的不够好
这种情形会出现两个主要问题
一、导致QA验证标准不明确，造成QA不知道这是bug。
二、分析考虑不全面，导致后续用例设计不全面
举个最简单的例子：
需求文档内写到，收到新邮件时，邮件上会有一个红点提示。
文档分析没做好，便会造成QA错误的认知现象：需求上写着有一个红点提示，嗯，没问题，有红点就可以了。但是真的就这样吗？如果QA真的觉得这个需求没问题的话，那么在测试用例阶段，也只会设计：收到新邮件时邮件上出现一个红点。测试时，新邮件的右上角确实是有一个红点，QA可能就认为这个需求没问题了。等到生成环境下玩家反馈后，才知道这个原来是bug。
以上面的例子来说，文档分析时，我们就需要和策划明确红点的显示路径是什么，同时还要结合邮件系统的其他需求进行一个联动的考虑，以及提出一些缺失的设计内容是否需要补充，例如邮件是否需要回收，玩家间是否需要可以发邮件等等设计层面的东西。 - 用例设计不够全面
这一点简单了，QA测试肯定是都需要按照测试用例上写明的测试点来测试。如果测试点都缺了，按测试过程肯定就会遗漏。一开始都没想到的一堆点，难不成测试过程就能全部想到了吗？ - 缺少用例review的过程
用例review也是较为简单，就是在用例设计完成后，组内的QA开会听设计者对玩法介绍，讲解用例的测试点，同时大家进行头脑风暴提出自己的观点沟通交流，设计者可能因为经验不足亦或者对游戏不够熟悉等问题造成的用例设计测试点遗漏 - 测试经验的不足
这个就不必多说了，顾名思义
总结
分析内说了那么多，其实提到了测试流程内的几个环节。每个公司测试工作流程可能都不一样，但是核心还是不变的，有需求分析、设计测试用例。有差别的地方就是整体环节的好坏以及合理程度。
前言说道：在测试环境下如何做到侧无遗漏，对于自己的测试质量充满自信呢？这在分析中其实都有提到了。侧无遗漏，最好的保障方法便是做好需求文档分析、设计出好的测试用例，加入用例review环节。对测试质量充满自信的方法除了侧无遗漏所提到的，最重要的就是深入了解功能玩法的实现逻辑，以及策划设计的玩法规则，做好接口协议测试，必要且有能力时辅以白盒测试。
