现代软件工程 第十三章 【软件测试】 练习与讨论
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的 软件测试工具，请使用一些其他平台上的测试工具，并写博客介绍如何在你的项目中具体使用。
13.5.10 历史上的20 大bug
http://www.devtopics.com/20-famous-software-disasters/
http://www.devtopics.com/20-famous-software-disasters-part-2/
http://www.devtopics.com/20-famous-software-disasters-part-3/
http://www.devtopics.com/20-famous-software-disasters-part-4/
如果你在这些项目中负责测试工作，你要设计什么样的测试用例才能发现这些bug? 还有什么样的改进能避免bug 的发生?
丰田公司是一个世界著名的汽车公司，汽车上有不少软件，有些软件对行车安全起着至关重要的作用，这些软件有bug么？ 请看这个报道：
技术分析：
http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf
13.5.11 历史悠久的bug
这是什么样的bug？ 要过37 年才修复?
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/head/head.c.diff?r1=1.17&r2=1.18&f=h
http://www.reddit.com/r/programming/comments/2ind4f/fix_a_37_year_old_bug_introduced_by_bill_joy_on/
源代码作者是 Bill Joy, 他最初写这个程序的时候犯错误了么? 还是因为外界的变化是原来没有bug 的程序产生了bug?
13.5.12 经验分享 - TPS 和 并发用户数
http://hitest.aliyun.com/front/share/shareDetail.htm?spm=0.0.0.0.hoDObJ&shareId=194011410749727463