微软修复的那个存在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年的漏洞，有没有可能？非常有可能。但是这不能说明微软的测试和开发水平很低。从第一点可知，开发很可能根本不知道有这样的漏洞。从第二点可知，这个漏洞可能需要经过及其复杂的操作才能发现，根本不在测试人员的测试用例里。很可能是测试人员在扩展测试时无意中发现的。测试人员发现这种bug，往往是运气，和技术关系不大。

4、有人会说，如果测试人员的测试用例发现不了问题，需要扩展测试才能发现问题，那测试用例还有什么用？第一，测试用例能够发现的问题，基本会在产品发布前就被解决。或者很快被更新补丁解决。所以它有多大的用，用户完全不知道。第二，测试用例的基本作用，是保证产品发布之后，正常使用不出问题。简单的说就是：测试人员的时间有限，要把精力放在更重要的测试用例上。如果这样的操作都需要加到测试用例里，那么测试用例将会无穷大，测试人员也不可能执行完所有的测试用例。

5、微软的每个产品，hotfix和SP版本都发布的非常多，而且我在使用时遇到的绝大多数问题都能在TechNet上找到解决方案，我作为一个普通用户能够感受到它对客户的诚意。一个bug存在了19年，微软默默的把它修复了，没有继续放任，我觉得很给力。

6、这漏洞过了19年才被发现——不管是被测试人员发现还是被使用者or黑客发现——本身就说明这漏洞没那么可怕：后果很危险，但是发现很困难。

也有匿名用户表示：

当一个 Bug 存在了十九年之后，就不再是一个 Bug 了，而是变成了 Feature :p 。而且这种 Bug 不是每个公司每个产品都能有的，首先你得有个十九年之后还处于垄断地位的产品。

正如大家讨论的那样，我们更多时候在谈论是Bug的后果，而忽略了Bug会出现的前提条件。并没有哪一家公司敢说自己的代码不会出现Bug，而这也不是说Bug就应该存在，Bug毕竟会给用户带来使用隐患，那么软件提供商所做的就是尽量保证用户在正常使用状态下不会出现问题，就如Windows，微软会在发布之前完成调试，如果在正常使用中出现的问题，就会在发布之间解决，而正式发布之后发现的一些问题，则是通过更新或者发布新版本解决。

就如另一位网友提到的，一个Bug出现的可能性很关键，他举了一个简单的例子，我们就能明白为何有些Bug要很长时间才能发现，因为真的是要靠运气：“可能有些bug是需要「点2014次开始按钮后再打开11次OUTLOOK，再连续发15次邮件」才能出现，这种操作显然不是正常使用，对于测试人员来说，也是一个测试需求很低的操作。”

总而言之，Bug被发现，被解决是一件好事，过于关注19年或者是6位数的价值，有些舍本逐末了。