來源：Bill Liu
因為工作在微軟的緣故，無論我在給國內企業做軟體測試內訓的時候，還是在質量技術大會上做演講的時候，問的最多的一個問題就是：微軟如何做測試的？前幾天看見有人在新浪微博上討論是否需要專職QA，再有我剛剛決定帶領兩個google在西雅圖的測試工程師一起翻譯google的新書《how google tests software》。微軟以前也有一本書《how we test software at microsoft》。所以幾件事情碰到一起，有感而發，決定寫一個“xx公司如何測試的”系列文章。目的不是為了回答以上問題，旨在通過分析對比如Microsoft、Google、 Amazon、Facebook等在保證產品質量的諸多具體實踐， 和大家分享一下我個人認為這些公司在保證軟體質量中的最為關鍵的幾個實踐和經驗。希望大家有所收穫和思考。我們今天先談談微軟在提高軟體質量上有哪些值得學習和借鑑的經驗：
1. Evolving test role
微軟的正式測試工程師可以追溯到1990年左右，以後以每年大概500人遞增。現在大概有1萬左右的測試工程師。回顧走過的20多年，其中最為明顯的特徵就是微軟對軟體測試和質量控制的認識不是一成不變的，而是隨著經驗的積累，產品的演變不斷演變，同時測試工程師的職責也不斷在演變。最開始叫software test engineer (STE)，主要職責是設計測試用例，手工黑盒測試。2000年左右演變成Software Design Engineer in Test (SDET)，主要職責是設計測試用例，開發測試自動化程式碼，測試基礎設施和測試工具。同時把繁瑣的簡單的手工測試外包給印度和中國的外包公司。2005年以前公司的測試文化基本上是：產品質量是測試人員的責任，測試人員保證產品質量，測試人員很多時候像給開發打下手為開發服務。2005年後隨著敏捷和軟體及服務的出現，測試的角色逐漸從依賴測試來提高產品質量轉變成用測試來建立保證產品質量的具體要素。測試不再像給開發打下手，而是轉變成一個獨立的崗位為產品質量服務。2010後，隨著軟體即服務和雲端計算的日趨成熟，微軟很多產品組轉向開發服務型的產品，同時測試人員的角色為了適應新的挑戰而繼續演變，比如現在很多組開發也做測試，測試也做開發，兩者間的界限越來越模糊。正是測試的這種靈活性和對不同時期不同產品的適應性使得每個釋出產品的質量得以有效保證。
2. Set full-time test role
微軟的產品一直以桌面產品為主，比如Windows, Office, SQL server, etc…。這些型別的產品的共同特點就是對釋出版本的質量要求非常非常高，它要求產品在釋出之前必須修復幾乎所有的bug，至少不可以有關鍵性bug。因為萬一漏掉一個關鍵性的bug，召回產品或釋出熱修復的代價太大。所以每個產品組在產品開發過程中投入大量的測試人員來全方位，反反覆覆測試， 包括功能測試，效能壓力測試，本地化國際化測試，安全性測試，使用性和相容性測試，等等。這些大量繁重的工作不可能都有dev來做。有了專職的測試人員不僅大大減輕了開發人員的工作量，而且通過測試人員特有的、經過專門訓練的技能可以在產品釋出之前找出更多、更為關鍵的bug。所以在這種情況下，專職測試人員不僅是有用的而且是必須的，他們對提高軟體質量起到至關重要的作用。在像windows和office這兩個最大的產品組，專職測試人員的數量和開發一樣多，再加上大量外包公司的測試人員，可以說測試人員的數量實際上是開發的將近兩倍。但是，如前所述，隨著從桌面產品逐漸轉向服務型的產品（軟體即服務），專職測試人員的作用在逐漸下降。主要原因是：首先產品質量不再是光光通過“測試”來提高了；其次對釋出版本質量要求有所降低，因為服務型產品不是安裝在使用者機器上而是部署在微軟自己的資料中心裡，如果有bug，開發人員可以很快修復然後及時更新產品（而不是像桌面產品需要召回），所以熱修復的成本大大降低了；還有就是利用使用者來做測試（我們在下面會具體再談）。所以在服務型產品中，專職測試人員的作用不再像以前那樣顯得至關重要。微軟現在許多組在削減測試，或者轉成dev，即使保留測試的頭銜，做的工作也不是嚴格意義上的測試了。另外一點值得說明的是，雖然專職測試人員數量有所減少，但是並不意味著測試的覆蓋率就一定減少了。很多時候實際上是測試的覆蓋率更多了，這主要是因為開發做越來越多的測試，同時測試的效率提高。
3. Heavily invest in test automation
測試自動化不是萬能的，但是沒有測試自動化是萬萬不能的。測試自動化可以把測試人員從枯燥重複的手工測試中解脫出來做更多更有有技術含量的工作。當然測試自動化需要前期投入，而且不穩定的測試自動化還會把測試人員拽到疲於維護的泥潭中。但是這不是否定測試自動化的理由。沒有用好測試自動化並不代表它沒有用。而且，敏捷測試，持續整合，快速交付，等等都是以測試自動化為基礎的。公司可以根據具體情況採用逐步提高的策略，比如先自動化每日構建，再自動化部署，然後自動化最關鍵的測試用例，次關鍵的測試用例，等等。微軟測試工程師有超過80％的時間是在寫測試程式碼。它們包括測試自動化程式碼，開發基礎設施程式碼以及開發測試工具。預設情況下自動化所有測試用例，除非你有合理的理由不自動化。我個人的準則是：如果手工重複執行一個過程超過3次，就是時候自動化了。通常在一個釋出週期的計劃階段，PM,dev，test,根據本次釋出的時間長短和內容各自做計劃，然後彙總討論，制定一個最終的符合各個角色的釋出計劃。Pm和dev決定本次釋出中的產品新功能，測試決定本次釋出中的測試有關的工作量，比如為新功能而新增的測試自動化，為修改現有功能而修改測試，需要開發或改進的測試工具或基礎設施。經過討論後大家一致同意最終計劃。計劃好後，大家就根據各自的計劃並行工作，當然中間大家及時溝通進度，如果需要，調整計劃。這個過程的好處是把與測試自動相關的所有工作都放到開始專案計劃中來，包括新功能測試自動化，現有程式碼的維護，工具的建立和改進等等，這不僅逐步提高測試自動化覆蓋率，而且使得基礎設施和測試工具逐漸成熟和完善。成熟和完善的設施和工具同時極大提供了開發效率和速度，比如大部分產品組都有daily execution 和checkin quality gate：
× Daily execution: 每天晚上，自動生成每日構建，自動部署到測試環境，自動執行測試用例。對於失敗的測試用例，系統自動報bug,並且對測試日誌和產品日誌進行自動分析，把相關資訊放到bug中。最後自動傳送測試結果到整個組。第二天早上到辦公室，每個人都會看到已經執行完的測試報告。這使得測試可以有更多的時間自動化更多的用例，更多的時間分析測試缺口或做探索性測試。
× Checkin quality gate: 開發在提交程式碼之前通過執行一個簡單命令可以把相關測試自動執行一遍。這使得開發從一開始就提交高質量的程式碼。
即使在做手工或探索性測試，測試工程師也儘可能使用測試工具來自動化其中步驟，從而使得測試人員完全專注於應該專注的地方，比如思考探索嘗試，而不是在別的地方浪費時間，比如準備測試資料，搭建測試環境，分析日誌，報bug等等。 打個簡單的比喻，比如你要從北京到上海開會，手工測試就好像你騎自行車過去，你的目的是開會但是你結果把大量時間浪費在路上了。測試自動化就好像你乘飛機過去。還有看起來來好像飛機票很貴，成本比騎自行車要大，但實際上最後騎自行車的成本要高的很多。只不過很多成本你當時看不到罷了。
所以很多我給做培訓的公司的經理抱怨說我們也想做單元測試，做測試自動化，但是就是成本負擔不起。我就說你只看到“做”的成本，因為它很直接；而看不到“不做”的成本，因為你不能馬上看到。業界無數公司，專案已經證明在單元測試和測試自動化在提高軟體質量方面“不做”的成本要比“做”的成本大的多得多。
軟體質量控制實踐――Microsoft 篇（下）