微软修复的那个存在19年的漏洞到底是什么？？

上个月11日，微软照常每周推送周二更新，但与以往不同的是，在本周的周二更新中，微软修复了一个存在了19年的漏洞，这也让很多人质疑操作系统的安全性和微软的工作方式。

在《华盛顿邮报》的报道中，IBM X-Force部门的研究员RobertFreeman爆料称，微软修复的这个漏洞已经存在了19年，这个漏洞可能存在让黑客操纵计算机的风险。在黑市上，一个19岁的漏洞的价值超过6位数。带来价格后，大家的讨论会更加活跃。

当然，在我们看来，微软在任何情况下都应该努力修复操作系统中的漏洞，微软现在也在这么做。每周二，它都会为操作系统推送补丁，以提高系统本身的安全性，这也说明了失去微软官方更新保证的Windows XP是多么危险。这个潜在的漏洞已经在Windows操作系统中存在了19年，并且从Windows 95的第一个版本就已经存在了。只能说，微软修复Windows漏洞的努力将持续提升用户的安全性。

在很多业内人士看来，这个19年的漏洞可能代表不了太多。该网友根据自己的工作经历分析了这一事件：

1.理论上，所有需要修复的bug都应该由测试人员发现。写完代码后能发现的问题，很难出现在内部迭代的测试版本中。大多数bug，如果测试人员没有发现，那么开发人员根本不知道有这样的bug。

2.测试人员的任务不是发现所有的bug，而是优先发现软件正常使用中会出现的bug，确保软件正常正确使用不会出现问题，然后再考虑其他极端情况。无论是黑盒测试还是白盒测试，测试用例都要优先保证正常运行没有问题。

3.微软的操作系统已经脆弱了19年。有可能吗？很有可能。但这并不意味着微软的测试开发水平很低。从第一点，我们可以看到开发人员可能根本不知道这个漏洞。从第二点可以看出，这个漏洞可能需要复杂的操作才能被发现，它根本不在测试人员的测试用例中。很可能是测试人员在扩展测开发者_如何学JAVA试时意外发现的。测试人员经常会侥幸发现这个bug，这和技术关系不大。

4.有人会说，如果测试人员的测试用例找不到问题，就需要扩展测试来发现问题。测试用例有什么用？第一，测试用例中能发现的问题，在产品发布之前基本都会解决。或者通过更新补丁快速修复。所以它有多有用，用户完全不知道。第二，测试用例的基本功能是保证产品发布后正常使用没有问题。简单来说，测试人员的时间有限，所以他们应该关注更重要的测试用例。如果这样的操作需要添加到测试用例中，那么测试用例将是无限的，测试人员不可能执行所有的测试用例。

5.微软的每一个产品、修复程序和SP版本都发布了很多，我在使用时遇到的大部分问题都可以在TechNet上解决。作为一个普通用户，我能感受到它对客户的诚意。一个bug已经存在了19年，微软已经悄悄修复了，但是一直没有放过。我觉得很棒。

6.这个漏洞花了19年才被发现。——无论是被测试人员还是用户或者黑客发现，3354本身就说明这个漏洞并没有那么可怕：后果很危险，但是很难发现。

也有匿名用户说：

当一个Bug存在了十九年，它就不再是Bug，而是一个特性：p。而且，这个Bug不是每个公司的每个产品都能找到的。首先你要有一个19年后还处于垄断地位的产品。

正如我们所讨论的，我们经常谈论bug的后果，而忽略了bug会出现的前提阈值。没有一家公司敢说自己的代码中不会有bug，但这并不意味着bug就应该存在，毕竟bug会给用户带来隐患。所以软件提供商做的就是尽力保证用户在正常使用中不会出现问题。比如Windows，微软会在发布前完成调试，如果在正常使用中出现问题，会在发布之间解决。但是官方发布后发现的一些问题，通过更新或发布新版本来解决。

正如另一位网友提到的，出现Bug的可能性非常重要。他举了一个简单的例子，我们可以理解为什么有些bug需要很长时间才能发现，因为这真的要看运气：“可能有些bug是在2014年点击开始按钮，然后打开OUTLOOK 11次，然后连续发送15次电子邮件之后才能出现”。这个操作显然不是正常使用，也是对测试人员的测试要求。

总而言之，发现并解决bug是一件好事。太关注19年或者6位数的价值，有些人已经绝望了。