微軟軟件測試培訓心得

從需求開始說起，正如我們所知需求是一個項目的靈魂，如果需求偏離了，后面的開發測試可能要走很多彎路。需求不明確，迫使開發人員按照他自己的想法去設計，可能出來的結果不是客戶所需的。導致大量的無效代碼寫出來，被推翻，然后再繼續，又被推翻……有句老話叫：失之毫厘，謬以千里就是這個意思，如果為了搶進度，而在需求這部分擠時間的話，到了項目的后期就必須要花成倍的人力，物力來彌補。測試在需求不明確的情況下測試，有些早期可以規避的設計問題在后期發現，無疑于亡羊補牢而非未雨綢繆。

　　那么微軟是怎么樣做的呢？一個大的項目，分成若干子模塊。每一個模塊對應一個需求人員，一個開發人員和一個測試人員。微軟的項目是沒有概要需求的，從長期總結下來的經驗看，概要需求的設計作用不是很大，因為沒有什么內容也很容易導致概要需求的評審大家也都是很happy就通過。直接就是詳細需求文檔，要詳細到每個接口的定義，甚至每個輸入框可輸的數據類型。這個模塊的需求文檔出來之后，都有什么人參與評審呢？其中包括，此模塊的開發人員和測試人員；開發經理和測試經理（評審需求用來保證和其他模塊兼容）；市場人員（從用戶角度考慮）；大頭（據說是比爾.G直接的下屬）這六個人去評審這個模塊的需求，這六個人一起去看需求文檔是否合理細致，實行一票否決制，任何一個人不Sign Off都不能通過。之后就是這個模塊的詳細設計文檔（開發人員）和詳細測試計劃（測試人員）。這就保證了開發和測試的并行。同樣，詳細設計文檔和測試計劃也都是六人評審制。為什么需要那么多的人評審？是要在做事之前，讓其他人幫助你看你想清楚了沒有，人無完人，一個人想的再全面也有可能有疏漏的地方，所以聚集其他人的力量幫你想清楚避免走彎路。假設某個項目有30個模塊的話，意味著大頭要看30個模塊的需求文檔，30個模塊的詳細設計文檔和30個模塊的詳細測試計劃。他將需要看90份文檔，這樣，就能夠保證了整個項目了然于心。我聽到老師講的很震撼的話就是，在微軟是沒有QA的，因為在微軟每個人都是QA.

　　接下來是開發過程。因為不是重點，講的不是特別細致。主要的核心點是如果來預防缺陷要高于如何解決缺陷。嚴格按照詳細設計文檔來編碼，就不會產生之前的大量無效代碼的情況。開發團隊還需要有Code Guide Line編碼規范。認真執行編碼規范。開發人員在check-in之前要保證自己的編碼為有效代碼。如何保證開發人員的編碼為有效代碼呢？這就引入了自動化測試，為了保證編碼有效，就要利用自動化測試工具來保證。思路是用程序來檢查程序。在編碼的過程當中，運行自動化測試工具能幫助開發人員邊編碼邊檢查。提交上去的代碼自然要比沒有經過編碼檢查的質量要高很多。這樣就做到了邊開發邊測試，也就是所謂的“極限編程”。當然微軟的自動化測試工具都是自己開發的，量身為項目本身所打造。

　　自動化測試，它是軟件質量的保障體系，自動化測試最大的優點就是把重復性的勞動交給計算機去做，包括review靜態代碼，每個版本更新后都需要重復測試的功能，或者是大量的數據的重復操作。這些如果在項目之前都開發完成的話，對于軟件的效率會有極大的提高。但是有利有弊，自動化測試也有一定的局限性：

　　● 自動化測試前期投入很大，包括編寫自動化測試工具，開發自動化測試腳本。如果項目周期短，沒有可持續性不適合自動化測試。

　　● 自動化測試的技術門檻相對較高，測試團隊整體水平不高的情況下無法完成工具的發開，心有余而力不足。

　　● 對于沒有預期結果的測試，不適應自動化。

　　● 對于用戶體驗的測試，主觀性比較強的不適應自動化。

　　下面就從測試計劃開始：

　　基于前面詳盡的需求文檔，測試人員開始制定詳細測試計劃，和詳細設計可在同一時間完成。完美的測試是90%的測試任務和開發并行完成，10%的測試任務在開發之后完成，還是剛才說的，預防缺陷要比解決缺陷效果好的多。讓開發人員邊開發就邊測試自己的代碼使之都是有效代碼。測試計劃中除了包含常見的測試內容，功能測試，性能測試，健壯性測試，安全測試，界面測試等，還應該考慮到UE用戶體驗測試，因為用戶體驗的好壞是決定商業上是否成功的標準。不僅把產品做到能用，還要把產品做到好用。所以產品開發完成之后積累用戶的反饋也很重要。還有風險的方面，包括自動化測試工具的使用，售后升級是否有保障等。需求不明確所導致的測試時間的延長，這些都要計算到測試風險之中。關于架構的測試是十分重要的，一定要提前到需求層面上。當然系統架構師需要極高的技術壁壘來保證系統的架構。

原文轉自：http://www.anti-gravitydesign.com