有关游戏性能测试的那些事儿

有关游戏性能测试的那些事儿 (2010-05-15 09:25:19)

转载▼

标签： 软件测试 软件 游戏测试 游戏 杂谈

最近被游戏的瓶颈问题，搞得胶头烂额，这里做一个备忘，供大家共同思考：

　　1. 不单游戏，在这个星球上的任何的软件开发，性能，性能分析和性能的优化都是提升性能的根本三步骤；

　　2. 黑盒发现瓶颈，白盒发现问题。性能测试，除了（黑盒）外， 在进度允许的情况下，还应当引入到和某些模块测试中（白盒），特别是复杂方法，必须在编码完成后进行性能测试， 这样保证了原子性的操作足够优化，才能保证整个系统的性能足够高；

　　3. 不管是一个系统，一个模块，还是一个类，运行次数和单次运行时间的卷积最小，都是性能优化的根本目标；

　　4. 并发数，响应时间，CPU负载，和内存使用率，是服务器端性能的主要指标；

　　5. 性能分析必须是主观分析和实际测试相结合，既不能让主观分析变成主观臆想，也要避免进行了错误的测试（方法）导致错误的结论；

　　6. 无论怎么玩，游戏压力测试的方式，也都是那么三种：机器人模拟；第3方性能测试工具模拟；封测，公测真实性测试；机器人模拟缺点在量大，优点是可模拟性强，第3方工具是否能高模拟游戏，还有待验证；真实测试最靠谱， 但费钱；

　　7. 玩家的上线，下线，掉线，由于涉及到多个服务器的联动（， 场景服，session），具备牵一发而动全身的特点，所以它们是最有可能造成服务器宕机的； 相对而言，纯粹的正常游戏状态，很难让服务器死掉（除了一些意外的数据操作）；

　　8. 根据以上一点，除了关键游戏操作（比如战斗和任务），压力测试的重点，也将是玩家的上线，下线以及掉线；

　　9. 在实测中我们发现，服务器端的性能瓶颈主要集中在以下位置：

　　　　a. 玩家登陆数据加载

　　　　b. 实体进入场景引起的数据同步，以及由此引起的可能的外围逻辑；

　　　　c. 战斗， 特别是战斗动作的执行和数据返回

　　10. 以下地方，最底层，调用运行次数最多，因而最容易影响性能，它们是否足够简单，单次运行时间是否足够低，对整体性能，有着最重要的影响：

　　　　a. 实体属性设置，特别是hp，mp的设置

　　　　b. log

　　　　c. 事件分发