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

例如新的 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肯定沒有經過內部測試就正式發布了。


推薦閱讀:

你和微軟小冰,小娜最有意思的對話是什麼?
微軟對世界的改變有多大?
為什麼win8之後直接是win10,有沒有win9?
微軟停止零售 Windows 7 之後,Win 7 旗艦版如何購買?
如何在西雅圖認識工作的中國男生?

TAG:微軟Microsoft | MicrosoftWindows | 操作系統 | 微軟產品與服務 |