前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >微软Zune闰年BUG分析

微软Zune闰年BUG分析

作者头像
FunTester
发布2019-08-06 11:50:03
8720
发布2019-08-06 11:50:03
举报
文章被收录于专栏:FunTester

最近在网上看到一篇帖子,得知了当年微软zune 的历史留名的 bug,具体事件的起因发展和结果我就不多说了。找到了出现 bug 的源码,分享出来。

代码语言:javascript
复制
while (days > 365) {
      if (IsLeapYear(year)) {
        if (days > 366) {
          days -= 366;
          year += 1;
        }
      } else {
        days -= 365;
        year += 1;
      }
    }

这段代码是zune 内置的日期更新驱动里面的,作用是处理一下由于闰年引起的年份更新问题。结果非但没解决问题,还造出了一个历史留名的 bug。

方法的设计思路是这样的。当天数大于365时进入 while 循环,如果年份是闰年,则判断是否超过366,然后进行年份和天数的增减。非闰年情况直接进行年份和天数的增减。

程序员的想法完全没有问题,但在判断是闰年后,选择是否增减的条件却是有点异想天开了。因为在外层的 whlie 循环的days 的值是大于365,但是 while 循环的内部,处理的 days 值却是大于366。在当闰年 dsys=366的情况并没有处理,结果就导致了此次历史级的 bug 的产生。

虽然无法复盘 bug 是如何产生的,但却给测试提了个醒:越是基础的测试、越不能丢。因为这个 bug 的影响范围足够大,产生 bug 的代码足够简单,测试难度足够低,所以在历史上留名也不足为奇。

再次多说一些边界值。如果要测试这段代码,在设计用例时,考虑两个因素。一个年份一个天数。年份暂且考虑IsLeapYear()的 false 和 true两个值。天数考虑在边界值365、366、367,三个边界值在数轴上划片,然后取值。然后再和年份进行组合,就可以得到需要的测试用例。

点击阅读原文,有兴趣的童鞋可以一起交流

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-08-02,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 FunTester 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档