軟件測(cè)試基礎(chǔ)
文章出處：微軟 作者：不詳 發(fā)布時(shí)間：2005-11-08
一、軟件測(cè)試概述
軟件測(cè)試是軟件開發(fā)過(guò)程的重要組成部分，是用來(lái)確認(rèn)一個(gè)程序的品質(zhì)或性能是否符合開發(fā)之前所提出的一些要求。軟件測(cè)試的目的，第一是確認(rèn)軟件的質(zhì)量，其一方面是確認(rèn)軟件做了你所期望的事情（Do the right thing），另一方面是確認(rèn)軟件以正確的方式來(lái)做了這個(gè)事件（Do it right）。第二是提供信息，比如提供給開發(fā)人員或程序經(jīng)理的反饋信息，為風(fēng)險(xiǎn)評(píng)估所準(zhǔn)備的信息。第三軟件測(cè)試不僅是在測(cè)試軟件產(chǎn)品的本身，而且還包括軟件開發(fā)的過(guò)程。如果一個(gè)軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問(wèn)題，這說(shuō)明此軟件開發(fā)過(guò)程很可能是有缺陷的。因此軟件測(cè)試的第三個(gè)目的是保證整個(gè)軟件開發(fā)過(guò)程是高質(zhì)量的。
軟件質(zhì)量是由幾個(gè)方面來(lái)衡量的：一、在正確的時(shí)間用正確的的方法把一個(gè)工作做正確（Doing the right things right at the right time.）。二、符合一些應(yīng)用標(biāo)準(zhǔn)的要求，比如不同國(guó)家的用戶不同的操作習(xí)慣和要求，項(xiàng)目工程中的可維護(hù)性、可測(cè)試性等要求。三、質(zhì)量本身就是軟件達(dá)到了最開始所設(shè)定的要求，而代碼的優(yōu)美或精巧的技巧并不代表軟件的高質(zhì)量（Quality is defined as conformance to requirements, not as “goodness” or “elegance”.）。四、質(zhì)量也代表著它符合客戶的需要（Quality also means “meet customer needs”.）。作為軟件測(cè)試這個(gè)行業(yè)，最重要的一件事就是從客戶的需求出發(fā)，從客戶的角度去看產(chǎn)品，客戶會(huì)怎么去使用這個(gè)產(chǎn)品，使用過(guò)程中會(huì)遇到什么樣的問(wèn)題。只有這些問(wèn)題都解決了，軟件產(chǎn)品的質(zhì)量才可以說(shuō)是上去了。
測(cè)試人員在軟件開發(fā)過(guò)程中的任務(wù)：
1、尋找Bug；
2、避免軟件開發(fā)過(guò)程中的缺陷；
3、衡量軟件的品質(zhì)；
4、關(guān)注用戶的需求。
總的目標(biāo)是：確保軟件的質(zhì)量。
二、常用的軟件測(cè)試方法
1. 黑盒測(cè)試
黑盒測(cè)試顧名思義就是將被測(cè)系統(tǒng)看成一個(gè)黑盒，從外界取得輸入，然后再輸出。整個(gè)測(cè)試基于需求文檔，看是否能滿足需求文檔中的所有要求。黑盒測(cè)試要求測(cè)試者在測(cè)試時(shí)不能使用與被測(cè)系統(tǒng)內(nèi)部結(jié)構(gòu)相關(guān)的知識(shí)或經(jīng)驗(yàn)，它適用于對(duì)系統(tǒng)的功能進(jìn)行測(cè)試。
黑盒測(cè)試的優(yōu)點(diǎn)有：
1）比較簡(jiǎn)單，不需要了解程序內(nèi)部的代碼及實(shí)現(xiàn)；
2）與軟件的內(nèi)部實(shí)現(xiàn)無(wú)關(guān)；
3）從用戶角度出發(fā)，能很容易的知道用戶會(huì)用到哪些功能，會(huì)遇到哪些問(wèn)題；
4）基于軟件開發(fā)文檔，所以也能知道軟件實(shí)現(xiàn)了文檔中的哪些功能；
5）在做軟件自動(dòng)化測(cè)試時(shí)較為方便。
黑盒測(cè)試的缺點(diǎn)有：
1）不可能覆蓋所有的代碼，覆蓋率較低，大概只能達(dá)到總代碼量的30%；
2）自動(dòng)化測(cè)試的復(fù)用性較低。
2. 白盒測(cè)試
白盒測(cè)試是指在測(cè)試時(shí)能夠了解被測(cè)對(duì)象的結(jié)構(gòu)，可以查閱被測(cè)代碼內(nèi)容的測(cè)試工作。它需要知道程序內(nèi)部的設(shè)計(jì)結(jié)構(gòu)及具體的代碼實(shí)現(xiàn)，并以此為基礎(chǔ)來(lái)設(shè)計(jì)測(cè)試用例。如下例程序代碼：
HRESULT Play( char* pszFileName )
{
if ( NULL == pszFileName )
return;
if ( STATE_OPENED == currentState )
{
PlayTheFile();
}
return;
}
讀了代碼之后可以知道，先要檢查一個(gè)字符串是否為空，然后再根據(jù)播放器當(dāng)前的狀態(tài)來(lái)執(zhí)行相應(yīng)的動(dòng)作。可以這樣設(shè)計(jì)一些測(cè)試用例：比如字符串（文件）為空的話會(huì)出現(xiàn)什么情況；如果此時(shí)播放器的狀態(tài)是文件剛打開，會(huì)是什么情況；如果文件已經(jīng)在播放，再調(diào)用這個(gè)函數(shù)會(huì)是什么情況。也就是說(shuō)，根據(jù)播放器內(nèi)部狀態(tài)的不同，可以設(shè)計(jì)很多不同的測(cè)試用例。這些是在純粹做黑盒測(cè)試時(shí)不一定能做到的事情。
白盒測(cè)試的直接好處就是知道所設(shè)計(jì)的測(cè)試用例在代碼級(jí)上哪些地方被忽略掉，它的優(yōu)點(diǎn)是幫助軟件測(cè)試人員增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱藏的問(wèn)題。
白盒測(cè)試的缺點(diǎn)有：
1）程序運(yùn)行會(huì)有很多不同的路徑，不可能測(cè)試所有的運(yùn)行路徑；
2）測(cè)試基于代碼，只能測(cè)試開發(fā)人員做的對(duì)不對(duì)，而不能知道設(shè)計(jì)的正確與否，可能會(huì)漏掉一些功能需求；
3）系統(tǒng)龐大時(shí)，測(cè)試開銷會(huì)非常大。
3. 基于風(fēng)險(xiǎn)的測(cè)試
基于風(fēng)險(xiǎn)的測(cè)試是指評(píng)估測(cè)試的優(yōu)先級(jí)，先做高優(yōu)先級(jí)的測(cè)試，如果時(shí)間或精力不夠，低優(yōu)先級(jí)的測(cè)試可以暫時(shí)先不做。有如下一個(gè)圖，橫軸代表影響，豎軸代表概率，根據(jù)一個(gè)軟件的特點(diǎn)來(lái)確定：如果一個(gè)功能出了問(wèn)題，它對(duì)整個(gè)產(chǎn)品的影響有多大，這個(gè)功能出問(wèn)題的概率有多大？如果出問(wèn)題的概率很大，出了問(wèn)題對(duì)整個(gè)產(chǎn)品的影響也很大，那么在測(cè)試時(shí)就一定要覆蓋到。對(duì)于一個(gè)用戶很少用到的功能，出問(wèn)題的概率很小，就算出了問(wèn)題的影響也不是很大，那么如果時(shí)間比較緊的話，就可以考慮不測(cè)試。
基于風(fēng)險(xiǎn)測(cè)試的兩個(gè)決定因素就是：該功能出問(wèn)題對(duì)用戶的影響有多大，出問(wèn)題的概率有多大。其它一些影響因素還有復(fù)雜性、可用性、依賴性、可修改性等。測(cè)試人員主要根據(jù)事情的輕重緩急來(lái)決定測(cè)試工作的重點(diǎn)。
4. 基于模型的測(cè)試
模型實(shí)際上就是用語(yǔ)言把一個(gè)系統(tǒng)的行為描述出來(lái)，定義出它可能的各種狀態(tài)，以及它們之間的轉(zhuǎn)換關(guān)系，即狀態(tài)轉(zhuǎn)換圖。模型是系統(tǒng)的抽象。基于模型的測(cè)試是利用模型來(lái)生成相應(yīng)的測(cè)試用例，然后根據(jù)實(shí)際結(jié)果和原先預(yù)想的結(jié)果的差異來(lái)測(cè)試系統(tǒng)，過(guò)程如下圖所示。
三、軟件測(cè)試的類型
常見的軟件測(cè)試類型有：
BVT (Build Verification Test)
BVT是在所有開發(fā)工程師都已經(jīng)檢入自己的代碼，項(xiàng)目組編譯生成當(dāng)天的版本之后進(jìn)行，主要目的是驗(yàn)證最新生成的軟件版本在功能上是否完整，主要的軟件特性是否正確。如無(wú)大的問(wèn)題，就可以進(jìn)行相應(yīng)的功能測(cè)試。BVT優(yōu)點(diǎn)是時(shí)間短，驗(yàn)證了軟件的基本功能。缺點(diǎn)是該種測(cè)試的覆蓋率很低。因?yàn)檫\(yùn)行時(shí)間短，不可能把所有的情況都測(cè)試到。
Scenario Tests（基于用戶實(shí)際應(yīng)用場(chǎng)景的測(cè)試）
在做BVT、功能測(cè)試的時(shí)候，可能測(cè)試主要集中在某個(gè)模塊，或比較分離的功能上。當(dāng)用戶來(lái)使用這個(gè)應(yīng)用程序的時(shí)候，各個(gè)模塊是作為一個(gè)整體來(lái)使用的，那么在做測(cè)試的時(shí)候，就需要模仿用戶這樣一個(gè)真實(shí)的使用環(huán)境，即用戶會(huì)有哪些用法，會(huì)用這個(gè)應(yīng)用程序做哪些事情，操作會(huì)是一個(gè)怎樣的流程。加了這些測(cè)試用例后，再與BVT、功能測(cè)試配合，就能使軟件整體都能符合用戶使用的要求。Scenario Tests優(yōu)點(diǎn)是關(guān)注了用戶的需求，缺點(diǎn)是有時(shí)候難以真正模仿用戶真實(shí)的使用情況。
Smoke Test
在測(cè)試中發(fā)現(xiàn)問(wèn)題，找到了一個(gè)Bug，然后開發(fā)人員會(huì)來(lái)修復(fù)這個(gè)Bug。這時(shí)想知道這次修復(fù)是否真的解決了程序的Bug，或者是否會(huì)對(duì)其它模塊造成影響，就需要針對(duì)此問(wèn)題進(jìn)行專門測(cè)試，這個(gè)過(guò)程就被稱為Smoke Test。在很多情況下，做Smoke Test是開發(fā)人員在試圖解決一個(gè)問(wèn)題的時(shí)候，造成了其它功能模塊一系列的連鎖反應(yīng)，原因可能是只集中考慮了一開始的那個(gè)問(wèn)題，而忽略其它的問(wèn)題，這就可能引起了新的Bug。Smoke Test優(yōu)點(diǎn)是節(jié)省測(cè)試時(shí)間，防止build失敗。缺點(diǎn)是覆蓋率還是比較低。
此外，Application Compatibility Test（兼容性測(cè)試），主要目的是為了兼容第三方軟件，確保第三方軟件能正常運(yùn)行，用戶不受影響。Accessibility Test（軟件適用性測(cè)試），是確保軟件對(duì)于某些有殘疾的人士也能正常的使用，但優(yōu)先級(jí)比較低。其它的測(cè)試還有Functional Test（功能測(cè)試）、Security Test（安全性測(cè)試）、Stress Test（壓力測(cè)試）、Performance Test（性能測(cè)試）、Regression Test（回歸測(cè)試）、Setup/Upgrade Test（安裝升級(jí)測(cè)試）等。
四、微軟的軟件測(cè)試工作
1. 基本情況
測(cè)試在微軟公司是一項(xiàng)非常重要的工作，微軟公司在此方面的投入是非常巨大的。微軟對(duì)測(cè)試的重視表現(xiàn)在工程開發(fā)隊(duì)伍的人員構(gòu)成上，微軟的項(xiàng)目經(jīng)理、軟件開發(fā)人員和測(cè)試人員的比例基本是1：3：3或1：4：4，可以看出開發(fā)人員與測(cè)試人員的比例是1：1。對(duì)于測(cè)試的重視還表現(xiàn)在最后產(chǎn)品要發(fā)布的時(shí)候，此產(chǎn)品的所有相關(guān)部門都必須簽字，而測(cè)試人員則具有絕對(duì)的否決權(quán)。
測(cè)試人員中分成兩種職位，Software Development Engineer in Test（測(cè)試組的軟件開發(fā)工程師）實(shí)際上還是屬于開發(fā)人員，他們具備編寫代碼的能力和開發(fā)工具軟件的經(jīng)驗(yàn)，側(cè)重于開發(fā)自動(dòng)化測(cè)試工具和測(cè)試腳本，實(shí)現(xiàn)測(cè)試的自動(dòng)化。Software Test Engineer（軟件測(cè)試工程師）具體負(fù)責(zé)測(cè)試軟件產(chǎn)品，主要完成一些手工測(cè)試以及安裝配置測(cè)試。
2. 測(cè)試計(jì)劃
測(cè)試計(jì)劃是測(cè)試人員管理測(cè)試項(xiàng)目，在軟件中尋找Bug的一種有效的工具。測(cè)試計(jì)劃主要有兩個(gè)作用，一是評(píng)判團(tuán)隊(duì)的測(cè)試覆蓋率以及效率，讓測(cè)試工作很有條理的逐步展開。二是有利于與項(xiàng)目經(jīng)理、開發(fā)人員進(jìn)行溝通。有了測(cè)試計(jì)劃之后，他們就能夠知道你是如何開展測(cè)試工作的，他們也會(huì)從中提出很多有益的意見，確保測(cè)試工作順利進(jìn)行?？傊辛藴y(cè)試計(jì)劃可以更好的完成測(cè)試工作，確保用戶的滿意度。
測(cè)試人員在編寫測(cè)試計(jì)劃之前，應(yīng)獲得以下文檔：
1）程序經(jīng)理編寫的產(chǎn)品功能說(shuō)明書或產(chǎn)品開發(fā)計(jì)劃；
2）程序經(jīng)理或開發(fā)人員提供的開發(fā)進(jìn)度表。
根據(jù)產(chǎn)品的特性及開發(fā)進(jìn)度安排，測(cè)試人員制定具體的測(cè)試計(jì)劃。測(cè)試計(jì)劃通常包括以下內(nèi)容：
1）測(cè)試目標(biāo)和發(fā)布條件：
a. 給出清晰的測(cè)試目標(biāo)描述；
b. 定義產(chǎn)品的發(fā)布條件，即在達(dá)到何種測(cè)試目標(biāo)的前提下才可以發(fā)布產(chǎn)品的某個(gè)特定版本。
2）待測(cè)產(chǎn)品范圍：
a. 軟件主要特性/功能說(shuō)明，即待測(cè)軟件主要特性的列表；
b. 特性/功能測(cè)試一覽，應(yīng)涵蓋所有特性、對(duì)話框、菜單和錯(cuò)誤信息等待測(cè)內(nèi)容，并列舉每個(gè)測(cè)試范圍內(nèi)要重點(diǎn)考慮的關(guān)鍵功能。
3）測(cè)試方法描述：
a. 定義測(cè)試軟件產(chǎn)品時(shí)使用的測(cè)試方法；
b. 描述每一種特定的測(cè)試方法可以覆蓋哪些測(cè)試范圍。
4）測(cè)試進(jìn)度表：
a. 定義測(cè)試?yán)锍瘫?div style="height:15px;">
b. 定義當(dāng)前里程碑的詳細(xì)測(cè)試進(jìn)度。
5）測(cè)試資源和相關(guān)的程序經(jīng)理/開發(fā)工程師：
a. 定義參與測(cè)試的人員；
b. 描述每位測(cè)試人員的職責(zé)范圍；
c. 給出與測(cè)試有關(guān)的程序經(jīng)理/開發(fā)工程師的相關(guān)信息。
6）配置范圍和測(cè)試工具：
a. 給出測(cè)試時(shí)使用的所有計(jì)算機(jī)平臺(tái)列表；
b. 描述測(cè)試覆蓋了哪些硬件設(shè)備；
c. 測(cè)試時(shí)使用的主要測(cè)試工具。
此外，還應(yīng)列出測(cè)試中可能會(huì)面臨的風(fēng)險(xiǎn)及測(cè)試的依賴性，即測(cè)試是否依賴于某個(gè)產(chǎn)品或某個(gè)團(tuán)隊(duì)。比如此項(xiàng)測(cè)試依賴性WindowsCE這個(gè)操作系統(tǒng)，而這個(gè)系統(tǒng)要明年2月份才能做好，那么此項(xiàng)測(cè)試就可能只有在明年5月份才能完成，這樣就存在著依賴關(guān)系。如果那個(gè)團(tuán)隊(duì)的開發(fā)計(jì)劃往后推，則此項(xiàng)測(cè)試也會(huì)被推遲。
3. 測(cè)試用例開發(fā)
一個(gè)好的測(cè)試用例就是有一個(gè)合理的概率來(lái)找到Bug，不要冗余，要有針對(duì)性，一個(gè)測(cè)試只針對(duì)一件事情。特別是功能測(cè)試的時(shí)候，如果一個(gè)測(cè)試是測(cè)了兩項(xiàng)功能，那么如果測(cè)試結(jié)果失敗的話，就不知道到底是哪項(xiàng)功能出了問(wèn)題。
測(cè)試用例開發(fā)中主要使用的技術(shù)有等價(jià)類劃分，邊界值的分析，Error Guessing Testing。
等價(jià)類劃分是根據(jù)輸入輸出條件，以及自身的一些特性分成兩個(gè)或更多個(gè)子集，來(lái)減少所需要測(cè)試的用例個(gè)數(shù)，并且能用很少的測(cè)試用例來(lái)覆蓋很多的情況，減少測(cè)試用例的冗余度。在等價(jià)類劃分中，最基本的劃分是一個(gè)為合法的類，一個(gè)為不合法的類。
邊界值的分析是利用了一個(gè)規(guī)律，即程序最容易發(fā)生錯(cuò)誤的地方就是在邊界值的附近，它取決于變量的類型，以及變量的取值范圍。一般對(duì)于有n個(gè)變量時(shí)，會(huì)有6n+1個(gè)測(cè)試用例，取值分別是min-1, min, min+1, normal, max-1, max,max+1的組合。邊界值的分析的缺點(diǎn)，是對(duì)邏輯變量和布爾型變量不起作用，還有可能會(huì)忽略掉某些輸入的組合。
Error Guessing Testing完全靠的是經(jīng)驗(yàn)，所設(shè)計(jì)的測(cè)試用例就是常說(shuō)的猜測(cè)。感覺(jué)到軟件在某個(gè)地方可能出錯(cuò)，就去設(shè)計(jì)相應(yīng)的測(cè)試用例，這主要是靠實(shí)際工作中所積累的經(jīng)驗(yàn)和知識(shí)。其優(yōu)點(diǎn)是速度快，只要想得到，就能很快設(shè)計(jì)出測(cè)試用例。缺點(diǎn)就是沒(méi)有系統(tǒng)性，無(wú)法知道覆蓋率會(huì)有多少，很可能會(huì)遺漏一些測(cè)試領(lǐng)域。
實(shí)際上在微軟是采用一些專門的軟件或工具負(fù)責(zé)測(cè)試用例的管理，有一些測(cè)試信息可以被記錄下來(lái)，比如測(cè)試用例的簡(jiǎn)單描述，在哪些平臺(tái)執(zhí)行，是手工測(cè)試還是自動(dòng)測(cè)試，運(yùn)行的頻率是每天運(yùn)行一次，還是每周運(yùn)行一次。此外還有清晰的測(cè)試通過(guò)或失敗的標(biāo)準(zhǔn)，以及詳細(xì)記錄測(cè)試的每個(gè)步驟。
4. Bug跟蹤過(guò)程
在軟件開發(fā)項(xiàng)目中，測(cè)試人員的一項(xiàng)最重要使命就是對(duì)所有已知Bug進(jìn)行有效的跟蹤和管理，保證產(chǎn)品中出現(xiàn)的所有問(wèn)題都可以得到有效的解決。一般地，項(xiàng)目組發(fā)現(xiàn)、定位、處理和最終解決一個(gè)Bug的過(guò)程包括Bug報(bào)告、Bug評(píng)估和分配、Bug處理、Bug關(guān)閉等四個(gè)階段：
1）測(cè)試工程師在測(cè)試過(guò)程中發(fā)現(xiàn)新的Bug后，應(yīng)向項(xiàng)目組報(bào)告該Bug的位置、表現(xiàn)、當(dāng)前狀態(tài)等信息。項(xiàng)目組在Bug數(shù)據(jù)庫(kù)中添加該Bug的記錄。
2）開發(fā)經(jīng)理對(duì)已發(fā)現(xiàn)的Bug進(jìn)行集中討論，根據(jù)Bug對(duì)軟件產(chǎn)品的影響來(lái)評(píng)估Bug的優(yōu)先級(jí)，制定Bug的修正策略。按照Bug的優(yōu)先級(jí)順序和開發(fā)人員的工作安排，開發(fā)經(jīng)理將所有需要立即處理的Bug分配給相應(yīng)的開發(fā)工程師。
3）開發(fā)工程師根據(jù)安排對(duì)特定的Bug進(jìn)行處理，找出代碼中的錯(cuò)誤原因，修改代碼，重新生成產(chǎn)品版本。
4）開發(fā)工程師處理了Bug之后，測(cè)試人員需要對(duì)處理后的結(jié)果進(jìn)行驗(yàn)證，經(jīng)過(guò)驗(yàn)證確認(rèn)已正確處理的Bug被標(biāo)記為關(guān)閉（Close）狀態(tài)。測(cè)試工程師既需要驗(yàn)證Bug是否已經(jīng)被修正，也需要確定開發(fā)人員有沒(méi)有在修改代碼的同時(shí)引入新的Bug。
5. Bug的不同處理方式
在某些情況下，Bug已處理并不意味著Bug已經(jīng)被修正。開發(fā)工程師可以推遲Bug的修正時(shí)間，也可以在分析之后告知測(cè)試工程師這實(shí)際上不是一個(gè)真正的Bug。也就是說(shuō)，某特定的Bug經(jīng)開發(fā)工程師處理之后，該Bug可能包括以下幾種狀態(tài)。
已修正：開發(fā)工程師已經(jīng)修正了相應(yīng)的程序代碼，該Bug不會(huì)出現(xiàn)了。
可推遲：該Bug的重要程度較低，不會(huì)影響當(dāng)前應(yīng)提交版本的主要功能，可安排在下一版本中再行處理。
設(shè)計(jì)問(wèn)題：該Bug與程序?qū)崿F(xiàn)無(wú)關(guān)，其所表現(xiàn)出來(lái)的行為完全符合設(shè)計(jì)要求，對(duì)此應(yīng)提交給程序經(jīng)理處理。
無(wú)需修正：該Bug的重要程度非常低，根本不會(huì)影響程序的功能，項(xiàng)目組沒(méi)有必要在這些Bug上浪費(fèi)時(shí)間。
五、成為優(yōu)秀測(cè)試工程師的要求
要成為一名優(yōu)秀的測(cè)試工程師，首先對(duì)計(jì)算機(jī)的基本知識(shí)要有很好的了解，精通一門或多門的編程語(yǔ)言，具備一定的程序調(diào)試技能，掌握測(cè)試工具的開發(fā)和使用技術(shù)。同時(shí)要比較細(xì)心，會(huì)按照任務(wù)的輕重緩急來(lái)安排自己的工作，要有很好的溝通能力。此外，還要善于用非常規(guī)的方式思考問(wèn)題，盡可能多的參加軟件測(cè)試項(xiàng)目，在實(shí)踐中學(xué)習(xí)技能，積累經(jīng)驗(yàn)，不斷分析和總結(jié)軟件開發(fā)過(guò)程中可能出錯(cuò)的環(huán)節(jié)。這樣，一名優(yōu)秀的測(cè)試工程師就從軟件測(cè)試的實(shí)踐中脫穎而出了。
結(jié)束語(yǔ)：微軟的軟件開發(fā)經(jīng)驗(yàn)積淀深厚，微軟工程師們的授課生動(dòng)溢彩，其中有些內(nèi)容是結(jié)合編程代碼所作的詳細(xì)講解，較難用介紹性文字加以概括提煉，加之筆者受能力和精力所限，只能擷取部分精華內(nèi)容整理成文以饗讀者，因此難免是掛一漏萬(wàn)，甚至?xí)惺д`之處，敬請(qǐng)對(duì)本系列文章的關(guān)注者諒解及指正。最后對(duì)微軟老師們的辛勤付出再表由衷謝意！
