你知道哥德堡号是怎样沉没的吗？07年第8期的《读者》上有篇文章引起了我的兴趣。哥德堡号是18世纪瑞典人的希望：他们需要从海上贸易来充实因为战争而濒临枯竭的国库。建造哥德堡号动用了瑞典当时15%的国内生产总值，船坚炮利不在话下。然而在最后一次返航途中离码头900米的地方撞上了当地人再熟悉不过的一块暗礁，在欢迎人群的注视下满载着从中国运来的瓷器、茶叶和丝绸沉入海底。
你的开发工作中也会有平时再熟悉不过的暗礁：
你不会在工作目录少放一两个文件，特别是开发了半年后；
你不会在调试上个星期的版本的时候，心里以为是最新的版本；
你不会把产品的名字都写错...
是的，谁都不会撞上这样的暗礁。不过考虑一下临交货前一天可能发生的事情：
发现一个小bug，顺手改了一把；
bug都改完了，开始兴冲冲的写下一个版本；
客户发个email来说某些显眼处的标题要改，他们也很抱歉，说是上头今天异想天开...
如果这时候就打包刻盘，明天交货时会发生哪些事情呢？
出现了一些以前出现过的bug，但是dev说早就改好了；
有些问题在自己的环境里面总没法复现出来，客户那边100%出现，直到有一天发现少了个文件；
被问到“为什么这里说的和那里不一致呢？”...
在把发布测试当一回事来抓之前，客户拿到手的产品可能会有这些问题：
产品安装/上线之后不是多了就是少了些东西；
好像是调试版本；
文档和产品不一致；
有些承诺修改过的bug还在...
所有这一切，都源于开发人员和客户关注角度的差别。作为测试人员，应该站在客户的位置上，可惜他们还是开发团队的一部分，往往还是以开发人员的眼光去看bug。发布阶段的bug，拥有许多不一样的地方：
这不是/这里没有客户需要的东西；
这不影响使用，但影响客户的生意（比如把人家的logo都搞错了）；
你会用，但客户不会用；
在你的环境好用，但和客户环境不太兼容；
触了客户的霉头（别笑，你见过主版本号是13的产品吗？）...
成熟的软件工业会进行一系列的发布阶段测试：
安全漏洞测试；
各个语言版本的界面内容（文本，图片，多媒体资源等），用户文档，发布说明的复核，确保没有违反法律和地缘政治文化（想想十字军东征的画面被放在阿拉伯文版里面）；
数字签名校验；
病毒扫描（想想熊猫烧香是怎样传播的）；
再一次基本功能测试。
噢，忘了说为什么哥德堡号撞上暗礁的根本原因：航海多年的水手看见陆地和欢迎人群，兴奋起来所以提早在船上开庆祝party；舵手的位置在二楼，需要甲板上的人指示方向；本来每条船上都有当地向导作为领航员，但是他去参加party了。
