1、測(cè)試流程

　　首先說(shuō)說(shuō)測(cè)試流程，微軟的測(cè)試流程也沒什么新的東西，和大多數(shù)的測(cè)試流程一樣。

　　大致是先進(jìn)行測(cè)試準(zhǔn)備，然后是Testcase的編寫，然后是白盒測(cè)試（不一定每個(gè)項(xiàng)目都有），然后是功能測(cè)試階段，然后是驗(yàn)收測(cè)試，終release。

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

　　第一，微軟的流程執(zhí)行的非常認(rèn)真。

　　這點(diǎn)非常值得提倡，我們都知道，測(cè)試的終質(zhì)量決定于測(cè)試流程和測(cè)試人員素質(zhì)，要想測(cè)試質(zhì)量有保證，要么是流程很完善，要么你流程不行，但是個(gè)人能力超強(qiáng)。如果有一個(gè)很好的流程，算執(zhí)行的人稍微差點(diǎn)，終的質(zhì)量也不會(huì)差到哪里去。所以流程是很重要的。

　　但是，看國(guó)內(nèi)的公司欠缺的是這個(gè)，要么是沒有流程，要么流程是個(gè)花架子，沒認(rèn)真執(zhí)行過(guò)。我想微軟的測(cè)試人都是超級(jí)牛人，但是人家還是老老實(shí)實(shí)的忠實(shí)按照流程來(lái)走，我覺得這點(diǎn)非常好。（在IBM 也是這樣，筆者以前在IBM作項(xiàng)目的時(shí)候，發(fā)現(xiàn)他們的文檔寫的特認(rèn)真，流程特認(rèn)真），所以說(shuō)忠實(shí)的執(zhí)行一個(gè)好的流程是成功的一大半。

　　第二，在整個(gè)流程中，微軟非常強(qiáng)調(diào)測(cè)試盡早介入。

　　微軟在這方面是一致提倡的，按照我們國(guó)內(nèi)IT業(yè)的惡習(xí)，一般都是軟件主體差不多成型了，拉幾個(gè)測(cè)試人員過(guò)來(lái)點(diǎn)點(diǎn)，其實(shí)這是非常不好的。微軟的測(cè)試人員在項(xiàng)目一開始和開發(fā)人員同步介入，在需求階段開始介入，進(jìn)行需求評(píng)審。在開發(fā)人員開始編碼的時(shí)候，測(cè)試人員開始編寫Test case，并開發(fā)一些測(cè)試工具，或者寫一些配套的測(cè)試代碼（不要奇怪，微軟的測(cè)試人員都能寫很好的代碼）。微軟的理念是：預(yù)防bug比解決bug好，所以非常提倡測(cè)試盡早介入，把一部分bug消滅在需求階段。

　　2、自動(dòng)化流程

　　說(shuō)到自動(dòng)化，大家可能以為我是說(shuō)微軟的自動(dòng)化測(cè)試工具多牛，其實(shí)微軟內(nèi)部用到的自動(dòng)化測(cè)試工具倒是不多，算有也都是內(nèi)部開發(fā)的，非常實(shí)用的，他們不會(huì)去用MI的工具。

　　說(shuō)微軟的自動(dòng)化程度高，主要是體現(xiàn)在流程方面，譬如說(shuō)整個(gè)自動(dòng)構(gòu)建流程，在開發(fā)人員代碼check in之后，系統(tǒng)自動(dòng)發(fā)郵件，郵件內(nèi)容是一個(gè)change list，包括代碼更新list以及一個(gè)編譯者添加的comment，其內(nèi)容是該版本功能的變化或者修改掉的bug ID。整個(gè)測(cè)試過(guò)程中能用自動(dòng)化的地方都盡可能采用自動(dòng)化，盡可能減少人為失誤，并且可以使人和機(jī)器并行工作。個(gè)人覺得，這點(diǎn)很值得我們國(guó)內(nèi)的測(cè)試公司借鑒，能自動(dòng)化的流程都自動(dòng)化，減少一些不必要的溝通。

　　3、質(zhì)量控制機(jī)制

　　說(shuō)到質(zhì)量控制是個(gè)大問題，需要整個(gè)團(tuán)隊(duì)和流程提高素質(zhì)。那么微軟的質(zhì)量控制可以借鑒的是什么呢？是他們的機(jī)制。在微軟的測(cè)試流程當(dāng)中，在開發(fā)的早期，項(xiàng)目中所有的問題都是Dev leader和PM商量說(shuō)了算（當(dāng)然也要參考需求方的意見），但是到后期，具體是功能測(cè)試之后，項(xiàng)目的主動(dòng)權(quán)都在測(cè)試這邊，某個(gè)bug的要不要解決，或者項(xiàng)目進(jìn)度控制都是測(cè)試leader說(shuō)了算。這和國(guó)內(nèi)的大多數(shù)軟件公司是不一樣的，在微軟，測(cè)試人員要對(duì)終的軟件質(zhì)量負(fù)責(zé)任，但是也有相應(yīng)的權(quán)利來(lái)約束開發(fā)人員。當(dāng)然，他們也肯定有一些bug是產(chǎn)生爭(zhēng)議的，這個(gè)時(shí)候的仲裁機(jī)制是PM，這個(gè)不是我們傳統(tǒng)的PM（Project manager），而是一種具有微軟特色的PM（全稱是Program manager）。這樣，測(cè)試人員在對(duì)一些爭(zhēng)議bug的處理上有相當(dāng)?shù)脑捳Z(yǔ)權(quán)。

　　4、測(cè)試用例及管理

　　微軟的測(cè)試用例倒沒什么特別的，不過(guò)看過(guò)他們用例之后，還是覺得寫的詳細(xì)，認(rèn)真，但是又不冗長(zhǎng)拖沓，這個(gè)需要很高深的水平。另外，微軟的測(cè)試用例管理用的是微軟自己開發(fā)的用例管理工具。

　　另外值得說(shuō)明的是，微軟的每個(gè)用例都進(jìn)行了分級(jí)，并且功能所在的模塊都標(biāo)的很清楚。

　　5、效率

　　在效率方面，微軟的測(cè)試效率非常高！高的讓人驚嘆，我問一個(gè)在微軟工作的哥們，“你們那邊測(cè)試的大特點(diǎn)是什么”，他說(shuō)“大特點(diǎn)是快！”，是效率很高，具體是在測(cè)試后期過(guò)程中測(cè)試和開發(fā)之間的反饋非？欤_發(fā)修改一定量的bug，提交一個(gè)新的版本。測(cè)試人員往往能在很快的時(shí)間內(nèi)把測(cè)試結(jié)果反饋出來(lái)，一般是在1天之內(nèi)能把用例快速run一遍，這樣能減少某些后期才發(fā)現(xiàn)bug導(dǎo)致的項(xiàng)目delay。在國(guó)內(nèi)很多項(xiàng)目的通病是，開發(fā)解決問題帶進(jìn)一個(gè)新問題，測(cè)試人員整個(gè)遍歷一遍用例之后才能發(fā)現(xiàn)，這樣來(lái)回反復(fù)消耗了大量的時(shí)間。

　　但微軟是如何才能實(shí)現(xiàn)快速反饋呢？

　　第一，測(cè)試人員對(duì)程序的了解，微軟的測(cè)試人員對(duì)程序內(nèi)部結(jié)構(gòu)都非常熟悉，修改某一個(gè)地方，可能引起什么問題，哪些用例需要重新測(cè)試，測(cè)試人員非常清楚，能快速的執(zhí)行可能出錯(cuò)的地方。如果某些模塊不熟悉，那么他們會(huì)和開發(fā)人員在一起溝通這次修改可能引起的問題。

　　第二，工具！還是工具，在微軟的測(cè)試中，測(cè)試人員用各種工具幫助測(cè)試，提高測(cè)試效率是占到很大的比重。

　　第三，時(shí)間意識(shí)。微軟的測(cè)試人員有強(qiáng)烈的時(shí)間意識(shí)。