使用人工或者自動(dòng)手段來(lái)運(yùn)行或測(cè)試某個(gè)系統(tǒng)的過(guò)程,其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別.
它是幫助識(shí)別開發(fā)完成（中間或最終的版本）的計(jì)算機(jī)軟件（整體或部分）的正確度(correctness)、完全度(completeness)和質(zhì)量(quality)的軟件過(guò)程；是SQA(softwarequalityassurance)的重要子域。
GrenfordJ.Myers曾對(duì)軟件測(cè)試的目的提出過(guò)以下觀點(diǎn):
(1)測(cè)試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過(guò)程；
(2)好的測(cè)試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試方案；
(3)成功的測(cè)試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。
然而,這種觀點(diǎn)指出測(cè)試是以查找錯(cuò)誤為中心,而不是為了演示軟件的正確功能.但是只從字面意思理解,可能會(huì)產(chǎn)生誤導(dǎo),認(rèn)為發(fā)現(xiàn)錯(cuò)誤是軟件測(cè)試的唯一目的,查找不出錯(cuò)誤的測(cè)試就是沒有價(jià)值的測(cè)試,實(shí)際上并非如此!
(1)測(cè)試并不僅僅是為了找出錯(cuò)誤.通過(guò)分析錯(cuò)誤產(chǎn)生的原因和錯(cuò)誤的發(fā)生趨勢(shì),可以幫助項(xiàng)目管理者
發(fā)現(xiàn)當(dāng)前軟件開發(fā)過(guò)程中的缺陷,以便及時(shí)改進(jìn)；
(2)這種分析也能幫助測(cè)試人員設(shè)計(jì)出有針對(duì)性的測(cè)試方法,改善測(cè)試的效率和有效性；
(3)沒有發(fā)現(xiàn)錯(cuò)誤的測(cè)試也是有價(jià)值的,完整的測(cè)試是評(píng)定軟件質(zhì)量的一種方法
軟件測(cè)試的內(nèi)容
軟件測(cè)試主要工作內(nèi)容是驗(yàn)證(verification)和確認(rèn)(validation)，下面分別給出其概念：
驗(yàn)證(verification)是保證軟件正確地實(shí)現(xiàn)了一些特定功能的一系列活動(dòng)，即保證軟件做了你所期望的事情。(Dotherightthing)
1.確定軟件生存周期中的一個(gè)給定階段的產(chǎn)品是否達(dá)到前階段確立的需求的過(guò)程；
2.程序正確性的形式證明，即采用形式理論證明程序符號(hào)設(shè)一計(jì)規(guī)約規(guī)定的過(guò)程；
3.評(píng)市、審查、測(cè)試、檢查、審計(jì)等各類活動(dòng)，或?qū)δ承╉?xiàng)處理、服務(wù)或文件等是否和規(guī)定的需求相一致進(jìn)行判斷和提出報(bào)告。
確認(rèn)(validation)是一系列的活動(dòng)和過(guò)程，目的是想證實(shí)在一個(gè)給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式來(lái)做了這個(gè)事件(Doitright)
1.靜態(tài)確認(rèn)，不在計(jì)算機(jī)上實(shí)際執(zhí)行程序，通過(guò)人工或程序分析來(lái)證明軟件的正確性；
2.動(dòng)態(tài)確認(rèn)，通過(guò)執(zhí)行程序做分析，測(cè)試程序的動(dòng)態(tài)行為，以證實(shí)軟件是否存在問(wèn)題。
軟件測(cè)試的對(duì)象不僅僅是程序測(cè)試，軟件測(cè)試應(yīng)該包括整個(gè)軟件開發(fā)期問(wèn)各個(gè)階段所產(chǎn)生的文檔，如需求規(guī)格說(shuō)明、概要設(shè)計(jì)文檔、詳細(xì)設(shè)計(jì)文檔，當(dāng)然軟件測(cè)試的主要對(duì)象還是源程序。
從不同的角度出發(fā)，軟件測(cè)試可以劃分為不同的分類
從是否關(guān)心軟件內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)的角度劃分
A.白盒測(cè)試
B.黑盒測(cè)試
C.灰盒測(cè)試
從是否執(zhí)行程序的角度
A.靜態(tài)測(cè)試
B.動(dòng)態(tài)測(cè)試。
從軟件開發(fā)的過(guò)程按階段劃分有
A.單元測(cè)試
B.集成測(cè)試
C.確認(rèn)測(cè)試
D.驗(yàn)收測(cè)試
E.系統(tǒng)測(cè)試
軟件測(cè)試是軟件開發(fā)過(guò)程的重要組成部分，是用來(lái)確認(rèn)一個(gè)程序的品質(zhì)或性能是否符合開發(fā)之前所提出的一些要求。軟件測(cè)試就是在軟件投入運(yùn)行前，對(duì)軟件需求分析、設(shè)計(jì)規(guī)格說(shuō)明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過(guò)程。軟件測(cè)試在軟件生存期中橫跨兩個(gè)階段：通常在編寫出每一個(gè)模塊之后就對(duì)它做必要的測(cè)試（稱為單元測(cè)試）。編碼和單元測(cè)試屬于軟件生存期中的同一個(gè)階段。在結(jié)束這個(gè)階段后對(duì)軟件系統(tǒng)還要進(jìn)行各種綜合測(cè)試，這是軟件生存期的另一個(gè)獨(dú)立階段，即測(cè)試階段。
軟件測(cè)試的目的，第一是確認(rèn)軟件的質(zhì)量，其一方面是確認(rèn)軟件做了你所期望的事情（Do the right thing），另一方面是確認(rèn)軟件以正確的方式來(lái)做了這個(gè)事件（Do it right）。
第二是提供信息，比如提供給開發(fā)人員或程序經(jīng)理的反饋信息，為風(fēng)險(xiǎn)評(píng)估所準(zhǔn)備的信息。
第三軟件測(cè)試不僅是在測(cè)試軟件產(chǎn)品的本身，而且還包括軟件開發(fā)的過(guò)程。如果一個(gè)軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問(wèn)題，這說(shuō)明此軟件開發(fā)過(guò)程很可能是有缺陷的。因此軟件測(cè)試的第三個(gè)目的是保證整個(gè)軟件開發(fā)過(guò)程是高質(zhì)量的。
軟件質(zhì)量是由幾個(gè)方面來(lái)衡量的：一、在正確的時(shí)間用正確的的方法把一個(gè)工作做正確（Doing the right things right at the right time.）。二、符合一些應(yīng)用標(biāo)準(zhǔn)的要求，比如不同國(guó)家的用戶不同的操作習(xí)慣和要求，項(xiàng)目工程中的可維護(hù)性、可測(cè)試性等要求。三、質(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”.）。作為軟件測(cè)試這個(gè)行業(yè)，最重要的一件事就是從客戶的需求出發(fā)，從客戶的角度去看產(chǎn)品，客戶會(huì)怎么去使用這個(gè)產(chǎn)品，使用過(guò)程中會(huì)遇到什么樣的問(wèn)題。只有這些問(wèn)題都解決了，軟件產(chǎn)品的質(zhì)量才可以說(shuō)是上去了。
測(cè)試人員在軟件開發(fā)過(guò)程中的任務(wù)：
1、尋找Bug；
2、避免軟件開發(fā)過(guò)程中的缺陷；
3、衡量軟件的品質(zhì)；
4、關(guān)注用戶的需求。
總的目標(biāo)是：確保軟件的質(zhì)量。
軟件測(cè)試從不同的角度出發(fā)會(huì)派生出兩種不同的測(cè)試原則，從用戶的角度出發(fā)，就是希望通過(guò)軟件測(cè)試能充分暴露軟件中存在的問(wèn)題和缺陷，從而考慮是否可以接受該產(chǎn)品，從開發(fā)者的角度出發(fā)，就是希望測(cè)試能表明軟件產(chǎn)品不存在錯(cuò)誤，已經(jīng)正確地實(shí)現(xiàn)了用戶的需求，確立人們對(duì)軟件質(zhì)量的信心。
為了達(dá)到上述的原則，那么需要注意以下幾點(diǎn)：
1．應(yīng)當(dāng)把“盡早和不斷的測(cè)試”作為開發(fā)者的座右銘
2．程序員應(yīng)該避免檢查自己的程序，測(cè)試工作應(yīng)該由獨(dú)立的專業(yè)的軟件測(cè)試機(jī)構(gòu)來(lái)完。
3．設(shè)計(jì)測(cè)試用例時(shí)應(yīng)該考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況要制造極端狀態(tài)和意外狀態(tài)，比如網(wǎng)絡(luò)異常中斷、電源斷電等情況。
4．一定要注意測(cè)試中的錯(cuò)誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習(xí)慣有很大的關(guān)系。
5．對(duì)測(cè)試錯(cuò)誤結(jié)果一定要有一個(gè)確認(rèn)的過(guò)程，一般有A測(cè)試出來(lái)的錯(cuò)誤，一定要有一個(gè)B來(lái)確認(rèn)，嚴(yán)重的錯(cuò)誤可以召開評(píng)審會(huì)進(jìn)行討論和分析。
6．制定嚴(yán)格的測(cè)試計(jì)劃，并把測(cè)試時(shí)間安排的盡量寬松，不要希望在極短的時(shí)間內(nèi)完成一個(gè)高水平的測(cè)試。
7．回歸測(cè)試的關(guān)聯(lián)性一定要引起充分的注意，修改一個(gè)錯(cuò)誤而引起更多的錯(cuò)誤出現(xiàn)的現(xiàn)象并不少見。
8．妥善保存一切測(cè)試過(guò)程文檔，意義是不言而喻的，測(cè)試的重現(xiàn)性往往要靠測(cè)試文檔。
軟件測(cè)試并不等于程序測(cè)試。軟件測(cè)試應(yīng)該貫穿整個(gè)軟件定義與開發(fā)整個(gè)期間。因此需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說(shuō)明、概要設(shè)計(jì)規(guī)格說(shuō)明、詳細(xì)設(shè)計(jì)規(guī)格說(shuō)明以及源程序，都應(yīng)該是軟件測(cè)試的對(duì)象。
在對(duì)需求理解與表達(dá)的正確性、設(shè)計(jì)與表達(dá)的正確性、實(shí)現(xiàn)的正確性以及運(yùn)行的正確性的驗(yàn)證中，任何一個(gè)環(huán)節(jié)發(fā)生了問(wèn)題都可能在軟件測(cè)試中表現(xiàn)出來(lái)。
軟件測(cè)試的基本方法
單元測(cè)試的基本方法
綜合測(cè)試的基本方法
確認(rèn)測(cè)試的基本方法
系統(tǒng)測(cè)試的基本方法
軟件測(cè)試的基本方法
軟件測(cè)試的方法和技術(shù)是多種多樣的。
對(duì)于軟件測(cè)試技術(shù)，可以從不同的角度加以分類：
從是否需要執(zhí)行被測(cè)軟件的角度，可分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試。
從測(cè)試是否針對(duì)系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)算法的角度來(lái)看，可分為白盒測(cè)試和黑盒測(cè)試；
1、黑盒測(cè)試
黑盒測(cè)試也稱功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過(guò)測(cè)試來(lái)檢測(cè)每個(gè)功能是否都能正常使用，在測(cè)試時(shí)，把程序看作一個(gè)不能打開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測(cè)試者在程序接口進(jìn)行測(cè)試，它只檢查程序功能是否按照需求規(guī)格說(shuō)明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫(kù)或文件）的完整性。黑盒測(cè)試方法主要有等價(jià)類劃分、邊值分析、因果圖、錯(cuò)誤推測(cè)等，主要用于軟件確認(rèn)測(cè)試。 “黑盒”法著眼于程序外部結(jié)構(gòu)、不考慮內(nèi)部邏輯結(jié)構(gòu)、針對(duì)軟件界面和軟件功能進(jìn)行測(cè)試?！昂诤小狈ㄊ歉F舉輸入測(cè)試，只有把所有可能的輸入都作為測(cè)試情況使用，才能以這種方法查出程序中所有的錯(cuò)誤。實(shí)際上測(cè)試情況有無(wú)窮多個(gè)，人們不僅要測(cè)試所有合法的輸入，而且還要對(duì)那些不合法但是可能的輸入進(jìn)行測(cè)試。
2、白盒測(cè)試
白盒測(cè)試也稱結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試，它是知道產(chǎn)品內(nèi)部工作過(guò)程，可通過(guò)測(cè)試來(lái)檢測(cè)產(chǎn)品內(nèi)部動(dòng)作是否按照規(guī)格說(shuō)明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測(cè)試程序，檢驗(yàn)程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能，白盒測(cè)試的主要方法有邏輯驅(qū)動(dòng)、基路測(cè)試等，主要用于軟件驗(yàn)證。
“白盒”法全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對(duì)所有邏輯路徑進(jìn)行測(cè)試?！鞍缀小狈ㄊ歉F舉路徑測(cè)試。在使用這一方案時(shí)，測(cè)試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測(cè)試數(shù)據(jù)。貫穿程序的獨(dú)立路徑數(shù)是天文數(shù)字。但即使每條路徑都測(cè)試了仍然可能有錯(cuò)誤。第一，窮舉路徑測(cè)試決不能查出程序違反了設(shè)計(jì)規(guī)范，即程序本身是個(gè)錯(cuò)誤的程序。第二，窮舉路徑測(cè)試不可能查出程序中因遺漏路徑而出錯(cuò)。第三，窮舉路徑測(cè)試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯(cuò)誤。
3．ALAC(Act-like-a-customer)測(cè)試
ALAC測(cè)試是一種基于客戶使用產(chǎn)品的知識(shí)開發(fā)出來(lái)的測(cè)試方法。ALAC測(cè)試是基于復(fù)雜的軟件產(chǎn)品有許多錯(cuò)誤的原則。最大的受益者是用戶，缺陷查找和改正將針對(duì)那些客戶最容易遇到的錯(cuò)誤。
單元測(cè)試的基本方法
單元測(cè)試的對(duì)象是軟件設(shè)計(jì)的最小單位模塊。單元測(cè)試的依據(jù)是詳細(xì)設(shè)描述，單元測(cè)試應(yīng)對(duì)模塊內(nèi)所有重要的控制路徑設(shè)計(jì)測(cè)試用例，以便發(fā)現(xiàn)模塊內(nèi)部的錯(cuò)誤。單元測(cè)試多采用白盒測(cè)試技術(shù)，系統(tǒng)內(nèi)多個(gè)模塊可以并行地進(jìn)行測(cè)試。
單元測(cè)試任務(wù)
單元測(cè)試任務(wù)包括：1 模塊接口測(cè)試；2 模塊局部數(shù)據(jù)結(jié)構(gòu)測(cè)試；3 模塊邊界條件測(cè)試；4 模塊中所有獨(dú)立執(zhí)行通路測(cè)試；5 模塊的各條錯(cuò)誤處理通路測(cè)試。
模塊接口測(cè)試是單元測(cè)試的基礎(chǔ)。只有在數(shù)據(jù)能正確流入、流出模塊的前提下，其他測(cè)試才有意義。測(cè)試接口正確與否應(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)無(wú)關(guān)的參數(shù)引用；
9 是否修改了只讀型參數(shù)；
10 對(duì)全程變量的定義各模塊是否一致；
11是否把某些約束作為參數(shù)傳遞。
如果模塊內(nèi)包括外部輸入輸出，還應(yīng)該考慮下列因素：
1 文件屬性是否正確；
2 OPEN/CLOSE語(yǔ)句是否正確；
3 格式說(shuō)明與輸入輸出語(yǔ)句是否匹配；
4緩沖區(qū)大小與記錄長(zhǎng)度是否匹配；
5文件使用前是否已經(jīng)打開；
6是否處理了文件尾；
7是否處理了輸入/輸出錯(cuò)誤；
8輸出信息中是否有文字性錯(cuò)誤；
檢查局部數(shù)據(jù)結(jié)構(gòu)是為了保證臨時(shí)存儲(chǔ)在模塊內(nèi)的數(shù)據(jù)在程序執(zhí)行過(guò)程中完整、正確。局部數(shù)據(jù)結(jié)構(gòu)往往是錯(cuò)誤的根源，應(yīng)仔細(xì)設(shè)計(jì)測(cè)試用例，力求發(fā)現(xiàn)下面幾類錯(cuò)誤：
1 不合適或不相容的類型說(shuō)明；
2變量無(wú)初值；
3變量初始化或省缺值有錯(cuò)；
4不正確的變量名（拼錯(cuò)或不正確地截?cái)啵?br> 5出現(xiàn)上溢、下溢和地址異常。
除了局部數(shù)據(jù)結(jié)構(gòu)外，如果可能，單元測(cè)試時(shí)還應(yīng)該查清全局?jǐn)?shù)據(jù)（例如FORTRAN的公用區(qū)）對(duì)模塊的影響。
在模塊中應(yīng)對(duì)每一條獨(dú)立執(zhí)行路徑進(jìn)行測(cè)試，單元測(cè)試的基本任務(wù)是保證模塊中每條語(yǔ)句至少執(zhí)行一次。??的比較和不適當(dāng)?shù)目刂屏髟斐傻腻e(cuò)誤。此時(shí)基本路徑測(cè)試和循環(huán)測(cè)試是最常用且最有效的測(cè)試技術(shù)。計(jì)算中常見的錯(cuò)誤包括：
1 誤解或用錯(cuò)了算符優(yōu)先級(jí)；
2混合類型運(yùn)算；
3變量初值錯(cuò)；
4精度不夠；
5表達(dá)式符號(hào)錯(cuò)。
比較判斷與控制流常常緊密相關(guān)，測(cè)試用例還應(yīng)致力于發(fā)現(xiàn)下列錯(cuò)誤：
1不同數(shù)據(jù)類型的對(duì)象之間進(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)真測(cè)試，測(cè)試應(yīng)著重檢查下列問(wèn)題：
1輸出的出錯(cuò)信息難以理解；
2記錄的錯(cuò)誤與實(shí)際遇到的錯(cuò)誤不相符；
3在程序自定義的出錯(cuò)處理段運(yùn)行之前，系統(tǒng)已介入；
4異常處理不當(dāng)；
5錯(cuò)誤陳述中未能提供足夠的定位出錯(cuò)信息。
邊界條件測(cè)試是單元測(cè)試中最后，也是最重要的一項(xiàng)任務(wù)。眾的周知，軟件經(jīng)常在邊界上失效，采用邊界值分析技術(shù)，針對(duì)邊界值及其左、右設(shè)計(jì)測(cè)試用例，很有可能發(fā)現(xiàn)新的錯(cuò)誤。
單元測(cè)試過(guò)程
一般認(rèn)為單元測(cè)試應(yīng)緊接在編碼之后，當(dāng)源程序編制完成并通過(guò)復(fù)審和編譯檢查，便可開始單元測(cè)試。測(cè)試用例的設(shè)計(jì)應(yīng)與復(fù)審工作相結(jié)合，根據(jù)設(shè)計(jì)信息選取測(cè)試數(shù)據(jù)，將增大發(fā)現(xiàn)上述各類錯(cuò)誤的可能性。在確定測(cè)試用例的同時(shí)，應(yīng)給出期望結(jié)果。
應(yīng)為測(cè)試模塊開發(fā)一個(gè)驅(qū)動(dòng)模塊（driver）和（或）若干個(gè)樁模塊（stub）,下圖顯示了一般單元測(cè)試的環(huán)境。驅(qū)動(dòng)模塊在大多數(shù)場(chǎng)合稱為“主程序”，它接收測(cè)試數(shù)據(jù)并將這些數(shù)據(jù)傳遞到被測(cè)試模塊，被測(cè)試模塊被調(diào)用后，“主程序”打印“進(jìn)入-退出”消息。
驅(qū)動(dòng)模塊和樁模塊是測(cè)試使用的軟件，而不是軟件產(chǎn)品的組成部分，但它需要一定的開發(fā)費(fèi)用。若驅(qū)動(dòng)和樁模塊比較簡(jiǎn)單，實(shí)際開銷相對(duì)低些。遺憾的是，僅用簡(jiǎn)單的驅(qū)動(dòng)模塊和樁模塊不能完成某些模塊的測(cè)試任務(wù)，這些模塊的單元測(cè)試只能采用下面討論的綜合測(cè)試方法。
提高模塊的內(nèi)聚度可簡(jiǎn)化單元測(cè)試，如果每個(gè)模塊只能完成一個(gè)，所需測(cè)試用例數(shù)目將顯著減少，模塊中的錯(cuò)誤也更容易發(fā)現(xiàn)。
綜合測(cè)試的基本方法
時(shí)常有這樣的情況發(fā)生，每個(gè)模塊都能單獨(dú)工作，但這些模塊集成在一起之后卻不能正常工作。主要原因是，模塊相互調(diào)用時(shí)接口會(huì)引入許多新問(wèn)題。例如，數(shù)據(jù)經(jīng)過(guò)接口可能丟失；一個(gè)模塊對(duì)另一模塊可能造成不應(yīng)有的影響；幾個(gè)子功能組合起來(lái)不能實(shí)現(xiàn)主功能；誤差不斷積累達(dá)到不可接受的程度；全局?jǐn)?shù)據(jù)結(jié)構(gòu)出現(xiàn)錯(cuò)誤，等等。綜合測(cè)試是組裝軟件的系統(tǒng)測(cè)試技術(shù)，按設(shè)計(jì)要求把通過(guò)單元測(cè)試的各個(gè)模塊組裝在一起之后，進(jìn)行綜合測(cè)試以便發(fā)現(xiàn)與接口有關(guān)的各種錯(cuò)誤。
某設(shè)計(jì)人員習(xí)慣于把所有模塊按設(shè)計(jì)要求一次全部組裝起來(lái)，然后進(jìn)行整體測(cè)試，這稱為非增量式集成。這種方法容易出現(xiàn)混亂。因?yàn)闇y(cè)試時(shí)可能發(fā)現(xiàn)一大堆錯(cuò)誤，為每個(gè)錯(cuò)誤定位和糾正非常困難，并且在改正一個(gè)錯(cuò)誤的同時(shí)又可能引入新的錯(cuò)誤，新舊錯(cuò)誤混雜，更難斷定出錯(cuò)的原因和位置。與之相反的是增量式集成方法，程序一段一段地?cái)U(kuò)展，測(cè)試的范圍一步一步地增大，錯(cuò)誤易于定位和糾正，界面的測(cè)試亦可做到完全徹底。下面討論兩種增量式集成方法。
1 自頂向下集成
自頂向下集成是構(gòu)造程序結(jié)構(gòu)的一種增量式方式，它從主控模塊開始，按照軟件的控制層次結(jié)構(gòu)，以深度優(yōu)先或廣度優(yōu)先的策略，逐步把各個(gè)模塊集成在一起。深度優(yōu)先策略首先是把主控制路徑上的模塊集成在一起，至于選擇哪一條路徑作為主控制路徑，這多少帶有隨意性，一般根據(jù)問(wèn)題的特性確定。以下圖為例，若選擇了最左一條路徑，首先將模塊M1，M2，M5和M8集成在一起，再將M6集成起來(lái)，然后考慮中間和右邊的路徑。廣度優(yōu)先策略則不然，它沿控制層次結(jié)構(gòu)水平地向下移動(dòng)。仍以下圖為例，它首先把M2、M3和M4與主控模塊集成在一起，再將M5和M6 和其他模塊集資集成起來(lái)。
自頂向下綜合測(cè)試的具體步驟為：
1 以主控模塊作為測(cè)試驅(qū)動(dòng)模塊，把對(duì)主控模塊進(jìn)行單元測(cè)試時(shí)引入的所有樁模塊用實(shí)際模塊替代；
2 依據(jù)所選的集成策略（深度優(yōu)先或廣度優(yōu)先），每次只替代一個(gè)樁模塊；
3 每集成一個(gè)模塊立即測(cè)試一遍；
4 只有每組測(cè)試完成后，才著手替換下一個(gè)樁模塊；
5 為避免引入新錯(cuò)誤，須不斷地進(jìn)行回歸測(cè)試（即全部或部分地重復(fù)已做過(guò)的測(cè)試）。
從第二步開始，循環(huán)執(zhí)行上述步驟，直至整個(gè)程序結(jié)構(gòu)構(gòu)造完畢。下圖中，實(shí)線表示已部分完成的結(jié)構(gòu)，若采用深度優(yōu)先策略，下一步將用模塊M7替換樁模塊S7，當(dāng)然M7本身可能又帶有樁模塊，隨后將被對(duì)應(yīng)的實(shí)際模塊一一替代。
自頂向下集成的優(yōu)點(diǎn)在于能盡早地對(duì)程序的主要控制和決策機(jī)制進(jìn)行檢驗(yàn)，因此較早地發(fā)現(xiàn)錯(cuò)誤。缺點(diǎn)是在測(cè)試較高層模塊時(shí)，低層處理采用樁模塊替代，不能反映真實(shí)情況，重要數(shù)據(jù)不能及時(shí)回送到上層模塊，因此測(cè)試并不充分。解決這個(gè)問(wèn)題有幾種辦法，第一種是把某些測(cè)試推遲到用真實(shí)模塊替代樁模塊之后進(jìn)行，第二種是開發(fā)能模擬真實(shí)模塊的樁模塊；第三種是自底向上集成模塊。第一種方法又回退為非增量式的集成方法，使錯(cuò)誤難于定位和糾正，并且失去了在組裝模塊時(shí)進(jìn)行一些特定測(cè)試的可能性；第二種方法無(wú)疑要大大增加開銷；第三種方法比較切實(shí)可行，下面專門討論。
2自底向上集成
自底向上測(cè)試是從“原子”模塊（即軟件結(jié)構(gòu)最低層的模塊）開始組裝測(cè)試，因測(cè)試到較高層模塊時(shí)，所需的下層模塊功能均已具備，所以不再需要樁模塊。
自底向上綜合測(cè)試的步驟分為：
1 把低層模塊組織成實(shí)現(xiàn)某個(gè)子功能的模塊群（cluster）;
2 開發(fā)一個(gè)測(cè)試驅(qū)動(dòng)模塊，控制測(cè)試數(shù)據(jù)的輸入和測(cè)試結(jié)果的輸出；
3 對(duì)每個(gè)模塊群進(jìn)行測(cè)試；
4 刪除測(cè)試使用的驅(qū)動(dòng)模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。
從第一步開始循環(huán)執(zhí)行上述各步驟，直至整個(gè)程序構(gòu)造完畢。
下圖說(shuō)明了上述過(guò)程。首先“原子”模塊被分為三個(gè)模塊群，每個(gè)模塊群引入一個(gè)驅(qū)動(dòng)模塊進(jìn)行測(cè)試。因模塊群1、模塊群2中的模塊均隸屬于模塊Ma，因此在驅(qū)動(dòng)模塊D1、D2去掉后，模塊群1與模塊群2直接與Ma接口，這時(shí)可對(duì)MaD3被去掉后，M3與模塊群3直接接口，可對(duì)Mb進(jìn)行集成測(cè)試，最后Ma、Mb和 Mc全部集成在一起進(jìn)行測(cè)試。
自底向上集成方法不用樁模塊，測(cè)試用例的設(shè)計(jì)亦相對(duì)簡(jiǎn)單，但缺點(diǎn)是程序最后一個(gè)模塊加入時(shí)才具有整體形象。它與自頂向綜合測(cè)試方法優(yōu)缺點(diǎn)正好相反。因此，在測(cè)試軟件系統(tǒng)時(shí)，應(yīng)根據(jù)軟件的特點(diǎn)和工程的進(jìn)度，選用適當(dāng)?shù)臏y(cè)試策略，有時(shí)混和使用兩種策略更為有效，上層模塊用自頂向下的方法，下層模塊用自底向上的方法。
此外，在綜合測(cè)試中尤其要注意關(guān)鍵模塊，所謂關(guān)鍵模塊一般都具有下述一或多個(gè)特征：①對(duì)應(yīng)幾條需求；②具有高層控制功能；③復(fù)雜、易出錯(cuò)；④有特殊的性能要求。關(guān)鍵模塊應(yīng)盡早測(cè)試，并反復(fù)進(jìn)行回歸測(cè)試。
確認(rèn)測(cè)試的基本方法
通過(guò)綜合測(cè)試之后，軟件已完全組裝起來(lái)，接口方面的錯(cuò)誤也已排除，軟件測(cè)試的最后一步確認(rèn)測(cè)試即可開始。確認(rèn)測(cè)試應(yīng)檢查軟件能否按合同要求進(jìn)行工作，即是否滿足軟件需求說(shuō)明書中的確認(rèn)標(biāo)準(zhǔn)。
1. 確認(rèn)測(cè)試標(biāo)準(zhǔn)
實(shí)現(xiàn)軟件確認(rèn)要通過(guò)一系列墨盒測(cè)試。確認(rèn)測(cè)試同樣需要制訂測(cè)試計(jì)劃和過(guò)程，測(cè)試計(jì)劃應(yīng)規(guī)定測(cè)試的種類和測(cè)試進(jìn)度，測(cè)試過(guò)程則定義一些特殊的測(cè)試用例，旨在說(shuō)明軟件與需求是否一致。無(wú)是計(jì)劃還是過(guò)程，都應(yīng)該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準(zhǔn)確人機(jī)界面和其他方面（例如，可移植性、兼容性、錯(cuò)誤恢復(fù)能力和可維護(hù)性等）是否令用戶滿意。
確認(rèn)測(cè)試的結(jié)果有兩種可能，一種是功能和性能指標(biāo)滿足軟件需求說(shuō)明的要求，用戶可以接受；另一種是軟件不滿足??這個(gè)階段才發(fā)現(xiàn)嚴(yán)重錯(cuò)誤和偏差一般很難在預(yù)定的工期內(nèi)改正，因此必須與用戶協(xié)商，尋求一個(gè)妥善解決問(wèn)題的方法。
2. 配置復(fù)審
確認(rèn)測(cè)試的另一個(gè)重要環(huán)節(jié)是配置復(fù)審。復(fù)審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護(hù)所必須的細(xì)節(jié)。
3. α、β測(cè)試
事實(shí)上，軟件開發(fā)人員不可能完全預(yù)見用戶實(shí)際使用程序的情況。例如，用戶可能錯(cuò)誤的理解命令，或提供一些奇怪的數(shù)據(jù)組合，亦可能對(duì)設(shè)計(jì)者自認(rèn)明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應(yīng)由用戶進(jìn)行一系列“驗(yàn)收測(cè)試”。驗(yàn)收測(cè)試既可以是非正式的測(cè)試，也可以有計(jì)劃、有系統(tǒng)的測(cè)試。有時(shí)，驗(yàn)收測(cè)試長(zhǎng)達(dá)數(shù)周甚至數(shù)月，不斷暴露錯(cuò)誤，導(dǎo)致開發(fā)延期。一個(gè)軟件產(chǎn)品，可能擁有眾多用戶，不可能由每個(gè)用戶驗(yàn)收，此時(shí)多采用稱為α、β測(cè)試的過(guò)程，以期發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問(wèn)題。
α測(cè)試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶行對(duì)即將面市軟件產(chǎn)品（稱為α版本）進(jìn)行測(cè)試，試圖發(fā)現(xiàn)錯(cuò)誤并修正。α測(cè)試的關(guān)鍵在于盡可能逼真地模擬實(shí)際運(yùn)行環(huán)境和用戶對(duì)軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的 用戶操作方式。經(jīng)過(guò)α測(cè)試調(diào)整的軟件產(chǎn)品稱為β版本。緊隨其后的β測(cè)試是指軟件開發(fā)公司組織各方面的典型用戶在日常工作中實(shí)際使用β版本，并要求用戶報(bào)告異常情況、提出批評(píng)意見。然后軟件開發(fā)公司再對(duì)β版本進(jìn)行改錯(cuò)和完善。
系統(tǒng)測(cè)試的基本方法
計(jì)算機(jī)軟件是基于計(jì)算機(jī)系統(tǒng)的一個(gè)重要組成部分，軟件開發(fā)完畢后應(yīng)與系統(tǒng)中其它成分集成在一起，此時(shí)需要進(jìn)行一系列系統(tǒng)集成和確認(rèn)測(cè)試。對(duì)這些測(cè)試的詳細(xì)討論已超出軟件工程的范圍，這些測(cè)試也不可能僅由軟件開發(fā)人員完成。在系統(tǒng)測(cè)試之前，軟件工程師應(yīng)完成下列工作：
（1） 為測(cè)試軟件系統(tǒng)的輸入信息設(shè)計(jì)出錯(cuò)處理通路；
（2） 設(shè)計(jì)測(cè)試用例，模擬錯(cuò)誤數(shù)據(jù)和軟件界面可能發(fā)生的錯(cuò)誤，記錄測(cè)試結(jié)果，為系統(tǒng)測(cè)試提供經(jīng)驗(yàn)和幫助；
（3） 參與系統(tǒng)測(cè)試的規(guī)劃和設(shè)計(jì)，保證軟件測(cè)試的合理性。
系統(tǒng)測(cè)試應(yīng)該由若干個(gè)不同測(cè)試組成，目的是充分運(yùn)行系統(tǒng)，驗(yàn)證系統(tǒng)各部件是否都能政黨工作并完成所賦予的任務(wù)。下面簡(jiǎn)單討論幾類系統(tǒng)測(cè)試。
１、恢復(fù)測(cè)試
恢復(fù)測(cè)試主要檢查系統(tǒng)的容錯(cuò)能力。當(dāng)系統(tǒng)出錯(cuò)時(shí)，能否在指定時(shí)間間隔內(nèi)修正錯(cuò)誤并重新啟動(dòng)系統(tǒng)。恢復(fù)測(cè)試首先要采用各種辦法強(qiáng)迫系統(tǒng)失敗，然后驗(yàn)證系統(tǒng)是否能盡快恢復(fù)。對(duì)于自動(dòng)恢復(fù)需驗(yàn)證重新初始化（reinitialization）、檢查點(diǎn)(checkpointing mechanisms)、數(shù)據(jù)恢復(fù)(data recovery)和重新啟動(dòng) (restart)等機(jī)制的正確性；對(duì)于人工干預(yù)的恢復(fù)系統(tǒng)，還需估測(cè)平均修復(fù)時(shí)間，確定其是否在可接受的范圍內(nèi)。
２、安全測(cè)試
安全測(cè)試檢查系統(tǒng)對(duì)非法侵入的防范能力。安全測(cè)試期間，測(cè)試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如，①想方設(shè)法截取或破譯口令；②專門定做軟件破壞系統(tǒng)的保護(hù)機(jī)制；③故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)非法進(jìn)入；④試圖通過(guò)瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息，等等。理論上講，只要有足夠的時(shí)間和資源，沒有不可進(jìn)入的系統(tǒng)。因此系統(tǒng)安全設(shè)計(jì)的準(zhǔn)則是，使非法侵入的代價(jià)超過(guò)被保護(hù)信息的價(jià)值。此時(shí)非法侵入者已無(wú)利可圖。
３、強(qiáng)度測(cè)試
強(qiáng)度測(cè)試檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力。強(qiáng)度測(cè)試總是迫使系統(tǒng)在異常的資源配置下運(yùn)行。例如，①當(dāng)中斷的正常頻率為每秒一至兩個(gè)時(shí)，運(yùn)行每秒產(chǎn)生十個(gè)中斷的測(cè)試用例；②定量地增長(zhǎng)數(shù)據(jù)輸入率，檢查輸入子功能的反映能力；③運(yùn)行需要最大存儲(chǔ)空間（或其他資源）的測(cè)試用例；④運(yùn)行可能導(dǎo)致虛存操作系統(tǒng)崩潰或磁盤數(shù)據(jù)劇烈抖動(dòng)的測(cè)試用例，等等。
４、 性能測(cè)試
對(duì)于那些實(shí)時(shí)和嵌入式系統(tǒng)，軟件部分即使?jié)M足功能要求，也未必能夠滿足性能要求，雖然從單元測(cè)試起，每一測(cè)試步驟都包含性能測(cè)試，但只有當(dāng)系統(tǒng)真正集成之后，在真實(shí)環(huán)境中才能全面、可靠地測(cè)試運(yùn)行性能系統(tǒng)性能測(cè)試是為了完成這一任務(wù)。性能測(cè)試有時(shí)與強(qiáng)度測(cè)試相結(jié)合，經(jīng)常需要其他軟硬件的配套支持。
常見的軟件測(cè)試類型有：
BVT (Build Verification Test)
BVT是在所有開發(fā)工程師都已經(jīng)檢入自己的代碼，項(xiàng)目組編譯生成當(dāng)天的版本之后進(jìn)行，主要目的是驗(yàn)證最新生成的軟件版本在功能上是否完整，主要的軟件特性是否正確。如無(wú)大的問(wèn)題，就可以進(jìn)行相應(yīng)的功能測(cè)試。BVT優(yōu)點(diǎn)是時(shí)間短，驗(yàn)證了軟件的基本功能。缺點(diǎn)是該種測(cè)試的覆蓋率很低。因?yàn)檫\(yùn)行時(shí)間短，不可能把所有的情況都測(cè)試到。
Scenario Tests（基于用戶實(shí)際應(yīng)用場(chǎng)景的測(cè)試）
在做BVT、功能測(cè)試的時(shí)候，可能測(cè)試主要集中在某個(gè)模塊，或比較分離的功能上。當(dāng)用戶來(lái)使用這個(gè)應(yīng)用程序的時(shí)候，各個(gè)模塊是作為一個(gè)整體來(lái)使用的，那么在做測(cè)試的時(shí)候，就需要模仿用戶這樣一個(gè)真實(shí)的使用環(huán)境，即用戶會(huì)有哪些用法，會(huì)用這個(gè)應(yīng)用程序做哪些事情，操作會(huì)是一個(gè)怎樣的流程。加了這些測(cè)試用例后，再與BVT、功能測(cè)試配合，就能使軟件整體都能符合用戶使用的要求。Scenario Tests優(yōu)點(diǎn)是關(guān)注了用戶的需求，缺點(diǎn)是有時(shí)候難以真正模仿用戶真實(shí)的使用情況。
Smoke Test
在測(cè)試中發(fā)現(xiàn)問(wèn)題，找到了一個(gè)Bug，然后開發(fā)人員會(huì)來(lái)修復(fù)這個(gè)Bug。這時(shí)想知道這次修復(fù)是否真的解決了程序的Bug，或者是否會(huì)對(duì)其它模塊造成影響，就需要針對(duì)此問(wèn)題進(jìn)行專門測(cè)試，這個(gè)過(guò)程就被稱為Smoke Test。在很多情況下，做Smoke Test是開發(fā)人員在試圖解決一個(gè)問(wèn)題的時(shí)候，造成了其它功能模塊一系列的連鎖反應(yīng)，原因可能是只集中考慮了一開始的那個(gè)問(wèn)題，而忽略其它的問(wèn)題，這就可能引起了新的Bug。Smoke Test優(yōu)點(diǎn)是節(jié)省測(cè)試時(shí)間，防止build失敗。缺點(diǎn)是覆蓋率還是比較低。
此外，Application Compatibility Test（兼容性測(cè)試），主要目的是為了兼容第三方軟件，確保第三方軟件能正常運(yùn)行，用戶不受影響。Accessibility Test（軟件適用性測(cè)試），是確保軟件對(duì)于某些有殘疾的人士也能正常的使用，但優(yōu)先級(jí)比較低。其它的測(cè)試還有Functional Test（功能測(cè)試）、Security Test（安全性測(cè)試）、Stress Test（壓力測(cè)試）、Performance Test（性能測(cè)試）、Regression Test（回歸測(cè)試）、Setup/Upgrade Test（安?支持工具
一些受軟件開發(fā)人員歡迎的軟件測(cè)試工具為軟件測(cè)試提供了強(qiáng)有力的支持。本文將介紹美國(guó)Rational公司的著名套裝軟件SQA和Pure Atria公司極具特色的Purify。
SQA SuiteSQA直接支持對(duì)客戶/服務(wù)器應(yīng)用軟件的測(cè)試,它的一個(gè)重要特點(diǎn)是可以自動(dòng)驅(qū)動(dòng)被測(cè)程序的運(yùn)行。SQA可以自動(dòng)記錄和重放程序執(zhí)行過(guò)程,從而實(shí)現(xiàn)了對(duì)測(cè)試進(jìn)行"復(fù)查"的自動(dòng)化。
由于測(cè)試是一個(gè)需要反復(fù)進(jìn)行的過(guò)程,常常要數(shù)十次甚至數(shù)百次地重復(fù)。因此,這一特性大大地提高了軟件"再測(cè)試"(Re-Test)和"回歸測(cè)試"(Regression)的自動(dòng)化程度,把測(cè)試人員從繁雜的、重復(fù)性的手工測(cè)試中解脫出來(lái),從而顯著地提高軟件測(cè)試效率。
除了這個(gè)最基本的自動(dòng)錄放功能外,它還提供了一系列的輔助支持功能,比如,
· 被錄制的程序執(zhí)行過(guò)程可以被自動(dòng)轉(zhuǎn)換成具有良好可讀性的高級(jí)語(yǔ)言程序,從而使這個(gè)測(cè)試驅(qū)動(dòng)程序可以由測(cè)試人員根據(jù)測(cè)試需要進(jìn)行必要的修改,甚至完全用手工方式編制。
·自動(dòng)記錄和分析比較測(cè)試的執(zhí)行結(jié)果。不論是簡(jiǎn)單的正文方式的輸出結(jié)果,還是任意的圖表、聲音、動(dòng)畫、圖形用戶界面(GUI)中的任一構(gòu)件,都可以根據(jù)測(cè)試人員的指定被自動(dòng)記錄在測(cè)試結(jié)果庫(kù)中,并可對(duì)兩次測(cè)試的結(jié)果自動(dòng)地進(jìn)行比較,指出其差異部分。此項(xiàng)功能無(wú)疑對(duì)"自動(dòng)查找錯(cuò)誤"很有幫助。
·調(diào)節(jié)和設(shè)定事件的發(fā)生時(shí)間和速度。
·基本的測(cè)試庫(kù)管理功能。
此外,SQA還支持軟件測(cè)試人員進(jìn)行以下工作:
·制定測(cè)試計(jì)劃和測(cè)試大綱,并將這些文檔按照自然的樹狀結(jié)構(gòu)分層地管理起來(lái),并據(jù)此控制和驅(qū)動(dòng)整個(gè)測(cè)試過(guò)程。
·不僅能夠自動(dòng)記錄各類測(cè)試結(jié)果,而且對(duì)其進(jìn)行修改,從而使得測(cè)試人員可以在程序運(yùn)行結(jié)果尚有許多錯(cuò)誤的情況下,通過(guò)對(duì)所記錄下的結(jié)果做適當(dāng)修正來(lái)獲得理想的"期望結(jié)果" ,為測(cè)試結(jié)果的自動(dòng)比較奠定基礎(chǔ)。
·測(cè)試問(wèn)題報(bào)告的記錄與管理。
總之,SQA Suite提供了一個(gè)比較完整的測(cè)試平臺(tái),以支持軟件測(cè)試的各種基本活動(dòng),包括測(cè)試計(jì)劃與測(cè)試大綱的制定、回歸測(cè)試的自動(dòng)化、測(cè)試結(jié)果的分析比較、軟件問(wèn)題報(bào)告的生成與自動(dòng)分發(fā)和控制等。對(duì)于許多應(yīng)用軟件的開發(fā)無(wú)疑是個(gè)有力的測(cè)試支持工具。
Purify是原PureAtria公司(現(xiàn)已經(jīng)與美國(guó)Rational公司合并,改名為美國(guó)Rational公司)于90年代初率先推出的專門用于檢測(cè)程序中種種內(nèi)存使用錯(cuò)誤的軟件工具。幾乎所有使用過(guò)C語(yǔ)言開發(fā)軟件的程序員都會(huì)有這樣的體會(huì),C語(yǔ)言中使用極為靈活的指針給程序員帶來(lái)了很大便利,但同時(shí)也制造了許多的麻煩。由于指針使用不當(dāng)而引起的錯(cuò)誤通常是最難發(fā)現(xiàn)的,同時(shí)也是最難定位的一類錯(cuò)誤。而Purify對(duì)多種常見的內(nèi)存使用錯(cuò)誤的檢錯(cuò)能力和準(zhǔn)確的定位,受到廣大軟件開發(fā)人員的青睞。
Purify可以自動(dòng)識(shí)別出二十多種內(nèi)存使用錯(cuò)誤,包括
·未初始化的局部變量
·未申請(qǐng)的內(nèi)存
·使用已釋放的內(nèi)存
·數(shù)組越界
·內(nèi)存丟失
·文件描述問(wèn)題
·棧溢出問(wèn)題
·棧結(jié)構(gòu)邊界錯(cuò)誤等
在下面的例子中,暗藏著兩個(gè)內(nèi)存使用錯(cuò)誤。第一行為指針數(shù)組pp申請(qǐng)的空間尺寸不對(duì)。這類錯(cuò)誤往往不易發(fā)現(xiàn),因?yàn)樵贑語(yǔ)言中,一些"輕微"的內(nèi)存越界可能被系統(tǒng)所容忍。但這往往是導(dǎo)致更嚴(yán)重錯(cuò)誤的根源。例如,可能破壞其它數(shù)據(jù)區(qū)等。最后一行的錯(cuò)誤是在釋放pp 之前沒有釋放賦予它的字符串空間,從而把它們"丟失"了。這類錯(cuò)誤猶如慢性自殺,它會(huì)逐漸消耗掉內(nèi)存,降低系統(tǒng)的運(yùn)行效率,直到完全崩潰。而真正的問(wèn)題在于,這些程序中的"惡性腫瘤"用常規(guī)的測(cè)試手段和調(diào)試工具是極難發(fā)現(xiàn)和加以定位的。Purify則在此充分顯示了它的強(qiáng)大功效,所到之處,即對(duì)所測(cè)試過(guò)的情況,上述各種常見的內(nèi)存錯(cuò)誤都可以被一一揭露出來(lái),并且準(zhǔn)確地指出錯(cuò)誤的類型和位置。從而大大地提高了測(cè)試和糾錯(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!*/
………
今年以來(lái),原PureAtria公司陸續(xù)推出了其系列產(chǎn)品?/FONT>Pure,包括支持內(nèi)存檢測(cè)的Purify ,支持路徑覆蓋的PureCoverage,支持多線程應(yīng)用程序性能測(cè)試的Quantify,以及用以提高測(cè)試期間連接編譯被測(cè)程序效率的PureLink等。Pure系列現(xiàn)已支持C、C 、FORTRAN語(yǔ)言,以及UNIX和Window NT等操作系統(tǒng),如Sun OS、Solaris 2.3,HP-UX,Windows NT Server以及IBM A/ X等。
結(jié)束語(yǔ)
充分認(rèn)識(shí)軟件測(cè)試的重要性和復(fù)雜性,合理地選擇測(cè)試方法,有效地組織測(cè)試人員和安排測(cè)試任務(wù),并且盡量使用軟件測(cè)試工具增強(qiáng)軟件測(cè)試的自動(dòng)化程度,無(wú)疑可以幫助軟件開發(fā)和測(cè)試人員大大提高測(cè)試效率和軟件的質(zhì)量。
軟件測(cè)試是一個(gè)極為復(fù)雜的過(guò)程。如圖一所示,一個(gè)規(guī)范化的軟件測(cè)試過(guò)程通常須包括以下基本的測(cè)試活動(dòng)。
·擬定軟件測(cè)試計(jì)劃
·編制軟件測(cè)試大綱
·設(shè)計(jì)和生成測(cè)試用例
·實(shí)施測(cè)試
·生成軟件問(wèn)題報(bào)告
對(duì)整個(gè)測(cè)試過(guò)程進(jìn)行有效的管理實(shí)際上,軟件測(cè)試過(guò)程與??早在需求分析階段即應(yīng)開始制定,其它相關(guān)工作,包括測(cè)試大綱的制定、測(cè)試數(shù)據(jù)的生成、測(cè)試工具的選擇和開發(fā)等也應(yīng)在測(cè)試階段之前進(jìn)行。充分的準(zhǔn)備工作可以有效地克服測(cè)試的盲目性,縮短測(cè)試周期,提高測(cè)試效率,并且起到測(cè)試文檔與開發(fā)文檔互查的作用。
此外,軟件測(cè)試的實(shí)施階段是由一系列的測(cè)試周期(Test Cycle)組成的。在每個(gè)測(cè)試周期中,軟件測(cè)試工程師將依據(jù)預(yù)先編制好的測(cè)試大綱和準(zhǔn)備好的測(cè)試用例,對(duì)被測(cè)軟件進(jìn)行完整的測(cè)試。測(cè)試與糾錯(cuò)通常是反復(fù)交替進(jìn)行的。當(dāng)使用專業(yè)測(cè)試人員時(shí),測(cè)試與糾錯(cuò)甚至是平行進(jìn)行的,從而壓縮總的開發(fā)時(shí)間。更重要的是,由于專業(yè)測(cè)試人員豐富的測(cè)試經(jīng)驗(yàn)、所采用的系統(tǒng)化的測(cè)試方法、全時(shí)的投入,特別是獨(dú)立于開發(fā)人員的思維,使得他們能夠更有效地發(fā)現(xiàn)許多單靠開發(fā)人員很難發(fā)現(xiàn)的錯(cuò)誤和問(wèn)題。
軟件測(cè)試大綱是軟件測(cè)試的依據(jù)。它明確詳盡地規(guī)定了在測(cè)試中針對(duì)系統(tǒng)的每一項(xiàng)功能或特性所必須完成的基本測(cè)試項(xiàng)目和測(cè)試完成的標(biāo)準(zhǔn)。無(wú)論是自動(dòng)測(cè)試還是手動(dòng)測(cè)試,都必須滿足測(cè)試大綱的要求。
一般而言,測(cè)試用例是指為實(shí)施一次測(cè)試而向被測(cè)系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設(shè)置。測(cè)試用例控制著軟件測(cè)試的執(zhí)行過(guò)程,它是對(duì)測(cè)試大綱中每個(gè)測(cè)試項(xiàng)目的進(jìn)一步實(shí)例化。已有許多著名的論著總結(jié)了設(shè)計(jì)測(cè)試用例的各種規(guī)則和策略。從工程實(shí)踐的角度講有幾條基本準(zhǔn)則:
1.測(cè)試用例的代表性:能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,以及極限的輸入數(shù)據(jù)、操作和環(huán)境設(shè)置等;
2.測(cè)試結(jié)果的可判定性:即測(cè)試執(zhí)行結(jié)果的正確性是可判定的或可評(píng)估的;
3.測(cè)試結(jié)果的可再現(xiàn)性:即對(duì)同樣的測(cè)試用例,系統(tǒng)的執(zhí)行結(jié)果應(yīng)當(dāng)是相同的。
“工欲善其事，必先利其器”。專業(yè)的測(cè)試必須以一個(gè)好的測(cè)試計(jì)劃作為基礎(chǔ)。盡管測(cè)試的每一個(gè)步驟都是獨(dú)立的，但是必定要有一個(gè)起到框架結(jié)構(gòu)作用的測(cè)試計(jì)劃。測(cè)試的計(jì)劃應(yīng)該作為測(cè)試的起始步驟和重要環(huán)節(jié)。一個(gè)測(cè)試計(jì)劃應(yīng)包括：產(chǎn)品基本情況調(diào)研、測(cè)試需求說(shuō)明、測(cè)試策略和記錄、測(cè)試資源配置、計(jì)劃表、問(wèn)題跟蹤報(bào)告、測(cè)試計(jì)劃的評(píng)審、結(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)等。對(duì)于大的測(cè)試項(xiàng)目，還要包括測(cè)試的目的和側(cè)重點(diǎn)。
具體的要點(diǎn)有：
目的：重點(diǎn)描述如何使測(cè)試建立在客觀的基礎(chǔ)上，定義測(cè)試的策略，測(cè)試的配置， 粗略的估計(jì)測(cè)試大致需要的周期和最終測(cè)試報(bào)告遞交的時(shí)間。
變更：說(shuō)明有可能會(huì)導(dǎo)致測(cè)試計(jì)劃變更的事件。包括測(cè)試工具改進(jìn)了，測(cè)試的環(huán)境改變了，或者是添加了新的功能。
技術(shù)結(jié)構(gòu)：可以借助畫圖，將要測(cè)試的軟件劃分成幾個(gè)組成部分，規(guī)劃成一個(gè)適用于測(cè)試的完整的系統(tǒng)，包括數(shù)據(jù)是如何存儲(chǔ)的，如何傳遞的（數(shù)據(jù)流圖），每一個(gè)部分的測(cè)試是要達(dá)到什么樣的目的。每一個(gè)部分是怎么實(shí)現(xiàn)數(shù)據(jù)更新的。還有就是常規(guī)性的技術(shù)要求，比如運(yùn)行平臺(tái)、需要什么樣的數(shù)據(jù)庫(kù)等等。
產(chǎn)品規(guī)格：就是制造商和產(chǎn)品版本號(hào)的說(shuō)明。
測(cè)試范圍：簡(jiǎn)單的描述如何搭建測(cè)試平臺(tái)以及測(cè)試的潛在的風(fēng)險(xiǎn)。
項(xiàng)目信息：說(shuō)明要測(cè)試的項(xiàng)目的相關(guān)資料，如：用戶文檔，產(chǎn)品描述，主要功能的舉例說(shuō)明。
測(cè)試需求說(shuō)明：
這一部分要列出所有要測(cè)試的功能項(xiàng)。凡是沒有出現(xiàn)在這個(gè)清單里的功能項(xiàng)都排除在測(cè)試的范圍之外。萬(wàn)一有一天你在一個(gè)沒有測(cè)試的部分里發(fā)現(xiàn)了一個(gè)問(wèn)題，你應(yīng)該很高興你有這個(gè)記錄在案的文檔，可以證明你測(cè)了什么沒測(cè)什么。具體要點(diǎn)有：
功能的測(cè)試：理論上是測(cè)試是要覆蓋所有的功能項(xiàng)，例如：在數(shù)據(jù)庫(kù)中添加、編輯、刪除記錄等等，這會(huì)是一個(gè)浩大的工程，但是有利于測(cè)試的完整性。
設(shè)計(jì)的測(cè)試：對(duì)于一些用戶界面、菜單的結(jié)構(gòu)還有窗體的設(shè)計(jì)是否合理等的測(cè)試。
整體考慮：這部分測(cè)試需求要考慮到數(shù)據(jù)流從軟件中的一個(gè)模塊流到另一個(gè)模塊的過(guò)程中的正確性。
測(cè)試的策略和記錄：
這是整個(gè)測(cè)試計(jì)劃的重點(diǎn)所在，要描述如何公正客觀地開展測(cè)試，要考慮：模塊、功能、整體、系統(tǒng)、版本、壓力、性能、配置和安裝等各個(gè)因素的影響。要盡可能的考慮到細(xì)節(jié)，越詳細(xì)越好，并制作測(cè)試記錄文檔的模板，為即將開始的測(cè)試做準(zhǔn)備，測(cè)試記錄重要包括的部分具體說(shuō)明如下：
公正性聲明：要對(duì)測(cè)試的公正性、遵照的標(biāo)準(zhǔn)做一個(gè)說(shuō)明，證明測(cè)試是客觀的，整體上，軟件功能要滿足需求，實(shí)現(xiàn)正確，和用戶文檔的描述保持一致。
測(cè)試案例：描述測(cè)試案例是什么樣的，采用了什么工具，工具的來(lái)源是什么，如何執(zhí)行的，用了什么樣的數(shù)據(jù)。測(cè)試的記錄中要為將來(lái)的回歸測(cè)試留有余地，當(dāng)然，也要考慮同時(shí)安裝的別的軟件對(duì)正在測(cè)試的軟件會(huì)造成的影響。
特殊考慮：有的時(shí)候，針對(duì)一些外界環(huán)境的影響，要對(duì)軟件進(jìn)行一些特殊方面的測(cè)試。
經(jīng)驗(yàn)判斷：對(duì)以往的測(cè)試中，經(jīng)常出現(xiàn)的問(wèn)題加以考慮。
設(shè)想：采取一些發(fā)散性的思維，往往能幫助你找的測(cè)試的新途徑。
測(cè)試資源配置：
項(xiàng)目資源計(jì)劃：制定一個(gè)項(xiàng)目資源計(jì)劃，包含的是每一個(gè)階段的任務(wù)、所需要的資源，當(dāng)發(fā)生類似到了使用期限或者資源共享的事情的時(shí)候，要更新這個(gè)計(jì)劃。
計(jì)劃表：
測(cè)試的計(jì)劃表可以做成一個(gè)多個(gè)項(xiàng)目通用的形式，根據(jù)大致的時(shí)間估計(jì)來(lái)制作，操作流程要以軟件測(cè)試的常規(guī)周期作為參考，也可以是根據(jù)什么時(shí)候應(yīng)該測(cè)試哪一個(gè)模塊來(lái)制定。
問(wèn)題跟蹤報(bào)告：
在測(cè)試的計(jì)劃階段，我們應(yīng)該明確如何準(zhǔn)備去做一個(gè)問(wèn)題報(bào)告以及如何去界定一個(gè)問(wèn)題的性質(zhì)，問(wèn)題報(bào)告要包括問(wèn)題的發(fā)現(xiàn)者和修改者、問(wèn)題發(fā)生的頻率、用了什么樣的測(cè)試案例測(cè)出該問(wèn)題的，以及明確問(wèn)題產(chǎn)生時(shí)的測(cè)試環(huán)境。
問(wèn)題描述盡可能是定量的，分門別類的列舉，問(wèn)題有幾種：
1、嚴(yán)重問(wèn)題：嚴(yán)重問(wèn)題意味著功能不可用，或者是權(quán)限限制方面的失誤等等，也可能是某個(gè)地方的改變?cè)斐闪藙e的地方的問(wèn)題。
2、一般問(wèn)題：功能沒有按設(shè)計(jì)要求實(shí)現(xiàn)或者是一些界面交互的實(shí)現(xiàn)不正確。
3、建議問(wèn)題：功能運(yùn)行得不象要求的那么快，或者不符合某些約定俗成的習(xí)慣，但不影響系統(tǒng)的性能，界面先是錯(cuò)誤，格式不對(duì)，含義模糊混淆的提示信息等等。
測(cè)試計(jì)劃的評(píng)審：
又叫測(cè)試規(guī)范的評(píng)審，在測(cè)試真正實(shí)施開展之前必須要認(rèn)真負(fù)責(zé)的檢查一遍，獲得整個(gè)測(cè)試部門人員的認(rèn)同，包括部門的負(fù)責(zé)人的同意和簽字。
結(jié)果：
計(jì)劃并不是到這里就結(jié)束了，在最后測(cè)試結(jié)果的評(píng)審中，必須要嚴(yán)格驗(yàn)證計(jì)劃和實(shí)際的執(zhí)行是不是有偏差，體現(xiàn)在最終報(bào)告的內(nèi)容是否和測(cè)試的計(jì)劃保持一致，然后，就可以開始著手制作下一個(gè)測(cè)試計(jì)劃了。
報(bào)告軟件測(cè)試錯(cuò)誤的目的是為了保證修復(fù)錯(cuò)誤的人員可以重復(fù)報(bào)告的錯(cuò)誤，從而有利于分析錯(cuò)誤產(chǎn)生的原因，定位錯(cuò)誤，然后修正之。因此，報(bào)告軟件測(cè)試錯(cuò)誤的基本要求是準(zhǔn)確、簡(jiǎn)潔、完整、規(guī)范。需要掌握的報(bào)告技術(shù)歸納如下。
1. 描述 (Description)，簡(jiǎn)潔、準(zhǔn)確，完整，揭示錯(cuò)誤實(shí)質(zhì)，記錄缺陷或錯(cuò)誤出現(xiàn)的位置
描述要準(zhǔn)確反映錯(cuò)誤的本質(zhì)內(nèi)容，簡(jiǎn)短明了。為了便于在軟件錯(cuò)誤管理數(shù)據(jù)庫(kù)中尋找制定的測(cè)試錯(cuò)誤，包含錯(cuò)誤發(fā)生時(shí)的用戶界面（UI）是個(gè)良好的習(xí)慣。例如記錄對(duì)話框的標(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è)操作
保證簡(jiǎn)潔、條理井然，容易重復(fù)操作步驟。
6. 確認(rèn)步驟完整，準(zhǔn)確，簡(jiǎn)短
保證快速準(zhǔn)確的重復(fù)錯(cuò)誤，“完整”即沒有缺漏，“準(zhǔn)確”即步驟正確，“簡(jiǎn)短”即沒有多余的步驟。
7. 根據(jù)缺陷或錯(cuò)誤類型，選擇圖象捕捉的方式
為了直觀的觀察缺陷或錯(cuò)誤現(xiàn)象，通常需要附加缺陷或錯(cuò)誤出現(xiàn)的界面，以位圖的形式作為附件附著在記錄的“附件”部分。為了節(jié)省空間，又能真實(shí)反映缺陷或錯(cuò)誤本質(zhì)，可以捕捉缺陷或錯(cuò)誤產(chǎn)生時(shí)的全屏幕，活動(dòng)窗口和局部區(qū)域。為了迅速定位、修正缺陷或錯(cuò)誤位置，通常要求附加中英文對(duì)照?qǐng)D。
8. 附加必要的特殊文檔和個(gè)人建議和注解
如果打開某個(gè)特殊的文檔而產(chǎn)生的缺陷或錯(cuò)誤，則必須附加該文檔，從而可以迅速再現(xiàn)缺陷或錯(cuò)誤。有時(shí)，為了使缺陷或錯(cuò)誤修正者進(jìn)一步明確缺陷或錯(cuò)誤的表現(xiàn)，可以附加個(gè)人的修改建議或注解。
9. 檢查拼寫和語(yǔ)法錯(cuò)誤
在提交每條缺陷或錯(cuò)誤之前，檢查拼寫和語(yǔ)法，確保內(nèi)容正確，正確的描述錯(cuò)誤。
10. 盡量使用業(yè)界慣用的表達(dá)術(shù)語(yǔ)和表達(dá)方法
使用業(yè)界慣用的表達(dá)術(shù)語(yǔ)和表達(dá)方法，保證表達(dá)準(zhǔn)確，體現(xiàn)專業(yè)化。
11. 通用UI要統(tǒng)一、準(zhǔn)確
錯(cuò)誤報(bào)告的UI要與測(cè)試的軟件UI保持一致，便于查找定位。
12. 盡量使用短語(yǔ)和短句，避免復(fù)雜句型句式
軟件錯(cuò)誤管理數(shù)據(jù)庫(kù)的目的是便于定位錯(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)告測(cè)試錯(cuò)誤的規(guī)范要求，隨著軟件的測(cè)試要求不同，測(cè)試者經(jīng)過(guò)長(zhǎng)期測(cè)試，積累了相應(yīng)的測(cè)試經(jīng)驗(yàn)，將會(huì)逐漸養(yǎng)成良好的專業(yè)習(xí)慣，不斷補(bǔ)充新的規(guī)范書寫要求。此外，經(jīng)常閱讀、學(xué)習(xí)高級(jí)測(cè)試工程師的測(cè)試錯(cuò)誤報(bào)告，結(jié)合自己以前的測(cè)試錯(cuò)誤報(bào)告進(jìn)行對(duì)比和思考，可以不斷提高技巧。
軟件測(cè)試工程師是軟件行業(yè)中一種即年輕又古老的職業(yè)，進(jìn)入二十一世紀(jì)以來(lái)，隨著中國(guó)加入WTO以后，從事這項(xiàng)職業(yè)的人也越來(lái)越多。一個(gè)公司在組建一個(gè)測(cè)試隊(duì)伍的時(shí)候如何分配人員結(jié)構(gòu)，從而使公司軟件測(cè)試工作水平得到提高，是大家比較關(guān)注的問(wèn)題。本人依照自己的經(jīng)驗(yàn)提出自己的觀點(diǎn)：
我們首先來(lái)看一下測(cè)試人員的縱向結(jié)構(gòu)
1，測(cè)試經(jīng)理
測(cè)試經(jīng)理主要負(fù)責(zé)測(cè)試隊(duì)伍的內(nèi)部管理以及與其他外部人員，客戶的交流，詳細(xì)說(shuō)來(lái)主要包括進(jìn)度管理，風(fēng)險(xiǎn)管理，資金管理，人力資源管理，交流管理等等，測(cè)試經(jīng)理需要具有項(xiàng)目經(jīng)理的知識(shí)和技能。同時(shí)測(cè)試工作開始前項(xiàng)目經(jīng)理需要書寫《測(cè)試計(jì)劃書》，測(cè)試結(jié)束需要書寫《測(cè)試總結(jié)報(bào)告》
2，測(cè)試文檔審核師
測(cè)試文檔審核師主要負(fù)責(zé)前置測(cè)試，包括在需求期與設(shè)計(jì)期間產(chǎn)生的文檔進(jìn)行審核，比如《業(yè)務(wù)建模書》，《需求規(guī)格說(shuō)明書》，《概要設(shè)計(jì)書》，《詳細(xì)設(shè)計(jì)書》等等。審核需要進(jìn)行書寫審核報(bào)告。當(dāng)文檔確定后，需要整理文檔報(bào)告，并且反映介紹給測(cè)試設(shè)計(jì)師。
3，測(cè)試設(shè)計(jì)師
測(cè)試設(shè)計(jì)師主要根據(jù)需求期與設(shè)計(jì)期間產(chǎn)生的文檔設(shè)計(jì)各個(gè)測(cè)試階段的測(cè)試用例。
（往往測(cè)試文檔審核師，測(cè)試設(shè)計(jì)師可以有相同的一組人來(lái)完成）
4， 測(cè)試工程師
測(cè)試工程師按照測(cè)試用例，來(lái)完成測(cè)試工作。
但是測(cè)試人員應(yīng)該有哪些人來(lái)組成呢？也就是測(cè)試人員的橫向組成，讓我們?cè)賮?lái)討論討論：
1， 需要具有一定開發(fā)經(jīng)驗(yàn)的計(jì)算機(jī)專業(yè)人員
由于具有一定開發(fā)經(jīng)驗(yàn)的計(jì)算機(jī)專業(yè)人員即懂得計(jì)算機(jī)的基本理論，又有一定的開發(fā)經(jīng)驗(yàn)。所以對(duì)于軟件中哪里容易出錯(cuò)，哪里不容易出錯(cuò)他們了如指掌；他們可以分析程序的性能，軟件性能差是否是占有內(nèi)存空間太多，或者是占有CPU時(shí)間太多引起的，還是其他原因，他們往往是專家。尤其是進(jìn)行非功能測(cè)試的時(shí)候，他們可以更好的搭建系統(tǒng)測(cè)試平臺(tái)。這種人員應(yīng)該占測(cè)試隊(duì)伍中一半以上。
2， 需要具有本軟件業(yè)務(wù)經(jīng)驗(yàn)的人員
測(cè)試隊(duì)伍中需要有這樣的人員的目的在于，這些人員由于對(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è)用語(yǔ)不準(zhǔn)確，業(yè)務(wù)流程不規(guī)范等等，這種人才對(duì)于專業(yè)性比較強(qiáng)的軟件測(cè)試工作尤為重要，比如稅務(wù)，法律，藝術(shù)，CAD,CAM…
3， 只需要會(huì)操作計(jì)算機(jī)的人員
由于軟件一旦賣出去之后，使用軟件的人各種各樣，各種各樣的人帶來(lái)各種各樣的操作情況，請(qǐng)一大部分人員在軟件測(cè)試工作后期進(jìn)行測(cè)試工作是十分重要的，他們往往會(huì)發(fā)現(xiàn)專業(yè)測(cè)試人員測(cè)試不出的東西和一些希奇古怪的錯(cuò)誤。這就是軟件測(cè)試學(xué)中所謂的猴子測(cè)試法。
對(duì)于一個(gè)軟件公司來(lái)說(shuō)，并不是說(shuō)所有的測(cè)試隊(duì)伍都需要這三種人員，實(shí)際中可以一組人代替多個(gè)角色，但是要遵循以下原則：
1，對(duì)于業(yè)務(wù)不是很專業(yè)的軟件，具有一定開發(fā)經(jīng)驗(yàn)的計(jì)算機(jī)專業(yè)人員與具有本軟件業(yè)務(wù)經(jīng)驗(yàn)的人員可以合并；
2，只需要會(huì)操作計(jì)算機(jī)的人員，可以由公司行政人員來(lái)充當(dāng)。
“從我在微軟工作的經(jīng)歷來(lái)看，軟件測(cè)試絕對(duì)不是開發(fā)活動(dòng)完成后的收尾工作，很多大型的開發(fā)項(xiàng)目，測(cè)試會(huì)占據(jù)項(xiàng)目周期一半以上的時(shí)間。以IE4.0為例，代碼開發(fā)時(shí)間為6個(gè)月，而穩(wěn)定程序花去了8個(gè)月的時(shí)間?！鼻拔④泚喼扪芯吭翰┦俊④浖y(cè)試專家陳宏剛談道。從投入的資金和人力物力來(lái)看，測(cè)試、使產(chǎn)品穩(wěn)定和修改花去的時(shí)間可能占到80%。
還處在嬰兒期
軟件測(cè)試之所以發(fā)展相對(duì)緩慢，一個(gè)原因是做研究和做開發(fā)的人交流的機(jī)會(huì)相對(duì)少。只有做大型系統(tǒng)工程的人才會(huì)對(duì)測(cè)試提出較高的要求，重要性才能顯現(xiàn)出來(lái)，而做研究和教學(xué)的人沒有大型系統(tǒng)工程案例，所以造成了測(cè)試?yán)碚撗芯康陌l(fā)展缺乏充實(shí)的基礎(chǔ)材料。真正做大型系統(tǒng)開發(fā)的工程師，又沒有時(shí)間將第一手的測(cè)試經(jīng)驗(yàn)變成系統(tǒng)的理論。
“在美國(guó)，佛羅里達(dá)州和華盛頓州分別有一所大學(xué)開設(shè)軟件測(cè)試課程，其他有正規(guī)課程的學(xué)校不是很多。軟件測(cè)試正停留在沒有學(xué)科系統(tǒng)、沒有系統(tǒng)教育的階段。雖然已經(jīng)有學(xué)校開設(shè)了這門課程，但是使用的教學(xué)案例，多半是單機(jī)軟件，還談不上系統(tǒng)的理論?！标惡陝偛┦拷榻B說(shuō)。
高素質(zhì)的“雜牌軍”
由于企業(yè)對(duì)測(cè)試人才有著迫切的需要，因此，只好自??品制定測(cè)試規(guī)范，開設(shè)一些課程，通過(guò)講座的形式對(duì)測(cè)試技術(shù)人員進(jìn)行培訓(xùn)，但是也還未形成系統(tǒng)的理論。
即使在微軟，測(cè)試隊(duì)伍是典型的“雜牌軍”，沒有科班，沒有統(tǒng)一的專業(yè)，更多的是具有豐富的經(jīng)驗(yàn)和不同行業(yè)背景的員工，例如具有語(yǔ)言學(xué)、數(shù)學(xué)、物理學(xué)、計(jì)算機(jī)、工程、管理等學(xué)科等背景的員工。但是，這不是說(shuō)隨便什么人都可以做測(cè)試工作，陳宏剛工作過(guò)的那個(gè)試驗(yàn)室，20個(gè)人中有7個(gè)博士?？梢?，雖然測(cè)試不是一個(gè)專門的學(xué)科，但是，這個(gè)部門對(duì)于一個(gè)成熟的軟件企業(yè)又是至關(guān)重要的部門。
認(rèn)識(shí)需再提高
IBM和微軟公司屬于領(lǐng)先的大公司，對(duì)測(cè)試的認(rèn)識(shí)也經(jīng)歷了一個(gè)過(guò)程。開始的時(shí)候，也是開發(fā)人員兼職做測(cè)試，就像今天國(guó)內(nèi)一些較小規(guī)模的軟件企業(yè)。但是，后來(lái)的結(jié)果表明，花在軟件修補(bǔ)上面的費(fèi)用太高，以至于遠(yuǎn)遠(yuǎn)超出了所能夠允許的范圍。這個(gè)時(shí)候，增加測(cè)試隊(duì)伍的規(guī)模，提高測(cè)試隊(duì)伍的素質(zhì)，提高測(cè)試隊(duì)伍的待遇和受重視的程度是更加劃算的。
還有一個(gè)問(wèn)題是，很多工程師不愿意做測(cè)試，認(rèn)為是一種打下手的工作，沒有前途，這也是國(guó)內(nèi)比較大軟件企業(yè)面臨的問(wèn)題。所以，企業(yè)從上到下普遍自覺和不自覺地只重視技術(shù)，不重視質(zhì)量，后果是產(chǎn)品在市場(chǎng)上競(jìng)爭(zhēng)力不高，產(chǎn)品售后維護(hù)和服務(wù)費(fèi)用偏高。
巨大反差
微軟的開發(fā)工程師與測(cè)試工程師的比例是1∶2，國(guó)內(nèi)一般公司是6∶1。而且，致命的問(wèn)題是沒有哪個(gè)機(jī)構(gòu)專門培養(yǎng)測(cè)試工程師。這個(gè)矛盾提示我們，在中國(guó)不能等到實(shí)際的需求和人力資源矛盾十分尖銳的時(shí)候，再談培養(yǎng)問(wèn)題；也不能等到產(chǎn)品質(zhì)量成為產(chǎn)業(yè)阻礙的時(shí)候再來(lái)提高軟件業(yè)的測(cè)試水平。測(cè)試工作不能靠手工勞動(dòng)來(lái)完成，更多的情況是要使用工具軟件和編寫測(cè)試程序來(lái)完成，培養(yǎng)全面的測(cè)試專業(yè)人才是項(xiàng)任重道遠(yuǎn)的工作。
通常情況下，一個(gè)軟件模型說(shuō)明的內(nèi)容主要包括，在測(cè)試過(guò)程中你應(yīng)該考慮到哪些問(wèn)題，如何對(duì)測(cè)試進(jìn)行計(jì)劃，測(cè)試要達(dá)到什么目標(biāo)，什么時(shí)候開始，在測(cè)試中你要用到哪些信息資源。一個(gè)好的模型可以引導(dǎo)你對(duì)問(wèn)題進(jìn)行思考，而不好的模型則只能使你誤入歧途。
這里我要宣稱的是，目前的大多數(shù)軟件測(cè)試模型都是不好的模型。這是因?yàn)檫@些測(cè)試模型僅僅是軟件開發(fā)模型的一些裝飾和補(bǔ)充而已。
人們一直在苦苦尋找軟件開發(fā)的模型，在創(chuàng)建了新的模型后，就把測(cè)試作為一個(gè)階段放在模型的后面部分。因此測(cè)試總被作為一種事后行為，測(cè)試總是被開發(fā)所驅(qū)動(dòng)?？偟膩?lái)說(shuō)，我們是在檢測(cè)他們的完成品。但是，作為事后處理的測(cè)試，其驅(qū)動(dòng)方式是不正確的。實(shí)際上它顯而易見地和開發(fā)過(guò)程中各種行為之間有關(guān)，測(cè)試沒有起到應(yīng)有的平衡作用。這樣的測(cè)試只是檢測(cè)了開發(fā)人員做了什么，而并沒有檢測(cè)到他們是否按照規(guī)則做了什么，這樣的做法割裂了本該緊密聯(lián)系的行為，剩下的只有那些匆忙而草率的想法所帶來(lái)的傷害。
而這樣做的結(jié)果就是效果很差的、效率很低的測(cè)試。效果很差的測(cè)試將導(dǎo)致很多bug沒有被發(fā)現(xiàn)，而效率很低的測(cè)試所浪費(fèi)的是成本。
在本文中，我要做2件事，其一，我要否定一個(gè)不好的模型，即V模型。我希望通過(guò)論述來(lái)表明，“單元測(cè)試”和“集成測(cè)試”這2個(gè)詞匯可以從我們的詞匯表中取消了。其二，我將描述一個(gè)更好的模型。不過(guò)首先我認(rèn)為，要真正擁有一個(gè)充分合理的模型還為時(shí)尚早。我僅僅是描述了一些新模型應(yīng)該符合的重要的要求。這些要求將在本文末尾處列舉。
V模型有什么問(wèn)題呢？
在本文中我要把V模型作為不好的模型的典型來(lái)進(jìn)行分析。我選擇V模型作為分析的典型是因?yàn)閂模型是最廣為人知的測(cè)試模型。
最典型的V模型版本一般會(huì)在其開始部分對(duì)軟件開發(fā)過(guò)程進(jìn)行描述，如下圖所示：
這是古老的瀑布模型。作為開發(fā)模型，它有很多問(wèn)題，不過(guò)這里不作討論。盡管它的各種狀態(tài)是我們接著要討論的大家最熟悉的V模型的基礎(chǔ)。我的批評(píng)意見同時(shí)也針對(duì)其它的裝飾在一些更好的開發(fā)模型之上的測(cè)試模型，例如螺旋模型【Boehm88】。
在V模型中，測(cè)試過(guò)程被加在開發(fā)過(guò)程的后半部分，如下圖所示：
單元測(cè)試所檢測(cè)的是，代碼的開發(fā)是否符合詳細(xì)設(shè)計(jì)的要求。集成測(cè)試所檢測(cè)的是，此前測(cè)試過(guò)的各組成部分是否能完好地結(jié)合到一起。系統(tǒng)測(cè)試所檢測(cè)的是，已集成在一起的產(chǎn)品是否符合系統(tǒng)規(guī)格說(shuō)明書的要求。而驗(yàn)收測(cè)試則檢測(cè)產(chǎn)品是否符合最終用戶的需求。
對(duì)于測(cè)試設(shè)計(jì)，顯而易見的是，V模型的用戶往往會(huì)把執(zhí)行測(cè)試與測(cè)試設(shè)計(jì)分開對(duì)待。在開發(fā)文檔準(zhǔn)備就緒后，就可以開始進(jìn)行相關(guān)的測(cè)試設(shè)計(jì)。如下圖所示，相應(yīng)的測(cè)試設(shè)計(jì)覆蓋在了相關(guān)的開發(fā)過(guò)程之上：
V模型有著很吸引人的對(duì)稱外形，并且把很多人都帶入了歧途。本文將集中討論它在單元測(cè)試和集成測(cè)試中引起的問(wèn)題。
為了說(shuō)明的方便，這里專門制作了以下圖片，圖中包括一個(gè)單獨(dú)的單元，以及一個(gè)單元組，我稱之為子系統(tǒng)（subsystem）。
對(duì)于一個(gè)單元應(yīng)該多大才最為合適的問(wèn)題，已經(jīng)有過(guò)很多的討論，究竟一個(gè)單元僅僅是一個(gè)函數(shù)，一個(gè)類，還是相關(guān)的類的集合？這些討論并不影響我在這里所要闡述的觀點(diǎn)。我們權(quán)且認(rèn)為一個(gè)單元就是一個(gè)具有最小程度的代碼塊，開發(fā)人員可以對(duì)進(jìn)行獨(dú)立地討論。
V模型認(rèn)為人們首先應(yīng)該對(duì)每一個(gè)單元進(jìn)行測(cè)試。當(dāng)子系統(tǒng)中所有的單元都已經(jīng)測(cè)試完畢，它們將被集中到一起進(jìn)行測(cè)試，以驗(yàn)證它們是否可以構(gòu)成一個(gè)可運(yùn)行的整體。
那么，如何針對(duì)單元進(jìn)行測(cè)試呢？我們會(huì)查看在詳細(xì)設(shè)計(jì)中對(duì)接口的定義，或者查看源代碼，或者同時(shí)對(duì)兩者進(jìn)行查看，找出符合某些測(cè)試設(shè)計(jì)中的有關(guān)準(zhǔn)則的輸入數(shù)據(jù)來(lái)進(jìn)行輸入，然后檢查結(jié)果，看其是否正確。由于各單元一般來(lái)說(shuō)不能獨(dú)立地運(yùn)行，所以我們不得不另外設(shè)計(jì)樁模塊（Stub）和驅(qū)動(dòng)模塊（Driver），如下圖所示。
圖中的箭頭代表了測(cè)試的執(zhí)行軌跡。這就是大多數(shù)人所說(shuō)的“單元測(cè)試”。我認(rèn)為這樣的方法有時(shí)候是一種不好的方法。
同樣的輸入也可以有同一子系統(tǒng)中的其它單元來(lái)提供，這樣，其它的單元既扮演了樁模塊，又扮演了驅(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ò)的困難程度有多大？如果我們的測(cè)試直到集成測(cè)試時(shí)才真正開始，那么一些bug可能較晚才被發(fā)現(xiàn)。由此造成的代價(jià)同設(shè)計(jì)樁模塊和驅(qū)動(dòng)模塊的代價(jià)如何比較？等等。
V模型沒有去考慮這些問(wèn)題，當(dāng)單元開發(fā)完成后就執(zhí)行單元測(cè)試，而當(dāng)自系統(tǒng)被集中在一起后就執(zhí)行集成測(cè)試，僅此而已。令我奇怪和沮喪的是，人們從不去做一些權(quán)衡，他們已經(jīng)受制于他們的模型。
因此，一個(gè)有用的模型應(yīng)該允許測(cè)試人員考慮節(jié)省并推遲測(cè)試的可能性。
一個(gè)測(cè)試，如果要發(fā)現(xiàn)一個(gè)特定的單元中的bug，最好是在該單元保持獨(dú)立的情況下執(zhí)行，并且在其外部輔以特定的樁模塊和驅(qū)動(dòng)模塊。而另一種方法則是讓它作為子系統(tǒng)的一部分來(lái)進(jìn)行測(cè)試，該測(cè)試的設(shè)計(jì)主要是為了發(fā)現(xiàn)集成的問(wèn)題。由于一個(gè)子系統(tǒng)本身也需要樁模塊和驅(qū)動(dòng)模塊來(lái)模擬該子系統(tǒng)和其它子系統(tǒng)的聯(lián)系，因此，單元測(cè)試和集成測(cè)試可能被推遲到至少整個(gè)系統(tǒng)已經(jīng)部分集成的時(shí)候。在這種情況下，測(cè)試者可能通過(guò)產(chǎn)品的外部接口同時(shí)進(jìn)行單元測(cè)試、集成測(cè)試和系統(tǒng)測(cè)試，同樣的，其主要目的還是為了減少總體生命周期的成本，對(duì)測(cè)試成本和延期進(jìn)行測(cè)試及由此造成延期發(fā)現(xiàn)bug的代價(jià)成本進(jìn)行權(quán)衡。據(jù)此而言，“單元測(cè)試”、“集成測(cè)試”和“系統(tǒng)測(cè)試”的區(qū)別已經(jīng)大大削弱了。其結(jié)果可參考下圖：
在上圖右邊的方塊中，最好要改成為“執(zhí)行某些適當(dāng)?shù)臏y(cè)試并得到相應(yīng)的結(jié)果”。
圖中的左邊會(huì)怎樣？考慮一下系統(tǒng)測(cè)試設(shè)計(jì)，它的主要根據(jù)和信息來(lái)源是是規(guī)格說(shuō)明。假設(shè)你知道有2個(gè)單元處在一個(gè)特定的子系統(tǒng)中，它們?cè)谶\(yùn)行時(shí)相互聯(lián)系，并且要執(zhí)行規(guī)格說(shuō)明中的一個(gè)特定的聲明。為什么不在該子系統(tǒng)被集成時(shí)立即對(duì)此規(guī)格說(shuō)明中的聲明進(jìn)行測(cè)試，就象是在設(shè)計(jì)完成后立即開始測(cè)試的設(shè)計(jì)一樣呢？如果該聲明的執(zhí)行和子系統(tǒng)外的子系統(tǒng)沒有任何關(guān)系，為什么還要等到整個(gè)系統(tǒng)完成以后再測(cè)試呢？難道越早發(fā)現(xiàn)bug成本越低不對(duì)嗎？
在上一張圖片中，我們用了向上指的箭頭（更有效，但在時(shí)間上有延遲）。這里還可以把箭頭往下指（在時(shí)間上提前）：
在這種情況下，左邊的方塊中最好被標(biāo)記為：“在當(dāng)前信息條件和情況下可以做的任何測(cè)試設(shè)計(jì)”。這樣，當(dāng)測(cè)試設(shè)計(jì)得自于系統(tǒng)中某一個(gè)組件的描述時(shí)，模型必須允許這樣的測(cè)試在組件被裝配之前被執(zhí)行。我必須承認(rèn)我的圖片非常難看，這些箭頭指得到處都是，對(duì)此我有2點(diǎn)說(shuō)明：
1. 我們所討論的事情不是創(chuàng)造美，而是想要發(fā)現(xiàn)盡可能多的嚴(yán)重錯(cuò)誤，同時(shí)盡可能地降低成本。
2. 難看的部分原因也是因?yàn)楸仨毎凑漳承┐涡騺?lái)執(zhí)行的結(jié)果，亦即開發(fā)人員先提供系統(tǒng)描述文檔，然后測(cè)試和這些文檔進(jìn)行關(guān)聯(lián)。這些文檔就象是堅(jiān)實(shí)的老橡樹，而測(cè)試設(shè)計(jì)則象是細(xì)細(xì)的枝條纏繞在樹上。如果我們采用不同的原理來(lái)進(jìn)行組織，圖片可能就會(huì)變得好看些。但復(fù)雜性仍不可避免，因?yàn)槲覀円懻摰膯?wèn)題本身就很復(fù)雜。
V模型失敗的原因是它把系統(tǒng)開發(fā)過(guò)程劃分為具有固定邊界的不同階段，這使得人們很難跨過(guò)這些邊界來(lái)采集測(cè)試所需要的信息。有些測(cè)試應(yīng)該執(zhí)行得更早些，有些測(cè)試則需要延后進(jìn)行。而且，它也阻礙了你從系統(tǒng)描述的不同階段中取得信息進(jìn)行綜合。例如，某些組織有時(shí)執(zhí)行這樣的做法，即對(duì)完成的工作進(jìn)行簽署。這樣的規(guī)定也擴(kuò)展到系統(tǒng)測(cè)試的設(shè)計(jì)。簽署表示已經(jīng)過(guò)評(píng)估，該測(cè)試設(shè)計(jì)工作已經(jīng)完成，除非對(duì)應(yīng)的設(shè)計(jì)文檔改變，否則就不會(huì)被修訂。如果同這些測(cè)試相關(guān)的信息后來(lái)被重新挖掘和認(rèn)識(shí)，例如，架構(gòu)設(shè)計(jì)表明有些測(cè)試是多余的，或者，詳細(xì)設(shè)計(jì)表明有一個(gè)內(nèi)部的邊界可以和已存在的系統(tǒng)測(cè)試組合在一起進(jìn)行測(cè)試的話，那么實(shí)際上還需要繼續(xù)調(diào)整原來(lái)的系統(tǒng)測(cè)試設(shè)計(jì)。
因此，模型必須允許利用不同來(lái)源的綜合信息進(jìn)行個(gè)別的測(cè)試設(shè)計(jì)。另外，模型還應(yīng)該允許在新的信息來(lái)源出現(xiàn)后重新進(jìn)行測(cè)試的設(shè)計(jì)。
一個(gè)不同的模型
讓我們來(lái)看本文的第二項(xiàng)內(nèi)容，一個(gè)不同的模型。
很多時(shí)候人們把代碼移交給其他人，并且說(shuō)：“希望你能接受和喜歡它?！边@不僅發(fā)生在將整個(gè)項(xiàng)目放在一張光盤中交給客戶的時(shí)候，也發(fā)生在項(xiàng)目?jī)?nèi)部。
例如，一個(gè)小組對(duì)另一個(gè)小組說(shuō)：“我們已經(jīng)完成了為COMM庫(kù)加入了對(duì)XML的支持。源代碼現(xiàn)在已經(jīng)放在master庫(kù)中，可執(zhí)行庫(kù)則已經(jīng)加入到集成與創(chuàng)建的環(huán)境中。XARG小組的工作已經(jīng)沒有什么阻礙了，隨時(shí)去取吧?！?/p>
某個(gè)程序員檢查了bug的修改并且發(fā)出郵件：“我已經(jīng)修改了Bug列表中的那個(gè)Bug，很抱歉！”至此，早先受該問(wèn)題影響的其它代碼就可以繼續(xù)處理了。
在這些情況下，人們要把代碼移交給其它人，其中有可能會(huì)存在一些影響。測(cè)試人員需要干預(yù)這個(gè)過(guò)程。在移交之前，測(cè)試人員應(yīng)執(zhí)行這些代碼，發(fā)現(xiàn)其中的bug（影響），并且提出問(wèn)題：“你確實(shí)要提交這些嗎？”由此，移交的內(nèi)容可能會(huì)被延期，直到bug被修復(fù)好。
盡管你還要做其它的各種測(cè)試，這項(xiàng)測(cè)試仍然是很基本的測(cè)試工作。如果你沒有做這樣的測(cè)試，就不能算是合格的測(cè)試人員。
我們的測(cè)試模型必須包含這一重要的現(xiàn)實(shí)需要：針對(duì)代碼移交的測(cè)試。由此，測(cè)試模型應(yīng)提示進(jìn)行針對(duì)每一次代碼移交的測(cè)試。
就讓我以支持XML的COMM庫(kù)作為例子。這里存在著一個(gè)小組把代碼移交給XARG小組以進(jìn)行項(xiàng)目的余下部分。那么誰(shuí)會(huì)遭受影響？
要將這些支持XML的代碼直接進(jìn)行使用的XARG小組可能會(huì)立即受到影響；
這可能會(huì)在稍后影響到市場(chǎng)人員，他們要在一個(gè)行業(yè)展示會(huì)議上為“合作伙伴發(fā)行”版本提供產(chǎn)品演示和宣傳，而XML支持是影響他們銷售的重要部分；
還有，它可能損害采納我們的產(chǎn)品的合作伙伴。
現(xiàn)在我們可以提出一些有趣的關(guān)于測(cè)試計(jì)劃的問(wèn)題了。最簡(jiǎn)單的可以做的事情是，在移交的時(shí)候立即執(zhí)行XML支持的完整測(cè)試。（“完整”的含義是，為此設(shè)計(jì)盡可能多的測(cè)試）但也許一些XML特性并不是XARG小組所需要的，因此可以把它們放在合作伙伴版本封版（下圖中的“Partner Release”）的測(cè)試中去。這意味著可以把一些XML相關(guān)測(cè)試放到稍后的移交過(guò)程中去?；蛘呋谄渌碛桑缭诮A段有其它的測(cè)試任務(wù)要執(zhí)行。而XARG小組則要因XML中的bug修復(fù)而延遲一小段時(shí)間。
我們的測(cè)試計(jì)劃所表示的進(jìn)度可以通過(guò)在開發(fā)的時(shí)
我們應(yīng)嚴(yán)格地圍繞在XML支持的功能交接的時(shí)段里進(jìn)行測(cè)試。測(cè)試設(shè)計(jì)和測(cè)試支持工作要早于測(cè)試執(zhí)行。而另外的XML測(cè)試則要延遲到基于整個(gè)項(xiàng)目范圍的“代碼完成”（圖中的“Code Complete”里程碑），或者要等到全部的子系統(tǒng)被集中在一起，而且整個(gè)產(chǎn)品為了行業(yè)會(huì)議而在經(jīng)過(guò)穩(wěn)定化處理后創(chuàng)建了版本（圖中的“Partner Release”里程碑）。
顯然，有兩項(xiàng)內(nèi)容沒有包含在代碼完成里程碑中：
還有大量其它的測(cè)試工作（包括設(shè)計(jì)、工具選用）。這些工作可能因?yàn)镃OMM以外的子系統(tǒng)的交接而延期。
而且，還有用于完成里程碑中所規(guī)定的某些風(fēng)險(xiǎn)的測(cè)試，例如，可能還有一組用于運(yùn)行市場(chǎng)人員的演示Demo腳本的測(cè)試，包括她可能在無(wú)意中引起的偏離。其目的是要避免這樣的情況，即當(dāng)她站在1000人的觀眾面前時(shí)，她還僅僅是第一次以某種特定的順序來(lái)輸入數(shù)據(jù)。
一些首次交接時(shí)進(jìn)行的XML測(cè)試需要在代碼完成里程碑上再次執(zhí)行。
我的觀點(diǎn)是，測(cè)試計(jì)劃是由很多困難的決定所組成，這些決定包括人員組織安排、機(jī)器資源配置、測(cè)試設(shè)計(jì)的時(shí)間定位、測(cè)試支持代碼的數(shù)量、哪些測(cè)試要做自動(dòng)化，等等。這些決定應(yīng)根據(jù)單獨(dú)的交接中的內(nèi)容信息來(lái)作出。如果僅有一次交接，那么你可以更順利一些。測(cè)試計(jì)劃還應(yīng)繼續(xù)考慮以下問(wèn)題：
1. 風(fēng)險(xiǎn)分析，誰(shuí)會(huì)因此受到損害，以什么方式？
2. 選定一種測(cè)試途徑來(lái)定位特定的風(fēng)險(xiǎn)。
3. 對(duì)測(cè)試設(shè)計(jì)和執(zhí)行的周期和成本進(jìn)行估計(jì)。
4. 在項(xiàng)目進(jìn)度上的特定位置，將計(jì)劃納入執(zhí)行的行動(dòng)：
A. 開始對(duì)測(cè)試進(jìn)行設(shè)計(jì)…
B. … 同時(shí)設(shè)計(jì)和創(chuàng)建一些支持測(cè)試的代碼…
C. … 在全部測(cè)試完成以前就執(zhí)行部分的測(cè)試，因?yàn)榭赡艽嬖诓恢灰淮蔚慕唤?，在每一次交接的測(cè)試規(guī)劃中，可能存在一些潛在的復(fù)雜的相互影響。工作安排不得不進(jìn)行一些調(diào)整以達(dá)到相互間的平衡。測(cè)試支持代碼和工具需要在各項(xiàng)任務(wù)中得到共享。你還必須考慮到在什么程度上讓那些為早先的交接所設(shè)計(jì)的測(cè)試在以后重新執(zhí)行，等等。
這看起來(lái)很復(fù)雜。看上去似乎有太多的內(nèi)容需要跟蹤，而且太多的內(nèi)容可能被忽略。也許你認(rèn)為我是在要求你要對(duì)每一次交接來(lái)執(zhí)行IEEE 829 【IEEE98】中關(guān)于測(cè)試計(jì)劃的要求，然后把它們合并為一份貫穿整個(gè)項(xiàng)目的針對(duì)交接進(jìn)行測(cè)試的測(cè)試計(jì)劃。
是，也不是。思考問(wèn)題總是要占用時(shí)間的。太多的計(jì)劃可能會(huì)減少結(jié)果的產(chǎn)出。在有些時(shí)候，你需要做的是停止計(jì)劃并開始行動(dòng)。例如，你無(wú)法思考并描述每一個(gè)bug修復(fù)，盡管bug修復(fù)也是一種交接。
但是bug修復(fù)是實(shí)際工作中現(xiàn)實(shí)存在的問(wèn)題?？傮w項(xiàng)目計(jì)劃中應(yīng)該包含bug修復(fù)。需要強(qiáng)調(diào)的是，你應(yīng)該有一個(gè)默認(rèn)的bug修改處理的標(biāo)準(zhǔn)過(guò)程，該過(guò)程應(yīng)包括運(yùn)行于每一個(gè)提交的bug修復(fù)的驗(yàn)證過(guò)程。你還需要努力地去思考問(wèn)題。很多時(shí)候，各項(xiàng)驗(yàn)證是被放在一起同時(shí)進(jìn)行并完成的。
比較現(xiàn)實(shí)地來(lái)說(shuō)，一個(gè)模型應(yīng)該允許一些機(jī)械式行為，例如，“不管是哪一個(gè)X類型的交接，都要執(zhí)行下列操作”。同時(shí)我們鼓勵(lì)對(duì)特定的交接執(zhí)行剛剛夠的檢查，對(duì)于風(fēng)險(xiǎn)越小的交接，就越可以采用機(jī)械式的測(cè)試行為。
一個(gè)明確考慮到基本的測(cè)試現(xiàn)實(shí)的模型肯定會(huì)比忽略這些現(xiàn)實(shí)或者把你的工作復(fù)雜性完全抽象化的模型做得更好。文檔則是另一個(gè)例子。
我還沒有提到需求及規(guī)格說(shuō)明書，或者設(shè)計(jì)文檔。某個(gè)交接中產(chǎn)生的一系列變化會(huì)引起很多爭(zhēng)議。這些文檔所扮演的角色是什么呢？它們常常是這么被使用的：
（圖10：測(cè)試中對(duì)開發(fā)文檔的利用）
文檔可以指導(dǎo)你在一個(gè)交接變化時(shí)如何作出反應(yīng)。如果你有一份很好的需求文檔，它可能是產(chǎn)品所解決的問(wèn)題的描述，盡管也許不是很直接。它可以幫助你對(duì)風(fēng)險(xiǎn)進(jìn)行分析。一份好的規(guī)格說(shuō)明應(yīng)對(duì)系統(tǒng)的行為進(jìn)行描述。這將幫助你把測(cè)試方法轉(zhuǎn)化為具體的測(cè)試。一份好的架構(gòu)設(shè)計(jì)則可以幫助你理解變化可能引起的幾種不同的情況：系統(tǒng)的其它部分會(huì)受到怎樣的影響？什么測(cè)試需要再次進(jìn)行？
我并不是經(jīng)常能看到好的文檔。需求文檔常常象是市場(chǎng)銷售用的系統(tǒng)特性列表。規(guī)格說(shuō)明書有時(shí)就象是在代碼完成后提交的用戶手冊(cè)文件。而設(shè)計(jì)文檔經(jīng)常不存在。
好了，通過(guò)針對(duì)交接所引起的變化的集中討論，我已把測(cè)試過(guò)程和軟件開發(fā)過(guò)程相對(duì)地分離開了。如果文檔中關(guān)于“XML支持功能加入到COMM”的描述很薄弱的話，我會(huì)盡自己所知來(lái)進(jìn)行盡可能好的測(cè)試設(shè)計(jì)。然后，假如在項(xiàng)目后期，XML相關(guān)的用戶文檔出來(lái)了，我就可以對(duì)后來(lái)再次提交的交接增加相關(guān)的測(cè)試。假如市場(chǎng)需求改變了，她們經(jīng)常會(huì)這么做，我還會(huì)在此后增加或者去除一些測(cè)試。所有這一切看起來(lái)是這樣的：
（圖11--在文檔不完整的條件下進(jìn)行測(cè)試，并在后期補(bǔ)充測(cè)試）
這樣，雖然項(xiàng)目文檔總是不到位，而且經(jīng)常延遲提交，測(cè)試的效果也因此常常被降低，我們還是要避免測(cè)試受到項(xiàng)目文檔的制約。
頭腦靈活的測(cè)試人員并不過(guò)于相信文檔。畢竟，總是人在犯錯(cuò)誤。那么，難道不是人在寫這些文檔嗎？
由于“正式的”文檔是很薄弱的，測(cè)試模型必須明確地鼓勵(lì)在測(cè)試過(guò)程中使用項(xiàng)目文檔之外的各種不同信息來(lái)源。
測(cè)試人員必須和程序員、用戶、市場(chǎng)人員、技術(shù)作者以及任何的可能為實(shí)現(xiàn)更好測(cè)試提供線索的人進(jìn)行交流。測(cè)試人員還應(yīng)該努力把自己沉浸在某些技術(shù)所構(gòu)建的氛圍中。例如，我希望測(cè)試人員在做XML測(cè)試工作時(shí)常去訪問(wèn)W3組織的XML地址（http://www.w3.org/XML/）以及其它XML站點(diǎn)、郵件列表，甚至包括比較特別的 如Dave Winer的DaveNet/腳本新聞（http://www.scripting.com/）。這些資源并不是所謂的“輔助通道”，而是可以被列入計(jì)劃和進(jìn)度日程的資源。
另外，所執(zhí)行的測(cè)試本身也是一種有用的信息的資源。好的測(cè)試人員會(huì)仔細(xì)閱讀bug報(bào)告，因?yàn)檫@些報(bào)告講授了系統(tǒng)所存在的薄弱之處。特別地，這些報(bào)告還暗示了一些正式的架構(gòu)設(shè)計(jì)所沒有提供的架構(gòu)上的策略。執(zhí)行測(cè)試的行為應(yīng)該產(chǎn)生一些新的測(cè)試想法。如果模型沒有考慮到這些，那么它就是一個(gè)落后的模型。
因此，測(cè)試模型應(yīng)該包含反饋的循環(huán)，讓測(cè)試設(shè)計(jì)可以考慮到，在運(yùn)行測(cè)試時(shí)還可以繼續(xù)發(fā)現(xiàn)到更多的測(cè)試內(nèi)容。
在我們的工作中，真正的復(fù)雜性來(lái)自于所有計(jì)劃的執(zhí)行都處于一個(gè)不確定的、容易忽略的環(huán)境里。代碼并不是唯一在不斷變化的東西。而計(jì)劃日程也在改變。新的功能擴(kuò)充會(huì)帶來(lái)新的里程碑。某些功能會(huì)從當(dāng)前版本中去除。在開發(fā)過(guò)程中，所有人--市場(chǎng)人員、開發(fā)人員和測(cè)試人員，都會(huì)逐漸對(duì)諸如“產(chǎn)品究竟提供什么”這樣的問(wèn)題有越來(lái)越清晰的了解。在這些情形下，我們?cè)趺茨苷f(shuō)測(cè)試計(jì)劃的第一個(gè)版本會(huì)是完全正確的呢？
因此，模型應(yīng)該要求測(cè)試計(jì)劃人制定明確的規(guī)定，對(duì)已交接的交接內(nèi)容，新的交接，以及交接內(nèi)容的變更進(jìn)行負(fù)責(zé)。
總結(jié)
V模型有以下致命的缺陷，其它模型實(shí)際上也與此相似：
1. 忽略了這樣的事實(shí)情況，即軟件開發(fā)是由一系列的交接所組成，每一次交接內(nèi)容都改變了前一次交接的行為。
2. 依賴于開發(fā)文檔的存在，及文檔的精確性、完整性，并且沒有對(duì)時(shí)間進(jìn)行限制。
3. 認(rèn)定一種測(cè)試的設(shè)計(jì)是依據(jù)某一個(gè)單獨(dú)的文檔，而不包括根據(jù)其前后階段的文檔的修改而作相應(yīng)修改。
4. 認(rèn)定這些依賴于某個(gè)單獨(dú)文檔的測(cè)試一定要在一起執(zhí)行。
我大致描述了一個(gè)替代模型，但還不夠精細(xì)。它考慮到了代碼的交接和里程碑。對(duì)測(cè)試成本控制作了以下明確描述：
測(cè)試設(shè)計(jì)的目標(biāo)是定義好可能發(fā)現(xiàn)bug的測(cè)試輸入，而測(cè)試執(zhí)行的目標(biāo)是以各種方式加入這些數(shù)據(jù)，并檢驗(yàn)結(jié)果，由此來(lái)降低整個(gè)生命周期的成本。
我們的模型假設(shè)軟件產(chǎn)品總是不完美的，開發(fā)過(guò)程中有很多變更，而且對(duì)產(chǎn)品的測(cè)試也是一個(gè)不斷學(xué)習(xí)的過(guò)程。
過(guò)去，我很少考慮到模型。表面上我一直還在用V模型。雖然我按此制訂計(jì)劃，但我總是還要花費(fèi)很多額外的精力和時(shí)間來(lái)考慮模型中沒有提到的方面。換言之，模型造成了一些阻礙，因此我有必要對(duì)此進(jìn)行研究。
對(duì)一個(gè)新的模型來(lái)說(shuō)，對(duì)模型所提出的要求必須非常明確，這就象業(yè)務(wù)需求對(duì)產(chǎn)品開發(fā)非常重要一樣。我希望自己對(duì)本文中所提倡的模型的要求的描述能夠和V模型中的描述一樣精確，并具有同樣的指導(dǎo)意義。
理想的測(cè)試模型應(yīng)該包括下列要求：
1. 使測(cè)試對(duì)項(xiàng)目中的每一次代碼交接有所反應(yīng)。
2. 要求測(cè)試計(jì)劃人制定明確的規(guī)定，對(duì)已交接的交接內(nèi)容，新的交接，以及交接內(nèi)容的變更進(jìn)行負(fù)責(zé)。
3. 在測(cè)試設(shè)計(jì)中，除了使用項(xiàng)目文檔外，還應(yīng)明確鼓勵(lì)使用其它各種信息，這些信息有不同來(lái)源。
4. 事實(shí)上項(xiàng)目文檔總是不到位，而且經(jīng)常延遲提交，測(cè)試的效果也因此常常被降低。但我們還是要盡量避免測(cè)試受到項(xiàng)目文檔的制約。
5. 允許根據(jù)多種來(lái)源提供的綜合信息來(lái)設(shè)計(jì)一些獨(dú)立的測(cè)試。
6. 讓測(cè)試被重新設(shè)計(jì)，以新的信息形式進(jìn)行表現(xiàn)。
7. 包含反饋的循環(huán)，讓測(cè)試設(shè)計(jì)可以考慮到，在運(yùn)行測(cè)試時(shí)還可以繼續(xù)發(fā)現(xiàn)到更多的測(cè)試內(nèi)容。
8. 讓測(cè)試人員認(rèn)識(shí)到，避免測(cè)試的延遲可以節(jié)省成本。
9. 在組件被組裝到程序中去之前對(duì)組件的執(zhí)行進(jìn)行測(cè)試。
