微軟是怎樣測試新版 Windows 的？

12-31

例如新的 Windows 10，Preview 版本號提升很快，有時候一天就發布兩個版本，微軟是怎樣做到在短時間內測試 Windows 系統，找到大量 bug 並優化和修復的？

在Office裡面，很久以前build team就發布消息說，以後編譯器只能在Windows 10 上用。所以在Windows 10整體上還處於一個超級傻逼的狀態的時候，我們就被迫在上面寫代碼，找出了無數的bug。

謝邀。

版本號每天都加，和測試沒關係，和bug修復也沒關係。只要一天之內代碼有變化就一定會加。

windows底下分為非常多的小組，每個組負責不同的功能。以前每個組的dev和tester比例是1:1，現在基本變成每個組只有很少的tester。他們每天的工作就是把所有測試程序在不同配置下全都跑一遍，給出報表，建立bug。dev lead和PM會分析那些bug，分給適合的dev解決。解決之後可能已經幾天過去了，該修正會被放到下一天的build里。

減少tester的一個很主要原因是自動化測試的成熟。preview里都有遙測的機制，一旦有程序crash之類，會自動發一個bug。如果同一個地方crash多次，優先順序就會提高，也會更快被分析和解決。

這些測試同時也包括性能測試，所以bug列表裡可能還包含性能項。

樓上兩位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咯。

其實通過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。

微軟裡面有個叫狗食的東西，叫大家都來用還沒上市的產品我基本一周會裝三四個Win10

說一下我的理解。原來在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請輕拍(^_^)

@dark fall 不是說 M$ 的 SDET 都死光了嗎？

於是依他的話，答案是不測試

主要靠的還是regression test。這些feature branch的build很少會有人dogfood。

當然是靠吾等忠實的傳教士。我一般只要出了預覽版，第一時間下載安裝在我的工作機上面。所有後果自己承擔，所有bug能解決自己解決，解決不了裝個副系統，也堅決捍衛windows最新版的地位。

我曾經試過為了解決一個windows8開監控的問題，浪費了一天一夜才解決。解決方法奇葩到不行。

哪有一天幾個版本。一般一個版本，快速版的會員也會保持一個月左右更新。

最近情況特殊，越來越接近發布，不能慢，而且現在完善度基本沒問題了。

MS怎麼測試不知道。

但從實際使用經驗來看，OS X和iOS肯定沒有經過內部測試就正式發布了。