目錄

自動測試和測試工具

工具和自動化的好處

測試工具

查看器和監(jiān)視器

驅動程序

樁

壓力和負載工具

干擾注入器和噪聲發(fā)生器

分析工具

軟件測試自動化

宏錄制和回放

可編程的宏

完全可編程的自動測試工具

隨機測試：猴子和大猩猩

使用測試工具和自動化的實質

缺陷轟炸和beta測試

讓別人測試你的軟件

測試共享

beta測試

外包測試

計劃測試工作

測試計劃的目標

測試計劃主題

高級期望

人、地點和事

定義

團隊之間的責任

哪些要測試、哪些不要測試

測試的階段

測試策略

資源需求

測試員的任務分配

測試進度

測試用例

軟件缺陷報告

度量和統(tǒng)計

風險和問題

編寫和跟蹤測試用例

測試用例計劃的目標

測試用例綜述

測試設計

測試用例

測試程序

測試用例組織和跟蹤

自動測試和測試工具

測試軟件是一項艱苦的工作。如果在閱讀本書的同時已經(jīng)進行了一些測試，就會明白執(zhí)行測試工作需要投入大量的時間和精力。誠然，可以多花- -些時間對測試用例進行等價劃分，減少執(zhí)行的數(shù)量，但是隨之就會冒更多風險，因為減少了測試覆蓋范圍，選擇對某些重要的特性不進行測試。

如果測試員需要做更多測試，但是沒有時間，怎么辦?答案是采用人們在其他領域和行業(yè)中用了多年的辦法一：開 發(fā)并使用工具，使工作更加輕松和高效。本章要講的就是這方面的內容。

工具和自動化的好處

如果一個小型軟件項目有數(shù)千個測試用例要執(zhí)行，時間可能只夠執(zhí)行一次測試。 多次執(zhí)行測試是不可能的，更不用說多次測試的單調和枯燥了。通過提供比手工測試更有效的手段，軟件測試工具和自動化可以幫助解決這個問題。

工具和自動化的主要屬性是:

●速度。想一想手工嘗試Windows計算器的數(shù)千個測試用例要花多少時間。也許大約平均每5秒執(zhí)行一個測試用例。而自動化可能以10倍、100倍 甚至1000倍這樣的速度來執(zhí)行。

●效率。當測試員忙于執(zhí)行測試用例時，他會無暇干別的。如果有一個測試工具減少了執(zhí)行測試用例的時間，測試員就有更多時間進行測試計劃，考慮新的測試用例。

●準確度和精確度。測試員嘗試幾百個測試用例之后，注意力可能會分散，并開始犯錯誤。而測試工具則會一如既往地每次執(zhí)行同樣的測試，并毫無差錯地檢查結果。

●節(jié)省資源。有時要執(zhí)行一些測試用例基本上是不可能的，比如創(chuàng)建測試條件需要的人數(shù)或設備數(shù)目可能就不允許。測試工具可以用來模擬真實的情況，大大減少執(zhí)行測試需要

的物理資源。

●仿真和模擬。測試工具常用來代替正常情況下與產(chǎn)品連接的硬件或軟件。這些“偽”設備或“偽”程序以選定的方式來驅動或響應軟件一- 除此之外，實現(xiàn)起來可能困難。

●堅持不懈。測試工具和自動化永遠不會勞累或者半途而廢。它們就像電視廣告中電動的小兔子一不停地跑啊跑。

測試工具

軟件測試員會面對一大堆測試工具。使用工具的類型取決于測試的軟件類型，以及是進行黑盒測試還是白盒測試。

測試工具的好處是使用時并不是總需要深人了解工具在怎樣做或者做什么。假設正在測試允許一臺計算機同時與1百萬臺計算機連接的網(wǎng)絡軟件。即使有可能，也很難用1百萬個真實的連接進行可以控制的測試。但是，如果有人提供能夠模擬那些連接的專用工具，也許可以從1到1百萬調整連接的數(shù)目，就可以在不搭建實際連接環(huán)境的前提下進行測試。測試員不必了解工具是怎樣做到的，只要知道它做得到就可以了，這就是 黑盒測試。

另一方面，還可以建立工具監(jiān)視和改變上百萬計算機之間原始通信的工具。要有效使用這些工具，測試員需要具備一些白盒技能以及底層協(xié)議的知識。

查看器和監(jiān)視器

查看器(viewer) 或者監(jiān)視器( monitor)測試工具能夠看到正常情況下看不到的軟件運行的細節(jié)。第7章“帶上X光眼鏡測試軟件”講述了代碼覆蓋率分析器是如何提供一種方式來查看哪些代碼行得以執(zhí)行、什么函數(shù)正在運行、執(zhí)行測試時所運行的代碼分支的。代碼覆蓋:串分析器是查看工具的一個例子。大多數(shù)代碼覆蓋率分析器是人侵式工具，因為它們需要編譯并鏈接到原程序中才能獲得所需信息。

驅動程序

驅動程序是控制和操作被測試軟件的工具。最簡單的驅動程序例子是批處理文件(batchfile)，即依先后順序執(zhí)行的程序或命令的一個簡單清單。在MS-DOS時代， 這是測試員執(zhí)行測試程序的流行方式。他們會創(chuàng)建包含測試程序名稱的批處理文件，啟動運行批處理文件，然后返回。在現(xiàn)今的操作系統(tǒng)和編程語言下，執(zhí)行測試程序有更多復雜的方法。

例如，Java和Perl腳本可以取代老的MS-DOS批處理文件，并且Windows任務調度程序，可以在全天24小時的任意時刻執(zhí)行各種測試程序。

樁

樁和驅動程序一樣，屬于第7章所述的白盒測試技術。樁與驅動程序本質上是相反的，樁不控制或者操作被測試軟件;相反，它接收或者響應軟件發(fā)送的數(shù)據(jù)。給出的例子有助于澄清這一一點。如果測試向打印機發(fā)送數(shù)據(jù)的軟件，一種方法是輸入數(shù)據(jù)并打印，然后查看打印輸出結果。這樣雖然可行，但是太慢、沒有效率、易發(fā)生錯誤。怎樣分辨輸出是缺了一個像素還是一點點色差?如果換成用運行樁軟件的另一臺計算機來代替打印機，讀取并解釋打印數(shù)據(jù)，就可以非常快捷并且準確地檢驗測試結果。

壓力和負載工具

壓力(stress) 和負載(load) 工具用于向被測試軟件增加壓力和負載。文字處理程序如果作為系統(tǒng)上唯一運行的應用程序，有足夠的內存和磁盤空間，工作狀況就可能相當好。但是，如果系統(tǒng)資源不足，就極有可能碰到許多潛在軟件缺陷。雖然可以通過復制文件使磁盤占滿，運行大量程序耗盡內存等，但是這些方法效率不高，而且不夠恰當。為此專門設計的壓力工具可以使測試更加容易。

其他操作系統(tǒng)和語言也有類似的工具軟件。壓力程序可以分別設置內存量、磁盤空間大小、文件數(shù)量，以及在該機器上運行軟件的其他可用資源。

干擾注入器和噪聲發(fā)生器

另一.類工具是干擾注入器(interference injectors) 和噪聲發(fā)生器(noise generators)。 它們類似于壓力和負載工具，但是在行為上更具有隨機性。例如，壓力工具有隨機更改可用.資源的執(zhí)行模式。某個程序可能在內存充足條件下運行良好，也能應付內存不足狀況，但是如果可用內存不斷變化，就可能有問題。壓力工具的執(zhí)行模式可以暴露此類軟件缺陷。

分析工具

最后一類工具稱為分析工具(analysis tool)，是余下的- -組最佳工具。大多數(shù)軟件測試員利用以下常用工具使日常工作簡化。它們不- -定像前面的工具-樣吸引人。雖然它們常常不受重視，但是它們能夠促進測試，節(jié)省大量時間。

●文字處理軟件

●電子表格軟件

●數(shù)據(jù)庫軟件

●文件比較軟件

●抓屏和比較軟件

●調試器

●二進制一十六進制計算器

●秒表

●錄像機或者照相機

當然，軟件的復雜性和方向性總是在變。要視具體情況來決定最有效的工具是什么，以及如何運用他們。

軟件測試自動化

雖然測試自動化(test automation)只是另- .類軟件測試工具，但是它是值得特別考慮的。到目前為止，所學的軟件測試工具雖然確實有效，但是仍然需要手工操作或者監(jiān)視。假如這些工具結合起來，啟動、執(zhí)行幾乎不用人工千預會怎樣?它們可以執(zhí)行測試用例、查找軟件缺陷、分析看到的信息、記錄結果。這就是軟件測試自動化。

宏錄制和回放

宏錄制器和播放器是一種驅動程序工具。如前所述，驅動程序是用于控制和操作被測試軟件的工具。利用宏程序，測試員可以這樣做一回 放錄制的宏，重復執(zhí)行測試軟件的操作。

Macro Magic設置向導可以設置宏的如下選項:

●名稱。為宏命名以便以后辨認。即使對于小型軟件項目，也可能要編寫數(shù)百個宏。

●重復次數(shù)。重復測試是找出軟件缺陷的好方法?？梢栽O置宏在運行時重復或者循環(huán)的次數(shù)。

●觸發(fā)條件。設置宏如何啟動，可以按熱鍵( 例如Ctrl + Shift+T).輸入一串字符(例如run macro 1)、單擊快捷方式、當某個窗口顯示出來時(例如，一旦計算器啟動)或者當系統(tǒng)閑置一段時間之后來啟動。

●捕捉對象?？梢赃x擇只捕獲(記錄)鍵盤操作或鍵盤以及鼠標的移動和單擊都記錄。

●回放速度。宏回放的速度比最初錄制時最多慢20%，最多快500%。這對于軟件性能可以變化的情形很重要。假如測試的軟件變得有點慢,而宏單擊的按鈕還未出現(xiàn)在屏幕上，結果會怎樣?

●回放位置。該選項確定鼠標移動和單擊位置與某個窗口的位置是絕對的還是相對的。如果測試某個可能在屏幕上改變位置的應用程序,使鼠標移動相對于應用程序是個好主意:否則鼠標單擊位置可能不是預期的位置。

現(xiàn)在該實驗宏的錄制和回放了。尋找和下載- -些宏軟件，在幾個簡單程序( 例如計算器和記事本)。上反復試用， 驗證想法。要像測試員那樣思考!通過實驗可以發(fā)現(xiàn)雖然宏可以進行一些自動測試，使重新執(zhí)行測試更加容易和迅速，但是效果并不理想。最大的問題是缺乏驗證。宏無法檢驗軟件是否以預期方式進行。宏雖然可以在計算器中輸入100-99,但是不能測試結果是否為1-測試 員仍然要測試。誠然，這是一個問題，但是許多測試員樂于宏消除了所有重復輸人和鼠標移動。只觀察宏的執(zhí)行，確認得到預期結果是非常輕松的。

回放速度是宏的另外一個難題。即使可以調整回放的速度，也不見得總能保持宏同步執(zhí)行。網(wǎng)頁可能需要1秒或者10秒來加載。雖然可以根據(jù)預計最差情形降低宏的速度，但是它的執(zhí)行速度就會一直慢，即使軟件運行速度變快了也無濟于事。此外，如果網(wǎng)頁加載意外地用了15秒鐘，宏仍然會出現(xiàn)混亂一在 錯誤時刻單擊錯誤的位置。

可編程的宏

可編程的宏是在簡單錄制和回放的變化上的一大進步。

與其通過錄制第一次執(zhí)行測試時的操作來創(chuàng)建可編程的宏，不如在創(chuàng)建時編寫回放系統(tǒng)遵循的簡單指令。此類宏可以通過從菜單中選擇獨立的操作方式來編程一甚至不必輸入命令。

注意，此類可編程的宏與錄制的宏相比，具有真正的優(yōu)勢。盡管仍然無法驗證測試的結果，但是它可以暫停執(zhí)行，向測試員提示預期結果，并詢問測試是通過還是失敗(見圖15-8)?？删幊痰暮赀€可以解決錄制宏的許多時序問題，不是依靠絕對延時，而是等待特定條件成立才繼續(xù)執(zhí)行。在計算器例子中，宏等待程序加載之后繼續(xù)進行測試一這 是比較可靠的方法。

完全可編程的自動測試工具

這些自動化工具具有的最重要特點是進行驗證的能力，實際上就是檢查軟件是否以預期方式運行。實現(xiàn)這一點有以下幾種方式:

●屏幕捕獲。首次執(zhí)行自動測試時，可以在肯定正確的關鍵點捕捉并保存屏幕圖像。在以后進行測試時，自動化工具可以利用保存的屏幕畫面與當前屏幕畫面進行比較。如果兩者不同，就說明出現(xiàn)意外，自動化工具會把它標記為軟件缺陷。注意，使用屏幕捕獲進行測試有相當大量的工作要進行維護。即使一個像素點的變化都會導致屏幕比較失敗。除非軟件的用戶接口不變化，否則在每次測試時進行手工捕獲和比較，那就違反了自動測試的目的了。

●控件值。比屏幕捕獲更進一步，可以檢查軟件窗口中各種控件的值。如果測試計算器程序，自動化工具就會從顯區(qū)域讀取數(shù)值，與預期結果進行比較。還可以判斷是否單擊了按鈕或者選中了復選框。在測試程序中使用自動化工具可以輕松實現(xiàn)這一點。

●文件和其他輸出。同樣的，如果軟件把數(shù)據(jù)保存在文件中一例如文字處理程序一 自動化工具就能在建立文件之后將其讀出，與已知正確的文件比較。該技術同樣適用于通過調制解調器或者網(wǎng)絡發(fā)送數(shù)據(jù)的被測試軟件。自動化工具可以配置為讀回數(shù)據(jù)與預期數(shù)據(jù)進行比較。

隨機測試：猴子和大猩猩

到目前為止，我們學習的測試自動化工具和技術主要是使軟件測試員的工作更加輕松和富有成效。其設計目標是幫助測試員執(zhí)行測試用例，或者在理想狀態(tài)下，自動執(zhí)行測試用例，而不必管它。

出于該目的，使用工具和自動化有助于找出軟件缺陷;在工具忙著進行回歸測試時，軟件測試員就有更多時間計劃新的測試，設計新奇有趣的用例。

然而，另一類自動測試不是為幫助執(zhí)行或者自動執(zhí)行測試用例而設計的，其目標是模擬用戶可能的操作。此類自動化工具稱為測試猴子( test monkey )。

測試猴子的說法來源于一一個想法，如果讓一百萬只猴子在一百萬只鍵盤上敲- - 百萬年，從統(tǒng)計的角度講，它們最終就可能寫出莎士比亞話劇Adventures of Curious George (好奇喬治歷險記)等巨著。胡亂敲鍵可能無意間碰到正確的字母組合，這樣猴子瞬間變得才華橫溢,如圖15-10所示。

當軟件公開發(fā)布后，可能會有成千上萬的人使用。除非盡最大努力設計測試用例，查找缺陷，否則有些軟件缺陷就會漏掉，而被這些用戶發(fā)現(xiàn)。在產(chǎn)品發(fā)布之前，如果用模擬這些用戶可能的操作的方式來補充測試用例，結果會怎樣?這就有可能發(fā)現(xiàn)以其他測試方式會漏掉的軟件缺陷。這正是測試猴子做的工作。

使用測試工具和自動化的實質

在滿懷喜悅地準備開始在測試中使用測試工具和自動化之前，需要閱讀本節(jié)并記在心里。測試自動化不是萬能的。如果正確規(guī)劃和執(zhí)行的話，工具和自動化可以使測試效率大大提高并且能發(fā)現(xiàn)其他方式不能發(fā)現(xiàn)的缺陷。然而，如果自動化和工具步入歧途，會導致無數(shù)的自動化測試的努力被放棄，并且使項目成本大大增加。

在開始使用本章所述的技術之前，應該對以下這些重要的問題加以考慮:

●軟件變更。產(chǎn)品說明書從未修復過。后期增加了新特性。產(chǎn)品名稱在最后一刻被更改。如果錄制了數(shù)千個宏執(zhí)行全部測試，而在產(chǎn)品發(fā)布的前一周， 軟件改為啟動時多顯示一屏，結果會怎樣?所有錄制的宏都將運行失敗，因為它們不知道多出一屏。這時，需要編寫的自動化程序具備靈活性，在需要時能夠方便快捷地改變。

●人眼和直覺是不可替代的。編出來的聰明猴子的聰明有限。它們只能執(zhí)行人交給它們的測試。它們永遠不可能看到什么說:“呀，這很有趣。我還要做更多檢查”一至少 目前不會。

●驗證難以實現(xiàn)。如果測試用戶界面，驗證測試結果最簡單、最顯然的方法是捕捉和比較屏幕畫面。但是,屏幕畫面是大型文件，而且這些屏幕畫面在產(chǎn)品開發(fā)過程中不斷變化。要保證測試工具只檢查需要的畫面，而且能夠在產(chǎn)品開發(fā)過程中高效處理變化。

●容易過分依賴自動化。永遠不要因為執(zhí)行了全部自動化測試沒有發(fā)現(xiàn)軟件缺陷，就認為沒有軟件缺陷要找了。軟件缺陷仍然有，這是殺蟲劑怪現(xiàn)象。

●不要花費太多時間使用達不到測試軟件目的的測試工具和自動化。開始編寫宏和聰明猴子雖然輕松愉快，但這不是測試。這些工具有助于提高效率，但是需要在軟件運行時使用它們，并進行實際的測試，才能找出軟件缺陷。

●編寫宏、開發(fā)工具和編制猴子都屬于開發(fā)工作。軟件測試員應該遵守要求程序員遵守的標準和規(guī)范。僅僅因為你是測試員不意味著可以破壞規(guī)則。

●某些工具是入侵式的，可能導致被測試的軟件不正常地失敗。如果使用工具發(fā)現(xiàn)了一個軟件缺陷，要設法在不使用該工具的情況下重現(xiàn)這個軟件缺陷。結論可能是一個簡單的可重現(xiàn)的軟件缺陷，也可能是工具引起的問題。

缺陷轟炸和beta測試

讓別人測試你的軟件

人們很容易落入希望自己單獨負責測試軟件的陷阱中，不要這樣做。借助他人幫助會有很多收獲。

測試共享

可能的話，除非軟件項目特別小，否則至少有幾個測試員來測試軟件。即使只有幾個人，也可以多讓幾個人來查找缺陷。

一個常用方法是在一定時間內簡單互換測試任務，可以理解為“ 你執(zhí)行我的測試，我執(zhí)行你的測試”。

雙方都得以獨立查看軟件，同時完成基本測試任務。雙方還會了解自己不熟悉的軟件領城，從而可能會想出其他的測試用例來測試。至少可以讓他人花時間審查等價劃分和測試用例。他們可以根據(jù)自身經(jīng)驗為測試提供新的或不同的思路。共享測試任務的有趣方法是安排缺陷轟炸(bug bash)。缺陷轟炸是在一段時間(一般為幾個小時)內整個測試小組停下指定的常規(guī)測試任務，參加轟炸。在缺陷轟炸中，選擇軟件中某一區(qū)域，所有測試員集中測試這個區(qū)域或者這組特性。

選擇區(qū)域可能是軟件缺陷聚集之處，看是否還有更多潛伏的問題;也可能是懷疑不存在軟件缺陷的區(qū)域。利用缺陷轟炸可以確定普通測試是否會遺漏軟件缺陷，代碼編寫質量如何。選擇區(qū)域雖然有不少內在規(guī)則，但是最終要用缺陷轟炸讓許多人從特定的軟件區(qū)域尋找軟件缺陷。請求協(xié)助尋找軟件缺陷的最佳伙伴是產(chǎn)品支持或者客戶服務小組一他們在客戶打電話或者通過電子郵件咨詢問題時與客戶交談。這些人顯然對軟件缺陷非常敏感，是用來協(xié)助你測試的一一個巨大資源。找到產(chǎn)品發(fā)布后提供支持的人，請他們參加測試共享活動。他們幫忙找到的軟件缺陷會出人意料。

beta測試

這里所述的測試共享想法已經(jīng)成為內部方法，也就是說，協(xié)助共享測試的人要么來自測試小組，要么來自產(chǎn)品開發(fā)小組。另一種讓他人驗證和確認軟件的常用過程稱為beta測試( beta testing)

●誰是beta測試者?由于beta測試可能有不同的目標，因此有必要了解誰參加beta測試。例如，測試員也許想要指出軟件中殘留的易用性缺陷，但是beta測試者可能全是有經(jīng)驗的技術人員，更關心底層操作，而不是易用性。如果測試員測試的軟件部分要進行beta測試，一定要在過程中指定所需的beta測試者類型，以便從中獲得最大收獲。

●同樣，怎樣知道beta測試者使用過軟件呢?如果1000個beta測試者拿到軟件一個月后，報告沒有發(fā)現(xiàn)問題，那么是沒有軟件缺陷，還是看到軟件缺陷卻沒有報告，還是郵寄的磁盤丟失了呢? beta測試者先把軟件放上幾天才開始試用的現(xiàn)象并不少見，當他們開始試用時，使用時間和特性都很有限。執(zhí)行beta程序的測試員或者其他人一定要跟蹤參加beta測試者，以保證他們在使用軟件并符合計劃的目標。

●beta測試可以成為尋找配置和兼容性軟件缺陷的好方法。如第8章“配置測試”和第9章“兼容性測試”中所述，明確和測試能代表所有實際硬件和軟件設置的典型樣本是非常困難的。如果beta測試者挑選得明智，能夠代表目標客戶，他們就會幫大忙，找出配置和兼容性軟件缺陷。

●易用性測試是beta測試能有所作為的另一個領域。條件是精心挑選參加者一有 經(jīng)驗的用戶和無經(jīng)驗的用戶的完美結合。他們第一次看到軟件，將會輕松地找出不清楚或者難于使用之處。

●撇開配置、兼容性和易用性，beta測試在尋找軟件缺陷方面竟然出人意外地差。由于參加者一般沒有足夠的時間使用軟件，因此他們只能找出明顯的大問題一測試員可能已經(jīng)知道的。此外，因為beta測試一般在開發(fā)周期行將結束時進行，所以沒有太多時間修復找到的軟件缺陷。

●Beta測試程序會耗費測試員大量時間，測試新手的常見任務是與beta客戶一起，幫助解決他們的問題，回答提問，確認他們找到的軟件缺陷。如果受命執(zhí)行該任務，還需要和其他測試員合作，以了解軟件缺陷是怎樣溜到beta測試者那里的，以及如何改善測試用。

例，使得軟件缺陷將來能夠在內部發(fā)現(xiàn)。所有這些可能是滿負荷的工作，留給自己親自做實際測試的時間幾乎沒有。

外包測試

許多公司采用的一種常用做法是向擅長各方面軟件測試的其他公司外包或提交部分測試工作。雖然這看上去比由產(chǎn)品小組的測試員來完成要更麻煩、更昂貴，但是如果做得好，這可能成為共享測試的有效途徑。

配置和兼容性測試通常是外包測試的理想選擇。這些測試一般需要擁有眾多不同硬件和軟件組合的大型測試實驗室，以及一些人員來管理。大多數(shù)小型軟件公司無法承受維護這些測試實驗室的開銷，因此， 向專門從事配置和兼容性測試業(yè)務的公司外包測試很有意義。

本地化測試是另一個通常被外包測試的例子，除非擁有相當龐大的測試小組，否則配備能懂產(chǎn)品支持的各種語言的測試員是不可能的。小組中擁有一批講外語的測試員來查找基本的本地化問題雖然很有好處，但是外包特定語言的測試可能更加有效。專門從事本地化測試的公司擁有能講各種語言，而且具備測試經(jīng)驗的測試員。

以下是有助于使任務執(zhí)行更順利需要考慮，并與測試經(jīng)理或者項目經(jīng)理探討的問題:

●測試公司究竟要執(zhí)行哪些測試任務?誰來定義?誰來批準?

●他們遵守哪個進度?誰來制定進度?如果超過最后期限會怎樣?

●為測試公司提供哪些內容?例如軟件說明書、階段性軟件更新以及測試用例。

●測試公司提供哪些內容?至少要提供他們找出的軟件缺陷。

●如何與測試公司聯(lián)系?是電話、電子郵件、因特網(wǎng)、中心數(shù)據(jù)庫，還是每天登門造訪，誰是兩邊的聯(lián)絡點?

●怎樣知道測試公司是否滿足期望?他們怎樣知道是否滿足期望?

這些不是嚴格的科學課題，但是在匆忙外包測試任務時常常被忽視。把軟件扔過去要測試公司“測試它”是--種老毛病。然而，花一些時間提前計劃能使外包成為非常有效的測試手段，否則由于資源限制無法處理測試。

計劃測試工作

這一部分各章將把這些知識聯(lián)系起來，說明和軟件測試有關的所有工作是如何計劃、如何組織以及如何和項目小組之間進行交流的。

測試計劃的目標

測試過程不可能在真空中進行。如果程序員編寫代碼而不說明它干什么、如何工作、何時完成，執(zhí)行測試任務就很困難了。同樣，如果測試員之間不交流計劃測試的對象，需要什么資源，進度如何安排，整個項目就很難成功。軟件測試計劃( software test plan)是軟件測試員與產(chǎn)品開發(fā)小組交流意圖的主要方式。

根據(jù)該定義和IEEE的其他標準，我們注意到測試計劃采用的形式是書面文檔。這雖然并不奇怪，但卻是非常重要的一點，因為盡管最終結果只是一頁紙(或者聯(lián)機文檔，或者網(wǎng)頁),但是這頁紙不是測試計劃的全部內容。

測試計劃過程的最終目標是交流(而不是記錄)軟件測試小組的意圖、期望，以及對將要執(zhí)行的測試任務的理解。

測試計劃主題

因此，本書中看不到測試計劃模板。取而代之的是要遵循一系列重要主題的清單，該清單應該在整個項目小組一包括所有 測試員中全面討論、相互溝通并達成一致。該清單也許不能完全適用所有項目，但是因為它列出了常見的與重要測試相關的問題，所以比測試計劃模板更實用。由于從本質上講計劃是一個動態(tài)過程，因此如果發(fā)現(xiàn)列出的問題不適應具體情況，就可以自行調整。

當然，測試計劃過程的結果是某一種文檔。如果行業(yè)或者公司有自己的標準，格式可以預先定義。軟件測試文檔的IEEE標準829-1998推薦了一種常用格式。除此之外，格式可由項目小組來決定，應該能夠非常有效地交流工作成果。

高級期望

測試過程中的第1個論題是定義測試小組的高級期望。雖然這是項目小組全部成員必須一致同意的基本論題，但是常常被忽視。它們可能被認為“太過明顯”，并且想當然地假定每個人都了解一但是， 優(yōu)秀的測試員知道永遠不要假定任何事。

人、地點和事

測試計劃需要明確在項目中工作的人，他干什么，怎樣和他聯(lián)系。在小項目中這似乎沒有必要，但是即使是小項目，小組成員也可能分散在很遠的地方，或者人員變動，為跟蹤誰做什么造成困難。大型團隊可能有數(shù)十或數(shù)百個聯(lián)絡點，測試小組很可能要和所有人打交道,知道他們是誰和如何聯(lián)系是非常重要的。測試計劃應該包括項目中所有主要人員的姓名、職務、地址、電話號碼、電子郵件地址和職責范圍。

該論題最好的描述是“ 測試新手問題指南”。這通常是要測試新手負責的好的測試計劃部分。找到所有問題的答案，并把發(fā)現(xiàn)記錄下來。你想知道的也是別人想知道的。

定義

讓項目小組中的全部成員在高級質量和可靠性目標上達成一致是一件困難的事情。不幸的是，這只是軟件項目中需要定義的用詞和術語的開始?；仡櫟?章“軟件測試的背景”中關

于軟件缺陷的定義:

1)軟件未實現(xiàn)產(chǎn)品說明書要求的功能。

2)軟件出現(xiàn)了產(chǎn)品說明書指明不應該出現(xiàn)的錯誤。

3)軟件實現(xiàn)了產(chǎn)品說明書未提到的功能。

4)軟件未實現(xiàn)產(chǎn)品說明書雖未明確提及但應該實現(xiàn)的目標。

能確認小組全部成員知道、理解一更重要的是 ： 同意該定義嗎?項目經(jīng)理知道軟件測試員的目標嗎?如果不是這樣，測試計劃的過程就是保證他們要理解和同意。

以下是一些常用術語和相當松散的定義。不要把它當做完整或者定義明確的清單。它取決于具體項目、開發(fā)小組遵循的開發(fā)模式，以及小組成員的經(jīng)驗。該清單列出的術語只是在應該為項目定義哪些內容的考慮上開拓思路，并說明使全體人員了解其含義的重要性。

●構造。程序員放在一起需要測試的代碼和內容的搜集。測試計劃應該定義構造的頻率(每天、每周等)以及期望的質量等級。

●測試發(fā)布文檔(TRD)。 程序員發(fā)布的文檔。對每-一個構造都聲明新特性、不同特性、修復問題和準備測試的內容。

●Alpha版。意在對少數(shù)主要客戶和市場進行數(shù)量有限的分發(fā)，用于演示目的的早期構造。其無意在實際環(huán)境中使用。使用alpha版的所有人員必須了解確切內容和質量等級。

●Beta版。意在向潛在客戶廣泛分發(fā)的正式構造。回顧第16章“ 缺陷轟炸和beta測試”所述，進行beta測試的原因需要定義。

●說明書完成。說明書預計完成并且不再更改的日程安排。千過幾個項目之后，就會知道這個期限只能在虛幻小說中實現(xiàn)，但是它確實應該設定,以后只能進行控制范圍內的小改動。

●特性完成。程序員不再向代碼增加新特性，并集中修復缺陷的日期安排。

●軟件缺陷會議。由測試經(jīng)理、項目經(jīng)理、開發(fā)經(jīng)理和產(chǎn)品支持經(jīng)理組成的團隊，每周召

開會議審查軟件缺陷，并確定哪些需要修復，應該如何修復。軟件缺陷會議是在測試計劃中建立質量和可靠性目標的主要措施之--。

團隊之間的責任

團隊之間的責任是明確指出可能影響測試工作的任務和交付內容。測試小組的工作由許多其他功能團隊驅動一程序員、 項目經(jīng)理、技術文檔作者等。如果責任未明確，整個項目一 尤其是測試一 就會出現(xiàn)戲劇化情景:“我拿了，不，你拿了，你還沒有處理，不，我想你已經(jīng)處理過了”，從而導致重要的任務被忘記。

需要定義的任務類型不像測試員的測試、程序員的程序那樣容易分清。麻煩的任務可能有多個負責者，有時沒有責任者，或者由多人共同負責。計劃這些任務和交流計劃最容易的方法是使用如圖17-1所示的簡表。

哪些要測試、哪些不要測試

有時會驚奇地發(fā)現(xiàn)軟件產(chǎn)品中包含的某些內容不必測試。這些內容可能是以前發(fā)布過或者測試過的軟件部分。來自其他軟件公司并已經(jīng)測試過的內容可以直接接受。外包公司會提，供預先測試過的產(chǎn)品部分。計劃過程需要驗明軟件的每一部分，確定它是否要測試。如果沒有測試，需要說明這樣做的理由。如果由于誤解而使部分代碼在整個開發(fā)周期漏掉，未做任何測試，就可能導致一場災難。

測試的階段

要計劃測試的階段，測試小組就會查看預定的開發(fā)模式，并決定在項目期間是采用一個測試階段還是分階段測試。在邊寫邊改模式中，可能只有一個測試階段一不斷 測試，直到某個成員宣布測試停止。在瀑布和螺旋模式中，從檢查產(chǎn)品說明書到驗收測試可能有幾個階段，測試計劃也屬于其中一個測試階段。測試的計劃過程應該明確每一個預定的測試階段，并告知項目小組。該過程一般有助于整個小組形成和了解全部開發(fā)模式。

測試策略

與定義測試階段相關聯(lián)的練習是定義測試策略。測試策略描述測試小組用于測試整體和每個階段的方法?；仡櫟侥壳盀橹顾鶎W的軟件測試知識。如果你面對需要測試的產(chǎn)品，就需要決定使用黑盒測試好，還是白盒測試好。如果決定綜合使用這兩種技術，那么在軟件的哪些部分，什么時候運用它們呢?

某些代碼用手工測試，而其他代碼用工具和自動化測試也許是個不錯的想法。如果要使用工具，那么是否需要開發(fā)，或者能夠買到已有的商用解決方案?如果是，選擇哪一種情況?也許更有效的方法是把整個測試工作外包到專業(yè)測試公司，只要形同虛設的測試員監(jiān)督他們的工作即可。

資源需求

計劃資源需求是確定實現(xiàn)測試策略必備條件的過程。在項目期間測試可能用到的任何資源都要考慮到。例如:

●人員。人員數(shù)量、經(jīng)驗和專長?他們是全職、兼職、合同還是學生?

●設備。計算機、測試硬件、打印機、工具。

●辦公室和實驗室空間。在哪里?有多大?如何布局?

●軟件。文字處理程序、數(shù)據(jù)庫程序和自定義工具。要購買哪些東西?要寫什么材料?

●外包測試公司。用他們嗎?選擇他們有什么原則?他們的費用如何?

●其他配備。磁盤、電話、參考書、培訓資料。在項目期間還需要別的嗎?

特定資源需求取決于項目、小組和公司，因此測試計劃工作要仔細估算測試軟件的要求。開始不做好預算，到項目后期獲取資源通常很困難，甚至無法做到，因此創(chuàng)建完整清單是必要的。

測試員的任務分配

一旦定義了測試階段、測試策略和資源要求，這些信息加上產(chǎn)品說明書就可以分配每個測試員的任務。前面討論的團隊之間的責任是指哪些功能性團體(管理、測試和程序員等)負責哪些高級任務。計劃測試員任務分配是指，明確測試員負責軟件的哪些部分、哪些可測試特性。表17-1給出了一個極為簡化的Windows寫字板程序的測試員任務分配表。

測試進度

測試進度需要以上所述的全部信息，并將其映射到整個項目進度中。該階段一般在測試計劃工作中至關重要，因為原以為很容易設計和編碼的一些必要特性可能后來證實測試非常耗時。一個例子是某程序在不明顯的有限區(qū)域之外不執(zhí)行打印。沒有人意識到打印對測試的影響，而在產(chǎn)品中保留該特性，結果導致打印機配置測試要花幾周時間。作為測試計劃的一部分，完成測試進度安排可以為產(chǎn)品小組和項目經(jīng)理提供信息，以便更好地安排整個項目的進度。他們甚至會根據(jù)測試進度決定砍掉產(chǎn)品的一些特性，或者將其推遲到下一個版本中推出。

許多軟件進度安排產(chǎn)品會使該過程容易管理。項目經(jīng)理或者測試經(jīng)理最終負責進度安排,可能會使用此類軟件，但是要求測試員參與安排自己的具體任務。

測試用例

本書前面已經(jīng)講過什么是測試用例了。后面會詳細講到如何寫測試用例。測試計劃過程將決定用什么方法編寫測試用例，在哪里保存測試用例，如何使用和維護測試用例。

軟件缺陷報告

第19章“報告發(fā)現(xiàn)的問題”將講述用于記錄和跟蹤所發(fā)現(xiàn)的軟件缺陷的技術。報告的各種可能的方式包括:隔著墻壁呼喊，使用粘性便簽，使用復雜的觖陷跟蹤數(shù)據(jù)庫。使用哪些過程需要計劃，以便每個軟件缺陷從發(fā)現(xiàn)到修復的過程中都被跟蹤這樣就絕不會被忘掉。

度量和統(tǒng)計

度量和統(tǒng)計是跟蹤項目發(fā)展、成效和測試的手段。詳情見第20章“ 成效評價”。測試的計劃過程應該明確收集哪些信息，要做什么決定，誰來負責收集。實用的測試度量的例子如下:

●在項目期間每天發(fā)現(xiàn)的軟件缺陷總數(shù)。

●仍然需要修復的軟件缺陷清單。

●根據(jù)嚴重程度對當前軟件缺陷評級。

●每個測試員找出的軟件缺陷總數(shù)。

●從每個特性或者區(qū)域發(fā)現(xiàn)的軟件缺陷數(shù)目。

風險和問題

測試計劃中常用而且非常實用的部分是明確指出項目的潛在問題或者風險區(qū)域，這是對測試工作有影響的地方。假設有十幾個測試新手，全部軟件測試經(jīng)驗來自于閱讀本書，受命測試新建核電站的軟件，這就是風險。也許某個新軟件要對1500個調制解調器進行測試，在項目進度中的時間只能對其中500個進行測試，這又是一個風險。軟件測試員要負責明確指出計劃過程中的風險，并與測試經(jīng)理和項目經(jīng)理交換意見。這些風險應該在測試計劃中明確指出，在進度中給予說明。有些是真正的風險，而有些最終證實是無關緊要的。重要的是盡早明確指出，以免在項目晚期發(fā)現(xiàn)時感到驚慌。

編寫和跟蹤測試用例

測試用例計劃的目標

有一句老話:“對鵝是好東西，對鴨也是好東西”。意思是說對某個人或者團隊有益的事情對其他人或者團隊也有益。但愿讀者依據(jù)目前所學可以得出:程序員拿到產(chǎn)品說明書就立即開始編制代碼，而不必開發(fā)更詳細的計劃并分發(fā)出去審查是錯誤的。測試員拿到測試計劃馬上坐下來想出測試用例并開始測試，也應該視為錯誤的做法。如果軟件測試員指望項目經(jīng)理和程序員更加規(guī)范，向他們灌輸-些方法，按照規(guī)則來使開發(fā)過程更加順利進行，這種想法也是錯誤的。

有條不紊地仔細計劃測試用例，是達成目標的必由之路。這樣做的重要性有如下4條原因:

●組織。即使在小型軟件項目上，也可能有數(shù)千個測試用例。測試用例的建立可能需要一些測試員經(jīng)過幾個月甚至幾年時間。正確的計劃會組織好用例，以便全體測試員和其他項目小組成員有效地審查和使用。

●重復性。我們已經(jīng)知道，在項目期間有必要多次執(zhí)行同樣的測試，以尋找新的軟件缺陷，保證老的軟件缺陷得以修復。假如沒有正確的計劃，就不可能知道最后執(zhí)行哪個測試用例及其執(zhí)行情況，以便重復原有的測試。

●跟蹤。同樣，在整個項目期間需要回答一下這些重要的問題。計劃執(zhí)行多少個測試用例?在軟件最終發(fā)行版本上執(zhí)行多少個測試用例?多少個通過，多少個失敗?有被忽略的測試用例嗎?等等。如果測試用例沒有計劃，就不能回答這些問題。

●測試(或者不測試)證實。在少數(shù)高風險行業(yè)中，軟件測試小組必須證明確實執(zhí)行了計劃執(zhí)行的測試。發(fā)布忽略某些測試用例的軟件實際上是不合法和危險的。正確的測試用例計劃和跟蹤提供了一種證明測試內容的手段。

測試用例綜述

最低要求是測試小組應該創(chuàng)建包含IEEE829大綱中所述信息的測試計劃。如果書面文檔完全適用(難以置信)，那么全力使用它好了。然而，如果認為中心數(shù)據(jù)庫更有效，而且測試小組有時間和預算開支來開發(fā)或者購買，就應該使用該方法。這根本無關緊要。要緊的是完成工作后滿足了測試用例計劃的4個目標:組織、重復性、跟蹤和測試證實。

測試設計

整體項目計劃在非常高的等級上編制。它把軟件拆分為具體特性和可測試項，并將其分派到每個測試員頭上，但是不指明這些特性如何測試。測試計劃可能會提到使用自動化測試或者使用黑盒測試，或者使用白盒測試，但是不會涉及它們在哪里和如何使用的具體細節(jié)。為單個軟件特性定義測試方法的下一級細節(jié)是測試設計說明。

●標識符。用于引用和標記測試設計說明的唯一標識符。該說明還應該引用整個測試計劃，包含引用任何其他計劃或者說明的指示。

●要測試的特性。測試設計說明所包含的軟件特性描述一例如， “計算器程序的加法功能”、“寫字 板程序中的字體大小選擇和顯示”和“QuickTime軟件的視頻 卡配置測試”。該部分還將明確指出作為主要特性的輔助特性需要間接測試的特性。例如，“文件打開對話框的用戶界面雖然不是本計劃的目標，但是在測試讀寫功能的過程中要間接測試加載和保存功能”。還要列出不被測試的特性，即計劃中由于錯誤分析包含進來的特性。例如，“因為測試計算器程序的加法功能通過自動化方式發(fā)送擊鍵信息到程序來運行，所以沒有屏幕用戶界面的間接測試。用戶界面測試在單獨測試設計計劃中說明一CalcU12345中 。”

●方法。描述測試軟件特性的通用方法。如果在測試計劃中列出方法，就應該進行展開，描述要使用的技術，解釋結果如何驗證。例如，“要開發(fā)測試工具順序讀寫預先建好的各種大小的數(shù)據(jù)文件。通過黑盒技術加上程序員提供的白盒示例確定數(shù)據(jù)文件的數(shù)目、大小和包含的數(shù)據(jù)。通過文件比較工具逐位比較保存的文件和源文件來確定測試通過還是失敗。

●測試用例確認。對用于檢查特性的具體測試用例的高級描述和引用。它應該列出所選的等價劃分，并提供測試用例的引用信息以及用于執(zhí)行測試用例的程序。

●通過/失敗規(guī)則。描述測試特性的通過和失敗由什么構成。哪些可以接受，哪些不能接受。這可能是非常簡單和明確的一通過是指當執(zhí)行全部測試用例時沒有發(fā)現(xiàn)軟件缺陷;也可能是令人困惑的一失敗 是指10%以上測試用例沒有通過。然而，無疑總應該有什么構成特性的通過和失敗。

測試用例

IEEE 829標準稱測試用例說明為“ 編寫用于輸入的實際數(shù)值和預期輸出結果數(shù)值。測試用例還明確指出使用具體測試用例產(chǎn)生的測試程序的任何限制。”測試用例細節(jié)基本上應該清楚地解釋要向軟件發(fā)送什么值或者條件，以及預期結果。它可以由一個或多個測試用例說明來引用，也可以引用多個測試程序。IEEE 829標準還列出了其他應該包含在內的重要信息:

●標識符。由測試設計過程說明和測試程序說明引用的唯一標識符。

●測試項。描述被測試的詳細特性、代碼模塊等，應該比測試設計說明中所列的特性更加具體。如果測試設計說明說“計算器程序的加法功能”，那么測試用例說明會說“ 加法運算的上限溢出處理”。它還要提供產(chǎn)品說明書的引用信息或者測試用例所依據(jù)的其他設計文檔。

●輸入說明。該說明列舉送到軟件執(zhí)行測試用例的所有輸入內容或者條件。如果測試計算器程序，輸人說明可能簡單到1+1;如果測試移動電話交換軟件，輸入說明可能是成百上千種輸入條件;如果測試基于文件的產(chǎn)品，輸入說明可能是文件名和內容的描述。

●輸出說明。描述進行測試用例預期的結果。1+1等于2嗎?在移動電話軟件中上千個輸出變量設置正確嗎?加載文件的全部內容和預想的一樣嗎?

●環(huán)境要求。環(huán)境要求是指執(zhí)行測試用例必要的硬件、軟件、測試工具、實用工具、人員等。

●特殊過程要求。描述執(zhí)行測試必須做到的特殊要求。測試寫字板程序也許不需要任何特殊條件，但是測試核電站軟件就有特殊要求。

●用例之間的依賴性。第1章“軟件測試的背景”中講述了一個導致美國航天局火星極地登陸者號探測器在火星上撞毀的軟件缺陷。這是一個用例之間依賴性未形成文檔的好例子。如果一個測試用例依賴于其他用例，或者受其他用例的影響，就應該在此說明。

表述測試用例的其他選擇有簡單列表、大綱甚至諸如狀態(tài)表或數(shù)據(jù)流程圖之類的圖表。請記住，測試員在設法與他人交流測試用例時，應該使用最有效的方法。發(fā)揮創(chuàng)造性，但是要講求實際，不要偏離編寫測試用例的目的。

測試程序

編寫完測試設計和測試用例文檔之后，余下的是要執(zhí)行測試用例的程序。IEEE 829標準稱測試程序(test procedure)說明為“ 明確指出為實現(xiàn)相關測試設計而操作軟件系統(tǒng)和試驗具體測試用例的全部步驟”。測試程序或者測試腳本(test script) 說明詳細定義了執(zhí)行測試用例的每一步操作。以下是需要定義的內容:

●標識符。把測試程序與相關測試用例和測試設計捆綁在一起的唯一 標識符。

●目的。程序的目的以及將要執(zhí)行的測試用例的引用信息。.

●特殊要求。執(zhí)行程序所需的其他程序、特殊測試技術或者特殊設備。

●程序步驟。執(zhí)行測試的詳細描述: .

????????●日志。指出用什么方式、方法記錄結果和現(xiàn)象。

????????●設置。說明如何準備測試。

????????●啟動。說明用于啟動測試的步驟。

????????●程序。描述用于運行測試的步驟。

????????●度量。描述如何判斷結果一例如用秒表或者肉眼判斷。

????????●關閉。說明由于意外原因掛起測試的步驟。

????????●重啟。告訴測試人員如果出現(xiàn)故障或關者關閉以后如何在恰當?shù)臅r候重啟測試。

????????●終止。描述測試正常停止的步驟。.

????????●重置。說明如何把環(huán)境恢復到測試前的狀態(tài)。

????????●偶然事件。說明如何處理計劃之外的情況。

測試用例組織和跟蹤

在建立測試用例文檔時應該考慮的一個問題是如何組織和跟蹤信息。想一想測試員或者

測試小組應該能夠回答的下列問題:

●計劃執(zhí)行哪些測試用例?

●計劃執(zhí)行多少個測試用例?執(zhí)行需要多少時間?

●能否挑選出測試集(test suites,相關測試用例組)測試某些特性或者軟件部分?

●在執(zhí)行測試用例時，能否記錄哪-一個通過、哪-一個失敗?

●在失敗的測試用例中，哪些在最近的一次執(zhí)行時也失敗了?

●最近一次執(zhí)行測試用例時通過的百分比是多少?

這些重要問題的例子在多數(shù)項目的過程中要反復地問。第20章“成效評價”將詳細討論數(shù)據(jù)收集和統(tǒng)計。眼前先考慮管理測試用例和跟蹤執(zhí)行結果所需的一些過程。管理和跟蹤系統(tǒng)基本上有以下4種:

●憑腦子記。絕對不要考慮這一種，即使對于最簡單的項目也不例外，除非測試的軟件僅限于個人使用，沒有理由跟蹤測試。不能這樣做。

●書面文檔。對于非常小的項目可以用紙筆來管理測試用例。檢查清單的表格和框圖得到了有效利用。這顯然是管理和搜索數(shù)據(jù)的低劣方法，但是它提供了一個非常重要的物證----包含測試員親筆簽字注明執(zhí)行測試的書面檢查清單，在法律上是證明測試執(zhí)行過的極佳證據(jù)。

●電子表格。使用電子表格是跟蹤測試用例非常奏效的流行方法。圖18-4給出了一個這樣的例子。電子表格在一個地方保存測試用例的全部細節(jié)，從而可以提供測試狀態(tài)的一目了然的查看方式。這種方法容易使用，比較容易建立，可以為測試提供很好的跟蹤和證明。

●自定義數(shù)據(jù)庫。跟蹤測試用例的理想方法是使用測試用例管理工具(TestCaseManagement Tool),一種為處理測試用例而專門編程設計的數(shù)據(jù)庫。已經(jīng)有許多完成這項任務的商業(yè)應用程序。訪問第22章“軟件測試員的職業(yè)”中所列的- - 些Web鏈接，可以得到詳細信息和其他測試員的推薦。如果有興趣建立自己的跟蹤系統(tǒng)，諸如ClarisFileMaker Pro, Microsoft Access之類的數(shù)據(jù)庫軟件提供幾乎完全拖放式的數(shù)據(jù)庫建立方法，僅用幾個小時就可以建立反映IEEE 829標準的數(shù)據(jù)庫。在此基礎上可以建立能夠回答任何有關測試用例問題的報表和查詢。文章來源地址http://www.zghlxwxcb.cn/news/detail-713544.html

到了這里，關于軟件測試學習（四）自動測試和測試工具、缺陷轟炸、外包測試、計劃測試工作、編寫和跟蹤測試用例的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！