軟件測試
使用人工或者自動(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à)值的,完整的測試是評(píng)定軟件質(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.評(píng)市、審查、測試、檢查、審計(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)評(píng)估所準(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ò)誤可以召開評(píng)審會(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)行測試�！昂诤小狈ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯(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)行測試�！鞍缀小狈ㄊ歉F舉路徑測試。在使用這一方案時(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)告異常情況、提出批評(píng)意見。然后軟件開發(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)錄放功能外,它還提供了一系列的輔助支持功能,比如,
