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