首页 > 代码库 > 现代软件工程 第十三章 练习与讨论

现代软件工程 第十三章 练习与讨论

13.5.2  有错不改

果冻: 微软的产品经过这么多版本的不断完善,应该是把所有问题都搞定,“止于至善”了吧?

阿超: 那也不一定,在非常有名的电子表格软件Excel中,就有这样一个Bug:Excel 的日期计算功能认为1900年是一个闰年,这是不对的,但是它愣是一直没有改正这个错误。

众人: 真的?为什么屡教不改呢?

阿超: 故事是这样的,当时这类电子表格软件的市场领头羊是Lotus 1-2-3这一款软件。它的日期计算功能有一个Bug,就是把1900年当作闰年。这类软件在内部把日期保存为“从1900/1/1到当前日期的天数”这样的一个整数。Excel作为后来者,要支持Lotus 1-2-3的数据文件格式,这样才能正确处理别的软件产生的格式文件。于是,这个Bug就这么延续下来了,每一版本都有人报告,但是都没有改正。我们可以在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。从这一天开始的所有日期都错了一天。

果冻: 还是可以抓住机遇,促成飞跃,在某一个版本彻底改好,不就是一个数字嘛。

阿超: 改这个问题,技术上一点问题都没有。但是在现实中会出现下列问题:

1)几乎所有现存文件的日期数据都要减少一天,所有依赖于日期的Excel公式也要做检查和修改。这在现实生活中是很难办到的。

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

总之,这个问题就这样一直留下来了。中间也有人想改过,你要注意看Excel的Options设置,就会发现有这样一个设置——使用1904年开始的日期计算系统(use 1904 date system)(如图13-9所示),但是一般的用户谁没事在这里打一个勾?

                       

图13-9 Excel的Options设置

计算机程序在处理闰年这个问题上出现过很多bug,请看相关的博客:
http://www.cnblogs.com/xinz/archive/2011/11/29/2267022.html

13.5.3  侵官之害甚于寒

昔者韩昭候醉而寝,典冠者见君之寒也,故加衣于君之上,觉寝而说,问左右曰:“谁加衣者?”左右对曰:“典冠。”君因兼罪典衣与典冠。其罪典衣,以为失其事也;其罪典冠,以为越其职也。非不恶寒也,以为侵官之害甚于寒。

——《韩非子·二柄第七》

九条: (来找阿超) 我最近新建了不少Bug,今天发现它们的状态都变成了closed,本来要测试的Bug 都变成了关闭状态,我还用测试么?

阿超: 是别的测试人员替你测试了么?

九条: 没有,从记录上看是果冻修改了这些缺陷,然后把状态变成resolved,过了两天他又把状态变成 closed,但是我还没有运行验证测试呢。

他们把果冻找来了。

果冻: 我是看着我的Bug 老是没有关闭,心里很着急,然后昨天我就认真地把所有Bug 都验证了一遍,确信没有问题后,就把它们顺手关闭了。

九条: 是不是你的领导在统计你的Bug 数目了?呵呵。

阿超: 不同的角色在开发过程中有相互合作、相互制约的作用,不能替代。测试人员在做验证测试时,需要做多方面、多平台的测试,这些工作量,也许远远超过了开发人员的能力范围。因此,必须要由测试人员来验证并处理已经修理好的Bug。

侵官之害甚于寒——我们不是不鼓励开发人员主动帮助测试,我们是要避免导致职责不清的越界行为。

果冻: 韩昭候真过分!我很好心地帮助别的同事,没有功劳也有苦劳,他怎么能说“甚于寒”?这样我的心都寒了。

阿超: 果冻,你不是有“各司其职”的笔记么,好好看看。

九条: 果冻,谢谢你的帮助,你如果急需验证某些问题,可以告诉我,我会安排尽量早日完成。

13.5.7  测试经验交流

测试进行了一段时间后,大家发现小飞报告的Bug比较多,九条其次,小燕最少。阿超让测试人员交流一下各自的经验。

小飞: 我的原则是“如果问题看起来像一个Bug,那我就要报告这个Bug”。宁可多报一千,也不放过一个。这个原则也导致了我的Bug 有不少被归为“As Design”。

阿超: “As Design”也不是什么坏事,至少我们明确了Design是什么。这样以后就有依据了。

小燕: 我发现了一个问题,都是先跑去找开发人员商量是什么情况。或者自己研究,想找到问题的根源,有时自己想到如何修复,之后再报告Bug。

九条: 小燕的做法,似乎越界到了开发人员的职责范围了。我们的职责就是找到足够多的Bug,让开发人员有事可干。

阿超: 可以选定一个典型用户(Persona),然后按照典型人物的思路和看问题的角度,把整个系统的各项功能都经历一遍。如果有什么你觉得典型用户不满意的,那就可以考虑开一个Bug。我有时知道这个功能的设计想法,但是在测试的时候没必要替别人考虑太多,要把自己当成用户,而不是设计者。

小飞: 测试的时候,要各个角度都试试看,一些犄角旮旯也得用一些随机的数据去捣捣乱。黑箱、白箱都可以换着玩。就像对软件一窍不通的用户在使用软件一样。

阿超: 小飞的这一个经验,用正式的语言描述就是——保证测试方法的多样化。

九条: 我拿到一个测试任务,就想——这个功能最可能出问题的会是在什么地方?然后就集中火力,在容易出问题的地方测试。比如,如果一个产品的标题长度规定是32个字符,那我就测试31、32、33个字符,看看在这种边界条件下是否会出问题。

小飞: 测试的时候还要举一反三,看到产品标题字段出了问题,我就会检查一下别的字段有没有类似的问题。

阿超: 对,我们要注重从产品的风险出发进行测试。还有,我们要根据当前的产品特性来决定测试的策略,不必强求一律,举一反三很重要。

小飞: 有时候我测试自己负责的功能比较多了,就想和别人换一换,有点新鲜感。不料小燕拒绝了我的交换请求,说是没经过领导批准,是侵官之害。我只好和九条交换。

阿超: 我批准这样的交换,关键是找到Bug。我们都是同一类工作人员,在事先通知和安排好的情况下,不存在“侵官之害”的问题。

小飞: 我发现随着Bug的增多,我既要验证以前的Bug,又要发现新的Bug,工作量越来越大,你们都是怎么做到的?

九条: 我一般都把一些比较稳定的测试写成自动测试,这样就减轻了我手工测试的压力。

13.5.8  传说中的拐点

小飞: 我听说在软件项目中,有这样一个拐点存在——在这一点之前,新的Bug产生的数量大于Bug解决的数量;在这一点之后,Bug的解决数量大于新的Bug产生的数量。这样Bug的曲线就向下移动。我们移山项目的拐点到了么?

阿超: 我也听说过,不过这是在大型复杂项目中,测试人员和开发人员全部通过一个系统管理bug才会出现的现象。我们不能等待拐点的到来,对于我们这样的日期驱动型的小项目,拐点必须在发布日之前的若干时间发生,如果我们的Bug数量还是继续向上攀升,则无法保证以后曲线会像悬崖一样掉下来。我们就得主动让拐点发生,例如推迟一些Bug,砍掉一些功能,慢慢升高“必须修复的小强”这个标杆,等等。

13.5.9  练习——学习和使用多个平台上的测试工具

在本章中,我们介绍了不少VSTS的 软件测试工具,请使用一些其他平台上的测试工具,并写博客介绍如何在你的项目中具体使用。