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

这篇博客的目录

  • 文章目的
    • 正文
    • 错误之一
    • 出错后怎么改正?
    • 正确而简明的算法

文章目的

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

正文

我们谈了不少测试的名词, 软件是人写的, 测试计划和测试用例也是人写的, 人总会犯错误。错误发生之后, 总有人问: 为什么这个 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年是一个闰年。

软件测试的案例分析 - 闰年4.2_第1张图片

正确而简明的算法

输入:1980/1/1 到今天的天数。
返回:今天是哪一年(要考虑闰年的情况)

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

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

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

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

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

你可能感兴趣的:(软件工程,单元测试,用户运营,c++)