【IT168 评论】2008年的最后一天，数以千计的Zune用户发现，他们无法正常使用30GB版本Zune播放器。据微软表示，导致该故障的原因是，在Zune的固件代码中存在漏洞，未能正确的处理闰年问题。从该事件中，每一个软件开发者都应该吸取三个教训。

  微软高级项目经理斯科特•汉赛尔曼（Scott Hanselman）曾经为程序员们写了一篇非常好的技术分析文章，来介绍这类边界情况下编程的危险，而且很明显他不是唯一提醒人们注意这类漏洞的人。

  不过，该事件除了让我们知道在编程时不要犯此类错误外，还有三件重要的事情，值得开发者、软件质量保证（QA）专业人员和他们的管理者牢记。

  这是软件开发过程和质量保证（QA）测试的失败

  值得庆幸的是，这个问题的解决办法非常简单——只需等待一天即可自动恢复正常，但是对于微软来说，犯这种低级错误，无疑是一件尴尬的事情。

  记得曾经有一本书叫做《我们在微软如何测试软件（How We Test Software at Microsoft）》，我为该书的作者感到十分难过，他或许会因为这件事情而遭人耻笑。在微软的确有很多天才，他们都是了不起的人，其中有些人堪称最聪明的技术人才。但是无论如何，通过这次事件，却说明微软没有创造出一个质量至上的文化。

  实际上，这个问题本来是完全可以避免的。正如一个来自伦敦的Web开发者所言，“诸如闰年的跨年转换之类的边界情形，应该是必须要进行测试的情况之一，而且在设备上解决这类问题并不麻烦。”他表示，诸如此类的日期问题真的应该在测试的时候就被发现；任何一种代码审查都会发现这种无限循环的问题。那么，为什么这样的测试没有进行？或者为什么该漏洞没有被发现？

  我知道，有的时候厂商为了实现“按时上市销售”，会减少很多该做的工作。质量保证测试并不是其唯一的牺牲品。但是，这次微软Zune播放器的故障，任何基本的单元测试都能轻易发现它。

  每个人都有犯错的可能。但是软件工程学的目的就是在产品发布前，发现并修复它的错误。

  那么，让我们来反思一下，自己公司的软件开发过程是否能发现类似微软Zune固件程序漏洞的错误呢？