软件测试的案例分析 - 闰年4.1

文章目的

显示不同的博客能获得多少博客质量分
（这是关于博客质量分的测试 https://www.csdn.net/qc) 这个博客得了 60 分。 希望获得 70 分左右

正文

我们谈了不少测试的名词, 软件是人写的, 测试计划和测试用例也是人写的, 人总会犯错误。错误发生之后, 总有人问: 为什么这个bug 没有测出来啊?! 我们看看一类简单的bug是如何发生的，以及如何预防它们再度发生:

闰年

软件少不了和日期打交道, 日历系统算是人类的一个遗留系统 （legacy system）, 这个系统在逐步进化的过程中, 打了好多补丁, 闰年就是补丁之一。

关于闰年，现在的 规格说明书 （spec） 是:

年份被 4 整除的，就是闰年, 但是被 100 整除的年份不闰，被 400 整除的年份又是闰年。

但是，人们在写软件的时候，还是犯了不少错误。

错误之一

算不清某一年是不是闰年。

怎么避免这些错误呢？有两个办法：

1. 认真分析问题，写出正确的算法
2. 通过完备的测试用例来保证算法的正确

但是人类总是匆匆忙忙，有时候就不免犯很多小错误。 下面是C# 的代码片段, 这段程序对么?

public static bool IsLeapYear(int year)
{
    System.Diagnostics.Debug.Assert(year >= 1900);
    if (year % 400 == 0)
        return true;
    if (year % 100 == 0)
        return false;
    if (year % 4 == 0)
        return true;
    return false;
}

我们要写什么样的测试用例来保证程序的正确性呢？

出错后怎么改正？

1900 年是闰年么? 根据我们上面提到的规格说明书，这不是一个闰年。 如果出现了错误，我们改还不行么？

但是，在全世界被广泛使用的电子表格软件 Excel 就有这样一个Bug，而且它并不改正：Excel 的日期计算功能认为1900年是一个闰年。

程序员为何不修改这个明显的bug 呢？ 请看我写的其他博客。
（这个博客是作为测试案例，测试博客质量分）