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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、黑盒測試

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

2、白盒測試

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

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

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

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

單元測試的基本方法

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

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

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

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

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

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

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

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

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

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

單元測試過程

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

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

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

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

綜合測試的基本方法

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

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

1 自頂向下集成

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

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

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

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

2自底向上集成

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

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

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

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

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

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

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

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

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

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

2. 配置復(fù)審

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

3. α、β測試

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

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

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

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

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

１、恢復(fù)測試

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

２、安全測試

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

３、強(qiáng)度測試

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

４、 性能測試

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

常見的軟件測試類型有：

      BVT (Build Verification Test)

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

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

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

      Smoke Test

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

      此外，Application Compatibility Test（兼容性測試），主要目的是為了兼容第三方軟件，確保第三方軟件能正常運(yùn)行，用戶不受影響。Accessibility Test（軟件適用性測試），是確保軟件對于某些有殘疾的人士也能正常的使用，但優(yōu)先級(jí)比較低。其它的測試還有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)用軟件的測試,它的一個(gè)重要特點(diǎn)是可以自動(dòng)驅(qū)動(dòng)被測程序的運(yùn)行。SQA可以自動(dòng)記錄和重放程序執(zhí)行過程,從而實(shí)現(xiàn)了對測試進(jìn)行"復(fù)查"的自動(dòng)化。

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

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

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

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

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

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

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

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

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

  ·測試問題報(bào)告的記錄與管理。

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

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

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

  ·未初始化的局部變量

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

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

  ·數(shù)組越界

  ·內(nèi)存丟失

  ·文件描述問題

  ·棧溢出問題

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

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

  …/"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)識(shí)軟件測試的重要性和復(fù)雜性,合理地選擇測試方法,有效地組織測試人員和安排測試任務(wù),并且盡量使用軟件測試工具增強(qiáng)軟件測試的自動(dòng)化程度,無疑可以幫助軟件開發(fā)和測試人員大大提高測試效率和軟件的質(zhì)量。

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

  ·擬定軟件測試計(jì)劃

  ·編制軟件測試大綱

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

  ·實(shí)施測試

  ·生成軟件問題報(bào)告

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

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

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

      一般而言,測試用例是指為實(shí)施一次測試而向被測系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設(shè)置。測試用例控制著軟件測試的執(zhí)行過程,它是對測試大綱中每個(gè)測試項(xiàng)目的進(jìn)一步實(shí)例化。已有許多著名的論著總結(jié)了設(shè)計(jì)測試用例的各種規(guī)則和策略。從工程實(shí)踐的角度講有幾條基本準(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è)的測試必須以一個(gè)好的測試計(jì)劃作為基礎(chǔ)。盡管測試的每一個(gè)步驟都是獨(dú)立的，但是必定要有一個(gè)起到框架結(jié)構(gòu)作用的測試計(jì)劃。測試的計(jì)劃應(yīng)該作為測試的起始步驟和重要環(huán)節(jié)。一個(gè)測試計(jì)劃應(yīng)包括：產(chǎn)品基本情況調(diào)研、測試需求說明、測試策略和記錄、測試資源配置、計(jì)劃表、問題跟蹤報(bào)告、測試計(jì)劃的評審、結(jié)果等等。

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

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

      具體的要點(diǎn)有：

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

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

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

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

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

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

      測試需求說明：

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

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

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

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

      測試的策略和記錄：

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

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

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

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

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

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

      測試資源配置：

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

      計(jì)劃表：

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

      問題跟蹤報(bào)告：

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

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

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

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

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

      測試計(jì)劃的評審：

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

      結(jié)果：

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

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

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

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

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

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

　　4. UI要加引號(hào)，可以單引號(hào)，推薦使用雙引號(hào)

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

　　5. 每一個(gè)步驟盡量只記錄一個(gè)操作

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

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

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

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

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

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

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

　　9. 檢查拼寫和語法錯(cuò)誤

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

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

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

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

　　錯(cuò)誤報(bào)告的UI要與測試的軟件UI保持一致，便于查找定位。

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

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

　　13. 每條錯(cuò)誤報(bào)告只包括一個(gè)錯(cuò)誤

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

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

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

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

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

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

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

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

　 認(rèn)識(shí)需再提高

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

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

　　巨大反差

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

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

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

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

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

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

      V模型有什么問題呢？

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

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

 

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

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

 

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

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

 

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

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

 

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

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

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

 

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

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

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

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

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

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

 

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

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

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

 

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

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

  2. 難看的部分原因也是因?yàn)楸仨毎凑漳承┐涡騺韴?zhí)行的結(jié)果，亦即開發(fā)人員先提供系統(tǒng)描述文檔，然后測試和這些文檔進(jìn)行關(guān)聯(lián)。這些文檔就象是堅(jiān)實(shí)的老橡樹，而測試設(shè)計(jì)則象是細(xì)細(xì)的枝條纏繞在樹上。如果我們采用不同的原理來進(jìn)行組織，圖片可能就會(huì)變得好看些。但復(fù)雜性仍不可避免，因?yàn)槲覀円懻摰膯栴}本身就很復(fù)雜。

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

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

     一個(gè)不同的模型

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

      總結(jié)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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