现代软件工程第十三章【软件测试】练习与讨论-阿里云开发者社区

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，砍掉一些功能，慢慢升高“必须修复的小强”这个标杆，等等。