没有思考的机械化测试对个人能力的提升、对项目质量的保证都是非常不利的。只有在测试过程中、在bug跟进过程中不断反思，才能保证测试的深度和广度，并起到举一反三、提高测试效率的作用。下面举一个上周项目组的bug例子来说明。
这个bug的描述大致是这样的：同一个账号下，A角色在游戏中进入战斗状态后退出游戏，然后换角色B登录，此时B角色也具有了战斗状态。
qa开了bug单子给程序，程序修改后，qa回归发现bug没了，然后把单子关了。这个流程看起来没起来很美好，一切正常。但是当我通过svn diff查看程序的修改后，发现问题可能不是这么简单。程序的修改diff如下：
大致的意思就是，在角色退出游戏的时候，去清理下状态变量。这样修改有什么风险吗？直觉告诉我，游戏中那么多的状态不可能通过类似的方式，发现一个，清理一个，有点不科学。
通过查看相关代码了解到，我们游戏中角色状态的同步，可以简单的认为服务端推送下来一个list类型的数据，比如角色目前身上有状态a、b、c，那么此时的状态数据为：list[a,b,c]，客户端收到服务器推送过来的状态数据后，会遍历这个list，并根据其中的变量值，设置角色进入各种状态。
我们可以发现如果list中没有某个状态变量，例如d，那么角色是不会去主动更新d这个状态的，因为客户端在遍历服务器推送过来的list中，根本就没有发现d这个变量。对于大部分的角色状态这种实现方式是没有问题的，因为基本上状态都是有一个时间范围的，过了时间就主动结束了。那为什么战斗状态这个出了问题呢？有什么特殊性呢？进一步查看代码发现：这个战斗状态会在客户端进行一次赋值操作，即在客户端的全局变量中，包括了一个变量Var，当客户端遍历服务器推送下来的状态数据list的时候，如果发现有战斗状态变量，那么就会进行一次赋值操作，将Var设置成true。
到这里，我们终于可以把这个bug产生的前后逻辑理顺了：
A角色在战斗状态下线的时候，客户端的全局变量Var此时被设置为了true，然后切换到B角色登入，B初始的时候没有战斗状态，所以此时推送到客户端的状态同步信息的list中，是不包含这个战斗状态变量的，那么客户端在遍历这个list的时候，没有发现这个字段，也就不会去修改这个全局变量Var的值了，此次这个全局变量Var的值一直是true。由于我们没有关闭游戏客户端，只是退出到角色选择界面换一个角色登入，所以这个全局变量一直存在在内存中，并共同，也就导致了B角色被误判为在战斗状态了。如果我们是关闭游戏客户端，是不会出现这个问题。
这样，我们通过了解机制，就可以举一反三，发现潜在的问题：那些状态变量在客户端代码中被重新赋值给全局变量的，都有可能存在类似的bug。于是通过查看代码，发现了的确还存在其他状态变量被赋值的情况，并通过相同的操作流程，复现了一样的bug现象。
通过上面的整个分析和反思过程，就很好的实现了更好、更快的保证项目质量。思考和反思是非常重要的一个环节，不断反思，才能不断的完善测试用例，才能保证好项目的质量。程序也是通过不断的重构逐步完善和优化代码，测试用例作为qa最基本、最核心的输出，也必然不可能一蹴而就，只有不断反思，不断完善用例逻辑，才能不断提高测试深度和测试质量。
本文作者：朱洁
【声明】文章来源于网上采集整理，如有侵权，请邮件反馈yidunmarket@126.com，我们将尽快核实修改。