微軟高級開發管理峰會—軟件開發單元測試講座

歡迎大家來參加這個培訓，我叫袁華松，來自微軟總部SQL Server產品事業部，是軟件設計與測試工程師。大家聽了欒躍的講課以后，也知道我的任務是做什么。我主要是做測試工具的開發，我們這個小組里，也做了一些測試，因為我們是做產品API使用的測試，可以說是微軟API第一個用戶，在用戶API出版前第一個用戶。今天講的是單元測試，我在整個系列里一共要講三個方面，單元測試從測試角度來說是一個測試的開始的一部分。我將講一個(Bata)測試，怎么樣搜尾的部分。還要講測試自動化的問題，怎樣利用這些自動的測試，來達到你搜尾的一些指標。

　　我是復旦大學1988年進校，92年畢業。在浙江大學96年讀完碩士去美國留學，98年進入微軟公司，差不多已經有五年半的時間。我進入公司還是挺幸運的，我經歷了微軟最核心的一些產品的開發和測試過程，我經手所有的產品包括“SQL Server7.0”，然后是Windows2000等等，現在我們在進入下一代的開發。

　　我會提到微軟研發各個部門的分工，微軟產品開發和測試規劃的問題，微軟單元測試的流程問題，還有微軟產品測試包含的單元測試內容。不會包含各種各樣理論的問題，各種測試理論上怎么做，大家隨便去外面買一本書，可能比我講的更透徹。我不會講某個具體測試的利用，比如說有些先生或者女士，用到某個具體的測試工具有一些問題，我還沒有接觸過那些測試工具，沒法回答你具體的問題。而且我知道，外面軟件公司使用的測試工具和應用，和微軟內部的不是很一樣，如果沒有接觸的話也沒有辦法回答你具體的問題。也不會講其他測試工具的評價，也不會講具體測試的單元。大家來這的主要目的是想聽一下微軟總體測試是怎么樣的步驟。

　　微軟研發分工與流程簡介。正像早上欒躍提到過的，微軟所有的角色在研發部門分為四大部分，除研發部門以外還有產品知識部門，還有銷售部門，我是著重講研發部門是怎么樣分角色來做整個產品設計。首先研發部門需要有產品程序經理，主要功能是設計產品，編寫產品功能規格書，我們叫Spec，應該說是比較粗一級的規格說明書，是產品應該做什么，用戶干什么事情的時候，我們應該有什么樣的反應等等這些說明。程序經理還有別的角色，比如說是跟蹤產品總體項目的進程。有的進度如果比較大的話，可以由另外一個人單獨控制項目進程，如果這個產品進度比較小的話，有可能采取經理兼任的職務。他最主要的是設計產品，程序經理會參加各種各樣的開發會議，包括對手的開發會議，看他們下一步做什么，我們這個版本怎么做超過他們。程序經理還會參加用戶訪問，一般是由上級經理和程序經理參加的，主要聽取用戶對我們產品的各種各樣的意見、建議，下一版本我們可以采用哪些設計，可以改進我們的產品?？梢詤⒓哟笮图夹g發布會，比如PDC，微軟教育會議，參加PDC的人員編程人員比較多，選擇未來幾年內需要做什么東西，這些人知道預先的消息后可以知道這些新的技術，用于他們產品開發，可以跟微軟同步發行他們的產品。TechEd主要是做應用產品的教育，用戶比較多。程序經理都會參加這些會議，有時候跟用戶交流，教育用戶，我們會有什么新產品出來，我們的產品怎么樣使用等等。

　　開發小組就是開發經理、開發組長、產品設計工程師，他們主要是語言開發的細節，產品程序經理設計產品的時候，所有開發小組都是在做語言的功能，產品經理說我要設計某一個產品，我這個產品怎么樣實現，產品經理只知道用戶什么動作，怎么實現用戶的動作，是用什么樣的功能來做，可能細節上并不是很清楚，這是由開發小組做語言，會告訴產品經理，你這樣的設計我們無法實現，或者說我們實現起來非常難，可能要六個月才能實現，我們這個產品只能三個月，可能就不行，我們要趕產品設計。當然他們也會編寫產品設計規格書，包括的是怎樣實現這些細節的問題。

　　功能市場某一個產品細節是怎么樣實現的，我是用什么樣的數據結構來實現這些功能，整個模塊的流是怎么樣的，設計流是怎么樣的。開發小組最主要的工作是編碼、開發，實現這個軟件的模塊，實現它的功能。最后還是要做修改，產品總會有Bug，修改Bug等等。

　　問：

　　編碼之前先要寫設計?

　　袁華松：

　　編碼之前要寫一下總體結構圖模塊是怎么樣的，怎么樣實現這個工程，具體實現的思路、數據是怎樣的。他是在開發經理指導下進行的。

　　測試小組一般是測試經理，測試組長，軟件測試與設計工程師，還有軟件測試工程師等等。測試小組主要編寫軟件功能模塊測試規格書，然后編寫自動測試工具，最主要的是編寫測試代碼，還會進行運行測試，然后報告結果。這些動作實際上也是自動化的，所有運行這些測試是一個整體，由工具進行總體比較，比如說有什么區別，有各種各樣新的錯誤出現等等，都是有自動工具的。問題是測試工程師要進去看到這些結果，要分析這些錯誤是怎么樣造成的，然后根據這些錯誤匯報軟件的Bug，并且修改完以后要驗證Bug修改成功，如果沒有修改成功，要重新激活再去修改。對于每日的Build結果或以發布產品的SP運行回歸測試。

　　最后一部分是用戶教育編寫組，他們所做的主要是編寫用戶文件，還會編寫用戶示例。他們可以編寫一個很巨大的產品的實驗網站或者實驗的應用程序，等于說從頭到尾可以一個人完成整個程序驗證你的產品，所以他們是有計算機的背景進行工作。最后一個工作是與PSS合作編寫KB Article。如果用戶有意見，新的錯誤出來以后，微軟會把這些錯誤進行修改，修改完以后，對這個錯誤寫一篇文章解釋這些錯誤的原因、結果，上哪兒安裝Fix等等，會變成一張KB Article。

　　微軟研發流程。微軟做的產品比較大，研發流程拉的比較長。比如說Windows2000差不多用了五年的時間，整個流程內部分了很多，很長。我們從內部里程碑零開始，會有1、2、3，會有Alpha，然后是Beta，RC1-2，Release Candidate會給大的廠商使用，在他們的產品線上裝，是不是能夠成功，一切都沒有什么大的問題，如果一切都成功了，產品可以宣布發布。Milestone從0-3，或者是到4都有可能。應該說Alpha的用戶技術級別比較高，對你產品整體設計可以提供建設性的建議，對于產品具體結構，需要什么樣的功能有很強的建議，可以告訴你你這個產品整體模塊不對。Beta一般是比較廣的外部的用戶來看。Milestone一般是四個月，再劃分小的，有3.1、3.2、3.3等等。每個小的Milestone能夠促成Milestone的條件。我們在整個小的設計上也會有小的Milestone在，具體來說整個產品的設計，如果超過兩三個星期就會很明顯的知道超時了，就知道你這個產品沒有完成。

　　微軟開發與測試規劃。這張圖是在講微軟在一個產品Milestone之內我們應該怎么樣來做。這些Milestone是在講設計產品的時候我們應該怎么做。在一個Milestone里四個功能，他們都在干什么，我特地排了這些順序和同步的事情，他們同時在干什么。Milestone剛開始的時候，PM是在做產品的設計，在訪問用戶，訪問對手的網站，產品這些會議決定我們下一步要做什么。同時Dev是在研究我們怎么樣實現這些功能，我們應該用到哪些工具，同時也可以語言有點結果的時候，把大概寫出來。Test一般在優化整個測試過程，測試工具，這些就是在沒有測試的時候，我整個框架的設計都已經可以出來了。最關鍵的一點是Spec Review，當PM寫出來以后，都會參加一個比較大的會議，會PM的Spec進行評判，對于所產生的問題，對于有漏洞的，據我們的經驗會有什么樣錯誤的，等等意見會提出來。這些討論和回答的過程，比每個Spec要長很多倍。一般在Spec沒有開Spec Review會議之前，整個Spec已經討論的差不多了，大部分的問題都已經有結論了，才會開這個會議。會議結束了，PM手上還會有一個小單子，找出各種各樣需要修改的地方，他回去稍微修改一下，就可以簽字實現了。從此之后，大家才可以干各種不同的事情。如果SR會議結束以后，可以管理DCR。

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