软件测试的案例分析

文章目的

显示不同的博客能获得多少博客质量分
（这是关于博客质量分的测试 https://www.csdn.net/qc) 这个博客得了 83 分。怎么才能得到更多分数？

正文

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

闰年

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

关于闰年，现在的 规格说明书 （spec）非常简单:

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

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

错误之一

下面是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 年是闰年么? 根据我们上面说的规格说明书，这不是一个闰年。
如果你要写这个程序的单元测试, 你会列出多少个测试用例? 你们保证所有代码路径都被覆盖么?

要写测试用例, 一个暴力的做法是穷举所有例子, 但是这有问题 – 你穷举不完
即使穷举了很多例子, 但是它们未必能帮助发现 独特 的问题. 例如你可以测试输入为 100, 101, 102, 103, 104, … 但是你仍然不知道新加的一个测试数字 105 是否测试了 以前没有测试过的情况，也就是说， 105 这个测试数据，可能和 100，101 这些数字都是等价的。但是独特的测试数据，可能还有很多。

这里我们要引入 等价类 (Equivalence) 这一概念。一个粗浅的做法是:

如果一个函数可以返回 true | false, 你至少得有两类测试集合, 让它分别返回 true | false

如果你知道这个函数工作的原理, 或者了解程序要反映的现实世界, 你可以举出更详细的等价类, 例如针对 IsLeapYear():

被 400 整除的年份
被 100 整除, 但是不被400 整除的年份
被 100 整除, 同时被400 整除的年份
被 4 整除, 但是不被100 整除的年份
被 4 整除, 同时被100 整除的年份
偶数, 不被4 整除的年份
奇数年份
其它非法输入的年份

但是，在全世界被广泛使用的电子表格软件 Excel 就有这样一个Bug：Excel 的日期计算功能认为1900年是一个闰年。
故事是这样的，在 PC 萌芽的 1980 年代, 这类电子表格软件的市场领头羊是Lotus 1-2-3这一款软件：

来源: http://en.wikipedia.org/wiki/Lotus_1-2-3
Lotus 1-2-3 占据了大部分市场份额，这类软件在内部把日期保存为 “从1900/1/1 到当前日期的天数” 这样的一个整数。不过，它的日期计算功能有一个小Bug，就是把1900 年当作闰年。这样，内部保存的 “天数” 就是多算了 1900 年并不存在的 2/29 号。 Excel 作为后来者，要支持 Lotus 1-2-3 的数据文件格式，这样才能正确处理别的软件产生的格式文件，Excel 只好也这么照做。这个错误就这么延续下来了，每一版本都有人报告，但是都没有改正。我们可以在Excel 中试试看：

在任意格子（cell）中输入“=DATE(1900,2,28)”，并且定义这个格子的格式为数字。大家可以看到数值变为：59。表明1900/2/28 是1900/1/1开始的第59天。

输入“=DATE(1900,2,29)”，可以看到 60! 这是一个不存在的日期！

输入“=DATE(1900,3,1)”，数值是61，事实上，这应该是60。从这一天开始的所有日期都错了一天。

改正这个bug，技术上一点问题都没有。

改好了，我们更新 Excel 的版本，发布吧！但是在现实中会出现下列问题：

（1）几乎所有现存文件的日期数据都要减少一天，所有依赖于日期的 Excel公式也要做检查和修改。可以想象在计算利率，判断日期是否相等这些问题上都会出现细小而不能忽视的问题。这在现实生活会造成很大的麻烦。

（2）Excel的日期问题解决了，但是其他软件还是有这个Bug，数据文件在不同软件中使用，就会有很头痛的兼容性问题。

错误之二: 计算错误

一个应用程序从另一个模块中接到一个数值, 是当天距离 [1980/1/1] 的天数, 现在要求这个程序返回今天的年份。下面的程序怎么样? 有bug 么?

public static int NumberToYear(int days)
{int year = 1980; /* start with 1980 */System.Diagnostics.Debug.Assert(days >= 0);while (days > 365){if (IsLeapYear(year)){if (days > 366){days -= 366;year ++;}}else{days -= 365;year ++;}}return year;
}

程序员都知道程序经常在边界条件附近出错, 针对IsLeapYear(), 你还可以得出下面两个测试用例:

设计允许的最小的年份
设计允许的最大的年份

啊, 设计中没有考虑这个? 那这个设计要出现问题。在1950-70 年代, 很多程序用两位数字表示年份 (00 – 99), 那些聪明的程序员认为这已经足够了, 没想到这些程序和设计影响了很多要和它们兼容的程序 (就像 Excel 要兼容 Lotus 1-2-3 那样), 到了1990年代后期, IT 业花了很多人力物力来解决 Y2K 的千年虫问题。一些程序员非常钟爱的 UNIX 操作系统 (32 位) 也有自己的千年虫问题, 它会发生在 2038 年! 到时候人们还会用32位的机器么? 也许在一个大家想不到的关键部位, 一些老旧的, 嵌入式的 Unix 系统会悄悄地发作…

除了从外部的输入/输出来设计测试用例, 我们也可以从内部考虑, 看看这些测试用例是否把所有语句都覆盖了。但是要注意, 即使所有语句都被测试用例覆盖了, 程序还是可能出错!

例如, 我们测试 NumberToYear() 这个函数，分析它的各个条件, 我们推算出我们的数据要覆盖下面一些情况:

输入的 day 大于 365
输入的 day 小于 365
输入的 day 大于 366 并且1980 年到那一年中, 至少有一年是闰年, 例如输入一个2008年的某一天。
输入的 day 大于 366 并且1980 年到那一年中不包括闰年。

这样是不是就把所有路径都包括了? 程序就没有错了?

不巧的是, 这个程序用在了某著名公司的产品上, 出品的前两年没什么事, 到了2008 年的最后一天 (那一年有366 天), 出了一个问题:

正如下面的代码显示的，年份一直增加到了 2008, 这时候, day == 366, 我们看看循环能做下去么?

if (IsLeapYear(year))
{if (days > 366)   //day == 366, 不满足条件 {days -= 366;year ++;}
}

所以 day 没有减少, year 也没有增加, 循环又继续下去, 任何条件都没有改变, 进入了死循环!

不幸的是, 这个程序经过了种种测试, 进入了市场. 于是, 在2008 年的最后一天, 许多用户发现他们的 Zune Player (只限于 Zune 30 型号) 开机之后就进入死锁状态…

Microsoft says Zune players working again - USATODAY.com

http://www.zuneboards.com/forums/showthread.php?t=38143

官方的说法是 - 大家等到明天就好了! 不用说这对于用户, 对于产品的口碑, 对于这个代码的开发者, 测试者是一个极大的打击!

正确而简明的算法

也有程序员提出：

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

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

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

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

如果你是一个测试人员, 你应该增加什么测试用例呢? 如果用边界条件分析, 应该有至少 4 个新的测试用例:

闰年的第一天
闰年的最后一天
平年的第一天
平年的最后一天

错误之三: 没想到还有闰年

在IT 行业混了很多年的好处之一就是你可以看到不少 bug. 下面又来了一个:

Windows Home Server 与客户端的程序 connector 第一次连接时，需要 Server 为 connector 颁发安全证书。出于某种实现上无法避免的原因，客户端的证书日期一定要早于Windows Home Server 发布的日期，否则生成证书的函数会失败。Windows Home Server 是 2007年7月发布的。为了方便起见，设计中规定，给客户端生成证书的函数使用 2006 年作为年份。

作为一个程序员, 你如何实现这个设计呢? 一拍脑袋, 就取当天的日期, 然后把日期中的年字段改成 2006, 不就行了么?

然后到了 2008/2/29 这一天… 程序自动把日期改成了 2006/2/29，然后就悲剧了.

软件团队在自问: 为啥我们当初没测出来? 如果你是测试人员, 你会想到这个测试用例么?

错误之四: 闰年bug 一天损失 30 万

上面的错误都是外国软件公司搞的, 我们看看中国的软件 (还是嵌入式的软件) 也不甘落后, 也创出了自己的闰年bug:

广州出租车计价器无法识别闰年损失约30万(图)-搜狐新闻

参考阅读

测试用例的等价类划分和边界条件分析:
http://en.wikipedia.org/wiki/Equivalence_partitioning

http://en.wikipedia.org/wiki/Boundary_value_analysis