微軟軟體測試的可借鑒之處

開頭語：

　　做測試很久了，一直為一些問題所困擾，也一直對微軟有一種頂禮膜拜的嚮往，終於有一天，近距離的接觸了微軟的測試，感覺不是以前想象中那麼遙不可及，卻又難以企及。於是把個人覺得微軟值得借鑒的地方整理了一下，希望能對大家有所協助。

　　1. 測試流程

　　首先說說測試流程，微軟的測試流程也沒什麼新的東西，和大多數的測試流程一樣。

大致是先進行測試準備，然後是Testcase的編寫，然後是白盒測試(不一定每個項目都有)，然後是功能測試階段，然後是驗收測試，最終release。

　　如果看流程的話，和一般公司大同小異，沒什麼新花樣。但是我覺得值得借鑒的是兩點。

　　第一， 微軟的流程執行的非常認真。

這點非常值得提倡，我們都知道，測試的最終品質決定於測試流程和測試人員素質，要想測試品質有保證，要麼是流程很完善，要麼你流程不行，但是個人能力超強。如果有一個很好的流程，就算執行的人稍微差點，最終的品質也不會差到哪裡去。所以流程是很重要的。

　　但是，看國內的公司欠缺的就是這個，要麼是沒有流程，要麼流程是個花架子，沒認真執行過。我想微軟的測試人都是超級牛人，但是人家還是老老實實的忠實按照流程來走，我覺得這點非常好。(在IBM 也是這樣，筆者以前在IBM作項目的時候，發現他們的文檔寫的特認真，流程特認真)，所以說忠實的執行一個好的流程是成功的一大半。

　　第二， 在整個流程中，微軟非常強調測試儘早介入。

微軟在這方面是一致提倡的，按照我們國內IT業的惡習，一般都是軟體主體差不多成型了，拉幾個測試人員過來點點，其實這是非常不好的。微軟的測試人員在項目一開始就和開發人員同步介入，在需求階段就開始介入，進行需求評審。在開發人員開始編碼的時候，測試人員就開始編寫Test case，並開發一些測試載入器，或者寫一些配套的測試代碼(不要奇怪，微軟的測試人員都能寫很好的代碼)。微軟的理念就是：預防bug比解決bug好，所以非常提倡測試儘早介入，把一部分bug消滅在需求階段。

　　2. 自動化流程

　　說到自動化，大家可能以為我是說微軟的自動化測試載入器多牛，其實微軟內部用到的自動化測試載入器倒是不多，就算有也都是內部開發的，非常實用的，他們不會去用MI的工具。

　　說微軟的自動化程度高，主要是體現在流程方面，譬如說整個自動構建流程，在開發人員代碼check in之後，系統自動發郵件，郵件內容就是一個change list，包括代碼更新list以及一個編譯者添加的comment，其內容是該版本功能的變化或者修改掉的bug ID。整個測試過程中能用自動化的地方都儘可能採用自動化，儘可能減少人為失誤，並且可以使人和機器並行工作。個人覺得，這點很值得我們國內的測試公司借鑒，能自動化的流程都自動化，減少一些不必要的溝通。

　　3. 品質控制機制

　　說到品質控制是個大問題，需要整個團隊和流程提高素質。那麼微軟的品質控制可以借鑒的是什麼呢?是他們的機制。在微軟的測試流程當中，在開發的早期，項目中所有的問題都是Dev leader和PM商量說了算(當然也要參考需求方的意見)，但是到後期，具體就是功能測試之後，項目的主動權都在測試這邊，某個bug的要不要解決，或者項目進度控制都是測試leader說了算。這和國內的大多數軟體公司是不一樣的，在微軟，測試人員要對最終的軟體品質負責任，但是也有相應的權利來約束開發人員。當然，他們也肯定有一些bug是產生爭議的，這個時候的仲裁機制就是PM，這個不是我們傳統的PM(Project manager)，而是一種具有微軟特色的PM(全稱是Program manager)。這樣，測試人員在對一些爭議bug的處理上有相當的話語權。

      4. 測試案例及管理

　　微軟的測試案例倒沒什麼特別的，不過看過他們用例之後，還是覺得寫的詳細，認真，但是又不冗長拖遝，這個需要很高深的水平。另外，微軟的測試案例管理用的是微軟自己開發的用例管理工具。

　　另外值得說明的是，微軟的每個用例都進行了分級，並且功能所在的模組都標的很清楚。

　　5. 效率

　　在效率方面，微軟的測試效率非常高!高的讓人驚歎，我問一個在微軟工作的哥們，“你們那邊測試的最大特點是什麼”，他說“最大特點是快!”，就是效率很高，具體就是在測試後期過程中測試和開發之間的反饋非常快，開發修改一定量的bug，提交一個新的版本。測試人員往往能在很快的時間內把測試結果反饋出來，一般是在1天之內就能把用例快速run一遍，這樣就能減少某些後期才發現bug導致的項目delay。在國內很多項目的通病是，開發解決問題帶進一個新問題，測試人員整個遍曆一遍用例之後才能發現，這樣來回反覆就消耗了大量的時間。

       但微軟是如何才能實現快速反饋呢?

　　第一， 測試人員對程式的瞭解，微軟的測試人員對程式內部結構都非常熟悉，修改某一個地方，可能引起什麼問題，哪些用例需要重新測試，測試人員非常清楚，能快速的執行最可能出錯的地方。如果某些模組不熟悉，那麼他們會和開發人員在一起溝通這次修改可能引起的問題。

　　第二， 工具!還是工具，在微軟的測試中，測試人員用各種工具協助測試，提高測試效率是佔到很大的比重。

　　第三， 時間意識。微軟的測試人員有強烈的時間意識。

　　6. 測試載入器

　　測試載入器能很大程度上提高測試效率，這個作為測試人員都很清楚。當然測試載入器在微軟的測試中也應用非常廣泛，但是請注意，微軟並不是像我們國內的公司一樣使用的都是LR或QTP這類的錄製回放工具，反而這種工具倒是用的不多，就跟微軟不屑CMM一樣，可能是不想屈尊自己IT老大的身份吧。

　　但是微軟的測試載入器最大的特點是實用。他們用的測試載入器都是確實能提高效率，確實能辦事情的工具，都不是類似WR和QTP的很大很系統的工具，而是比較小的，很靈活，實用的小工具(譬如：Fiddler、Drip、httpwatch、IE DevToolBar、PaintNotNet、procexp etc.)。甚至有一些測試載入器是測試人員在開發人員協助下根據項目需要臨時開發的，不過大多數工具都是微軟內部已經共用出來的，在微軟內部各種各樣的小工具特別多。

　　總體給我的感覺是，不是為了用測試載入器而用，而是根據實際的需要，確實能提高效率而用到，在用的過程中確實也很大的提高了效率。

　　7. 測試人員的專業素質

　　微軟測試給我印象最深刻的還有他們測試人員的專業水準，在測試過程中，測試人員在一些技術上並不遜色於開發人員，在一些bug的處理上，能提出很多合理的很有建設性的建議。

　　8. 微軟的白盒測試

　　微軟的白盒測試怎麼執行呢?讓我略微有點吃驚的是，微軟的一半測試人員基本不做白盒測試，除非有些不能做黑盒的模組，另外也不是所有的產品都作白盒測試。

　　微軟的白盒測試一般還是由專門的白盒測試人員來做，但是開發人員要對測試人員的白盒測試代碼進行Review，另外微軟對開發人員的代碼，效率也都有一套詳細的考核機制，所以開發人員對自己的代碼也是非常負責任的，都進行很認真的進行測試。

　　9. 意識(時間，品質)

　　另外微軟的測試還有很好的一點就是意識，時間和品質的意識都是非常強。在控制時間成本上，意識非常強，這點非常值得我們國內同仁學習，另外，風險管理的機制和意識都是非常好。在微軟，項目組的每個成員都被明確告知，如果這個項目每delay一天，就會損失多少個million的美元，所以整個項目組都有比較好的時間意識。

　　另外，在微軟，項目組人員的品質意識都是比較強的。怎麼樣更好服務使用者，讓使用者體驗更好，怎麼樣更好的改進，這種意識比較強。

　　10. 微軟的培訓

　　在微軟內部，員工外訓的機會比較少，大多都是內部互訓，各人培訓自己的強項，有比較好的互相分享的習慣。另外微軟的內部有非常豐富的各種培訓文檔。以後我會上傳上去和大家分享。

　　11. 測試資料記錄

　　微軟的測試資料記錄是非常全的，也都是系統自動的，每天都是由系統自動統計當天的bug情況，然後發送一個report到每個項目群組成員的郵箱裡。最後到測試總結的時候，這些測試資料將變得非常有用。

　　

編後感：

　　在深入瞭解微軟的測試之前，對微軟這個IT業界巨無霸的測試感覺是頂禮膜拜，高不可攀，總覺得可能很神秘，用很牛的技術或者很高深的手段。深入瞭解之後，發現微軟的測試也是和我們做一樣的事情，只不過人家做的更認真，更細，更實用，更有效率。再回過頭來看時，微軟的測試給我留下印象最多的是，流程，效率，意識，工具，素質!也就是這幾項，成為我們國內IT企業亟需跨越的。