04.5~04.10
我的第一家公司：FS。
程序员。
写过php，html，jsp，java，as1，开始接触linux。
使用的语言很杂，而每种语言使用的时间都很短，好处是我在后面接触python、ruby等脚本语言时上手非常快，坏处是养成了我做什么都不求深入的坏习惯。

04.11~05.1
程序员。
用j2me写了个手机上的游戏小demo，可以通讯，走地图，完成简单的任务，聊天。基本上是自己摸索出来的，可惜没有继续写下去了。后来我总觉得，如果那时继续写了，没准我也可以做好程序员的。但测试行业就失去了一个好测试了
这段时间还兼职给GT管理层会议做会议记录，开始知道大佬们想些什么，开始知道部门之间的沟通、配合，当然还有扯皮。
有一件事情给我的触动很大：GT的副总看到会议室桌子脏了，亲自找了块抹布很仔细的把桌子擦干净了。我明白了什么叫做责任心。

05.2~05.9
程序员。
用php做了一个网站。
需求是boss直接提的，做出来效果boss看到后直接给意见改。很荣幸的得到了直接跟boss交流的机会，也通过这个机会，开始模糊的有点产品意识了。

05.10~06.10
小游戏测试。
正因为跟boss直接交流了，所以被boss赶出程序员的队伍来做测试了。这是我职业生涯重要的转折点。
一年的时间，我不仅掌握了测试流程、测试方法、测试工具，还学会了怎么跟团队中其他人配合把事情做好。
我接触到了非常优秀的程序员，跟他们学到了很多工作方法和思想，学会了用python写脚本来让工作自动化，也就是学会偷懒。
后来想起，我一直坚信是因为在做测试之前知道了什么叫责任，知道了什么叫产品。所以我才会那么努力认真的想要把工作做到完美、极致。
与此同时，我遇到了我职业生涯中第一个瓶颈——我自己知道怎样能把测试做好，但我不知道怎么让别人也具备把测试做好的能力，我自己在测试技术方面的能力似乎也到头了，不知可以往哪里走。

06.11~08.2
游戏社区测试。
公司策略问题，之前项目组撤销，我们开始开发一个类似虚拟人生的社区。
这段时间整组人状态都很低落。我开始在网上疯狂的看测试资料，试图找到一个方法——任何人，只要掌握了这个方法，就可以把测试做的跟我一样好，甚至比我更好。
后来我看到了一篇东西，作者认为测试人员在技术方面发展，还是要做一个能写C/C++的程序员。
我决定尝试一下。

08.3~10.4
我的第二家公司：8d。
测试经理。
做测试时团队里的一个程序员创业，带上了我。
产品用scrum，敏捷开发模式。这种模式需要团队里大部分人可以互相替代工作。
于是我决定尝试一下，做一个会写代码的测试，以方便做自动化、性能方面的测试。开始研究公司程序员写的代码，开始尝试自己动手甚至修改……不会的就缠着公司的程序员提问，可是一段时间下来，收效甚微。
我问自己：我真的要学会写代码吗？除了浪费别人的精力，我能得到什么？我能学会吗？
在想通了一件事以后，我很可耻的放弃了：写代码这件事，我需要花费比别人多的精力还做的比别人差。但做测试，分析测试点，分析框架合理性方面，我能做的比别人好很多，快很多。所以，我可以只设计测试需求，让会写代码的人帮我实现。
几乎与此同时，我得到了另外两个启发：
1、人和人是有差距的，能力、悟性、观念都是有差距的，要承认人能力的差距，所以根本不可能存在一种方法，可以让人掌握了之后可以无差别的工作。那么在用人的时候，一方面安排适合他能力和特长的工作给他，另一方面也要想办法培养提高他的能力和意识。
2、不必强求高大全，适合就好。这个感悟是来自于服务器安全性方面。我们用服务器时，由于出于安全方面的考虑，禁止使用root权限，而是给一个刚刚好的权限。我们在做项目，做产品，做测试，做什么都好，要兼顾质量、效率、成本多方面的考虑，找出一个适合我们的工作方法和流程。而对个人的职业规划也是如此，找到一条适合自己的路，没有人能把所有的事情都做的很好。
至此，之前遇到的瓶颈就算是突破了。

09年6月底，由于关键人物的离职，我需要兼顾美术部门的工作计划、安排和进度跟踪。同时打理两个部门。这段时间总结了一套关于外行的进度跟踪的方法，协调解决了几个产品上遗留的美术问题，并且还促进了一些美术部内部的培训、交流活动。
由于同时打理两个部门，对一些跨部门沟通的问题有了更深入的体会。也可以站在更高、更广的层面上看问题。
举个例子来说吧。当时的产品有一个美术效果很差的问题，美术提出的解决方案是要做高模，但程序质疑做高模会影响服务器计算性能，直接增加运营成本。于是这个问题一直丢在那里无人理会。我接手美术部工作进度跟进以后，就趁着美术主管有空，让他做了一个高模出来给我进行性能测试，测试结果出来，我吓了一跳：对服务器性能的影响远远小于我们以前的感觉，几乎可以视为没有影响。于是，高模版本顺利出炉。
看我把两个部门的事务都打理的不错，还促进了一些改进，老板对我表示很满意。
这时看到了一篇文章：java程序员的那些事儿。整篇看下来，我把其中的三句话刻在了心里：
1、把技术练到像吃饭走路一样熟练，像呼吸一样顺其自然。
2、适合的才是最好的，最厉害的技术都来自最基础的知识。
3、产品，产品，还是产品，只有产品。

10.5~至今
我的第三家公司：9y。
网页游戏测试组长。
不得不说，这是一个很舒服的职位，有责任，自有老大扛，有苦活累活，自有小弟担。
由于习惯了从产品和项目层面看问题，所以我挺好管闲事的，现在也开始收敛，因为明白，别人也有别人的无奈，他们更需要的是帮助，而不是责难。
所以我偶尔也教一下别的部门的人使用一些方便工作的小工具，甚至私底下做一些小工具给他们用。
我目前的工作重心，除了负责一个项目的各方面测试工作以外，就是招人，带人，培养人。
我之前说过，人，才是最重要的，把人的能力培养起来，才能真正把事情做好，光靠流程规范，是靠不住的。
但我在这方面的能力，还在积累经验中吧。
想把以下几个事情做好：
1、找到适合做测试的人；让自己拥有迅速分辨人的能力。
2、培养一群人能把测试做好；让自己拥有把人培养好的能力。
3、让更多的人拥有责任心和产品意识，让更多的人拥有振兴测试行业的能力和愿景。

任重而道远。好在我不强求。

经过yzzt三个多月的测试工作，其中在外网体验服也放了几个版本，发现大家在测试工作中碰到了一些问题。在不同的阶段，处理问题的方法是不太一样的，因为事情的轻重缓急会起变化。而我们的工作中应该有一个很重要的部分是给事情排优先级。

 

1、  QA文档阶段

最重要的是风险预估

Ø  思考玩法是否足够吸引，与整个游戏的联系是否紧密，能否很好的配合游戏主题

Ø  关注潜在的逻辑冲突和漏洞，功能本身的，和其它功能交叉的

Ø  思考有没有更好的实现方式，用更少的精力更小的风险达到同样的甚至更好的效果

Ø  尽多尽早的考虑版本、流程、产品中可能出现的问题

 

2、  开发阶段

最重要的是全盘了解版本状况

Ø  尽快拿到可测试版本，导致测试进行不下去的bug要追着程序修

Ø  尽快的跑通流程，导致流程跑不通的bug要催程序处理

Ø  不要让程序闲下来，尽可能快和多的发现问题，加bug

Ø  思考玩法是否达到了预期的目的，进一步发现产品设计上的问题

Ø  拿不准的问题跟策划沟通或在测试内部沟通，影响大的问题可以发到产品群

Ø  如果遇到细节问题想省事，可以直接加bug给策划，让策划回复确认

 

3、bugfix阶段

最重要的是让版本尽快稳定下来，可以体验

Ø  适当的调高影响体验的bug的优先级

Ø  有些严重但不影响体验的bug可以适当的调低优先级，延后解决

Ø  允许留下一些不影响体验的问题，尽早出版本让策划体验

Ø  对于盟战这种策划难以体验的功能，可以邀请策划来测试服一起体验

 

4、发布阶段

最重要的是发布，学会判断，学会放弃

Ø  确定发布时间后，要评估哪些bug必须修，哪些bug可以修，哪些bug不用理

Ø  在接近发布时间时发现的bug，能不处理的问题就不处理，以免引发更多更严重的问题

Ø  在接近发布时间时发现影响发布的bug，不必再走bug流程，直接提出让程序修，同时要发到测试群里，让其他人了解情况

Ø  接近发布时间的定义，一般是一天左右

Ø  严格把握发布流程，不能出任何纰漏

Ø  打包和上线的版本确认，关键是确认这个版本是不是我们确认可以发布的版本（例如看最后修复的bug还在不在，在关键流程上跑一跑，看有没有发布环境引起的问题）

 

5、空闲时间安排

最重要的是提升自己

Ø  关注细节，提高品质

Ø  对游戏的理解

Ø  对测试的理解（技术、管理、流程）

Ø  对游戏测试的理解

Ø  多思考，多总结，多交流

 

6、其它

Ø  如果是各个阶段交融怎么办？例如一个版本要发布，另一个版本提交测试。

--这种时候比较少，一般由主管特殊说明，大家不用过分担心。

Ø  在何时需要妥协，在何时需要寻求帮助？

--随机应变，多站在用户角度考虑，多站在产品品质角度考虑，但要兼顾我们的实际情况和时间压力。

Ø  策划和程序商量的修改不通知测试怎么办？

--一方面需要大家自己更主动的去了解，另一方面，在新的流程下再出现这种事情，向测试主管投诉。

 

1、判断数据在客户端、服务端缓存、数据库的方法

Ø  客户端操作后的显示----客户端

Ø  客户端操作后，重新登录后的显示----服务端缓存

Ø  客户端操作后，清缓存再重新登录的显示----数据库或内存

Ø  修改数据库后，必须要清缓存，数据库的数据才能生效

Ø  如果要进行外挂测试，则修改数据库后清缓存，但不重新登录客户端

2、区别客户端、服务端bug的方法

Ø  所有显示、操作、弹框等都是由客户端处理的

Ø  涉及到逻辑、数据的问题，则要检查服务端缓存和数据库/内存是否正确：

²  如果正确，表示是客户端的问题

²  如果不正确，也不能完全肯定不是客户端的问题，碰到这种情况bug指给服务端

Ø  遇到测试环境的bug，程序在自己的环境不能重现的，优先检查策划表是否正确

3、测试数值的方法

Ø  自己做表格方便计算数值

Ø  自己修改xml文件中的数值、公式

4、测试表格的方法

Ø  理解表格中每个字段的意思和在程序实现中的用法

Ø  分类分批检查，如技能表可以分成：主动技能/被动技能、人物技能/召唤兽技能

Ø  逻辑上明显的漏洞

Ø  错别字、语法错误

Ø  一些隐性的问题可以到游戏中测试

5、功能实现不全的测试方法

Ø  可以测到的功能先测，测不到的功能后测

Ø  通过构造数据的方法来绕过某些没实现的功能

²  加各种礼包

²  设置召唤兽的各种技能

²  帮敌人复活

²  把召唤兽技能放到怪物上测试

Ø  修改程序代码，绕过没实现或实现有问题的功能

6、服务端实现了，客户端没实现的测试方法

Ø  断点+单步

Ø  看log

7、做的好的地方

Ø  做一些实用的小工具

Ø  做存储过程

Ø  项目内工作交流、互相帮助

8、做的不足的地方

Ø  测试用例覆盖率（我自己写的战斗系统测试用例不好用）

Ø  比较被动

Ø  和程序、策划的交流没有在测试内部分享

Ø  测试经验和心得分享

Ø  Bug定位（寻找bug重现条件）、Bug描述

Ø  对程序的架构和思路不够了解

9、其它部门配合不足的地方

Ø  策划表数据不全，导致没有真实数据测试，只能自己构造

Ø  策划更新表不通知，或没有通知到所有相关人员

Ø  策划导表后不及时帮我们同步

Ø  策划提交表的修改后，程序没提交相应修改功能

Ø  程序提交sql不通知，不提供修改字段的sql，导致每次修改都要清库

Ø  程序功能实现不全，且很零散，又不及时修bug，导致测试很难全面系统的进行

 

    上篇日志抱怨了一下合服的事情，今天是第一次合服，果然又出大事了，于是想把合服发生的问题都记录一下。

1、sql执行速度的纠结
    由于运营商需要保留的数据太多，所以程序代码只解决一个用户名对应多个角色名的情况，可以挑选其中一个角色登录。而大部分的数据清理和合并，都用sql来实现。
    为了真实的创建测试环境，运维帮我们从外网拉了两个服的数据回来做测试用。拿程序的sql一跑……
    刚开始用navicat跑，跑了几次，navicat就死了几次。咨询了一下程序，说这种过大的数据量不能用这种工具跑，最好到数据库所在的服务器上用命令行跑。
    听了程序的话，试了一下命令行，2个小时过去了，sql还在执行中……
    我一边等，一边写了个命令行脚本，加上记录时间的log，同时向程序抗议：sql执行时间太久了，恢复一次库得大半天（后来确认要4~6个小时）。
    老大问我，能不能先用少量数据测功能，然后再用真实数据跑sql。我答：能。但是代码的功能修改非常的少，绝大多数的问题还是要用真实数据来做。
    于是问题分两头解决，一方面程序优化sql，一方面运维帮我们调优数据库。折腾一轮后，终于一次恢复数据+清理合并数据控制在40分钟左右。
    为了防止意外，我们用两台服务器，一台进行测试，另一台就赶紧重新构造数据。另外还有另一个项目的一台服务器给我们备用。

2、角色名的纠结
    由于我们的游戏是一个用户在一个服只能存在一个角色的，那么在合服的时候，不可避免的要面对角色名冲突的问题。
    （1）第一个方案：根据服号给每个角色名加上后缀作为区分，第一次改名免费。
    问题来了，原本客户端显示只为8个字符做的UI，现在一下子扩展到11甚至12位，界面全乱了……
    本来叫客户端做兼容，客户端认为工作量太大，于是有了
    （2）第二个方案：角色名保留，重名的玩家，第一个登录的可以顺利进入游戏，之后登录的玩家发现有重名玩家时，在登录时强制提示改名，不改名不给登录。
    问题又来了，我们的游戏加好友、发信函都是根据playername来判断的，当playername有重复的时候，由于程序提取的数据不止一条，会提示：找不到该玩家。
    这时，大家提出了
    （3）第二个方案补充版：a.当重名的玩家都登录过之后，因为已经强制改名，所以就不存在重名的情况了；b.当重名的玩家只有一个登录过，则默认选择已登录过的玩家；c.当重名的玩家都没有登录过，则默认选择同服的玩家。
    这里要介绍一下背景，所有合服都是两两进行，如果需要多个服合在一起，也是先两两合，然后再次合。
    所以这里碰到的问题就是，当多次合服又该怎么处理呢？
    （4）第三个方案（最终方案）：根据服号给每个角色名加上前缀（注意第一个版本是后缀）作为区分，超出显示8个字符的，则仅仅在客户端显示时从后面截断。玩家登录时，系统自动截掉前缀，如果截掉前缀后发现系统内有重名，则在登录时提示强制改名。

3、国家系统引发的纠结
    国家系统合并时，需要将涉及到的资金相加，相关科技等级取最高级。但是，由于科技是资金槽和时间槽轮流出现的，所以这里逻辑有点复杂。我感觉比较难测到所有情况，于是就去看了一下sql。
    一看之下，果然发现程序实现的有问题。于是跟程序讨论，修改，再设置测试数据进行测试。
    国家系统本身并不纠结，可是，通过国家科技的处理，我越想越不放心，于是把sql从头到尾，对照着数据库所有的表结构（由于我是新加入这个团队，对前期一些事情并不了解，所以实际上是全盘了解了一次游戏），重新检查了一次，结果真的发现了很多问题……
    惊出我一身冷汗。
    但，这还不是问题的全部。

4、清理用户数据的纠结
    本来运营商说一条用户数据都不能删的，后来做了让步，可以删掉一些很久很久没上过线的小号。
    于是，要清理所有的相关数据。
    可是公司另一个新项目上马，程序都调过去做新项目了，处理旧项目的程序员就很心不在焉。
    简单讲一下过程吧：
    千万级别的数据，执行程序提交的sql，报错。
    打开命令行，将sql里面的内容一条一条的复制粘贴执行，报错一共二十多次，每次都要帮程序找到问题，告诉程序怎么修改（否则他们就做新项目去了，我就得干等着）。
    等报错问题都解决了，重新恢复库，然后执行sql，开服……
    当然又是一堆bug等待解决。

5、新手礼包的纠结
    原本的设定是：所有相关礼包全部清掉，当开新服处理。这样带来的问题是，比如一个30级礼包，你已经50级了，在合服之前已经领过了，到合服里又可以再领一次。
    运营商对这个设定表示不满，经过若干次交涉以后，改成：已经领过的，到新服就不能再领了。
    于是，又加了一堆sql，又测试了一次，又耽误了一些时间，最杯具的是，这个时候，发现了下面这个最大的问题——

6、交易市场的纠结
    原本在第一次测合服的时候，已经发现了一点端倪，处理完合服数据后开服，交易市场会出现一些没图片的道具和装备，经过检查，发现是因为交易市场有数据，可是关联的userItem和userEquip没有相应的道具和装备。
    我自作聪明的问程序是不是因为导交易市场表时东西还在，导到道具装备表时，东西成交了，于是不见了。程序回答：有这种可能。于是就没太在意这个事情。

    到新手礼包那次测试，又有人提出交易市场的问题。
    由于需要一个合服前的库做对照着看是不是已经领过的礼包都不能领了，于是我就顺便让人看一下两边的交易市场的区别，结果发现：其实合服里不见的那些东西，在原来的库里是存在的，那也就是说，绝对不是我之前推测的那个问题。

    我找到一台服务器，把sql一条一条的执行，看到底哪里出了问题。经过近3小时的查验，原来，为了防止合服前两个服同表的id冲突，将id重构了，可是，交易市场里面的商品，是关联到userItem表和userEquip表的，id重构后，商品找不到了……
    解决方案当然不能直接保留id，因为都是从1开始自增的，所以合数据时一定会有冲突。
    最好的解决方法当然是不保留交易市场数据。可是到了这个时候，合服方案已经被运营商公布在官网了，要改已经是不可能了。于是，程序、测试、策划三部门一起讨论出一个方案：根据服号给id加上一个很大的数字，用来避免冲突。查到所有数据最大的是上千万，于是这个数字基础值被定为一亿，也就是说，1服的id全部加上1亿，2服的加上2亿，以此类推。
    当然，这里会有一个问题，当不同运营商合服时，还是可能会有冲突，不过那种情况真的发生的时候，肯定也还要走一个很长的流程，那就到时候再说吧。

    改sql，测试，有个tester发现道具批量出售时服务端有一个报错，问了程序，说是因为那个加了过亿的数字超出了integer类型的最大值，所以改成number类型就行了。修改，提交，测试，通过。
    事情很顺利。
    谁也没想到，这里的疏忽为后来的问题埋下了隐患。

    杯具的26号到了。
    运维合好数据，起服，进去做新手任务，发现穿戴装备时提示：用户装备不存在！
    老大小小声问我，是不是在内网时漏测新手任务这一块，我明明记得叫人测过的。赶紧回到内网，重新布置好环境，做新手任务，没事……
    之前提到的那个程序员说，可能就是因为整形类型的问题，服务端发出来后，客户端用int接，超出的长度被截断了，所以找不到那个装备。莫大的杯具！
    查了一下，int型的上限是21亿+，而我们这次合服的服号是29和30，也就是最大id为30亿+！
    在内网把自增的基础值改到30亿，果然，重现了这个bug！
    紧急解决方案如下：
    第一步：运维重新恢复数据，当作1服和2服来合数据，让游戏不会出问题。
    第二步：客户端一周内修复这个问题（把相关的int改成long），在内网测试通过。
    第三步：下周的例行维护中，把修复bug的客户端放出去，同时把用户道具、用户装备、交易市场三个表的id加上28亿。

    本来以为事情结束了。可是没想到，27号，外网有玩家报装备开印封印有问题。
    在内网查了一下，发现又是服务端的问题，上个bug只是把其中的一个integer改成了number，实际上还有N多地方要改。

    不知接下来还会又出什么事呢？