游戏引擎服务端应该也要具备测试模块
Table of Contents
1 游戏引擎服务端应该也要具备测试模块
1.1 经历
公司做网页游戏5年之久，今年公司在向手游方面扩展。公司在开发过程中，主程决定游戏模块的开发时间，一般星期一布置下任务，星期四做完，星期五测试员测试通过，按照这样，程序员也就不用去加班了。其实在模块的实现过程中，往往前端的设计会经常变更。当要变更服务端的时候，往往是游戏规则有所变化，代码改动少，同时客户端可能也要随之发生变化。而客户端比较注重细节，为了迎合玩家，往往UI以及控件的表现都要经常发生变化。当服务端完成时，往往客户端还在忙于贴图修饰等等。服务端程序员就等着，客户端直到星期四的才做完，于是乎服务端和客户端开始调试，突然服务端跳出一些bug，每发现bug都要停止服务端，修改代码，重新编译，在重新测试，要是所编写的代码比较底层，编译要等很长时间（服务端用的是C++），这样反复（所谓的联调），是很纠结的。有人可能提议，程序员就不能用自己脑袋来查看代码，把问题尽量减少。这样做能够检查一些肉眼所能够察觉的代码；但是我觉得解决bug的效率不够好，需得让程序运行起来，查看其运行的计算返回的数据，才能肃清大量的bug；而这样是需要有客户端的消息进行触发的。
1.2 感想
我的解决方案是模拟客户端的消息，来解决这些问题。一般游戏服务端的行为由三种方式来触发：a.自身的异步事件（也就是到了某个时间点，会自动触发）；b.自身的同步事件（也就是当发生了某件事情，会顺带立即触发其他的事情）；c.来自客户端的消息。a和b是服务端所自带的，已经具备。所要设计的主要是客户端消息的模拟。客户端的消息我们可以让服务端给自身发送数据来实现，这时候触发器和服务端共用同一格式的数据消息。我们还可以通过配置文件来设置事件触发的频率，服务端程序员只需要写少量的测试驱动程序就OK了。同时这样子也可以测试模块在极限的情况下服务端承受能力（我经常碰到一些bug只有在快速点击鼠标的时候才会出现）。
我只是把我的方案进行分享而已，同时我又见到公司服务端的框架设计不够好，而且底层的代码是dll库的，对普通员工隐藏。所以一些有点想法的员工要在代码基础上进行优化，是比较困难的; 更何况，别说扩展了。大系统，牵一发而动全身。