微软是怎样测试新版 Windows 的？

例如新的 Windows 10，Preview 版本号提升很快，有时候一天就发布两个版本，微软是怎样做到在短时间内测试 Windows 系统，找到大量 bug 并优化和修复的？

有关回应 · 2021-5-30 22:56:03

楼上两位M$的工程狮只讲到了build和automation，我再多嘴一句为何现在sdet职位的减少。
有大量的automation是原因之一，但是不是主因。主因其实反而是写automation来测试资金和时间成本都太高，尤其是老板们认为拉慢的产品进度。还有个理由提到automation发现的bug不如每天大量的stress testing和selfhosting来得多。所以，老板们决定在保持用automation覆盖一定量的普通scenario，用人力selfhosting来覆盖其他scenario。这个人力selfhosting既包括内部员工每天刷的新版，也包括对外发布的preview版。
其实，“automation发现的bug不够多”这个理由很牵强，因为好的automation来得简单易用，所以每个工程狮在提交代码前都可以用automation来跑regression看有没有一不小心break啥，进到repository里的代码质量有这个保证，每天lab出来的结果当然automation发现不了多少bug了。但要写出足够好的automation真的不是每个sdet都做得到的，如何写出更少更精简的case用更少的代码和时间去覆盖更多的scenario不是那么简单的事，什么test hook什么automation framework等等东西，真不是每个sdet都完全了然于胸。以至于要实现全靠automation完全覆盖feature这种理想状态可能导致周期加长一两倍不止。老板们当然知道这个，所以确实需要一个借口来节约成本，砍掉太多不称职的sdet。
靠人力selfhosting看似一个倒退，是的，是软件工程理论的倒退。因为理想的软件工程理论是如此强调自动化测试的重要性。实际中呢，软件工程是时间/成本/质量三者的平衡，过于追求质量，拉高了另两项的成本，是得不偿失的。所以不得不追求一个平衡，把有限牺牲质量的情况下把另两项成本降下来。
那牺牲了的质量怎么办？不要怕嘛。反正现在ship周期加快了，有严重bug马上fix马上出更新，有不是那么严重影响面不是那么大的bug，就麻烦用户忍一忍啦，等到下个更新再一起fix咯。

有关回应 · 2021-5-30 22:56:04

其实通过dogfood来抓bug的周期已经很长了，你想用来dogfood的branch是很上层的了，一个bug要能进到这个branch是挺不容易的。

像你们看到的一天一个build，并不是说所有程序员每天都往那个branch直接提交代码然后build出来大家一起测试。大部分代码是通过RI从底下的feature branch传上来的，这是个挺久的过程了。除非像现在这种接近release的时候才会允许一些严重的bug fix直接进main。

所以大部分bug在feature branch中就已经被发现了，主要靠的还是regression test。这些feature branch的build很少会有人dogfood。

有关回应 · 2021-5-30 22:56:05

谢邀。

版本号每天都加，和测试没关系，和bug修复也没关系。只要一天之内代码有变化就一定会加。

windows底下分为非常多的小组，每个组负责不同的功能。以前每个组的dev和tester比例是1:1，现在基本变成每个组只有很少的tester。他们每天的工作就是把所有测试程序在不同配置下全都跑一遍，给出报表，建立bug。dev lead和PM会分析那些bug，分给适合的dev解决。解决之后可能已经几天过去了，该修正会被放到下一天的build里。

减少tester的一个很主要原因是自动化测试的成熟。preview里都有遥测的机制，一旦有程序crash之类，会自动发一个bug。如果同一个地方crash多次，优先级就会提高，也会更快被分析和解决。

这些测试同时也包括性能测试，所以bug列表里可能还包含性能项。

有关回应 · 2021-5-30 22:56:06

微软里面有个叫狗食的东西，叫大家都来用还没上市的产品我基本一周会装三四个Win10

有关回应 · 2021-5-30 22:56:07

说一下我的理解。原来在SQL Server相关的项目中做外包，对MSSQL这边的过程比较了解，估妄推测一下，当然肯定会有不同。
基本上每天都有若干组的不同Branch的Build在机器池里面跑。估计是每个组都负责不同的方面，所以诞生了好多的Branch,最后再合并到Main或者Release Branch。基本上每个开发者都能提交Build来跑，只要是过了最开始的代码检查，SQL这边叫PCV，然后他们提的请求就会进入Build系统的等待序列，有相应的机器资源的时候就开始Build的过程。所以每天都有好多的Build出来供test team来做测试。Releae team提的请求通常会有最高的优先级来做，所以在产品即将发布的时候就会有频繁的Release啥的出来。然后OS这边应该差不多的流程，而且资源可能会更多，毕竟是MS比较大的现金牛。
一般情况下，确实好多人会不得不去吃Dogfood来发现更多问题。当Win比较稳定点，比如Milestone 或者Preview后在SQL的test机器池就会有单独的子池来跑test，以便测试兼容性，当然也可能发现OS的Bug,因为比较稳定了比较少就是了，估计其他产品组也会这样子。
然后Preview后MSIT就会发布一些镜像鼓励大家安装试用。
MS现在开发速度应该提升了不少，以前有什么问题的时候会发邮件给FTE，等美国那边上班之后在解决，但是从13年底变了FTE可能有24小时叫醒服务哦，免费的呦！
之前的Build系统都是人手工写脚本来跑的，后来才有的自动化Build系统。然后测试系统也差不多是这样，人在里面就跟机器差不多了，当然这部分都是外包商在做。
PS:14 年7月离开微软的外包商，当时负责Build和Test相关的打杂，可能有些东西已过时，现了解内情的FTE或者Vendor请轻拍(^_^)

微软是怎样测试新版 Windows 的？

5 个回复