本文主要是写了我参与的一个游戏项目首次精英测试的一些小小的感想

本次精英测试下来，还是比较顺利。我负责的部分出现了一个比较严重的bug和一个概率出现的后端报错，这个bug最先由测试发现，当时只知道bug的具体表现——玩家切换角色服装时会卡死，却不知道怎么重现。后来根据报错信息和自己的推测，重现了这个bug。其实出现这个bug的概率还是挺高的，只要玩家脱掉所有服装，然后重登进行换装就会触发。这个bug出现的原因是之前策划的设计是：服装是不允许脱下(只准替换)，后来改成可以脱下。前端代码改了，但是后端代码没有改导致的。

从这个bug中要吸取的教训就是——要时刻关注策划的修改。无论是数值的修改还是功能上的修改，都有可能导致bug的出现。而这些bug往往又会被测试忽略(因为该功能之前已经通过了测试)，所以功能的开发者是要为此负责的。

由于是线上测试，所以对待bug的态度比较严谨。从表现到报错一步步具体分析，证明自己的猜测。列出解决方案，逐个对比，然后修复测试。一个过程下来，并没有觉得浪费了时间，反而觉得赚到了(关于修改线上bug的规范化，我之后会另开一篇进行讨论)。还有遇到一个比较诡异的Collections.sort报错(java.lang.IllegalArgumentException Comparison method violates its general contra)，测试环境和开发环境都没出现过，经过不断反复的google和确认发现是自己一个地方写的不规范导致，而且这个问题是概率出现。对待bug的态度和行动越认真获得的就越多，bug越是难，修复之后获得的也越多。

下面是我来在项目开始到精英测期间开发的一点心得体会：

坚持写测试用例：
我有一个功能没有写单元测试——数据统计，然后这个地方就遇到了大坑。越重要越难的就越要写测试用例。写单元测试能大大缩短编码和测试的周期，一般来说要在没有单元测试的情况下，要完全写完一个对前端的接口才能进行测试，周期太长，而且随着新代码不断增加就会将原本可能有bug的地方掩饰起来，bug拖得越后就越难找到。写单元测试，写完就能测。
写测试用例(主要是单元测试)，是我上一个项目组就开始尝试的。在此之前都没有尝试过，带来的效果也是很明显。凡是进行了单元测试的功能模块，测试测出的bug数量都有很大程度的减少。很多bug在单元测试的时候就原形毕露了，而不是推到功能完全写完的自测阶段或者是测试同学的测试阶段甚至是功能已经上线。我目前所在的项目其实进行单元测试的基础模块还是比较完善的，起码有模拟调用、模拟登录这些模块，进行部分集成测试都比较轻松。

拿到需求不着急写，充分理解清楚透彻、问清策划再写
除去数据统计之外的功能，我基本上都会很仔细地策划案。其中不明白或者觉得不合理的都会批注出来，然后面对面地问策划，一条一条的过。基本上没有出现和策划有理解冲突的地方。作为反例数据统计这一功能就没有做到这一点。由于时间过于紧迫，我在不太清楚的情况下就开始了代码的编写，后果就是70%的细节部分理解都有偏差(还好都是同样的原因，改起来容易)。磨刀不误砍柴工，写代码其实就是建模，只有模型清楚写出来的代码才会清楚少bug。

随时重构代码，保证代码整洁：
这一点我只敢在自己那些有单元测试的代码上尝试。但是效果还不错，代码能越来越清晰。

在空闲的时间思考难以实现的功能
把比较难的问题放到空闲的时候思考是我以前刷LeetCode的习惯，后来在工作上也延续了下来。对于模型比较复杂的或比较重要的功能，我一般都要思考很久。思考的时间和地点都是不固定的，业余时间我比较喜欢在搭公交、睡觉和洗澡的时候去想。在脑子里面把模型一遍又一遍的构建，思考它的可行性、思考还有没有其他更好的方式。收到的效果也是明显，很多功能都是我在这种情况下构思出来的。这个很难在公司再现，可能是看起来比较傻吧。