第二章軟件測試流程概述測試計劃測試設(shè)計單元測試集成測試確認測試系統(tǒng)測試驗收測試評估測試測試流程概述測試計劃根據(jù)用戶需求報告中關(guān)于功能要求和性能指標的規(guī)格說明書，定義相應(yīng)的測試需求報告，使得隨后所有的測試工作都將圍繞著測試需求來進行。同時，適當選擇測試內(nèi)容，合理安排測試人員、測試時間及測試資源等。測試設(shè)計測試設(shè)計是指將測試計劃階段制訂的測試需求分解、細化為若干個可執(zhí)行的測試過程，并為每個測試過程選擇適當?shù)臏y試用例，保證測試結(jié)果的有效性。測試執(zhí)行執(zhí)行測試開發(fā)階段建立的自動測試過程，并對所發(fā)現(xiàn)的缺陷進行跟蹤管理。測試執(zhí)行一般由單元測試、組合測試、集成測試以及回歸測試等步驟組成。測試評估結(jié)合量化的測試覆蓋域及缺陷跟蹤報告，對于應(yīng)用軟件的質(zhì)量和開發(fā)團隊的工作進度及工作效率進行綜合評價。測試計劃

測試計劃的依據(jù)主要是項目開發(fā)計劃和測試需求分析結(jié)果而制定。測試計劃一般包括測試背景、測試依據(jù)、測試資源、測試策略和測試日程等內(nèi)容。測試設(shè)計

根據(jù)測試計劃設(shè)計測試方案，測試設(shè)計過程輸出的是各測試階段使用的測試用例，為每一個測試需求確定測試用例集，并且確定執(zhí)行測試用例的測試過程。測試設(shè)計

根據(jù)軟件測試計劃、軟件需求、軟件構(gòu)架設(shè)計、軟件詳細設(shè)計等文檔內(nèi)容，具體如下：對每一個測試需求，確定其需要的測試用例。對每一個測試用例，確定其輸入及預(yù)期結(jié)果。確定測試用例的環(huán)境配置、驅(qū)動程序。編寫測試用例文檔對測試用例進行同行評審測試執(zhí)行與評估

測試人員需要搭建測試環(huán)境，應(yīng)盡可能的模擬被測系統(tǒng)的實際應(yīng)用工作所必需的軟件、硬件系統(tǒng)、網(wǎng)絡(luò)設(shè)備、歷史數(shù)據(jù)和支持條件等，測試執(zhí)行過程又分為以下測試階段：單元測試、集成測試、確認測試、驗收測試等。軟件開發(fā)是一個自頂向下，逐步細化的過程。軟件測試則是依相反順序的自底向上，逐步集成的過程。低一級的測試為上一級的測試準備條件。集成測試確認測試系統(tǒng)測試單元測試單元測試單元測試單元測試模塊模塊模塊模塊已測模塊設(shè)計信息集成的軟件確認的軟件軟件需求其它系統(tǒng)元素集成測試確認測試系統(tǒng)測試單元測試單元測試單元測試單元測試模塊模塊模塊模塊模塊模塊模塊已測模設(shè)計信息設(shè)計信息集成的軟件確認的軟軟件需求軟件需求測試執(zhí)行階段單元測試

單元測試是在軟件開發(fā)過程中進行的最低級別的測試活動，其測試的對象是軟件設(shè)計的最小單位。例如：

●傳統(tǒng)的結(jié)構(gòu)化編程語言中，比如C語言，單元測試的對象一般是函數(shù)或子過程。

●在像C++這樣的面向?qū)ο蟮恼Z言中，單元測試的對象可以是類，或類的成員函數(shù)。

●對Ada語言，單元測試可以在獨立的過程和函數(shù)上進行，也可以在Ada包的級別上進行。

●單元測試的原則同樣也可以擴展到第四代語言(4GL)中，這時單元被典型地定義為一個菜單或顯示界面。

單元測試又稱為模塊測試，什么是模塊？并沒有嚴格的定義，不過按照一般的理解，模塊應(yīng)該具有以下的一些基本屬性：

●名字；

●明確規(guī)定的功能；

●內(nèi)部使用的數(shù)據(jù)，或稱局部數(shù)據(jù)；

●與其它模塊或外界的數(shù)據(jù)聯(lián)系；

●實現(xiàn)其特定功能的算法；

●可被其上層模塊調(diào)用，也可調(diào)用其下屬模塊進行協(xié)同工作。單元測試過程單元測試的任務(wù)

模塊接口測試——對被測模塊，檢測數(shù)據(jù)能否正確無誤地進入和流出模塊；模塊局部數(shù)據(jù)結(jié)構(gòu)測試——檢測模塊在工作過程中，其內(nèi)部數(shù)據(jù)能否保持其完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式以及相互之間關(guān)系；模塊邊界條件測試——檢測在數(shù)據(jù)邊界處，模塊能否正常工作；覆蓋測試——檢測模塊運行能否滿足特定的邏輯覆蓋；出錯處理檢測——檢測模塊出錯處理是否有效。

由于每個模塊在整個軟件中并不是孤立的，在對每個模塊進行單元測試時，需要考慮它和周圍模塊的相互聯(lián)系。為模擬這一聯(lián)系，在進行單元測試時，必須設(shè)置若干個輔助測試模塊。這些輔助模塊分為兩種：●

驅(qū)動模塊（driver）:用以模擬被測模塊上級模塊，相當于被測模塊的主程序。●

樁模塊（stub）:用以模擬被測模塊的下級模塊，相當于被測模塊調(diào)用的子模塊。

被測模塊與其相關(guān)的驅(qū)動模塊和樁模塊共同構(gòu)成了一個“測試環(huán)境”。集成測試

1999年9月，火星氣象人造衛(wèi)星在經(jīng)過41周4．16億英里的成功飛行之后，在就要進入火星軌道時失敗了。美國投資5萬美元調(diào)查事故原因，發(fā)現(xiàn)：太空科學家使用的是英制(磅)加速度數(shù)據(jù)，而噴氣推進實驗室采用公制(牛頓)加速度數(shù)據(jù)進行計算。

●模塊相互調(diào)用時引入了新的問題；●幾個子功能組合起來不能實現(xiàn)主功能；●誤差不斷積累達到不可接受的程度；●全局數(shù)據(jù)結(jié)構(gòu)出現(xiàn)錯誤等。集成測試非增式測試

增式測試

自頂向下測試自底向上測試獨立地測試程序的每個模塊，然后再把它們組合成整個程序的集成測試方法。把下一個待測試的模塊組合到已經(jīng)測試過的那些模塊上去，再進行測試。從主控模塊開始，按照軟件的控制層次結(jié)構(gòu)，逐步把各個模塊集成在一起。從最下層的模塊開始，按照程序的層次結(jié)構(gòu)，逐漸形成完整的整體。非增式集成測試法：獨立地測試該程序的每個模塊，然后再把它們組合成整個程序的方法。增式集成測試法：把下一個待測試的模塊組合到已經(jīng)測試過的那些模塊上去，再進行測試的方法。增式測試與非增式測試測試每一個模塊都需要驅(qū)動模塊和樁模塊。驅(qū)動模塊用以模擬被測模塊的上級模塊，用來驅(qū)動或傳送測試用例給被測模塊，還須向測試者顯示執(zhí)行被模塊所產(chǎn)生的結(jié)果。樁模塊由被測模塊調(diào)用，以便檢驗被測模塊與其下級模塊之間的接口。非增式集成測試M1S1S2S3M2M3M4M5d1d2d3d4S4S5M6d5S6M7d6圖6-2非增式測試M1S1S2S3M2M3M4M5d1d2d3d4S4S5M6d5S6M7d6M2M3M4M5d1d2d3d4S4S5M6d5M6d5S6M7d6圖6-2非增式測試M1M2M3M4M5M7M6圖6-1七模塊的程序簡圖M1M2M3M4M5M7M6M1M2M3M4M5M7M6圖6-1

在進行單元測試時，對模塊M2和M4配備了驅(qū)動模塊和樁模塊，對模塊M3，M5，M6和M7只配備了驅(qū)動模塊，對主模塊M1配備了3個樁模塊，以模擬被它調(diào)用的3個模塊M2、M3和M4。分別進行單元測試以后，再聯(lián)接起來，進行集成測試。

增式集成測試是另一種集成測試方法，它不是孤立地測試每一個模塊，而是一開始就把待測試的模塊與已測試過的模塊聯(lián)接起來。增式集成測試的過程，就是不斷地把待測試的模塊聯(lián)接到已測試過的模塊集(或其子集)上，對待測試模塊進行測試，直到最后一個模塊測試完畢。增式集成測試

M1M2M3M4M5M7M6圖6-1七模塊的程序簡圖M1M2M3M4M5M7M6M1M2M3M4M5M7M6圖6-1七模塊的程序簡圖增量測試方法的種類很多，比如從程序底部開始（自底向上）測試。先由4個人并行或順序地測試模塊M3，M5，M6和M7。這時，需為每個模塊準備一個驅(qū)動模塊，但不需要準備樁模塊。然后測試模塊M2和M4，它們不是孤立地測試，而是把M2聯(lián)在模塊M5和M6上，模塊M4聯(lián)在模塊M7上，也就是如果要測試模塊M2，先要設(shè)計一個驅(qū)動模塊，再對模塊對M2－M5，M2－M6進行測試。非增式集成測試方法工作量大。增式集成測試中，能夠較早地檢查出模塊之間接口的錯誤。增式集成測試，查找故障比較容易。增式集成測試可以更徹底地對程序進行測試。非增式集成測試方法需要的機器時間較少。采用非增式集成測試，所有模塊可以同時進行并行測試。非增式與增式的比較

增式集成是構(gòu)造程序結(jié)構(gòu)的一種方式，按照不同的模塊集成方式，又分為自頂向下增式測試和自底向上增式測試兩種。自頂向下集成從主控模塊開始，按照軟件的控制層次結(jié)構(gòu)，逐步把各個模塊集成在一起。自底向上集成則從最下層的模塊開始，按照程序的層次結(jié)構(gòu)，逐漸形成完整的整體。自頂向下與自底向上

原則：下一次要測試的模塊，至少有一個調(diào)用它的模塊已經(jīng)測試過。自頂向下增式測試的具體步驟為：

1）對主控模塊進行測試，然后以主控模塊作為測試驅(qū)動模塊，把對主控模塊進行單元測試時引入的所有樁模塊逐漸用實際模塊替代；

2）依據(jù)所選的集成策略，每次只替代一個樁模塊；

3）每集成一個模塊立即測試一遍；

4）只有每組測試完成后，才著手替換下一個樁模塊；

5）為避免引入新故障，需不斷地進行回歸測試（即全部或部分地重復已做過的測試）。從第二步開始，循環(huán)執(zhí)行上述步驟，直至整個程序結(jié)構(gòu)構(gòu)造完畢。自頂向下增式集成測試

先測試模塊M1。要測試模塊M1，必須先編寫出表示模塊M2、M3和M4的各個樁模塊s1,s2和s3，以模擬被M1調(diào)用的模塊。測試完M1后，將由下一個要測試的模塊來代替其中一個樁模塊，并加入這個模塊所需要的樁模塊。自頂向下集成測試M1S1S2S3圖6-4（a）自頂向下集成測試M1S1S2S3圖6-4（a）自頂向下集成測試M1M2S2S3圖6-4（b）自頂向下集成測試S4S5

測試了主模塊之后，有幾種可能的測試順序：M1，M2，M3，M4，M5，M6，M7，M8，M9，M10，M11，M12M1，M2，M5，M6，M10，M3，M7，M11，M4，M8，M12，M9M1，M4，M8，M9，M11，M12，M3，M7，M2，M6，M10，M5M1，M2，M6，M10，M4，M9，M5，M3，M7，M11，M8，M12下面兩點是應(yīng)該考慮的：

1）如果程序中有關(guān)鍵性的部分，設(shè)計次序就應(yīng)該盡早地把這些模塊加入進程序。所謂“關(guān)鍵部分”可能是一個復雜的模塊，一個具有新算法的模塊，或懷疑容易出錯的模塊。

2）設(shè)計次序時，要讓輸入/輸出模塊盡早地加入測試。

如果模塊M10，和M9是輸入／輸出模塊并且M7執(zhí)行一些關(guān)鍵性的功能，那么增量順序最好是：

M1，M2，M6，M10，M4，M9，M3，M7，M5，M11，M8，M12

并且第6次增量測試后的程序形式．

自頂向下測試可以自然地做到逐步求精，讓測試人員看到系統(tǒng)的雛型，有助于對程序的主要控制和決策模塊進行檢驗，增強測試人員的信心。

不足之處在于：測試較高層模塊時，由于低層處理用樁模塊替代，不能反映真實情況，重要數(shù)據(jù)不能及時回送到上層模塊，觀察和解釋測試輸出往往比較困難的。為了解決這個問題，可以采用幾種辦法：把某些模塊測試推遲到用真實模塊替代樁模塊之后進行；開發(fā)出能模擬真實模塊的樁模塊；采用自底向上集成測試方法。2.自底向上增式集成測試

自底向上增式集成測試是從軟件結(jié)構(gòu)的最下層模塊開始測試的，測試較高層模塊時，所需的下層模塊功能都已具備，所以不再需要樁模塊。自底向上增式集成測試的步驟為：

1）把低層模塊組織成實現(xiàn)某個子功能的模塊群;2）開發(fā)一個測試驅(qū)動模塊，控制測試數(shù)據(jù)的輸入和測試結(jié)果的輸出；

3）對每個模塊群進行測試；

4）刪除測試使用的驅(qū)動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。從第一步開始循環(huán)執(zhí)行上述各步驟，直至整個程序構(gòu)造完畢。自底向上集成測試自底向上測試d6M5d1d2d3M11d5d4d6M5d1M5d1d2d2d3d3d5(a)(b)(c)(d)(e)(f)d4d4M7M9M10M12第一步順序地或并行地測試M5，M7，M9，M10，M11和M12中的部分模塊或全部模塊。每一模塊都需要專門的驅(qū)動模塊：這個驅(qū)動模塊可以接受測試輸入，可以調(diào)用正在測試的模塊，并且可以顯示結(jié)果或?qū)嶋H輸出與期望輸出進行比較。影響測試順序的因素是模塊的關(guān)鍵性質(zhì)。如果可以確定模塊M4和M6是關(guān)鍵的，那么自底向上增式測試的中間狀態(tài)可能如圖所示。

優(yōu)點：自底向上測試方法不需要樁模塊，測試用例的設(shè)計亦相對比較簡單,也不存在還沒把前面的模塊完全測試卻又開始測試另一模塊的問題。如果關(guān)鍵的模塊是在結(jié)構(gòu)圖的底部，自底向上測試具有一定的優(yōu)越性。

缺點：在測試初期不能呈現(xiàn)出被測軟件系統(tǒng)的輪廓。實際上，直到最后一個模塊(模塊M1)加入時才具有整體形象，才能形成完整的程序。集成方法優(yōu)點缺點自頂向下測試如果主要故障發(fā)生在程序的頂端時，有利于查出故障。一旦加入I/O功能，測試用例易于形成。初期的程序輪廓可以讓人們看到程序的功能，增強信心需要樁模塊。在I/O功能加入以前，很難描述測試用例。很難觀察測試輸出。使人想推遲完成某些模塊的測試。自底向上測試如果主要故障發(fā)生在程序的底端時，有利于查出故障。測試用例生成容易。觀察測試結(jié)果容易。需要驅(qū)動程序。在加入最后一個每卡之前，程序不能作為一個整體存在。

自頂向下集成測試與自底向上集成測試比較系統(tǒng)測試

系統(tǒng)測試實際上是針對系統(tǒng)中各個組成部進行的綜合性檢驗，很接近我們的日常測試實踐。系統(tǒng)測試的目標不是要找出軟件故障，而是要證明系統(tǒng)的性能

●系統(tǒng)開發(fā)人員不能進行系統(tǒng)測試。

●系統(tǒng)開發(fā)組織不能負責系統(tǒng)測試。系統(tǒng)測試最好由獨立的測試機構(gòu)完成。

驗收測試

驗收測試是將最終產(chǎn)品與最終用戶的當前需求進行比較的過程，是軟件開發(fā)結(jié)束后，軟件產(chǎn)品向用戶交付之前進行的最后一次質(zhì)量檢驗活動，回答開發(fā)的軟件產(chǎn)品是否符合預(yù)期的各項要求，用戶是否接受等問題。驗收測試不只檢驗軟件某方面的質(zhì)量，還要進行全面的質(zhì)量檢驗并決定軟件是否合格。因此驗收測試是一項嚴格的正規(guī)的測試活動，并且應(yīng)該在生產(chǎn)環(huán)境中而不是開發(fā)環(huán)境中進行。驗收測試的主要任務(wù)包括：●明確規(guī)定驗收測試通過的標準；●確定驗收測試方法；●確定驗收測試的組織和可利用的資源；●確定測試結(jié)果的分析方法；●制定驗收測試計劃并進行評審；●設(shè)計驗收測試的測試用例；●審查驗收測試的準備工作；●執(zhí)行驗收測試；●分析測試結(jié)果，決定是否通過驗收。驗證的基本方法

驗證是對軟件產(chǎn)品進行人工檢查或評審。驗證的基本方法有：軟件審查、走查、伙伴檢查等。軟件審查走查伙伴檢查主持人非該軟件的編制人員任何人沒有參與人員3—6人小組多一些人1～2人準備有只有主持人無數(shù)據(jù)收集有不要求無輸出報告有不要求口頭評論優(yōu)點有效能使更多人熟悉產(chǎn)品費用低缺點短期成本高查出的故障較少查出的故障較少軟件審查

正式評審、技術(shù)評審以及軟件審查會是審查的幾種不同說法。軟件審查以會議的形式進行，利用集體的智慧查找軟件產(chǎn)品中存在的問題，從而保證軟件產(chǎn)品的質(zhì)量。軟件審查的對象可以是任何重要的工作產(chǎn)品，例如：需求分析、概要設(shè)計、詳細設(shè)計等階段的成果以及源程序代碼、測試計劃和測試用例等。軟件審查的目標是：

●收集數(shù)據(jù)，發(fā)現(xiàn)軟件故障。

●交流。信息。軟件審查的基本要素：

●確定問題。

●遵守規(guī)則。

●準備。

●編寫報告。軟件審查的輸入：

●被審查的文檔；

●有關(guān)的原始資料：

●審查單軟件審查的輸出：

●審查匯總/報告

●有關(guān)故障類型的數(shù)據(jù)。軟件審查的步驟：

●制定計劃；

●準備；

●審查會；

●返工；

●終審。走查

走查不像軟件審查那么正式，準備工作一般由主持者負責，參加人員只是簡單地參加會議，在會議前不需要做更多的準備工作。走查的目標是：熟悉材料、發(fā)現(xiàn)軟件故障。走查的主要元素有：定期的會議，只有主持人必須事先準備：2-7人，軟件開發(fā)人員或材料編寫者；主持人通常是軟件開發(fā)者。走查的輸入是被檢查的材料以及可使用的標準走查的輸出是走查報告?；锇闄z查

伙伴檢查常常只在編寫代碼的程序員和充當審查者的其他一二個程序員或測試員之間進行，這個小團體只是在一起審查代碼，尋找問題和失誤。聚集起來討論問題也能找出一些軟件缺陷，發(fā)現(xiàn)產(chǎn)品中的缺陷而不是人的錯誤，伙伴檢查不失為一種極好的訓練。驗證活動

驗證活動是測試生存周期中的一個階段，包括需求驗證、功能設(shè)計驗證、詳細設(shè)計驗證和代碼驗證。在每個驗證活動中，測試的目的都是為了發(fā)現(xiàn)盡可能多的故障，測試人員應(yīng)積極參與軟件審查和走查工作，并開展驗證工作。

在每一類的驗證活動中，都要考慮以下問題：

●使用的驗證方法(審查、走查、伙伴檢查等)●產(chǎn)品中要驗證的和不要驗證的范圍●沒有驗證的部分所承擔的風險?！裥枰獌?yōu)先進行驗證的范圍●資源、進度、工具和責任等。審查單

審查單是驗證測試的重要工具，尤其是對于像軟件審查這一類比較正式的驗證方法。針對各種類型的驗證活動都有相應(yīng)的審查單，例如，需求驗證審查單，功能設(shè)計驗證審查單，詳細設(shè)計驗證審查單，代碼驗證審查單、一般文檔驗證審查單等等。對于一切要進行檢查的項目都可以開發(fā)相應(yīng)的審查單。

進行驗證測試時，最重要的是利用一般的審查單，針對特殊目的和特別項目開發(fā)屬于自己組織的審查單，這些審查單應(yīng)該有明確的目的，并能充分反應(yīng)組織在驗證測試方面現(xiàn)有的成熟水平。需求驗證審查單包括:

●完整性；每一條款必須詳細說明所列問題的解決方案。

●準確、清楚；每一條款只有一種解釋。

●前后一致；規(guī)格說明中的前后條款不能自相矛盾。

●相關(guān)性；每一條款都與問題和解決方案相關(guān)。

●可測試性；項目開發(fā)及驗收測試期間，能確定該項目是否得到滿足。

●可跟蹤性；每一條款都能追蹤到它的起源。

●可行性；每一條款在規(guī)定的時間和開銷下，在現(xiàn)有的人力和物力支持下，都可以實現(xiàn)。功能設(shè)計驗證

功能設(shè)計是將用戶需求轉(zhuǎn)化為一組外部接口的過程。功能設(shè)計規(guī)格說明從功能角度對產(chǎn)品行為進行描述。對功能設(shè)計進行驗證測試，就是要確定用戶需求是如何在功能設(shè)計中得以具體體現(xiàn)的，需求中的每一項都要在功能設(shè)計規(guī)格說明中得到體現(xiàn)，如果不是這樣的話，它是被遺漏了還是被刪掉了？功能設(shè)計規(guī)格說明不完整是一種最常見的缺陷。

功能設(shè)計驗證審查單

一份通用的功能設(shè)計驗證審查單包含以下幾方面的內(nèi)容：

●如果術(shù)語已被明確定義，則盡可能用定義代替術(shù)語。

●如果對一個結(jié)構(gòu)進行了描述，則試著勾畫被描述結(jié)構(gòu)的結(jié)構(gòu)圖。

●如果指定了一項計算，則至少手工計算兩個例子并作為范例包含在規(guī)格說明內(nèi)。

●查找確定性語句時，應(yīng)根據(jù)需要一層層次進行搜索，直到滿足計算機所需要的確定性。

●注意含義不明確的詞。

●查找功能清單，找出沒有例子或例子雷同的功能，修改例子并包含在規(guī)格說明內(nèi)。詳細設(shè)計驗證

詳細設(shè)計是將功能設(shè)計轉(zhuǎn)化為詳細的數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)流和算法的過程，它表明了軟件產(chǎn)品具體是如何構(gòu)造的。詳細設(shè)計規(guī)格說明對測試人員來說十分寶貴。從測試的角度出發(fā)，對詳細設(shè)計規(guī)格說明進行仔細地審查，可以利用審查獲得的信息，了解產(chǎn)品將如何構(gòu)造，系統(tǒng)將如何集成，可以使測試者更加深入和全面地認識軟件產(chǎn)品。詳細設(shè)計驗證審查單

使用詳細設(shè)計驗證審查單對詳細設(shè)計規(guī)格說明進行驗證測試，發(fā)現(xiàn)問題可以追蹤到功能設(shè)計和需求階段，看看所用的算法及組合方式是否合適。一個典型的詳細設(shè)計驗證審查單中包括：

●設(shè)計文檔是否包含了詳細設(shè)計的步驟描述或說明。

●是否有計算機系統(tǒng)的用戶界面模型。

●是否有計算機系統(tǒng)其它接口的模型或描述。

●是否有被推薦的計算機系統(tǒng)高層功能模型。

●主要實施及評估方案在詳細設(shè)計規(guī)格說明中是否得到了反映。代碼驗證測試

對代碼進行驗證測試可以采用審查、走查或伙伴檢查的方式。代碼驗證測試包括以下幾方面的內(nèi)容：

●將代碼與詳細設(shè)計規(guī)格說明進行比較。

●對照特定語言的審查單檢查代碼。

●使用靜態(tài)分析工具對句法規(guī)則進行檢查。

●檢查代碼中的標識符是否與在數(shù)據(jù)字典和詳細設(shè)計規(guī)格說明中的一致。

●尋找邊界條件、可能的性能瓶頸、以及其他可能需要進行測試的內(nèi)部條件。標準或規(guī)范

在代碼驗證測試時，測試人員還應(yīng)檢查代碼編寫是否符合某種標準或規(guī)范。堅持標準或規(guī)范的原因有：

●可靠性。事實證明按照某種標準或規(guī)范編寫的代碼比不按標準編寫的代碼更可靠，軟件故障更少。

●可讀性／維護性。符合標準和規(guī)范的代碼易于閱讀、理解和維護。

●移植性。如果代碼符合標準，移植到另一個平臺就會輕而易舉，甚至完全沒有障礙。

數(shù)據(jù)引用錯誤數(shù)據(jù)聲明錯誤計算錯誤

比較錯誤

控制流錯誤

接口錯誤輸入／輸出錯誤

其他檢查

●是否引用了未初始化或未說明的變量?！駭?shù)組和字符串的下標是否是整數(shù)值，下標是否在維數(shù)定義的范圍之內(nèi)?！袷褂米址畷r，是否超過了字符串的邊界，使用數(shù)組時，是否出現(xiàn)“差一個”這樣的潛在錯誤?！袷欠裨趹?yīng)該使用常量的地方使用了變量?！袷欠褡兞勘毁x予了不同類型的值。●是否為引用的指針分配了內(nèi)存?！袢绻粋€數(shù)據(jù)結(jié)構(gòu)在多個函數(shù)或者子程序中被引用，每個引用對該數(shù)據(jù)結(jié)構(gòu)的定義是否一致。數(shù)據(jù)引用錯誤

數(shù)據(jù)聲明錯誤

●變量是否都賦予了正確的長度、類型和存儲類型●變量是否在聲明的同時被初始化了，是否正確初始化并與其存儲類型相匹配?！褡兞渴欠裼邢嗨频拿Q?！袷欠翊嬖诖嬖诼暶鬟^、但從未引用或者只引用過一次的變量。●模塊中所有變量都顯式聲明了嗎，如果沒有，是否該變量為更高級別的模塊所共享。計算錯誤

●計算中是否使用了不同數(shù)據(jù)類型的變量；●計算中是否使用了數(shù)據(jù)類型相同但長度不同的變量；●計算時是否了解或考慮了編譯器對類型或長度不一變量的轉(zhuǎn)換規(guī)則；●目標變量的分配空間是否小于右邊的表達式；●在數(shù)值計算過程中是否可能出現(xiàn)溢出；●除數(shù)／模是否可能為零；●對于算術(shù)運算，代碼處理是否可能丟失精度；●變量的值是否會超過合理的范圍；

●對于包含多個操作數(shù)的表達式，求值的次序是否混亂，運算優(yōu)先級是否正確，是否需要加括號使其清晰。比較錯誤

●比較運算符正確嗎，比較應(yīng)該是小于還是小于或等于；●是否存在分數(shù)或者浮點值之間的比較，如果有，精度問題是否會影響比較結(jié)果；●每一個邏輯表達式是否都表示正確，求值次序是否有問題；●邏輯表達式的操作數(shù)是否是邏輯值，是否將整型變量用于邏輯計算中。控制流錯誤

●如果程序包含begin…end和do…while等語句組，結(jié)尾與其相應(yīng)的語句組是否匹配；●程序、模塊、子程序或循環(huán)能否終止，如果不能，是否可以接受；●是否有死循環(huán)，是否會過早地退出循環(huán)；●是否有這種可能，由于入口條件的原因，某個循環(huán)永遠不會被執(zhí)行到；●如果程序包含有多個分支，是否能執(zhí)行到每個分支；●是否存在“差一個”錯誤，導致意外地進入或退出循環(huán)。接口錯誤●被調(diào)用模塊接收的參數(shù)類型和數(shù)量與調(diào)用模塊傳送的參數(shù)是否匹配，次序是否正確；●如果某模塊有多個入口點，引用的參數(shù)是否與當前入口點無關(guān)；●常量是否被當作形參傳遞；●子程序是否更改了只能作為輸入的參數(shù)；●每個參數(shù)的使用單位與形參匹配嗎，例如，度與弧度。輸入／輸出錯誤●如果文件被顯式地聲明，它們的屬性是否正確；●是否處理了文件、外設(shè)不存在或未準備好等錯誤的情況；●所有文件在使用之前是否都被打開了；●軟件是否以預(yù)期方式處理預(yù)計的錯誤；●是否檢查了錯誤提示信息的準確性、正確性、語法和拼寫錯誤。確認測試

集成測試完成以后，分散開發(fā)的模塊被聯(lián)接起來，構(gòu)成一個完整的程序。其中各模塊之間接口存在的種種問題都已消除。于是進入了確認測試階段。所謂確認測試，是對照軟件需求規(guī)格說明書，對軟件產(chǎn)品進行評估以確定其是否滿足需求規(guī)格的過程。

（1）經(jīng)過檢驗，軟件功能、性能及其它要求都已滿足需求規(guī)格說明書的規(guī)定，是一個合格的軟件。（2）經(jīng)過檢驗，發(fā)現(xiàn)與需求說明書有相當?shù)钠x，我們得到一個缺陷清單，這就需要開發(fā)部門和顧客進行協(xié)商，找出解決的辦法。確認任務(wù)

確認是指決定最后的軟件產(chǎn)品是否正確無誤。比如，開發(fā)的軟件是否符合軟件需求規(guī)格說明和用戶要求，輸出的信息是否是用戶想要的信息，在將來的實際使用環(huán)境中能否正確穩(wěn)定地運行，是否存在隱患等，這自然包含了對它在功能、性能、接口以及限制條件等方