【经典BUG分享】【不止是一份技术贴】【体力发放】

本文主要是介绍【经典BUG分享】【不止是一份技术贴】【体力发放】，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

【经典BUG分享】【不止是一份技术贴】【体力发放】

体力发放的BUG

描述现象：游戏有个体力的概念，类似于神仙道的设定，就是每天中午12点和下午6点会发放40点体力，然后检查到部分账号没有发到体力
解决思路：是因为这些账号没有登录吗？验证之后发现，不是因为这些账号没有登录，在线的也没有获得体力，那么原因在哪里呢？
回服务端查看原代码，local interval12, interval18 = isPassHour(oldtime, nowtime, 12), isPassHour(oldtime, nowtime, 18)。这句话是这样的逻辑，就是它记录了两个时间，一个是oldtime，一个是nowtime。就是上一次领取体力的时间和，这一次现在的时间，中间有没有12点这个时间和18点这个时间，如果有的话，就给他发体力。

而这个逻辑确实不应该这样写，而缺少的逻辑覆盖点应该是oldtime可不可信，是否定时轮询事件没有触发这种问题。

解决办法：

更换了一个逻辑，nowtime大于12点，并且当天没有领过，就给他发，当出现跨天的情况时，处理跨天的情况。这样的逻辑减少了不可信的因素，相对来说安全性会更高。验证后确实是正确的，第二天的体力发放也正常了。

验证方法：

比如这里分成两个层次来考虑：
1、oldTime和newTime的设置点前后的数据正确性。
2、直接调用接口，手动设置oldTime和newTime，验证这个逻辑的正确性

延伸拓展：

一般来说，服务器的架构有通用的处理每天，每周的timer。很多游戏都是这样做的，这块做成通用的逻辑，timer中的变量是每天自动reset的。

做系统的程序不需要关心这个，只需要保证这个变量是一个每日的timer类型就可以了

而登陆模块会做这种事情，登陆的时候判断是不是跨天，如果跨天，处理timer。

对于一个调用，无外乎是参数正确和函数正确两个层面。比如回档类的问题，那么测试思维的突破就是测试的验证点不应该是单纯的游戏中看到的数值，而是这个东西已经被写到数据库了。而如何验证这个东西被写到数据库了？这是测试手段和测试方法

其次，我们应该想想，游戏内有没有什么其他东西是每日清除的呢？如果有，那么必然有模块来处理这样的类型。那么完全可以用两个变量来标记12点已经领取和18点已经领取，而这两个变量是每天会清的，这样逻辑就简单了。

这篇关于【经典BUG分享】【不止是一份技术贴】【体力发放】的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---