微软Zune闰年bug 分析
发布网友
发布时间：2022-11-30 09:23
共1个回答
热心网友
时间：2023-11-03 12:32
这段代码是zune 内置的日期更新驱动里面的，作用是处理一下由于闰年引起的年份更新问题。结果非但没解决问题，还造出了一个 历史 留名的 bug。
方法的设计思路是这样的。当天数大于365时进入 while 循环，如果年份是闰年，则判断是否超过366，然后进行年份和天数的增减。非闰年情况直接进行年份和天数的增减。
程序员的想法完全没有问题，但在判断是闰年后，选择是否增减的条件却是有点异想天开了。因为在外层的 whlie 循环的days 的值是大于365，但是 while 循环的内部，处理的 days 值却是大于366。在当闰年 dsys=366的情况并没有处理，结果就导致了此次 历史 级的 bug 的产生。
虽然无法复盘 bug 是如何产生的，但却给测试提了个醒：越是基础的测试、越不能丢。因为这个 bug 的影响范围足够大，产生 bug 的代码足够简单，测试难度足够低，所以在 历史 上留名也不足为奇。
再次多说一些边界值。如果要测试这段代码，在设计用例时，考虑两个因素。一个年份一个天数。年份暂且考虑IsLeapYear()的 false 和 true两个值。天数考虑在边界值365、366、367，三个边界值在数轴上划片，然后取值。然后再和年份进行组合，就可以得到需要的测试用例。
