一,、軟件測試概述

軟件測試是軟件開發(fā)過程的重要組成部分,，是用來確認一個程序的品質(zhì)或性能是否符合開發(fā)之前所提出的一些要求。軟件測試的目的,，第一是確認軟件的質(zhì)量,，其一方面是確認軟件做了你所期望的事情（Do the right thing），另一方面是確認軟件以正確的方式來做了這個事件（Do it right）,。第二是提供信息,，比如提供給開發(fā)人員或程序經(jīng)理的反饋信息，為風險評估所準備的信息,。第三軟件測試不僅是在測試軟件產(chǎn)品的本身,，而且還包括軟件開發(fā)的過程。如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題,，這說明此軟件開發(fā)過程很可能是有缺陷的,。因此軟件測試的第三個目的是保證整個軟件開發(fā)過程是高質(zhì)量的。

軟件質(zhì)量是由幾個方面來衡量的：一,、在正確的時間用正確的的方法把一個工作做正確（Doing the right things right at the right time.）,。二、符合一些應用標準的要求,，比如不同國家的用戶不同的操作習慣和要求,，項目工程中的可維護性、可測試性等要求,。三,、質(zhì)量本身就是軟件達到了最開始所設定的要求，而代碼的優(yōu)美或精巧的技巧并不代表軟件的高質(zhì)量（Quality is defined as conformance to requirements, not as “goodness” or “elegance”.）,。四,、質(zhì)量也代表著它符合客戶的需要（Quality also means “meet customer needs”.）。作為軟件測試這個行業(yè),，最重要的一件事就是從客戶的需求出發(fā),，從客戶的角度去看產(chǎn)品，客戶會怎么去使用這個產(chǎn)品,，使用過程中會遇到什么樣的問題,。只有這些問題都解決了，軟件產(chǎn)品的質(zhì)量才可以說是上去了,。

測試人員在軟件開發(fā)過程中的任務：

1,、尋找Bug；

2、避免軟件開發(fā)過程中的缺陷,；

3,、衡量軟件的品質(zhì)；

4,、關(guān)注用戶的需求,。

總的目標是：確保軟件的質(zhì)量。

 

二,、常用的軟件測試方法

1. 黑盒測試

黑盒測試顧名思義就是將被測系統(tǒng)看成一個黑盒，從外界取得輸入,，然后再輸出,。整個測試基于需求文檔，看是否能滿足需求文檔中的所有要求,。黑盒測試要求測試者在測試時不能使用與被測系統(tǒng)內(nèi)部結(jié)構(gòu)相關(guān)的知識或經(jīng)驗,，它適用于對系統(tǒng)的功能進行測試。

黑盒測試的優(yōu)點有：
1）比較簡單,，不需要了解程序內(nèi)部的代碼及實現(xiàn),；

2）與軟件的內(nèi)部實現(xiàn)無關(guān)；

3）從用戶角度出發(fā),，能很容易的知道用戶會用到哪些功能,，會遇到哪些問題；

4）基于軟件開發(fā)文檔,，所以也能知道軟件實現(xiàn)了文檔中的哪些功能,；

5）在做軟件自動化測試時較為方便。

黑盒測試的缺點有：
1）不可能覆蓋所有的代碼,，覆蓋率較低,，大概只能達到總代碼量的30%；

2）自動化測試的復用性較低,。

2. 白盒測試

白盒測試是指在測試時能夠了解被測對象的結(jié)構(gòu),，可以查閱被測代碼內(nèi)容的測試工作。它需要知道程序內(nèi)部的設計結(jié)構(gòu)及具體的代碼實現(xiàn),，并以此為基礎來設計測試用例,。如下例程序代碼：

 

HRESULT Play( char* pszFileName )

{

if ( NULL == pszFileName )

return;

if ( STATE_OPENED == currentState )

{

PlayTheFile();

}

return;

}

 

讀了代碼之后可以知道，先要檢查一個字符串是否為空,，然后再根據(jù)播放器當前的狀態(tài)來執(zhí)行相應的動作,。可以這樣設計一些測試用例：比如字符串（文件）為空的話會出現(xiàn)什么情況,；如果此時播放器的狀態(tài)是文件剛打開,，會是什么情況；如果文件已經(jīng)在播放，再調(diào)用這個函數(shù)會是什么情況,。也就是說,，根據(jù)播放器內(nèi)部狀態(tài)的不同，可以設計很多不同的測試用例,。這些是在純粹做黑盒測試時不一定能做到的事情,。

白盒測試的直接好處就是知道所設計的測試用例在代碼級上哪些地方被忽略掉，它的優(yōu)點是幫助軟件測試人員增大代碼的覆蓋率,，提高代碼的質(zhì)量,，發(fā)現(xiàn)代碼中隱藏的問題。

白盒測試的缺點有：

1）程序運行會有很多不同的路徑,，不可能測試所有的運行路徑,；

2）測試基于代碼，只能測試開發(fā)人員做的對不對,，而不能知道設計的正確與否,，可能會漏掉一些功能需求；

3）系統(tǒng)龐大時,，測試開銷會非常大,。

3. 基于風險的測試

基于風險的測試是指評估測試的優(yōu)先級，先做高優(yōu)先級的測試,，如果時間或精力不夠,，低優(yōu)先級的測試可以暫時先不做。有如下一個圖,，橫軸代表影響,，豎軸代表概率，根據(jù)一個軟件的特點來確定：如果一個功能出了問題,，它對整個產(chǎn)品的影響有多大,，這個功能出問題的概率有多大,？如果出問題的概率很大,，出了問題對整個產(chǎn)品的影響也很大,，那么在測試時就一定要覆蓋到,。對于一個用戶很少用到的功能，出問題的概率很小,，就算出了問題的影響也不是很大,，那么如果時間比較緊的話，就可以考慮不測試,。

 

基于風險測試的兩個決定因素就是：該功能出問題對用戶的影響有多大,，出問題的概率有多大,。其它一些影響因素還有復雜性,、可用性,、依賴性、可修改性等,。測試人員主要根據(jù)事情的輕重緩急來決定測試工作的重點。

4. 基于模型的測試

模型實際上就是用語言把一個系統(tǒng)的行為描述出來,，定義出它可能的各種狀態(tài)，以及它們之間的轉(zhuǎn)換關(guān)系,，即狀態(tài)轉(zhuǎn)換圖。模型是系統(tǒng)的抽象,。基于模型的測試是利用模型來生成相應的測試用例,，然后根據(jù)實際結(jié)果和原先預想的結(jié)果的差異來測試系統(tǒng),，過程如下圖所示,。

 

三,、軟件測試的類型

常見的軟件測試類型有：

BVT (Build Verification Test)

BVT是在所有開發(fā)工程師都已經(jīng)檢入自己的代碼，項目組編譯生成當天的版本之后進行,，主要目的是驗證最新生成的軟件版本在功能上是否完整,，主要的軟件特性是否正確。如無大的問題,，就可以進行相應的功能測試,。BVT優(yōu)點是時間短,，驗證了軟件的基本功能。缺點是該種測試的覆蓋率很低,。因為運行時間短,，不可能把所有的情況都測試到,。

Scenario Tests（基于用戶實際應用場景的測試）

在做BVT,、功能測試的時候，可能測試主要集中在某個模塊,，或比較分離的功能上,。當用戶來使用這個應用程序的時候，各個模塊是作為一個整體來使用的,，那么在做測試的時候，就需要模仿用戶這樣一個真實的使用環(huán)境,，即用戶會有哪些用法,，會用這個應用程序做哪些事情，操作會是一個怎樣的流程,。加了這些測試用例后，再與BVT,、功能測試配合,，就能使軟件整體都能符合用戶使用的要求。Scenario Tests優(yōu)點是關(guān)注了用戶的需求,，缺點是有時候難以真正模仿用戶真實的使用情況,。

Smoke Test

在測試中發(fā)現(xiàn)問題，找到了一個Bug,，然后開發(fā)人員會來修復這個Bug。這時想知道這次修復是否真的解決了程序的Bug,，或者是否會對其它模塊造成影響,，就需要針對此問題進行專門測試,，這個過程就被稱為Smoke Test。在很多情況下,，做Smoke Test是開發(fā)人員在試圖解決一個問題的時候,，造成了其它功能模塊一系列的連鎖反應，原因可能是只集中考慮了一開始的那個問題,，而忽略其它的問題,，這就可能引起了新的Bug。Smoke Test優(yōu)點是節(jié)省測試時間,，防止build失敗,。缺點是覆蓋率還是比較低,。

此外，Application Compatibility Test（兼容性測試）,，主要目的是為了兼容第三方軟件,，確保第三方軟件能正常運行，用戶不受影響,。Accessibility Test（軟件適用性測試）,，是確保軟件對于某些有殘疾的人士也能正常的使用，但優(yōu)先級比較低,。其它的測試還有Functional Test（功能測試）,、Security Test（安全性測試）、Stress Test（壓力測試）,、Performance Test（性能測試）,、Regression Test（回歸測試）、Setup/Upgrade Test（安裝升級測試）等,。

 

四,、微軟的軟件測試工作

1. 基本情況

測試在微軟公司是一項非常重要的工作，微軟公司在此方面的投入是非常巨大的,。微軟對測試的重視表現(xiàn)在工程開發(fā)隊伍的人員構(gòu)成上,，微軟的項目經(jīng)理、軟件開發(fā)人員和測試人員的比例基本是1：3：3或1：4：4,，可以看出開發(fā)人員與測試人員的比例是1：1,。對于測試的重視還表現(xiàn)在最后產(chǎn)品要發(fā)布的時候，此產(chǎn)品的所有相關(guān)部門都必須簽字,，而測試人員則具有絕對的否決權(quán),。

測試人員中分成兩種職位，Software Development Engineer in Test（測試組的軟件開發(fā)工程師）實際上還是屬于開發(fā)人員,，他們具備編寫代碼的能力和開發(fā)工具軟件的經(jīng)驗，側(cè)重于開發(fā)自動化測試工具和測試腳本,，實現(xiàn)測試的自動化,。Software Test Engineer（軟件測試工程師）具體負責測試軟件產(chǎn)品，主要完成一些手工測試以及安裝配置測試,。

2. 測試計劃

測試計劃是測試人員管理測試項目,，在軟件中尋找Bug的一種有效的工具。測試計劃主要有兩個作用,，一是評判團隊的測試覆蓋率以及效率,，讓測試工作很有條理的逐步展開。二是有利于與項目經(jīng)理,、開發(fā)人員進行溝通,。有了測試計劃之后,，他們就能夠知道你是如何開展測試工作的，他們也會從中提出很多有益的意見,，確保測試工作順利進行,。總之,，有了測試計劃可以更好的完成測試工作,，確保用戶的滿意度。

測試人員在編寫測試計劃之前,，應獲得以下文檔：

1）程序經(jīng)理編寫的產(chǎn)品功能說明書或產(chǎn)品開發(fā)計劃,；

2）程序經(jīng)理或開發(fā)人員提供的開發(fā)進度表。

根據(jù)產(chǎn)品的特性及開發(fā)進度安排,，測試人員制定具體的測試計劃,。測試計劃通常包括以下內(nèi)容：

1）測試目標和發(fā)布條件：

a. 給出清晰的測試目標描述；

b. 定義產(chǎn)品的發(fā)布條件,，即在達到何種測試目標的前提下才可以發(fā)布產(chǎn)品的某個特定版本,。

2）待測產(chǎn)品范圍：

a. 軟件主要特性/功能說明，即待測軟件主要特性的列表,；

b. 特性/功能測試一覽,，應涵蓋所有特性、對話框,、菜單和錯誤信息等待測內(nèi)容,，并列舉每個測試范圍內(nèi)要重點考慮的關(guān)鍵功能。

3）測試方法描述：

a. 定義測試軟件產(chǎn)品時使用的測試方法,；

b. 描述每一種特定的測試方法可以覆蓋哪些測試范圍,。

4）測試進度表：

a. 定義測試里程碑；

b. 定義當前里程碑的詳細測試進度,。

5）測試資源和相關(guān)的程序經(jīng)理/開發(fā)工程師：

a. 定義參與測試的人員,；

b. 描述每位測試人員的職責范圍；

c. 給出與測試有關(guān)的程序經(jīng)理/開發(fā)工程師的相關(guān)信息,。

6）配置范圍和測試工具：

a. 給出測試時使用的所有計算機平臺列表,；

b. 描述測試覆蓋了哪些硬件設備；

c. 測試時使用的主要測試工具,。

此外,，還應列出測試中可能會面臨的風險及測試的依賴性，即測試是否依賴于某個產(chǎn)品或某個團隊,。比如此項測試依賴性WindowsCE這個操作系統(tǒng),，而這個系統(tǒng)要明年2月份才能做好，那么此項測試就可能只有在明年5月份才能完成，這樣就存在著依賴關(guān)系,。如果那個團隊的開發(fā)計劃往后推,，則此項測試也會被推遲。

3. 測試用例開發(fā)

一個好的測試用例就是有一個合理的概率來找到Bug,，不要冗余,，要有針對性，一個測試只針對一件事情,。特別是功能測試的時候,，如果一個測試是測了兩項功能，那么如果測試結(jié)果失敗的話,，就不知道到底是哪項功能出了問題,。

測試用例開發(fā)中主要使用的技術(shù)有等價類劃分，邊界值的分析,，Error Guessing Testing,。

等價類劃分是根據(jù)輸入輸出條件，以及自身的一些特性分成兩個或更多個子集,，來減少所需要測試的用例個數(shù),，并且能用很少的測試用例來覆蓋很多的情況，減少測試用例的冗余度,。在等價類劃分中,，最基本的劃分是一個為合法的類，一個為不合法的類,。

邊界值的分析是利用了一個規(guī)律,，即程序最容易發(fā)生錯誤的地方就是在邊界值的附近，它取決于變量的類型,，以及變量的取值范圍,。一般對于有n個變量時，會有6n+1個測試用例,，取值分別是min-1, min, min+1, normal, max-1, max,max+1的組合,。邊界值的分析的缺點，是對邏輯變量和布爾型變量不起作用,，還有可能會忽略掉某些輸入的組合,。

Error Guessing Testing完全靠的是經(jīng)驗，所設計的測試用例就是常說的猜測,。感覺到軟件在某個地方可能出錯,，就去設計相應的測試用例,，這主要是靠實際工作中所積累的經(jīng)驗和知識,。其優(yōu)點是速度快，只要想得到,，就能很快設計出測試用例,。缺點就是沒有系統(tǒng)性,，無法知道覆蓋率會有多少，很可能會遺漏一些測試領(lǐng)域,。

實際上在微軟是采用一些專門的軟件或工具負責測試用例的管理,，有一些測試信息可以被記錄下來，比如測試用例的簡單描述,，在哪些平臺執(zhí)行,，是手工測試還是自動測試，運行的頻率是每天運行一次,，還是每周運行一次,。此外還有清晰的測試通過或失敗的標準，以及詳細記錄測試的每個步驟,。

4. Bug跟蹤過程

在軟件開發(fā)項目中,，測試人員的一項最重要使命就是對所有已知Bug進行有效的跟蹤和管理，保證產(chǎn)品中出現(xiàn)的所有問題都可以得到有效的解決,。一般地,，項目組發(fā)現(xiàn)、定位,、處理和最終解決一個Bug的過程包括Bug報告,、Bug評估和分配、Bug處理,、Bug關(guān)閉等四個階段：

1）測試工程師在測試過程中發(fā)現(xiàn)新的Bug后,，應向項目組報告該Bug的位置、表現(xiàn),、當前狀態(tài)等信息,。項目組在Bug數(shù)據(jù)庫中添加該Bug的記錄。

2）開發(fā)經(jīng)理對已發(fā)現(xiàn)的Bug進行集中討論,，根據(jù)Bug對軟件產(chǎn)品的影響來評估Bug的優(yōu)先級,，制定Bug的修正策略。按照Bug的優(yōu)先級順序和開發(fā)人員的工作安排,，開發(fā)經(jīng)理將所有需要立即處理的Bug分配給相應的開發(fā)工程師,。

3）開發(fā)工程師根據(jù)安排對特定的Bug進行處理，找出代碼中的錯誤原因,，修改代碼,，重新生成產(chǎn)品版本。

4）開發(fā)工程師處理了Bug之后,，測試人員需要對處理后的結(jié)果進行驗證,，經(jīng)過驗證確認已正確處理的Bug被標記為關(guān)閉（Close）狀態(tài)。測試工程師既需要驗證Bug是否已經(jīng)被修正，也需要確定開發(fā)人員有沒有在修改代碼的同時引入新的Bug,。

5. Bug的不同處理方式

在某些情況下,，Bug已處理并不意味著Bug已經(jīng)被修正。開發(fā)工程師可以推遲Bug的修正時間,，也可以在分析之后告知測試工程師這實際上不是一個真正的Bug,。也就是說，某特定的Bug經(jīng)開發(fā)工程師處理之后,，該Bug可能包括以下幾種狀態(tài),。

已修正：開發(fā)工程師已經(jīng)修正了相應的程序代碼，該Bug不會出現(xiàn)了,。

可推遲：該Bug的重要程度較低,，不會影響當前應提交版本的主要功能，可安排在下一版本中再行處理,。

設計問題：該Bug與程序?qū)崿F(xiàn)無關(guān),，其所表現(xiàn)出來的行為完全符合設計要求，對此應提交給程序經(jīng)理處理,。

無需修正：該Bug的重要程度非常低,，根本不會影響程序的功能，項目組沒有必要在這些Bug上浪費時間,。

 

五,、成為優(yōu)秀測試工程師的要求

要成為一名優(yōu)秀的測試工程師，首先對計算機的基本知識要有很好的了解,，精通一門或多門的編程語言,，具備一定的程序調(diào)試技能，掌握測試工具的開發(fā)和使用技術(shù),。同時要比較細心,，會按照任務的輕重緩急來安排自己的工作，要有很好的溝通能力,。此外,，還要善于用非常規(guī)的方式思考問題，盡可能多的參加軟件測試項目,，在實踐中學習技能,，積累經(jīng)驗，不斷分析和總結(jié)軟件開發(fā)過程中可能出錯的環(huán)節(jié),。這樣,，一名優(yōu)秀的測試工程師就從軟件測試的實踐中脫穎而出了。

 

 

結(jié)束語：微軟的軟件開發(fā)經(jīng)驗積淀深厚,，微軟工程師們的授課生動溢彩,，其中有些內(nèi)容是結(jié)合編程代碼所作的詳細講解,，較難用介紹性文字加以概括提煉，加之筆者受能力和精力所限,，只能擷取部分精華內(nèi)容整理成文以饗讀者，因此難免是掛一漏萬,，甚至會有失誤之處,，敬請對本系列文章的關(guān)注者諒解及指正。最后對微軟老師們的辛勤付出再表由衷謝意,！