这是一个有代表性的事件，它关系到软件的测试策略问题。近些年来，随着敏捷开发，持续集成，自动化测试，DevOps等理念的不断普及和深入，软件的测试策略也随之发生改变。
一个整体发展趋势是，为了应对快速和高频交付的压力，软件测试越来越依赖于自动化。然而，做过自动化测试的人都清楚，越是系统/端到端(E2E)层面的测试，越难以实现自动化。即使实现了自动化测试，也难以让它快速，稳定，覆盖度高。
这意味着，软件测试本质上是越来越依赖于低级别的自动化测试，例如静态分析，动态分析，单元测试，接口测试等。端到端测试虽然也有，但是其空间被大大压缩。
根据测试金字塔理论，投入大量资源到低级别测试是合理的，毕竟它们单位成本低，执行速度快，效果也不错。然而，处于金字塔顶层的端到端或系统虽然单位成本高，耗时长，但是其测试完整性好，接近用户场景，容易发现对用户直接产生影响的软件缺陷。
一个理想的测试策略应该是"两条腿走路"，即低级别测试和系统测试各司其职，相辅相成，共同担当软件质量保障的重任。Win10事件之所以发生，正是因为它轻视了"系统测试"这一条腿的缘故。
在一些情况下，这种平衡状态可能会被主动打破。例如，许多互联网公司为了快速抢占市场，愿意为了进度而牺牲一部分质量，经过简单的系统测试就向市场发布产品。
需要注意的是，互联网产品有几个特点，能够减少缺乏系统测试而遗漏的缺陷，以及减少已发生缺陷的负面影响。这些特点包括：1) 许多互联网产品提供基于容器化的微服务，其开发环境接近生产环境，在开发阶段也能发现许多系统缺陷， 2) 互联网公司广泛使用了灰度发布，热修复，线上监控等技术，3) 互联网应用程序相对轻量级，易于升级和回退。
与互联网产品不同，操作系统与各种硬件设备联系紧密，其开发环境与生产环境之间的差异较大；由于系统日志非常庞大，操作系统的远程监控不易做到；操作系统的版本升级困难，用户接受程度低。
因此，对于类似操作系统这样复杂度高，与底层硬件关联度大的产品，其测试策略与互联网产品还是存在差异的，不可以盲目模仿。系统测试(以及探索性测试)，在这类产品的测试中占据重要地位。毕竟，用户希望安装好之后，它就稳定地拥有高质量，而不是通过不断升级来维持高质量。
不过，互联网测试的一些思想仍然值得借鉴。例如，微软现在要求Win10所有开发人员的电脑上都安装Win10的测试版本，开发自己去做功能测试。这就借鉴了灰度发布的思想：先在小范围试用，收集用户反馈，暴露并解决问题，然后才大面积铺开。
当然，开发人员对功能缺陷的敏感程度，以及他们识别，报告和推动软件缺陷解决的积极性是否能够达到专业测试人员的水平，从而实现同样的测试效果，还有待观察。
