游戏比较顺利公测初期记录

今天公司的D项目正式不限号测试，开了3组新服，每个服都达到了之前设定的人数，状态均良好。于是可以带着良好的心情，作为这半年的工作，可以适当的做个记录了。

我虽然才来了半年，D项目已经研发接近三年，但很幸运的是该项目框架是从头开始研发，并且比较密集的压力测试和问题等也都集中在这半年。不敢说获益许多，程序上的问题有多少记多少把。

首先从公测的推广手段说起。今天的公测跟以往不同，没有大规模的做广告，而是召集来了一个服务器上线人数的2-3倍人数，服务器组也准备2-3个。先确认好单点OK后，再进行大规模宣传。之所以这么做，我想说个案例。该公司之前的K项目，公测第一天就有10W人在线，结果压力问题、BUG问题，玩家急剧流失。即使把这些程序上的问题解决后，原本的玩家用户都已经成了脏用户。结果再也挽救不回来了。

其次是BUG,如我http://lin-style.iteye.com/blog/1208359 这篇帖子所说，普通的逻辑BUG尚可容忍，但是千万不要出现流程上的BUG.比如任务做不下去了，活动参加不了了等等这一类的。如果出现了刷钱、刷等级的问题，要能立刻从日志中找到玩家的行为，确定到问题发生点。

举个例子：游戏里面有些任务怪按正常流程下来会删除掉，但是总有不知道的意外发生，导致不删除，使其他玩家的流程无法进行下去。这时候首要之急是要加个定时的删除保护。虽然那个意外可能永远也找不到了。

然后是对性能的观测

1）网络带宽的利用。要搞清不同的业务占用了多少带宽。活动上的广播的占了多少，走路的占了多少，战斗占了多少。

2）CPU的利用。收发包占了多少，怪物逻辑占了多少，被玩家调用占了多少，跟脚本之间的交互占了多少，战斗计算占了多少

3）数据的存储。以前我一直对这块没怎么关注，但是发现实际上实现的方式会超出你的想象。这块的压力上倒不是特别大的问题，主要是在玩家数据存储正确性、回档上的问题。

4）完善的日志储备。如果可以的话，尽量做个日志服务器，有多少扔多少。这些日志都是你日后的救命福星。

最后再略提下压测

开机器人压测业务逻辑的问题不是主要要压的。主要是压网络带宽、登陆、下线保存、切服、广播等方面。

1）网络的话建议搭个模拟外网的环境，可以调节环境的丢包、抖动等等(软件名字我忘了，明天补上)。

2）下线保存和登陆，因为是机器人，所以你可以很变态的关、开、关、开。。。保准会发现很多问题。

3）广播主要是测试定点的扎堆情况，搭好机器人环境后，可以真人上去查看。

还有压测上的一些问题记录在这个帖子里：http://lin-style.iteye.com/blog/1268480