微软Zune闰年bug 分析

 阅读约 2 分钟

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

        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,三个边界值在数轴上划片,然后取值。然后再和年份进行组合,就可以得到需要的测试用例。

一起来~FunTester

阅读 236发布于 2019-08-02

推荐阅读
目录