軟件質量控制實踐 - Microsoft 篇 (1)

因為工作在微軟的緣故，無論我在給國內企業做軟件測試內訓的時候，還是在質量技術大會上做演講的時候，問的最多的一個問題就是：微軟如何做測試的？前幾天看見有人在新浪微博上討論是否需要專職 QA，再有我剛剛決定帶領兩個 google 在西雅圖的測試工程師一起翻譯 google 的新書《how google tests software》。微軟以前也有一本書《how we test software at microsoft》。所以幾件事情碰到一起，有感而發，決定寫一個“xx 公司如何測試的”系列文章。目的不是為了回答以上問題，旨在通過分析對比如 Microsoft,Google, Amazon, 非死book 等在保證產品質量的諸多具體實踐， 和大家分享一下我個人認為這些公司在保證軟件質量中的最為關鍵的幾個實踐和經驗。希望大家有所收獲和思考。我們今天先談談微軟在提高軟件質量上有哪些值得學習和借鑒的經驗：

 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 等等。 打個簡單的比喻，比如你要從北京到上海開會，手工測試就好像你騎自行車過去，你的目的是開會但是你結果把大量時間浪費在路上了。測試自動化就好像你乘飛機過去。還有看起來來好像飛機票很貴，成本比騎自行車要大，但實際上最后騎自行車的成本要高的很多。只不過很多成本你當時看不到罷了。

所以很多我給做培訓的公司的經理抱怨說我們也想做單元測試，做測試自動化，但是就是成本負擔不起。我就說你只看到“做”的成本，因為它很直接；而看不到“不做”的成本，因為你不能馬上看到。業界無數公司，項目已經證明在單元測試和測試自動化在提高軟件質量方面“不做”的成本要比“做”的成本大的多得多。