叛逆者2015-07-12 02:14:47謝邀。
版本號每天都加，和測試沒關係，和bug修復也沒關係。只要一天之內程式碼有變化就一定會加。
windows底下分為非常多的小組，每個組負責不同的功能。以前每個組的dev和tester比例是1：1，現在基本變成每個組只有很少的tester。他們每天的工作就是把所有測試程式在不同配置下全都跑一遍，給出報表，建立bug。dev lead和PM會分析那些bug，分給適合的dev解決。解決之後可能已經幾天過去了，該修正會被放到下一天的build裡。
減少tester的一個很主要原因是自動化測試的成熟。preview裡都有遙測的機制，一旦有程式crash之類，會自動發一個bug。如果同一個地方crash多次，優先順序就會提高，也會更快被分析和解決。
這些測試同時也包括效能測試，所以bug列表裡可能還包含效能項。
知乎使用者2015-07-12 07:49:00樓上兩位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咯。
Reacher Jack2015-07-12 07:57:16微軟裡面有個叫狗食的東西，叫大家都來用還沒上市的產品 我基本一週會裝三四個Win10
Tim Chen2015-07-12 12:02:32其實透過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。
知乎使用者2015-07-12 15:06:11說一下我的理解。原來在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請輕拍（^_^）
