使用人工或者自動手段來運行或測試某個系統(tǒng)的過程,其目的在于檢驗它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實際結(jié)果之間的差別.
　　它是幫助識別開發(fā)完成（中間或最終的版本）的計算機(jī)軟件（整體或部分）的正確度(correctness)、完全度(completeness)和質(zhì)量(quality)的軟件過程；是SQA(softwarequalityassurance)的重要子域。
　　GrenfordJ.Myers曾對軟件測試的目的提出過以下觀點:
　　(1)測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；
　　(2)好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；
　　(3)成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。
　　然而,這種觀點指出測試是以查找錯誤為中心,而不是為了演示軟件的正確功能.但是只從字面意思理解,可能會產(chǎn)生誤導(dǎo),認(rèn)為發(fā)現(xiàn)錯誤是軟件測試的唯一目的,查找不出錯誤的測試就是沒有價值的測試,實際上并非如此!
　　(1)測試并不僅僅是為了找出錯誤.通過分析錯誤產(chǎn)生的原因和錯誤的發(fā)生趨勢,可以幫助項目管理者
　　發(fā)現(xiàn)當(dāng)前軟件開發(fā)過程中的缺陷,以便及時改進(jìn)；
　　(2)這種分析也能幫助測試人員設(shè)計出有針對性的測試方法,改善測試的效率和有效性；
　　(3)沒有發(fā)現(xiàn)錯誤的測試也是有價值的,完整的測試是評定軟件質(zhì)量的一種方法

　　軟件測試的內(nèi)容
　　
　　軟件測試主要工作內(nèi)容是驗證(verification)和確認(rèn)(validation)，下面分別給出其概念：
　　驗證(verification)是保證軟件正確地實現(xiàn)了一些特定功能的一系列活動，即保證軟件做了你所期望的事情。(Dotherightthing)
　　1.確定軟件生存周期中的一個給定階段的產(chǎn)品是否達(dá)到前階段確立的需求的過程；
　　2.程序正確性的形式證明，即采用形式理論證明程序符號設(shè)一計規(guī)約規(guī)定的過程；
　　3.評市、審查、測試、檢查、審計等各類活動，或?qū)δ承╉椞幚?、服?wù)或文件等是否和規(guī)定的需求相一致進(jìn)行判斷和提出報告。
　　確認(rèn)(validation)是一系列的活動和過程，目的是想證實在一個給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式來做了這個事件(Doitright)
　　1.靜態(tài)確認(rèn)，不在計算機(jī)上實際執(zhí)行程序，通過人工或程序分析來證明軟件的正確性；
　　2.動態(tài)確認(rèn)，通過執(zhí)行程序做分析，測試程序的動態(tài)行為，以證實軟件是否存在問題。
　　軟件測試的對象不僅僅是程序測試，軟件測試應(yīng)該包括整個軟件開發(fā)期問各個階段所產(chǎn)生的文檔，如需求規(guī)格說明、概要設(shè)計文檔、詳細(xì)設(shè)計文檔，當(dāng)然軟件測試的主要對象還是源程序。
　　從不同的角度出發(fā)，軟件測試可以劃分為不同的分類
　　從是否關(guān)心軟件內(nèi)部結(jié)構(gòu)和具體實現(xiàn)的角度劃分
　　A.白盒測試
　　B.黑盒測試
　　C.灰盒測試
　　從是否執(zhí)行程序的角度
　　
　　A.靜態(tài)測試
　　B.動態(tài)測試。
　　從軟件開發(fā)的過程按階段劃分有
　　A.單元測試
　　B.集成測試
　　C.確認(rèn)測試
　　D.驗收測試
　　E.系統(tǒng)測試
     

 軟件測試是軟件開發(fā)過程的重要組成部分，是用來確認(rèn)一個程序的品質(zhì)或性能是否符合開發(fā)之前所提出的一些要求。軟件測試就是在軟件投入運行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。軟件測試在軟件生存期中橫跨兩個階段：通常在編寫出每一個模塊之后就對它做必要的測試（稱為單元測試）。編碼和單元測試屬于軟件生存期中的同一個階段。在結(jié)束這個階段后對軟件系統(tǒng)還要進(jìn)行各種綜合測試，這是軟件生存期的另一個獨立階段，即測試階段。

      軟件測試的目的，第一是確認(rèn)軟件的質(zhì)量，其一方面是確認(rèn)軟件做了你所期望的事情（Do the right thing），另一方面是確認(rèn)軟件以正確的方式來做了這個事件（Do it right）。

      第二是提供信息，比如提供給開發(fā)人員或程序經(jīng)理的反饋信息，為風(fēng)險評估所準(zhǔn)備的信息。

      第三軟件測試不僅是在測試軟件產(chǎn)品的本身，而且還包括軟件開發(fā)的過程。如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題，這說明此軟件開發(fā)過程很可能是有缺陷的。因此軟件測試的第三個目的是保證整個軟件開發(fā)過程是高質(zhì)量的。

      軟件質(zhì)量是由幾個方面來衡量的：一、在正確的時間用正確的的方法把一個工作做正確（Doing the right things right at the right time.）。二、符合一些應(yīng)用標(biāo)準(zhǔn)的要求，比如不同國家的用戶不同的操作習(xí)慣和要求，項目工程中的可維護(hù)性、可測試性等要求。三、質(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”.）。作為軟件測試這個行業(yè)，最重要的一件事就是從客戶的需求出發(fā)，從客戶的角度去看產(chǎn)品，客戶會怎么去使用這個產(chǎn)品，使用過程中會遇到什么樣的問題。只有這些問題都解決了，軟件產(chǎn)品的質(zhì)量才可以說是上去了。

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

      1、尋找Bug；
      2、避免軟件開發(fā)過程中的缺陷；
      3、衡量軟件的品質(zhì)；
      4、關(guān)注用戶的需求。

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

      軟件測試從不同的角度出發(fā)會派生出兩種不同的測試原則，從用戶的角度出發(fā)，就是希望通過軟件測試能充分暴露軟件中存在的問題和缺陷，從而考慮是否可以接受該產(chǎn)品，從開發(fā)者的角度出發(fā)，就是希望測試能表明軟件產(chǎn)品不存在錯誤，已經(jīng)正確地實現(xiàn)了用戶的需求，確立人們對軟件質(zhì)量的信心。

      為了達(dá)到上述的原則，那么需要注意以下幾點：
1．應(yīng)當(dāng)把“盡早和不斷的測試”作為開發(fā)者的座右銘
2．程序員應(yīng)該避免檢查自己的程序，測試工作應(yīng)該由獨立的專業(yè)的軟件測試機(jī)構(gòu)來完。
3．設(shè)計測試用例時應(yīng)該考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況要制造極端狀態(tài)和意外狀態(tài)，比如網(wǎng)絡(luò)異常中斷、電源斷電等情況。
4．一定要注意測試中的錯誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習(xí)慣有很大的關(guān)系。
5．對測試錯誤結(jié)果一定要有一個確認(rèn)的過程，一般有A測試出來的錯誤，一定要有一個B來確認(rèn)，嚴(yán)重的錯誤可以召開評審會進(jìn)行討論和分析。
6．制定嚴(yán)格的測試計劃，并把測試時間安排的盡量寬松，不要希望在極短的時間內(nèi)完成一個高水平的測試。
7．回歸測試的關(guān)聯(lián)性一定要引起充分的注意，修改一個錯誤而引起更多的錯誤出現(xiàn)的現(xiàn)象并不少見。
8．妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)性往往要靠測試文檔。

　　軟件測試并不等于程序測試。軟件測試應(yīng)該貫穿整個軟件定義與開發(fā)整個期間。因此需求分析、概要設(shè)計、詳細(xì)設(shè)計以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設(shè)計規(guī)格說明、詳細(xì)設(shè)計規(guī)格說明以及源程序，都應(yīng)該是軟件測試的對象。

　　在對需求理解與表達(dá)的正確性、設(shè)計與表達(dá)的正確性、實現(xiàn)的正確性以及運行的正確性的驗證中，任何一個環(huán)節(jié)發(fā)生了問題都可能在軟件測試中表現(xiàn)出來。  

軟件測試的基本方法
單元測試的基本方法
綜合測試的基本方法
確認(rèn)測試的基本方法
系統(tǒng)測試的基本方法
軟件測試的基本方法

　　軟件測試的方法和技術(shù)是多種多樣的。
　　對于軟件測試技術(shù)，可以從不同的角度加以分類：

　　從是否需要執(zhí)行被測軟件的角度，可分為靜態(tài)測試和動態(tài)測試。
　　從測試是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實現(xiàn)算法的角度來看，可分為白盒測試和黑盒測試；

1、黑盒測試

　　黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者在程序接口進(jìn)行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因果圖、錯誤推測等，主要用于軟件確認(rèn)測試。 “黑盒”法著眼于程序外部結(jié)構(gòu)、不考慮內(nèi)部邏輯結(jié)構(gòu)、針對軟件界面和軟件功能進(jìn)行測試?！昂诤小狈ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進(jìn)行測試。

2、白盒測試

　　白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅(qū)動、基路測試等，主要用于軟件驗證。

　　“白盒”法全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對所有邏輯路徑進(jìn)行測試?！鞍缀小狈ㄊ歉F舉路徑測試。在使用這一方案時，測試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測試數(shù)據(jù)。貫穿程序的獨立路徑數(shù)是天文數(shù)字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設(shè)計規(guī)范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤。

3．ALAC(Act-like-a-customer)測試

　　ALAC測試是一種基于客戶使用產(chǎn)品的知識開發(fā)出來的測試方法。ALAC測試是基于復(fù)雜的軟件產(chǎn)品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對那些客戶最容易遇到的錯誤。

單元測試的基本方法

單元測試的對象是軟件設(shè)計的最小單位模塊。單元測試的依據(jù)是詳細(xì)設(shè)描述，單元測試應(yīng)對模塊內(nèi)所有重要的控制路徑設(shè)計測試用例，以便發(fā)現(xiàn)模塊內(nèi)部的錯誤。單元測試多采用白盒測試技術(shù)，系統(tǒng)內(nèi)多個模塊可以并行地進(jìn)行測試。
單元測試任務(wù)

　　單元測試任務(wù)包括：1 模塊接口測試；2 模塊局部數(shù)據(jù)結(jié)構(gòu)測試；3 模塊邊界條件測試；4 模塊中所有獨立執(zhí)行通路測試；5 模塊的各條錯誤處理通路測試。

　　模塊接口測試是單元測試的基礎(chǔ)。只有在數(shù)據(jù)能正確流入、流出模塊的前提下，其他測試才有意義。測試接口正確與否應(yīng)該考慮下列因素：
　　 1 輸入的實際參數(shù)與形式參數(shù)的個數(shù)是否相同；
　　 2 輸入的實際參數(shù)與形式參數(shù)的屬性是否匹配；
　　 3 輸入的實際參數(shù)與形式參數(shù)的量綱是否一致；
　　 4 調(diào)用其他模塊時所給實際參數(shù)的個數(shù)是否與被調(diào)模塊的形參個數(shù)相同；
　　 5 調(diào)用其他模塊時所給實際參數(shù)的屬性是否與被調(diào)模塊的形參屬性匹配；
　　 6調(diào)用其他模塊時所給實際參數(shù)的量綱是否與被調(diào)模塊的形參量綱一致；
　　 7 調(diào)用預(yù)定義函數(shù)時所用參數(shù)的個數(shù)、屬性和次序是否正確；
　　 8 是否存在與當(dāng)前入口點無關(guān)的參數(shù)引用；
　　 9 是否修改了只讀型參數(shù)；
　　 10 對全程變量的定義各模塊是否一致；
　　 11是否把某些約束作為參數(shù)傳遞。

　　如果模塊內(nèi)包括外部輸入輸出，還應(yīng)該考慮下列因素：
　　 1 文件屬性是否正確；
　　 2 OPEN/CLOSE語句是否正確；
　　 3 格式說明與輸入輸出語句是否匹配；
　　 4緩沖區(qū)大小與記錄長度是否匹配；
　　 5文件使用前是否已經(jīng)打開；
　　 6是否處理了文件尾；
　　 7是否處理了輸入/輸出錯誤；
　　 8輸出信息中是否有文字性錯誤；

　　檢查局部數(shù)據(jù)結(jié)構(gòu)是為了保證臨時存儲在模塊內(nèi)的數(shù)據(jù)在程序執(zhí)行過程中完整、正確。局部數(shù)據(jù)結(jié)構(gòu)往往是錯誤的根源，應(yīng)仔細(xì)設(shè)計測試用例，力求發(fā)現(xiàn)下面幾類錯誤：
　　 1 不合適或不相容的類型說明；
　　 2變量無初值；
　　 3變量初始化或省缺值有錯；
　　 4不正確的變量名（拼錯或不正確地截斷）；
　　 5出現(xiàn)上溢、下溢和地址異常。

　　除了局部數(shù)據(jù)結(jié)構(gòu)外，如果可能，單元測試時還應(yīng)該查清全局?jǐn)?shù)據(jù)（例如FORTRAN的公用區(qū)）對模塊的影響。

　　在模塊中應(yīng)對每一條獨立執(zhí)行路徑進(jìn)行測試，單元測試的基本任務(wù)是保證模塊中每條語句至少執(zhí)行一次。??的比較和不適當(dāng)?shù)目刂屏髟斐傻腻e誤。此時基本路徑測試和循環(huán)測試是最常用且最有效的測試技術(shù)。計算中常見的錯誤包括：
　　 1 誤解或用錯了算符優(yōu)先級；
　　 2混合類型運算；
　　 3變量初值錯；
　　 4精度不夠；
　　 5表達(dá)式符號錯。

　　比較判斷與控制流常常緊密相關(guān)，測試用例還應(yīng)致力于發(fā)現(xiàn)下列錯誤：
　　 1不同數(shù)據(jù)類型的對象之間進(jìn)行比較；
　　 2錯誤地使用邏輯運算符或優(yōu)先級；
　　 3因計算機(jī)表示的局限性，期望理論上相等而實際上不相等的兩個量相等；
　　 4比較運算或變量出錯；
　　 5循環(huán)終止條件或不可能出現(xiàn)；
　　 6迭代發(fā)散時不能退出；
　　 7錯誤地修改了循環(huán)變量。

　　一個好的設(shè)計應(yīng)能預(yù)見各種出錯條件，并預(yù)設(shè)各種出錯處理通路，出錯處理通路同樣需要認(rèn)真測試，測試應(yīng)著重檢查下列問題：
　　 1輸出的出錯信息難以理解；
　　 2記錄的錯誤與實際遇到的錯誤不相符；
　　 3在程序自定義的出錯處理段運行之前，系統(tǒng)已介入；
　　 4異常處理不當(dāng)；
　　 5錯誤陳述中未能提供足夠的定位出錯信息。

　　邊界條件測試是單元測試中最后，也是最重要的一項任務(wù)。眾的周知，軟件經(jīng)常在邊界上失效，采用邊界值分析技術(shù)，針對邊界值及其左、右設(shè)計測試用例，很有可能發(fā)現(xiàn)新的錯誤。

單元測試過程

　　一般認(rèn)為單元測試應(yīng)緊接在編碼之后，當(dāng)源程序編制完成并通過復(fù)審和編譯檢查，便可開始單元測試。測試用例的設(shè)計應(yīng)與復(fù)審工作相結(jié)合，根據(jù)設(shè)計信息選取測試數(shù)據(jù)，將增大發(fā)現(xiàn)上述各類錯誤的可能性。在確定測試用例的同時，應(yīng)給出期望結(jié)果。

　　應(yīng)為測試模塊開發(fā)一個驅(qū)動模塊（driver）和（或）若干個樁模塊（stub）,下圖顯示了一般單元測試的環(huán)境。驅(qū)動模塊在大多數(shù)場合稱為“主程序”，它接收測試數(shù)據(jù)并將這些數(shù)據(jù)傳遞到被測試模塊，被測試模塊被調(diào)用后，“主程序”打印“進(jìn)入-退出”消息。

　　驅(qū)動模塊和樁模塊是測試使用的軟件，而不是軟件產(chǎn)品的組成部分，但它需要一定的開發(fā)費用。若驅(qū)動和樁模塊比較簡單，實際開銷相對低些。遺憾的是，僅用簡單的驅(qū)動模塊和樁模塊不能完成某些模塊的測試任務(wù)，這些模塊的單元測試只能采用下面討論的綜合測試方法。

　　提高模塊的內(nèi)聚度可簡化單元測試，如果每個模塊只能完成一個，所需測試用例數(shù)目將顯著減少，模塊中的錯誤也更容易發(fā)現(xiàn)。

綜合測試的基本方法

　　 時常有這樣的情況發(fā)生，每個模塊都能單獨工作，但這些模塊集成在一起之后卻不能正常工作。主要原因是，模塊相互調(diào)用時接口會引入許多新問題。例如，數(shù)據(jù)經(jīng)過接口可能丟失；一個模塊對另一模塊可能造成不應(yīng)有的影響；幾個子功能組合起來不能實現(xiàn)主功能；誤差不斷積累達(dá)到不可接受的程度；全局?jǐn)?shù)據(jù)結(jié)構(gòu)出現(xiàn)錯誤，等等。綜合測試是組裝軟件的系統(tǒng)測試技術(shù)，按設(shè)計要求把通過單元測試的各個模塊組裝在一起之后，進(jìn)行綜合測試以便發(fā)現(xiàn)與接口有關(guān)的各種錯誤。

　　某設(shè)計人員習(xí)慣于把所有模塊按設(shè)計要求一次全部組裝起來，然后進(jìn)行整體測試，這稱為非增量式集成。這種方法容易出現(xiàn)混亂。因為測試時可能發(fā)現(xiàn)一大堆錯誤，為每個錯誤定位和糾正非常困難，并且在改正一個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。與之相反的是增量式集成方法，程序一段一段地擴(kuò)展，測試的范圍一步一步地增大，錯誤易于定位和糾正，界面的測試亦可做到完全徹底。下面討論兩種增量式集成方法。

1 自頂向下集成

　　自頂向下集成是構(gòu)造程序結(jié)構(gòu)的一種增量式方式，它從主控模塊開始，按照軟件的控制層次結(jié)構(gòu)，以深度優(yōu)先或廣度優(yōu)先的策略，逐步把各個模塊集成在一起。深度優(yōu)先策略首先是把主控制路徑上的模塊集成在一起，至于選擇哪一條路徑作為主控制路徑，這多少帶有隨意性，一般根據(jù)問題的特性確定。以下圖為例，若選擇了最左一條路徑，首先將模塊M1，M2，M5和M8集成在一起，再將M6集成起來，然后考慮中間和右邊的路徑。廣度優(yōu)先策略則不然，它沿控制層次結(jié)構(gòu)水平地向下移動。仍以下圖為例，它首先把M2、M3和M4與主控模塊集成在一起，再將M5和M6 和其他模塊集資集成起來。

　　自頂向下綜合測試的具體步驟為：
　　 1 以主控模塊作為測試驅(qū)動模塊，把對主控模塊進(jìn)行單元測試時引入的所有樁模塊用實際模塊替代；
　　 2 依據(jù)所選的集成策略（深度優(yōu)先或廣度優(yōu)先），每次只替代一個樁模塊；
　　 3 每集成一個模塊立即測試一遍；
　　 4 只有每組測試完成后，才著手替換下一個樁模塊；
　　 5 為避免引入新錯誤，須不斷地進(jìn)行回歸測試（即全部或部分地重復(fù)已做過的測試）。
 

　　 從第二步開始，循環(huán)執(zhí)行上述步驟，直至整個程序結(jié)構(gòu)構(gòu)造完畢。下圖中，實線表示已部分完成的結(jié)構(gòu)，若采用深度優(yōu)先策略，下一步將用模塊M7替換樁模塊S7，當(dāng)然M7本身可能又帶有樁模塊，隨后將被對應(yīng)的實際模塊一一替代。

　　自頂向下集成的優(yōu)點在于能盡早地對程序的主要控制和決策機(jī)制進(jìn)行檢驗，因此較早地發(fā)現(xiàn)錯誤。缺點是在測試較高層模塊時，低層處理采用樁模塊替代，不能反映真實情況，重要數(shù)據(jù)不能及時回送到上層模塊，因此測試并不充分。解決這個問題有幾種辦法，第一種是把某些測試推遲到用真實模塊替代樁模塊之后進(jìn)行，第二種是開發(fā)能模擬真實模塊的樁模塊；第三種是自底向上集成模塊。第一種方法又回退為非增量式的集成方法，使錯誤難于定位和糾正，并且失去了在組裝模塊時進(jìn)行一些特定測試的可能性；第二種方法無疑要大大增加開銷；第三種方法比較切實可行，下面專門討論。

2自底向上集成

　　自底向上測試是從“原子”模塊（即軟件結(jié)構(gòu)最低層的模塊）開始組裝測試，因測試到較高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊。

　　自底向上綜合測試的步驟分為：
　　 1 把低層模塊組織成實現(xiàn)某個子功能的模塊群（cluster）;
　　 2 開發(fā)一個測試驅(qū)動模塊，控制測試數(shù)據(jù)的輸入和測試結(jié)果的輸出；
　　 3 對每個模塊群進(jìn)行測試；
　　 4 刪除測試使用的驅(qū)動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。

　　從第一步開始循環(huán)執(zhí)行上述各步驟，直至整個程序構(gòu)造完畢。

　　下圖說明了上述過程。首先“原子”模塊被分為三個模塊群，每個模塊群引入一個驅(qū)動模塊進(jìn)行測試。因模塊群1、模塊群2中的模塊均隸屬于模塊Ma，因此在驅(qū)動模塊D1、D2去掉后，模塊群1與模塊群2直接與Ma接口，這時可對MaD3被去掉后，M3與模塊群3直接接口，可對Mb進(jìn)行集成測試，最后Ma、Mb和 Mc全部集成在一起進(jìn)行測試。

　　 自底向上集成方法不用樁模塊，測試用例的設(shè)計亦相對簡單，但缺點是程序最后一個模塊加入時才具有整體形象。它與自頂向綜合測試方法優(yōu)缺點正好相反。因此，在測試軟件系統(tǒng)時，應(yīng)根據(jù)軟件的特點和工程的進(jìn)度，選用適當(dāng)?shù)臏y試策略，有時混和使用兩種策略更為有效，上層模塊用自頂向下的方法，下層模塊用自底向上的方法。

　　此外，在綜合測試中尤其要注意關(guān)鍵模塊，所謂關(guān)鍵模塊一般都具有下述一或多個特征：①對應(yīng)幾條需求；②具有高層控制功能；③復(fù)雜、易出錯；④有特殊的性能要求。關(guān)鍵模塊應(yīng)盡早測試，并反復(fù)進(jìn)行回歸測試。

確認(rèn)測試的基本方法
　　 通過綜合測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的最后一步確認(rèn)測試即可開始。確認(rèn)測試應(yīng)檢查軟件能否按合同要求進(jìn)行工作，即是否滿足軟件需求說明書中的確認(rèn)標(biāo)準(zhǔn)。

1. 確認(rèn)測試標(biāo)準(zhǔn)

　　實現(xiàn)軟件確認(rèn)要通過一系列墨盒測試。確認(rèn)測試同樣需要制訂測試計劃和過程，測試計劃應(yīng)規(guī)定測試的種類和測試進(jìn)度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。無是計劃還是過程，都應(yīng)該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準(zhǔn)確人機(jī)界面和其他方面（例如，可移植性、兼容性、錯誤恢復(fù)能力和可維護(hù)性等）是否令用戶滿意。

　　確認(rèn)測試的結(jié)果有兩種可能，一種是功能和性能指標(biāo)滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足??這個階段才發(fā)現(xiàn)嚴(yán)重錯誤和偏差一般很難在預(yù)定的工期內(nèi)改正，因此必須與用戶協(xié)商，尋求一個妥善解決問題的方法。

2. 配置復(fù)審

　　確認(rèn)測試的另一個重要環(huán)節(jié)是配置復(fù)審。復(fù)審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護(hù)所必須的細(xì)節(jié)。

3. α、β測試

　　事實上，軟件開發(fā)人員不可能完全預(yù)見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數(shù)據(jù)組合，亦可能對設(shè)計者自認(rèn)明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應(yīng)由用戶進(jìn)行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統(tǒng)的測試。有時，驗收測試長達(dá)數(shù)周甚至數(shù)月，不斷暴露錯誤，導(dǎo)致開發(fā)延期。一個軟件產(chǎn)品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為α、β測試的過程，以期發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問題。

　　α測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶行對即將面市軟件產(chǎn)品（稱為α版本）進(jìn)行測試，試圖發(fā)現(xiàn)錯誤并修正。α測試的關(guān)鍵在于盡可能逼真地模擬實際運行環(huán)境和用戶對軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的 用戶操作方式。經(jīng)過α測試調(diào)整的軟件產(chǎn)品稱為β版本。緊隨其后的β測試是指軟件開發(fā)公司組織各方面的典型用戶在日常工作中實際使用β版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對β版本進(jìn)行改錯和完善。

系統(tǒng)測試的基本方法

　　 計算機(jī)軟件是基于計算機(jī)系統(tǒng)的一個重要組成部分，軟件開發(fā)完畢后應(yīng)與系統(tǒng)中其它成分集成在一起，此時需要進(jìn)行一系列系統(tǒng)集成和確認(rèn)測試。對這些測試的詳細(xì)討論已超出軟件工程的范圍，這些測試也不可能僅由軟件開發(fā)人員完成。在系統(tǒng)測試之前，軟件工程師應(yīng)完成下列工作：
　　 （1） 為測試軟件系統(tǒng)的輸入信息設(shè)計出錯處理通路；
　　 （2） 設(shè)計測試用例，模擬錯誤數(shù)據(jù)和軟件界面可能發(fā)生的錯誤，記錄測試結(jié)果，為系統(tǒng)測試提供經(jīng)驗和幫助；
　　 （3） 參與系統(tǒng)測試的規(guī)劃和設(shè)計，保證軟件測試的合理性。

　　系統(tǒng)測試應(yīng)該由若干個不同測試組成，目的是充分運行系統(tǒng)，驗證系統(tǒng)各部件是否都能政黨工作并完成所賦予的任務(wù)。下面簡單討論幾類系統(tǒng)測試。

１、恢復(fù)測試

　　恢復(fù)測試主要檢查系統(tǒng)的容錯能力。當(dāng)系統(tǒng)出錯時，能否在指定時間間隔內(nèi)修正錯誤并重新啟動系統(tǒng)?；謴?fù)測試首先要采用各種辦法強(qiáng)迫系統(tǒng)失敗，然后驗證系統(tǒng)是否能盡快恢復(fù)。對于自動恢復(fù)需驗證重新初始化（reinitialization）、檢查點(checkpointing mechanisms)、數(shù)據(jù)恢復(fù)(data recovery)和重新啟動 (restart)等機(jī)制的正確性；對于人工干預(yù)的恢復(fù)系統(tǒng)，還需估測平均修復(fù)時間，確定其是否在可接受的范圍內(nèi)。

２、安全測試

　　安全測試檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如，①想方設(shè)法截取或破譯口令；②專門定做軟件破壞系統(tǒng)的保護(hù)機(jī)制；③故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)非法進(jìn)入；④試圖通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進(jìn)入的系統(tǒng)。因此系統(tǒng)安全設(shè)計的準(zhǔn)則是，使非法侵入的代價超過被保護(hù)信息的價值。此時非法侵入者已無利可圖。

３、強(qiáng)度測試

　　強(qiáng)度測試檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力。強(qiáng)度測試總是迫使系統(tǒng)在異常的資源配置下運行。例如，①當(dāng)中斷的正常頻率為每秒一至兩個時，運行每秒產(chǎn)生十個中斷的測試用例；②定量地增長數(shù)據(jù)輸入率，檢查輸入子功能的反映能力；③運行需要最大存儲空間（或其他資源）的測試用例；④運行可能導(dǎo)致虛存操作系統(tǒng)崩潰或磁盤數(shù)據(jù)劇烈抖動的測試用例，等等。

４、 性能測試

　　對于那些實時和嵌入式系統(tǒng)，軟件部分即使?jié)M足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每一測試步驟都包含性能測試，但只有當(dāng)系統(tǒng)真正集成之后，在真實環(huán)境中才能全面、可靠地測試運行性能系統(tǒng)性能測試是為了完成這一任務(wù)。性能測試有時與強(qiáng)度測試相結(jié)合，經(jīng)常需要其他軟硬件的配套支持。

常見的軟件測試類型有：

      BVT (Build Verification Test)

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

      Scenario Tests（基于用戶實際應(yīng)用場景的測試）

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

      Smoke Test

      在測試中發(fā)現(xiàn)問題，找到了一個Bug，然后開發(fā)人員會來修復(fù)這個Bug。這時想知道這次修復(fù)是否真的解決了程序的Bug，或者是否會對其它模塊造成影響，就需要針對此問題進(jìn)行專門測試，這個過程就被稱為Smoke Test。在很多情況下，做Smoke Test是開發(fā)人員在試圖解決一個問題的時候，造成了其它功能模塊一系列的連鎖反應(yīng)，原因可能是只集中考慮了一開始的那個問題，而忽略其它的問題，這就可能引起了新的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（安?支持工具

      一些受軟件開發(fā)人員歡迎的軟件測試工具為軟件測試提供了強(qiáng)有力的支持。本文將介紹美國Rational公司的著名套裝軟件SQA和Pure Atria公司極具特色的Purify。

      SQA SuiteSQA直接支持對客戶/服務(wù)器應(yīng)用軟件的測試,它的一個重要特點是可以自動驅(qū)動被測程序的運行。SQA可以自動記錄和重放程序執(zhí)行過程,從而實現(xiàn)了對測試進(jìn)行"復(fù)查"的自動化。

      由于測試是一個需要反復(fù)進(jìn)行的過程,常常要數(shù)十次甚至數(shù)百次地重復(fù)。因此,這一特性大大地提高了軟件"再測試"(Re-Test)和"回歸測試"(Regression)的自動化程度,把測試人員從繁雜的、重復(fù)性的手工測試中解脫出來,從而顯著地提高軟件測試效率。

      除了這個最基本的自動錄放功能外,它還提供了一系列的輔助支持功能,比如,

  · 被錄制的程序執(zhí)行過程可以被自動轉(zhuǎn)換成具有良好可讀性的高級語言程序,從而使這個測試驅(qū)動程序可以由測試人員根據(jù)測試需要進(jìn)行必要的修改,甚至完全用手工方式編制。

  ·自動記錄和分析比較測試的執(zhí)行結(jié)果。不論是簡單的正文方式的輸出結(jié)果,還是任意的圖表、聲音、動畫、圖形用戶界面(GUI)中的任一構(gòu)件,都可以根據(jù)測試人員的指定被自動記錄在測試結(jié)果庫中,并可對兩次測試的結(jié)果自動地進(jìn)行比較,指出其差異部分。此項功能無疑對"自動查找錯誤"很有幫助。

  ·調(diào)節(jié)和設(shè)定事件的發(fā)生時間和速度。

  ·基本的測試庫管理功能。

  此外,SQA還支持軟件測試人員進(jìn)行以下工作:

  ·制定測試計劃和測試大綱,并將這些文檔按照自然的樹狀結(jié)構(gòu)分層地管理起來,并據(jù)此控制和驅(qū)動整個測試過程。

  ·不僅能夠自動記錄各類測試結(jié)果,而且對其進(jìn)行修改,從而使得測試人員可以在程序運行結(jié)果尚有許多錯誤的情況下,通過對所記錄下的結(jié)果做適當(dāng)修正來獲得理想的"期望結(jié)果" ,為測試結(jié)果的自動比較奠定基礎(chǔ)。

  ·測試問題報告的記錄與管理。

      總之,SQA Suite提供了一個比較完整的測試平臺,以支持軟件測試的各種基本活動,包括測試計劃與測試大綱的制定、回歸測試的自動化、測試結(jié)果的分析比較、軟件問題報告的生成與自動分發(fā)和控制等。對于許多應(yīng)用軟件的開發(fā)無疑是個有力的測試支持工具。

      Purify是原PureAtria公司(現(xiàn)已經(jīng)與美國Rational公司合并,改名為美國Rational公司)于90年代初率先推出的專門用于檢測程序中種種內(nèi)存使用錯誤的軟件工具。幾乎所有使用過C語言開發(fā)軟件的程序員都會有這樣的體會,C語言中使用極為靈活的指針給程序員帶來了很大便利,但同時也制造了許多的麻煩。由于指針使用不當(dāng)而引起的錯誤通常是最難發(fā)現(xiàn)的,同時也是最難定位的一類錯誤。而Purify對多種常見的內(nèi)存使用錯誤的檢錯能力和準(zhǔn)確的定位,受到廣大軟件開發(fā)人員的青睞。

      Purify可以自動識別出二十多種內(nèi)存使用錯誤,包括

  ·未初始化的局部變量

  ·未申請的內(nèi)存

  ·使用已釋放的內(nèi)存

  ·數(shù)組越界

  ·內(nèi)存丟失

  ·文件描述問題

  ·棧溢出問題

  ·棧結(jié)構(gòu)邊界錯誤等

      在下面的例子中,暗藏著兩個內(nèi)存使用錯誤。第一行為指針數(shù)組pp申請的空間尺寸不對。這類錯誤往往不易發(fā)現(xiàn),因為在C語言中,一些"輕微"的內(nèi)存越界可能被系統(tǒng)所容忍。但這往往是導(dǎo)致更嚴(yán)重錯誤的根源。例如,可能破壞其它數(shù)據(jù)區(qū)等。最后一行的錯誤是在釋放pp 之前沒有釋放賦予它的字符串空間,從而把它們"丟失"了。這類錯誤猶如慢性自殺,它會逐漸消耗掉內(nèi)存,降低系統(tǒng)的運行效率,直到完全崩潰。而真正的問題在于,這些程序中的"惡性腫瘤"用常規(guī)的測試手段和調(diào)試工具是極難發(fā)現(xiàn)和加以定位的。Purify則在此充分顯示了它的強(qiáng)大功效,所到之處,即對所測試過的情況,上述各種常見的內(nèi)存錯誤都可以被一一揭露出來,并且準(zhǔn)確地指出錯誤的類型和位置。從而大大地提高了測試和糾錯的效率,提高了軟件的可靠性。

  …/"to get 10 words and print them out"/

  if(!(pp=(char**)malloc(10))){

  /*Size should be 10*sizeof(char*)*/

  printf("Out of memory.n");

  exit(-1);

  }

  for(i=0;i<10;i ){

  scanf("%s",buffer);

  if(!(pp【i】=(char*)malloc(strlen(buffer) 1))){

  print("Out of Memory. n");

  exit(-1);

  }

  strcpy(pp【i】,buffer);

  printf(pp【i】);

  }

  free(pp);/*all the strings pointed by it are lost!*/

  ………

      今年以來,原PureAtria公司陸續(xù)推出了其系列產(chǎn)品?/FONT>Pure,包括支持內(nèi)存檢測的Purify ,支持路徑覆蓋的PureCoverage,支持多線程應(yīng)用程序性能測試的Quantify,以及用以提高測試期間連接編譯被測程序效率的PureLink等。Pure系列現(xiàn)已支持C、C 、FORTRAN語言,以及UNIX和Window NT等操作系統(tǒng),如Sun OS、Solaris 2.3,HP-UX,Windows NT Server以及IBM A/ X等。

      結(jié)束語

      充分認(rèn)識軟件測試的重要性和復(fù)雜性,合理地選擇測試方法,有效地組織測試人員和安排測試任務(wù),并且盡量使用軟件測試工具增強(qiáng)軟件測試的自動化程度,無疑可以幫助軟件開發(fā)和測試人員大大提高測試效率和軟件的質(zhì)量。

      軟件測試是一個極為復(fù)雜的過程。如圖一所示,一個規(guī)范化的軟件測試過程通常須包括以下基本的測試活動。

  ·擬定軟件測試計劃

  ·編制軟件測試大綱

  ·設(shè)計和生成測試用例

  ·實施測試

  ·生成軟件問題報告

      對整個測試過程進(jìn)行有效的管理實際上,軟件測試過程與??早在需求分析階段即應(yīng)開始制定,其它相關(guān)工作,包括測試大綱的制定、測試數(shù)據(jù)的生成、測試工具的選擇和開發(fā)等也應(yīng)在測試階段之前進(jìn)行。充分的準(zhǔn)備工作可以有效地克服測試的盲目性,縮短測試周期,提高測試效率,并且起到測試文檔與開發(fā)文檔互查的作用。

      此外,軟件測試的實施階段是由一系列的測試周期(Test Cycle)組成的。在每個測試周期中,軟件測試工程師將依據(jù)預(yù)先編制好的測試大綱和準(zhǔn)備好的測試用例,對被測軟件進(jìn)行完整的測試。測試與糾錯通常是反復(fù)交替進(jìn)行的。當(dāng)使用專業(yè)測試人員時,測試與糾錯甚至是平行進(jìn)行的,從而壓縮總的開發(fā)時間。更重要的是,由于專業(yè)測試人員豐富的測試經(jīng)驗、所采用的系統(tǒng)化的測試方法、全時的投入,特別是獨立于開發(fā)人員的思維,使得他們能夠更有效地發(fā)現(xiàn)許多單靠開發(fā)人員很難發(fā)現(xiàn)的錯誤和問題。

      軟件測試大綱是軟件測試的依據(jù)。它明確詳盡地規(guī)定了在測試中針對系統(tǒng)的每一項功能或特性所必須完成的基本測試項目和測試完成的標(biāo)準(zhǔn)。無論是自動測試還是手動測試,都必須滿足測試大綱的要求。

      一般而言,測試用例是指為實施一次測試而向被測系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設(shè)置。測試用例控制著軟件測試的執(zhí)行過程,它是對測試大綱中每個測試項目的進(jìn)一步實例化。已有許多著名的論著總結(jié)了設(shè)計測試用例的各種規(guī)則和策略。從工程實踐的角度講有幾條基本準(zhǔn)則:

  1.測試用例的代表性:能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,以及極限的輸入數(shù)據(jù)、操作和環(huán)境設(shè)置等;

  2.測試結(jié)果的可判定性:即測試執(zhí)行結(jié)果的正確性是可判定的或可評估的;

  3.測試結(jié)果的可再現(xiàn)性:即對同樣的測試用例,系統(tǒng)的執(zhí)行結(jié)果應(yīng)當(dāng)是相同的。

      “工欲善其事，必先利其器”。專業(yè)的測試必須以一個好的測試計劃作為基礎(chǔ)。盡管測試的每一個步驟都是獨立的，但是必定要有一個起到框架結(jié)構(gòu)作用的測試計劃。測試的計劃應(yīng)該作為測試的起始步驟和重要環(huán)節(jié)。一個測試計劃應(yīng)包括：產(chǎn)品基本情況調(diào)研、測試需求說明、測試策略和記錄、測試資源配置、計劃表、問題跟蹤報告、測試計劃的評審、結(jié)果等等。

      產(chǎn)品基本情況調(diào)研：

      這部分應(yīng)包括產(chǎn)品的一些基本情況介紹，例如：產(chǎn)品的運行平臺和應(yīng)用的領(lǐng)域，產(chǎn)品的特點和主要的功能模塊，產(chǎn)品的特點等。對于大的測試項目，還要包括測試的目的和側(cè)重點。

      具體的要點有：

      目的：重點描述如何使測試建立在客觀的基礎(chǔ)上，定義測試的策略，測試的配置， 粗略的估計測試大致需要的周期和最終測試報告遞交的時間。

      變更：說明有可能會導(dǎo)致測試計劃變更的事件。包括測試工具改進(jìn)了，測試的環(huán)境改變了，或者是添加了新的功能。

      技術(shù)結(jié)構(gòu)：可以借助畫圖，將要測試的軟件劃分成幾個組成部分，規(guī)劃成一個適用于測試的完整的系統(tǒng)，包括數(shù)據(jù)是如何存儲的，如何傳遞的（數(shù)據(jù)流圖），每一個部分的測試是要達(dá)到什么樣的目的。每一個部分是怎么實現(xiàn)數(shù)據(jù)更新的。還有就是常規(guī)性的技術(shù)要求，比如運行平臺、需要什么樣的數(shù)據(jù)庫等等。

      產(chǎn)品規(guī)格：就是制造商和產(chǎn)品版本號的說明。

      測試范圍：簡單的描述如何搭建測試平臺以及測試的潛在的風(fēng)險。

      項目信息：說明要測試的項目的相關(guān)資料，如：用戶文檔，產(chǎn)品描述，主要功能的舉例說明。

      測試需求說明：

      這一部分要列出所有要測試的功能項。凡是沒有出現(xiàn)在這個清單里的功能項都排除在測試的范圍之外。萬一有一天你在一個沒有測試的部分里發(fā)現(xiàn)了一個問題，你應(yīng)該很高興你有這個記錄在案的文檔，可以證明你測了什么沒測什么。具體要點有：

      功能的測試：理論上是測試是要覆蓋所有的功能項，例如：在數(shù)據(jù)庫中添加、編輯、刪除記錄等等，這會是一個浩大的工程，但是有利于測試的完整性。

      設(shè)計的測試：對于一些用戶界面、菜單的結(jié)構(gòu)還有窗體的設(shè)計是否合理等的測試。

      整體考慮：這部分測試需求要考慮到數(shù)據(jù)流從軟件中的一個模塊流到另一個模塊的過程中的正確性。

      測試的策略和記錄：

      這是整個測試計劃的重點所在，要描述如何公正客觀地開展測試，要考慮：模塊、功能、整體、系統(tǒng)、版本、壓力、性能、配置和安裝等各個因素的影響。要盡可能的考慮到細(xì)節(jié)，越詳細(xì)越好，并制作測試記錄文檔的模板，為即將開始的測試做準(zhǔn)備，測試記錄重要包括的部分具體說明如下：

      公正性聲明：要對測試的公正性、遵照的標(biāo)準(zhǔn)做一個說明，證明測試是客觀的，整體上，軟件功能要滿足需求，實現(xiàn)正確，和用戶文檔的描述保持一致。

      測試案例：描述測試案例是什么樣的，采用了什么工具，工具的來源是什么，如何執(zhí)行的，用了什么樣的數(shù)據(jù)。測試的記錄中要為將來的回歸測試留有余地，當(dāng)然，也要考慮同時安裝的別的軟件對正在測試的軟件會造成的影響。

      特殊考慮：有的時候，針對一些外界環(huán)境的影響，要對軟件進(jìn)行一些特殊方面的測試。

      經(jīng)驗判斷：對以往的測試中，經(jīng)常出現(xiàn)的問題加以考慮。

      設(shè)想：采取一些發(fā)散性的思維，往往能幫助你找的測試的新途徑。

      測試資源配置：

      項目資源計劃：制定一個項目資源計劃，包含的是每一個階段的任務(wù)、所需要的資源，當(dāng)發(fā)生類似到了使用期限或者資源共享的事情的時候，要更新這個計劃。

      計劃表：

      測試的計劃表可以做成一個多個項目通用的形式，根據(jù)大致的時間估計來制作，操作流程要以軟件測試的常規(guī)周期作為參考，也可以是根據(jù)什么時候應(yīng)該測試哪一個模塊來制定。

      問題跟蹤報告：

      在測試的計劃階段，我們應(yīng)該明確如何準(zhǔn)備去做一個問題報告以及如何去界定一個問題的性質(zhì)，問題報告要包括問題的發(fā)現(xiàn)者和修改者、問題發(fā)生的頻率、用了什么樣的測試案例測出該問題的，以及明確問題產(chǎn)生時的測試環(huán)境。

      問題描述盡可能是定量的，分門別類的列舉，問題有幾種：

  1、嚴(yán)重問題：嚴(yán)重問題意味著功能不可用，或者是權(quán)限限制方面的失誤等等，也可能是某個地方的改變造成了別的地方的問題。

  2、一般問題：功能沒有按設(shè)計要求實現(xiàn)或者是一些界面交互的實現(xiàn)不正確。

  3、建議問題：功能運行得不象要求的那么快，或者不符合某些約定俗成的習(xí)慣，但不影響系統(tǒng)的性能，界面先是錯誤，格式不對，含義模糊混淆的提示信息等等。

      測試計劃的評審：

      又叫測試規(guī)范的評審，在測試真正實施開展之前必須要認(rèn)真負(fù)責(zé)的檢查一遍，獲得整個測試部門人員的認(rèn)同，包括部門的負(fù)責(zé)人的同意和簽字。

      結(jié)果：

      計劃并不是到這里就結(jié)束了，在最后測試結(jié)果的評審中，必須要嚴(yán)格驗證計劃和實際的執(zhí)行是不是有偏差，體現(xiàn)在最終報告的內(nèi)容是否和測試的計劃保持一致，然后，就可以開始著手制作下一個測試計劃了。

       報告軟件測試錯誤的目的是為了保證修復(fù)錯誤的人員可以重復(fù)報告的錯誤，從而有利于分析錯誤產(chǎn)生的原因，定位錯誤，然后修正之。因此，報告軟件測試錯誤的基本要求是準(zhǔn)確、簡潔、完整、規(guī)范。需要掌握的報告技術(shù)歸納如下。
　　 1. 描述 (Description)，簡潔、準(zhǔn)確，完整，揭示錯誤實質(zhì)，記錄缺陷或錯誤出現(xiàn)的位置

　　描述要準(zhǔn)確反映錯誤的本質(zhì)內(nèi)容，簡短明了。為了便于在軟件錯誤管理數(shù)據(jù)庫中尋找制定的測試錯誤，包含錯誤發(fā)生時的用戶界面（UI）是個良好的習(xí)慣。例如記錄對話框的標(biāo)題、菜單、按鈕等控件的名稱。

　　2. 明確指明錯誤類型：布局、翻譯、功能、雙字節(jié)
根據(jù)錯誤的現(xiàn)象，總結(jié)判斷錯誤的類型。例如，即布局錯誤、翻譯錯誤、功能錯誤、雙字節(jié)錯誤，這是最常見的缺陷或錯誤類型，其他形式的缺陷或錯誤也從屬于其中某種形式。

　　3. 短行之間使用自動數(shù)字序號，使用相同的字體、字號、行間距

　　短行之間使用自動數(shù)字序號，使用相同的字體、字號、行間距，可以保證各條記錄格式一致，做到規(guī)范專業(yè)。

　　4. UI要加引號，可以單引號，推薦使用雙引號

　　UI加引號，可以容易區(qū)分UI與普通文本，便于分辨、定位缺陷或錯誤。

　　5. 每一個步驟盡量只記錄一個操作

　　保證簡潔、條理井然，容易重復(fù)操作步驟。

　　6. 確認(rèn)步驟完整，準(zhǔn)確，簡短

　　保證快速準(zhǔn)確的重復(fù)錯誤，“完整”即沒有缺漏，“準(zhǔn)確”即步驟正確，“簡短”即沒有多余的步驟。

　　7. 根據(jù)缺陷或錯誤類型，選擇圖象捕捉的方式

　　為了直觀的觀察缺陷或錯誤現(xiàn)象，通常需要附加缺陷或錯誤出現(xiàn)的界面，以位圖的形式作為附件附著在記錄的“附件”部分。為了節(jié)省空間，又能真實反映缺陷或錯誤本質(zhì)，可以捕捉缺陷或錯誤產(chǎn)生時的全屏幕，活動窗口和局部區(qū)域。為了迅速定位、修正缺陷或錯誤位置，通常要求附加中英文對照圖。

　　8. 附加必要的特殊文檔和個人建議和注解

　　如果打開某個特殊的文檔而產(chǎn)生的缺陷或錯誤，則必須附加該文檔，從而可以迅速再現(xiàn)缺陷或錯誤。有時，為了使缺陷或錯誤修正者進(jìn)一步明確缺陷或錯誤的表現(xiàn)，可以附加個人的修改建議或注解。

　　9. 檢查拼寫和語法錯誤

　　在提交每條缺陷或錯誤之前，檢查拼寫和語法，確保內(nèi)容正確，正確的描述錯誤。

　　10. 盡量使用業(yè)界慣用的表達(dá)術(shù)語和表達(dá)方法

　　使用業(yè)界慣用的表達(dá)術(shù)語和表達(dá)方法，保證表達(dá)準(zhǔn)確，體現(xiàn)專業(yè)化。

　　11. 通用UI要統(tǒng)一、準(zhǔn)確

　　錯誤報告的UI要與測試的軟件UI保持一致，便于查找定位。

　　12. 盡量使用短語和短句，避免復(fù)雜句型句式

　　軟件錯誤管理數(shù)據(jù)庫的目的是便于定位錯誤，因此，要求客觀的描述操作步驟，不需要修飾性的詞匯和復(fù)雜的句型，增強(qiáng)可讀性。

　　13. 每條錯誤報告只包括一個錯誤

　　每條錯誤報告只包括一個錯誤，可以使錯誤修正者迅速定位一個錯誤，集中精力每次只修正一個錯誤。校驗者每次只校驗一個錯誤是否已經(jīng)正確修正。

　　以上概括了報告測試錯誤的規(guī)范要求，隨著軟件的測試要求不同，測試者經(jīng)過長期測試，積累了相應(yīng)的測試經(jīng)驗，將會逐漸養(yǎng)成良好的專業(yè)習(xí)慣，不斷補(bǔ)充新的規(guī)范書寫要求。此外，經(jīng)常閱讀、學(xué)習(xí)高級測試工程師的測試錯誤報告，結(jié)合自己以前的測試錯誤報告進(jìn)行對比和思考，可以不斷提高技巧。  

      軟件測試工程師是軟件行業(yè)中一種即年輕又古老的職業(yè)，進(jìn)入二十一世紀(jì)以來，隨著中國加入WTO以后，從事這項職業(yè)的人也越來越多。一個公司在組建一個測試隊伍的時候如何分配人員結(jié)構(gòu)，從而使公司軟件測試工作水平得到提高，是大家比較關(guān)注的問題。本人依照自己的經(jīng)驗提出自己的觀點：

我們首先來看一下測試人員的縱向結(jié)構(gòu)
1，測試經(jīng)理
測試經(jīng)理主要負(fù)責(zé)測試隊伍的內(nèi)部管理以及與其他外部人員，客戶的交流，詳細(xì)說來主要包括進(jìn)度管理，風(fēng)險管理，資金管理，人力資源管理，交流管理等等，測試經(jīng)理需要具有項目經(jīng)理的知識和技能。同時測試工作開始前項目經(jīng)理需要書寫《測試計劃書》，測試結(jié)束需要書寫《測試總結(jié)報告》
2，測試文檔審核師
測試文檔審核師主要負(fù)責(zé)前置測試，包括在需求期與設(shè)計期間產(chǎn)生的文檔進(jìn)行審核，比如《業(yè)務(wù)建模書》，《需求規(guī)格說明書》，《概要設(shè)計書》，《詳細(xì)設(shè)計書》等等。審核需要進(jìn)行書寫審核報告。當(dāng)文檔確定后，需要整理文檔報告，并且反映介紹給測試設(shè)計師。
3，測試設(shè)計師
測試設(shè)計師主要根據(jù)需求期與設(shè)計期間產(chǎn)生的文檔設(shè)計各個測試階段的測試用例。
（往往測試文檔審核師，測試設(shè)計師可以有相同的一組人來完成）
4， 測試工程師
測試工程師按照測試用例，來完成測試工作。

但是測試人員應(yīng)該有哪些人來組成呢？也就是測試人員的橫向組成，讓我們再來討論討論：
1， 需要具有一定開發(fā)經(jīng)驗的計算機(jī)專業(yè)人員
由于具有一定開發(fā)經(jīng)驗的計算機(jī)專業(yè)人員即懂得計算機(jī)的基本理論，又有一定的開發(fā)經(jīng)驗。所以對于軟件中哪里容易出錯，哪里不容易出錯他們了如指掌；他們可以分析程序的性能，軟件性能差是否是占有內(nèi)存空間太多，或者是占有CPU時間太多引起的，還是其他原因，他們往往是專家。尤其是進(jìn)行非功能測試的時候，他們可以更好的搭建系統(tǒng)測試平臺。這種人員應(yīng)該占測試隊伍中一半以上。
2， 需要具有本軟件業(yè)務(wù)經(jīng)驗的人員
測試隊伍中需要有這樣的人員的目的在于，這些人員由于對業(yè)務(wù)非常熟悉，軟件質(zhì)量的前提又是滿足用戶的需求。專業(yè)業(yè)務(wù)知識是計算機(jī)專業(yè)人員達(dá)不到的，所以這方面人才可以利用它們的業(yè)務(wù)知識和專業(yè)水平，參與系統(tǒng)需求期間的文當(dāng)審核，可以發(fā)現(xiàn)軟件中存在的業(yè)務(wù)性錯誤。比如專業(yè)用語不準(zhǔn)確，業(yè)務(wù)流程不規(guī)范等等，這種人才對于專業(yè)性比較強(qiáng)的軟件測試工作尤為重要，比如稅務(wù)，法律，藝術(shù)，CAD,CAM…
3， 只需要會操作計算機(jī)的人員
由于軟件一旦賣出去之后，使用軟件的人各種各樣，各種各樣的人帶來各種各樣的操作情況，請一大部分人員在軟件測試工作后期進(jìn)行測試工作是十分重要的，他們往往會發(fā)現(xiàn)專業(yè)測試人員測試不出的東西和一些希奇古怪的錯誤。這就是軟件測試學(xué)中所謂的猴子測試法。
對于一個軟件公司來說，并不是說所有的測試隊伍都需要這三種人員，實際中可以一組人代替多個角色，但是要遵循以下原則：
1，對于業(yè)務(wù)不是很專業(yè)的軟件，具有一定開發(fā)經(jīng)驗的計算機(jī)專業(yè)人員與具有本軟件業(yè)務(wù)經(jīng)驗的人員可以合并；
2，只需要會操作計算機(jī)的人員，可以由公司行政人員來充當(dāng)。

 　　“從我在微軟工作的經(jīng)歷來看，軟件測試絕對不是開發(fā)活動完成后的收尾工作，很多大型的開發(fā)項目，測試會占據(jù)項目周期一半以上的時間。以IE4.0為例，代碼開發(fā)時間為6個月，而穩(wěn)定程序花去了8個月的時間?！鼻拔④泚喼扪芯吭翰┦俊④浖y試專家陳宏剛談道。從投入的資金和人力物力來看，測試、使產(chǎn)品穩(wěn)定和修改花去的時間可能占到80%。
還處在嬰兒期

　　軟件測試之所以發(fā)展相對緩慢，一個原因是做研究和做開發(fā)的人交流的機(jī)會相對少。只有做大型系統(tǒng)工程的人才會對測試提出較高的要求，重要性才能顯現(xiàn)出來，而做研究和教學(xué)的人沒有大型系統(tǒng)工程案例，所以造成了測試?yán)碚撗芯康陌l(fā)展缺乏充實的基礎(chǔ)材料。真正做大型系統(tǒng)開發(fā)的工程師，又沒有時間將第一手的測試經(jīng)驗變成系統(tǒng)的理論。

　　“在美國，佛羅里達(dá)州和華盛頓州分別有一所大學(xué)開設(shè)軟件測試課程，其他有正規(guī)課程的學(xué)校不是很多。軟件測試正停留在沒有學(xué)科系統(tǒng)、沒有系統(tǒng)教育的階段。雖然已經(jīng)有學(xué)校開設(shè)了這門課程，但是使用的教學(xué)案例，多半是單機(jī)軟件，還談不上系統(tǒng)的理論?！标惡陝偛┦拷榻B說。

　　高素質(zhì)的“雜牌軍”

　　由于企業(yè)對測試人才有著迫切的需要，因此，只好自??品制定測試規(guī)范，開設(shè)一些課程，通過講座的形式對測試技術(shù)人員進(jìn)行培訓(xùn)，但是也還未形成系統(tǒng)的理論。

　　即使在微軟，測試隊伍是典型的“雜牌軍”，沒有科班，沒有統(tǒng)一的專業(yè)，更多的是具有豐富的經(jīng)驗和不同行業(yè)背景的員工，例如具有語言學(xué)、數(shù)學(xué)、物理學(xué)、計算機(jī)、工程、管理等學(xué)科等背景的員工。但是，這不是說隨便什么人都可以做測試工作，陳宏剛工作過的那個試驗室，20個人中有7個博士?？梢姡m然測試不是一個專門的學(xué)科，但是，這個部門對于一個成熟的軟件企業(yè)又是至關(guān)重要的部門。

　 認(rèn)識需再提高

　 IBM和微軟公司屬于領(lǐng)先的大公司，對測試的認(rèn)識也經(jīng)歷了一個過程。開始的時候，也是開發(fā)人員兼職做測試，就像今天國內(nèi)一些較小規(guī)模的軟件企業(yè)。但是，后來的結(jié)果表明，花在軟件修補(bǔ)上面的費用太高，以至于遠(yuǎn)遠(yuǎn)超出了所能夠允許的范圍。這個時候，增加測試隊伍的規(guī)模，提高測試隊伍的素質(zhì)，提高測試隊伍的待遇和受重視的程度是更加劃算的。

　　還有一個問題是，很多工程師不愿意做測試，認(rèn)為是一種打下手的工作，沒有前途，這也是國內(nèi)比較大軟件企業(yè)面臨的問題。所以，企業(yè)從上到下普遍自覺和不自覺地只重視技術(shù)，不重視質(zhì)量，后果是產(chǎn)品在市場上競爭力不高，產(chǎn)品售后維護(hù)和服務(wù)費用偏高。

　　巨大反差

　　微軟的開發(fā)工程師與測試工程師的比例是1∶2，國內(nèi)一般公司是6∶1。而且，致命的問題是沒有哪個機(jī)構(gòu)專門培養(yǎng)測試工程師。這個矛盾提示我們，在中國不能等到實際的需求和人力資源矛盾十分尖銳的時候，再談培養(yǎng)問題；也不能等到產(chǎn)品質(zhì)量成為產(chǎn)業(yè)阻礙的時候再來提高軟件業(yè)的測試水平。測試工作不能靠手工勞動來完成，更多的情況是要使用工具軟件和編寫測試程序來完成，培養(yǎng)全面的測試專業(yè)人才是項任重道遠(yuǎn)的工作。

       通常情況下，一個軟件模型說明的內(nèi)容主要包括，在測試過程中你應(yīng)該考慮到哪些問題，如何對測試進(jìn)行計劃，測試要達(dá)到什么目標(biāo)，什么時候開始，在測試中你要用到哪些信息資源。一個好的模型可以引導(dǎo)你對問題進(jìn)行思考，而不好的模型則只能使你誤入歧途。

      這里我要宣稱的是，目前的大多數(shù)軟件測試模型都是不好的模型。這是因為這些測試模型僅僅是軟件開發(fā)模型的一些裝飾和補(bǔ)充而已。

      人們一直在苦苦尋找軟件開發(fā)的模型，在創(chuàng)建了新的模型后，就把測試作為一個階段放在模型的后面部分。因此測試總被作為一種事后行為，測試總是被開發(fā)所驅(qū)動?？偟膩碚f，我們是在檢測他們的完成品。但是，作為事后處理的測試，其驅(qū)動方式是不正確的。實際上它顯而易見地和開發(fā)過程中各種行為之間有關(guān)，測試沒有起到應(yīng)有的平衡作用。這樣的測試只是檢測了開發(fā)人員做了什么，而并沒有檢測到他們是否按照規(guī)則做了什么，這樣的做法割裂了本該緊密聯(lián)系的行為，剩下的只有那些匆忙而草率的想法所帶來的傷害。

      而這樣做的結(jié)果就是效果很差的、效率很低的測試。效果很差的測試將導(dǎo)致很多bug沒有被發(fā)現(xiàn)，而效率很低的測試所浪費的是成本。

      在本文中，我要做2件事，其一，我要否定一個不好的模型，即V模型。我希望通過論述來表明，“單元測試”和“集成測試”這2個詞匯可以從我們的詞匯表中取消了。其二，我將描述一個更好的模型。不過首先我認(rèn)為，要真正擁有一個充分合理的模型還為時尚早。我僅僅是描述了一些新模型應(yīng)該符合的重要的要求。這些要求將在本文末尾處列舉。

      V模型有什么問題呢？

      在本文中我要把V模型作為不好的模型的典型來進(jìn)行分析。我選擇V模型作為分析的典型是因為V模型是最廣為人知的測試模型。

      最典型的V模型版本一般會在其開始部分對軟件開發(fā)過程進(jìn)行描述，如下圖所示：

 

      這是古老的瀑布模型。作為開發(fā)模型，它有很多問題，不過這里不作討論。盡管它的各種狀態(tài)是我們接著要討論的大家最熟悉的V模型的基礎(chǔ)。我的批評意見同時也針對其它的裝飾在一些更好的開發(fā)模型之上的測試模型，例如螺旋模型【Boehm88】。

     在V模型中，測試過程被加在開發(fā)過程的后半部分，如下圖所示：

 

      單元測試所檢測的是，代碼的開發(fā)是否符合詳細(xì)設(shè)計的要求。集成測試所檢測的是，此前測試過的各組成部分是否能完好地結(jié)合到一起。系統(tǒng)測試所檢測的是，已集成在一起的產(chǎn)品是否符合系統(tǒng)規(guī)格說明書的要求。而驗收測試則檢測產(chǎn)品是否符合最終用戶的需求。

     對于測試設(shè)計，顯而易見的是，V模型的用戶往往會把執(zhí)行測試與測試設(shè)計分開對待。在開發(fā)文檔準(zhǔn)備就緒后，就可以開始進(jìn)行相關(guān)的測試設(shè)計。如下圖所示，相應(yīng)的測試設(shè)計覆蓋在了相關(guān)的開發(fā)過程之上：

 

     V模型有著很吸引人的對稱外形，并且把很多人都帶入了歧途。本文將集中討論它在單元測試和集成測試中引起的問題。

      為了說明的方便，這里專門制作了以下圖片，圖中包括一個單獨的單元，以及一個單元組，我稱之為子系統(tǒng)（subsystem）。

 

      對于一個單元應(yīng)該多大才最為合適的問題，已經(jīng)有過很多的討論，究竟一個單元僅僅是一個函數(shù)，一個類，還是相關(guān)的類的集合？這些討論并不影響我在這里所要闡述的觀點。我們權(quán)且認(rèn)為一個單元就是一個具有最小程度的代碼塊，開發(fā)人員可以對進(jìn)行獨立地討論。

     V模型認(rèn)為人們首先應(yīng)該對每一個單元進(jìn)行測試。當(dāng)子系統(tǒng)中所有的單元都已經(jīng)測試完畢，它們將被集中到一起進(jìn)行測試，以驗證它們是否可以構(gòu)成一個可運行的整體。

      那么，如何針對單元進(jìn)行測試呢？我們會查看在詳細(xì)設(shè)計中對接口的定義，或者查看源代碼，或者同時對兩者進(jìn)行查看，找出符合某些測試設(shè)計中的有關(guān)準(zhǔn)則的輸入數(shù)據(jù)來進(jìn)行輸入，然后檢查結(jié)果，看其是否正確。由于各單元一般來說不能獨立地運行，所以我們不得不另外設(shè)計樁模塊（Stub）和驅(qū)動模塊（Driver），如下圖所示。

 

        圖中的箭頭代表了測試的執(zhí)行軌跡。這就是大多數(shù)人所說的“單元測試”。我認(rèn)為這樣的方法有時候是一種不好的方法。

      同樣的輸入也可以有同一子系統(tǒng)中的其它單元來提供，這樣，其它的單元既扮演了樁模塊，又扮演了驅(qū)動模塊。如下圖所示：

      到底選擇哪一種方法，這需要一種折衷和權(quán)衡。設(shè)計樁模塊和驅(qū)動模塊要付出多少代價？這些模塊如何進(jìn)行維護(hù)？子系統(tǒng)是否會由此而掩蓋了一些故障？在整個子系統(tǒng)范圍內(nèi)進(jìn)行排錯的困難程度有多大？如果我們的測試直到集成測試時才真正開始，那么一些bug可能較晚才被發(fā)現(xiàn)。由此造成的代價同設(shè)計樁模塊和驅(qū)動模塊的代價如何比較？等等。

     V模型沒有去考慮這些問題，當(dāng)單元開發(fā)完成后就執(zhí)行單元測試，而當(dāng)自系統(tǒng)被集中在一起后就執(zhí)行集成測試，僅此而已。令我奇怪和沮喪的是，人們從不去做一些權(quán)衡，他們已經(jīng)受制于他們的模型。

      因此，一個有用的模型應(yīng)該允許測試人員考慮節(jié)省并推遲測試的可能性。

      一個測試，如果要發(fā)現(xiàn)一個特定的單元中的bug，最好是在該單元保持獨立的情況下執(zhí)行，并且在其外部輔以特定的樁模塊和驅(qū)動模塊。而另一種方法則是讓它作為子系統(tǒng)的一部分來進(jìn)行測試，該測試的設(shè)計主要是為了發(fā)現(xiàn)集成的問題。由于一個子系統(tǒng)本身也需要樁模塊和驅(qū)動模塊來模擬該子系統(tǒng)和其它子系統(tǒng)的聯(lián)系，因此，單元測試和集成測試可能被推遲到至少整個系統(tǒng)已經(jīng)部分集成的時候。在這種情況下，測試者可能通過產(chǎn)品的外部接口同時進(jìn)行單元測試、集成測試和系統(tǒng)測試，同樣的，其主要目的還是為了減少總體生命周期的成本，對測試成本和延期進(jìn)行測試及由此造成延期發(fā)現(xiàn)bug的代價成本進(jìn)行權(quán)衡。據(jù)此而言，“單元測試”、“集成測試”和“系統(tǒng)測試”的區(qū)別已經(jīng)大大削弱了。其結(jié)果可參考下圖：

 

        在上圖右邊的方塊中，最好要改成為“執(zhí)行某些適當(dāng)?shù)臏y試并得到相應(yīng)的結(jié)果”。

     圖中的左邊會怎樣？考慮一下系統(tǒng)測試設(shè)計，它的主要根據(jù)和信息來源是是規(guī)格說明。假設(shè)你知道有2個單元處在一個特定的子系統(tǒng)中，它們在運行時相互聯(lián)系，并且要執(zhí)行規(guī)格說明中的一個特定的聲明。為什么不在該子系統(tǒng)被集成時立即對此規(guī)格說明中的聲明進(jìn)行測試，就象是在設(shè)計完成后立即開始測試的設(shè)計一樣呢？如果該聲明的執(zhí)行和子系統(tǒng)外的子系統(tǒng)沒有任何關(guān)系，為什么還要等到整個系統(tǒng)完成以后再測試呢？難道越早發(fā)現(xiàn)bug成本越低不對嗎？

     在上一張圖片中，我們用了向上指的箭頭（更有效，但在時間上有延遲）。這里還可以把箭頭往下指（在時間上提前）：

 

     在這種情況下，左邊的方塊中最好被標(biāo)記為：“在當(dāng)前信息條件和情況下可以做的任何測試設(shè)計”。這樣，當(dāng)測試設(shè)計得自于系統(tǒng)中某一個組件的描述時，模型必須允許這樣的測試在組件被裝配之前被執(zhí)行。我必須承認(rèn)我的圖片非常難看，這些箭頭指得到處都是，對此我有2點說明：

  1. 我們所討論的事情不是創(chuàng)造美，而是想要發(fā)現(xiàn)盡可能多的嚴(yán)重錯誤，同時盡可能地降低成本。

  2. 難看的部分原因也是因為必須按照某些次序來執(zhí)行的結(jié)果，亦即開發(fā)人員先提供系統(tǒng)描述文檔，然后測試和這些文檔進(jìn)行關(guān)聯(lián)。這些文檔就象是堅實的老橡樹，而測試設(shè)計則象是細(xì)細(xì)的枝條纏繞在樹上。如果我們采用不同的原理來進(jìn)行組織，圖片可能就會變得好看些。但復(fù)雜性仍不可避免，因為我們要討論的問題本身就很復(fù)雜。

      V模型失敗的原因是它把系統(tǒng)開發(fā)過程劃分為具有固定邊界的不同階段，這使得人們很難跨過這些邊界來采集測試所需要的信息。有些測試應(yīng)該執(zhí)行得更早些，有些測試則需要延后進(jìn)行。而且，它也阻礙了你從系統(tǒng)描述的不同階段中取得信息進(jìn)行綜合。例如，某些組織有時執(zhí)行這樣的做法，即對完成的工作進(jìn)行簽署。這樣的規(guī)定也擴(kuò)展到系統(tǒng)測試的設(shè)計。簽署表示已經(jīng)過評估，該測試設(shè)計工作已經(jīng)完成，除非對應(yīng)的設(shè)計文檔改變，否則就不會被修訂。如果同這些測試相關(guān)的信息后來被重新挖掘和認(rèn)識，例如，架構(gòu)設(shè)計表明有些測試是多余的，或者，詳細(xì)設(shè)計表明有一個內(nèi)部的邊界可以和已存在的系統(tǒng)測試組合在一起進(jìn)行測試的話，那么實際上還需要繼續(xù)調(diào)整原來的系統(tǒng)測試設(shè)計。

      因此，模型必須允許利用不同來源的綜合信息進(jìn)行個別的測試設(shè)計。另外，模型還應(yīng)該允許在新的信息來源出現(xiàn)后重新進(jìn)行測試的設(shè)計。

     一個不同的模型

     讓我們來看本文的第二項內(nèi)容，一個不同的模型。

     很多時候人們把代碼移交給其他人，并且說：“希望你能接受和喜歡它?！边@不僅發(fā)生在將整個項目放在一張光盤中交給客戶的時候，也發(fā)生在項目內(nèi)部。

     例如，一個小組對另一個小組說：“我們已經(jīng)完成了為COMM庫加入了對XML的支持。源代碼現(xiàn)在已經(jīng)放在master庫中，可執(zhí)行庫則已經(jīng)加入到集成與創(chuàng)建的環(huán)境中。XARG小組的工作已經(jīng)沒有什么阻礙了，隨時去取吧?！?/P>

      某個程序員檢查了bug的修改并且發(fā)出郵件：“我已經(jīng)修改了Bug列表中的那個Bug，很抱歉！”至此，早先受該問題影響的其它代碼就可以繼續(xù)處理了。

     在這些情況下，人們要把代碼移交給其它人，其中有可能會存在一些影響。測試人員需要干預(yù)這個過程。在移交之前，測試人員應(yīng)執(zhí)行這些代碼，發(fā)現(xiàn)其中的bug（影響），并且提出問題：“你確實要提交這些嗎？”由此，移交的內(nèi)容可能會被延期，直到bug被修復(fù)好。

      盡管你還要做其它的各種測試，這項測試仍然是很基本的測試工作。如果你沒有做這樣的測試，就不能算是合格的測試人員。

      我們的測試模型必須包含這一重要的現(xiàn)實需要：針對代碼移交的測試。由此，測試模型應(yīng)提示進(jìn)行針對每一次代碼移交的測試。

      就讓我以支持XML的COMM庫作為例子。這里存在著一個小組把代碼移交給XARG小組以進(jìn)行項目的余下部分。那么誰會遭受影響？

      要將這些支持XML的代碼直接進(jìn)行使用的XARG小組可能會立即受到影響；

      這可能會在稍后影響到市場人員，他們要在一個行業(yè)展示會議上為“合作伙伴發(fā)行”版本提供產(chǎn)品演示和宣傳，而XML支持是影響他們銷售的重要部分；

      還有，它可能損害采納我們的產(chǎn)品的合作伙伴。

      現(xiàn)在我們可以提出一些有趣的關(guān)于測試計劃的問題了。最簡單的可以做的事情是，在移交的時候立即執(zhí)行XML支持的完整測試。（“完整”的含義是，為此設(shè)計盡可能多的測試）但也許一些XML特性并不是XARG小組所需要的，因此可以把它們放在合作伙伴版本封版（下圖中的“Partner Release”）的測試中去。這意味著可以把一些XML相關(guān)測試放到稍后的移交過程中去?；蛘呋谄渌碛桑缭诮A段有其它的測試任務(wù)要執(zhí)行。而XARG小組則要因XML中的bug修復(fù)而延遲一小段時間。

      我們的測試計劃所表示的進(jìn)度可以通過在開發(fā)的時

 

      我們應(yīng)嚴(yán)格地圍繞在XML支持的功能交接的時段里進(jìn)行測試。測試設(shè)計和測試支持工作要早于測試執(zhí)行。而另外的XML測試則要延遲到基于整個項目范圍的“代碼完成”（圖中的“Code Complete”里程碑），或者要等到全部的子系統(tǒng)被集中在一起，而且整個產(chǎn)品為了行業(yè)會議而在經(jīng)過穩(wěn)定化處理后創(chuàng)建了版本（圖中的“Partner Release”里程碑）。

      顯然，有兩項內(nèi)容沒有包含在代碼完成里程碑中：

      還有大量其它的測試工作（包括設(shè)計、工具選用）。這些工作可能因為COMM以外的子系統(tǒng)的交接而延期。

      而且，還有用于完成里程碑中所規(guī)定的某些風(fēng)險的測試，例如，可能還有一組用于運行市場人員的演示Demo腳本的測試，包括她可能在無意中引起的偏離。其目的是要避免這樣的情況，即當(dāng)她站在1000人的觀眾面前時，她還僅僅是第一次以某種特定的順序來輸入數(shù)據(jù)。

      一些首次交接時進(jìn)行的XML測試需要在代碼完成里程碑上再次執(zhí)行。

      我的觀點是，測試計劃是由很多困難的決定所組成，這些決定包括人員組織安排、機(jī)器資源配置、測試設(shè)計的時間定位、測試支持代碼的數(shù)量、哪些測試要做自動化，等等。這些決定應(yīng)根據(jù)單獨的交接中的內(nèi)容信息來作出。如果僅有一次交接，那么你可以更順利一些。測試計劃還應(yīng)繼續(xù)考慮以下問題：

  1. 風(fēng)險分析，誰會因此受到損害，以什么方式？

  2. 選定一種測試途徑來定位特定的風(fēng)險。

  3. 對測試設(shè)計和執(zhí)行的周期和成本進(jìn)行估計。

  4. 在項目進(jìn)度上的特定位置，將計劃納入執(zhí)行的行動：

  A. 開始對測試進(jìn)行設(shè)計…

  B. … 同時設(shè)計和創(chuàng)建一些支持測試的代碼…

  C. … 在全部測試完成以前就執(zhí)行部分的測試，因為可能存在不只一次的交接，在每一次交接的測試規(guī)劃中，可能存在一些潛在的復(fù)雜的相互影響。工作安排不得不進(jìn)行一些調(diào)整以達(dá)到相互間的平衡。測試支持代碼和工具需要在各項任務(wù)中得到共享。你還必須考慮到在什么程度上讓那些為早先的交接所設(shè)計的測試在以后重新執(zhí)行，等等。

      這看起來很復(fù)雜?？瓷先ニ坪跤刑嗟膬?nèi)容需要跟蹤，而且太多的內(nèi)容可能被忽略。也許你認(rèn)為我是在要求你要對每一次交接來執(zhí)行IEEE 829 【IEEE98】中關(guān)于測試計劃的要求，然后把它們合并為一份貫穿整個項目的針對交接進(jìn)行測試的測試計劃。

      是，也不是。思考問題總是要占用時間的。太多的計劃可能會減少結(jié)果的產(chǎn)出。在有些時候，你需要做的是停止計劃并開始行動。例如，你無法思考并描述每一個bug修復(fù)，盡管bug修復(fù)也是一種交接。

      但是bug修復(fù)是實際工作中現(xiàn)實存在的問題。總體項目計劃中應(yīng)該包含bug修復(fù)。需要強(qiáng)調(diào)的是，你應(yīng)該有一個默認(rèn)的bug修改處理的標(biāo)準(zhǔn)過程，該過程應(yīng)包括運行于每一個提交的bug修復(fù)的驗證過程。你還需要努力地去思考問題。很多時候，各項驗證是被放在一起同時進(jìn)行并完成的。

      比較現(xiàn)實地來說，一個模型應(yīng)該允許一些機(jī)械式行為，例如，“不管是哪一個X類型的交接，都要執(zhí)行下列操作”。同時我們鼓勵對特定的交接執(zhí)行剛剛夠的檢查，對于風(fēng)險越小的交接，就越可以采用機(jī)械式的測試行為。

      一個明確考慮到基本的測試現(xiàn)實的模型肯定會比忽略這些現(xiàn)實或者把你的工作復(fù)雜性完全抽象化的模型做得更好。文檔則是另一個例子。

      我還沒有提到需求及規(guī)格說明書，或者設(shè)計文檔。某個交接中產(chǎn)生的一系列變化會引起很多爭議。這些文檔所扮演的角色是什么呢？它們常常是這么被使用的：

 

  （圖10：測試中對開發(fā)文檔的利用）

      文檔可以指導(dǎo)你在一個交接變化時如何作出反應(yīng)。如果你有一份很好的需求文檔，它可能是產(chǎn)品所解決的問題的描述，盡管也許不是很直接。它可以幫助你對風(fēng)險進(jìn)行分析。一份好的規(guī)格說明應(yīng)對系統(tǒng)的行為進(jìn)行描述。這將幫助你把測試方法轉(zhuǎn)化為具體的測試。一份好的架構(gòu)設(shè)計則可以幫助你理解變化可能引起的幾種不同的情況：系統(tǒng)的其它部分會受到怎樣的影響？什么測試需要再次進(jìn)行？

      我并不是經(jīng)常能看到好的文檔。需求文檔常常象是市場銷售用的系統(tǒng)特性列表。規(guī)格說明書有時就象是在代碼完成后提交的用戶手冊文件。而設(shè)計文檔經(jīng)常不存在。

      好了，通過針對交接所引起的變化的集中討論，我已把測試過程和軟件開發(fā)過程相對地分離開了。如果文檔中關(guān)于“XML支持功能加入到COMM”的描述很薄弱的話，我會盡自己所知來進(jìn)行盡可能好的測試設(shè)計。然后，假如在項目后期，XML相關(guān)的用戶文檔出來了，我就可以對后來再次提交的交接增加相關(guān)的測試。假如市場需求改變了，她們經(jīng)常會這么做，我還會在此后增加或者去除一些測試。所有這一切看起來是這樣的：

 

  （圖11--在文檔不完整的條件下進(jìn)行測試，并在后期補(bǔ)充測試）

      這樣，雖然項目文檔總是不到位，而且經(jīng)常延遲提交，測試的效果也因此常常被降低，我們還是要避免測試受到項目文檔的制約。

      頭腦靈活的測試人員并不過于相信文檔。畢竟，總是人在犯錯誤。那么，難道不是人在寫這些文檔嗎？

      由于“正式的”文檔是很薄弱的，測試模型必須明確地鼓勵在測試過程中使用項目文檔之外的各種不同信息來源。

      測試人員必須和程序員、用戶、市場人員、技術(shù)作者以及任何的可能為實現(xiàn)更好測試提供線索的人進(jìn)行交流。測試人員還應(yīng)該努力把自己沉浸在某些技術(shù)所構(gòu)建的氛圍中。例如，我希望測試人員在做XML測試工作時常去訪問W3組織的XML地址（http://www./XML/）以及其它XML站點、郵件列表，甚至包括比較特別的 如Dave Winer的DaveNet/腳本新聞（http://www./）。這些資源并不是所謂的“輔助通道”，而是可以被列入計劃和進(jìn)度日程的資源。

      另外，所執(zhí)行的測試本身也是一種有用的信息的資源。好的測試人員會仔細(xì)閱讀bug報告，因為這些報告講授了系統(tǒng)所存在的薄弱之處。特別地，這些報告還暗示了一些正式的架構(gòu)設(shè)計所沒有提供的架構(gòu)上的策略。執(zhí)行測試的行為應(yīng)該產(chǎn)生一些新的測試想法。如果模型沒有考慮到這些，那么它就是一個落后的模型。

      因此，測試模型應(yīng)該包含反饋的循環(huán)，讓測試設(shè)計可以考慮到，在運行測試時還可以繼續(xù)發(fā)現(xiàn)到更多的測試內(nèi)容。

      在我們的工作中，真正的復(fù)雜性來自于所有計劃的執(zhí)行都處于一個不確定的、容易忽略的環(huán)境里。代碼并不是唯一在不斷變化的東西。而計劃日程也在改變。新的功能擴(kuò)充會帶來新的里程碑。某些功能會從當(dāng)前版本中去除。在開發(fā)過程中，所有人--市場人員、開發(fā)人員和測試人員，都會逐漸對諸如“產(chǎn)品究竟提供什么”這樣的問題有越來越清晰的了解。在這些情形下，我們怎么能說測試計劃的第一個版本會是完全正確的呢？

      因此，模型應(yīng)該要求測試計劃人制定明確的規(guī)定，對已交接的交接內(nèi)容，新的交接，以及交接內(nèi)容的變更進(jìn)行負(fù)責(zé)。

      總結(jié)

      V模型有以下致命的缺陷，其它模型實際上也與此相似：

  1. 忽略了這樣的事實情況，即軟件開發(fā)是由一系列的交接所組成，每一次交接內(nèi)容都改變了前一次交接的行為。

  2. 依賴于開發(fā)文檔的存在，及文檔的精確性、完整性，并且沒有對時間進(jìn)行限制。

  3. 認(rèn)定一種測試的設(shè)計是依據(jù)某一個單獨的文檔，而不包括根據(jù)其前后階段的文檔的修改而作相應(yīng)修改。

  4. 認(rèn)定這些依賴于某個單獨文檔的測試一定要在一起執(zhí)行。

      我大致描述了一個替代模型，但還不夠精細(xì)。它考慮到了代碼的交接和里程碑。對測試成本控制作了以下明確描述：

      測試設(shè)計的目標(biāo)是定義好可能發(fā)現(xiàn)bug的測試輸入，而測試執(zhí)行的目標(biāo)是以各種方式加入這些數(shù)據(jù)，并檢驗結(jié)果，由此來降低整個生命周期的成本。

      我們的模型假設(shè)軟件產(chǎn)品總是不完美的，開發(fā)過程中有很多變更，而且對產(chǎn)品的測試也是一個不斷學(xué)習(xí)的過程。

      過去，我很少考慮到模型。表面上我一直還在用V模型。雖然我按此制訂計劃，但我總是還要花費很多額外的精力和時間來考慮模型中沒有提到的方面。換言之，模型造成了一些阻礙，因此我有必要對此進(jìn)行研究。

      對一個新的模型來說，對模型所提出的要求必須非常明確，這就象業(yè)務(wù)需求對產(chǎn)品開發(fā)非常重要一樣。我希望自己對本文中所提倡的模型的要求的描述能夠和V模型中的描述一樣精確，并具有同樣的指導(dǎo)意義。

      理想的測試模型應(yīng)該包括下列要求：

  1. 使測試對項目中的每一次代碼交接有所反應(yīng)。

  2. 要求測試計劃人制定明確的規(guī)定，對已交接的交接內(nèi)容，新的交接，以及交接內(nèi)容的變更進(jìn)行負(fù)責(zé)。

  3. 在測試設(shè)計中，除了使用項目文檔外，還應(yīng)明確鼓勵使用其它各種信息，這些信息有不同來源。

  4. 事實上項目文檔總是不到位，而且經(jīng)常延遲提交，測試的效果也因此常常被降低。但我們還是要盡量避免測試受到項目文檔的制約。

  5. 允許根據(jù)多種來源提供的綜合信息來設(shè)計一些獨立的測試。

  6. 讓測試被重新設(shè)計，以新的信息形式進(jìn)行表現(xiàn)。

  7. 包含反饋的循環(huán)，讓測試設(shè)計可以考慮到，在運行測試時還可以繼續(xù)發(fā)現(xiàn)到更多的測試內(nèi)容。

  8. 讓測試人員認(rèn)識到，避免測試的延遲可以節(jié)省成本。

  9. 在組件被組裝到程序中去之前對組件的執(zhí)行進(jìn)行測試。