软件测试的案例分析 - 闰年4.2 (加投票）

这篇博客的目录

• 文章目的

文章目的

显示不同的博客能获得多少博客质量分
（这是关于博客质量分的测试 https://www.csdn.net/qc) 这个博客得了 60 分。 希望在新的质量分系统中，获得 80 - 90 分左右

正文

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

闰年

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

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

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

错误之一

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

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

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年是一个闰年。

正确而简明的算法

输入：1980/1/1 到今天的天数。
返回：今天是哪一年（要考虑闰年的情况）

@bnu_chenshuo: 文中的函数可用一句话搞定

int NumberToYear(int days)
{       
    return 1980 + 100 * days / 36525;
}

我们看到，这段程序用了 36525 这个魔术数字，这个数字是怎么来的？因为近代科学测量的结果是：地球绕太阳转一圈，准确值是365天小5时48分46秒。如果用天为单位，就是 365.242199 天。

大家觉得这个函数有没有什么 bug？ 在今后的 100 年都可以使用么？这个函数有多少条件分支，我们要如何去做分支测试，如何考察整个函数的覆盖率？

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