3）稳定阶段。
到了一个开发阶段的尾声，这时测试团队就可以依据以前制定的验收标准，对软件逐项进行验收测试。按照测试计划，各个方面的测试都会宣布“测试完成”——所有想到的测试都做了，所有问题都发现了。在此阶段，团队也可以把软件发布给外部进行Alpha/Beta测试。
这时，伙伴测试会用于保证新代码签入前能得到足够的检测。
一般情况下，测试队伍要把迄今为止发现的所有小强都重新试一遍，确保它们都在最后的版本中被清除了，没有一个“回归”出现。
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所示），但是一般的用户谁没事在这里打一个勾？
图7-1
相关链接：
