4）发布阶段。

　　测试队伍要把尽可能多的测试用例自动化，并为下一个版本的测试工作做好准备。

　　2、怎样写测试计划

　　这会在后面的章节中讨论。测试计划的模板在移山社区网站上有下载。

　　3、如果一个Bug在实际应用中根本不可能发生，这还是一个Bug么

　　看这里：http：//www.testingcraft.com/Bug-in-forest.pdf。

　　另外，要知道这世界上有各种各样的用户，有些用户“亡软件之心不死”，IE和Windows的许多安全漏洞，都在这些用户的努力下被发现并且被利用了。很多人当初会说“缓冲区溢出？这是根本不会发生的事，用户怎么会在字符串后面加这么多乱七八糟的东西？！”。

　　4、Bug的数量和测试人员的工作效率有关么？和开发人员的工作绩效有关么

　　阿亨：当然有关！我们会在以后的实践中碰到这些问题。

　　阿超：有关，但是也不是太有关。一个极端的例子，如果一个开发人员写的模块没有任何Bug，那测试人员的工作效率如何衡量？我们以后再说。

　　5、有错不改

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

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

　　众人：真的？为什么屡教不改呢？

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