【文章內(nèi)容簡介】 )? 單元測(cè)試又稱模塊測(cè)試，是針對(duì)軟件設(shè)計(jì)的最小單位 ─ 程序模塊，進(jìn)行正確性檢驗(yàn)的測(cè)試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯(cuò)。? 單元測(cè)試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例。多個(gè)模塊可以平行地獨(dú)立進(jìn)行單元測(cè)試。1. 單元測(cè)試的內(nèi)容? 在單元測(cè)試時(shí)，測(cè)試者需要依據(jù)詳細(xì)設(shè)計(jì)說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測(cè)試的測(cè)試用例，輔之以黑盒測(cè)試的測(cè)試用例，使之對(duì)任何合理的輸入和不合理的輸入，都能鑒別和響應(yīng)。(1) 模塊接口測(cè)試? 在單元測(cè)試的開始，應(yīng)對(duì)通過被測(cè)模塊的數(shù)據(jù)流進(jìn)行測(cè)試。測(cè)試項(xiàng)目包括：– 調(diào)用本模塊的輸入?yún)?shù)是否正確；– 本模塊調(diào)用子模塊時(shí)輸入給子模塊的參數(shù)是否正確；– 全局量的定義在各模塊中是否一致? 在做內(nèi)外存交換時(shí)要考慮：– 文件屬性是否正確；– OPEN與CLOSE語句是否正確；– 緩沖區(qū)容量與記錄長度是否匹配；– 在進(jìn)行讀寫操作之前是否打開了文件；– 在結(jié)束文件處理時(shí)是否關(guān)閉了文件；– 正文書寫／輸入錯(cuò)誤，– I／O錯(cuò)誤是否檢查并做了處理。(2) 局部數(shù)據(jù)結(jié)構(gòu)測(cè)試? 不正確或不一致的數(shù)據(jù)類型說明? 使用尚未賦值或尚未初始化的變量? 錯(cuò)誤的初始值或錯(cuò)誤的缺省值? 變量名拼寫錯(cuò)或書寫錯(cuò)? 不一致的數(shù)據(jù)類型? 全局?jǐn)?shù)據(jù)對(duì)模塊的影響 (3) 路徑測(cè)試? 選擇適當(dāng)?shù)臏y(cè)試用例，對(duì)模塊中重要的執(zhí)行路徑進(jìn)行測(cè)試。? 應(yīng)當(dāng)設(shè)計(jì)測(cè)試用例查找由于錯(cuò)誤的計(jì)算、不正確的比較或不正常的控制流而導(dǎo)致的錯(cuò)誤。? 對(duì)基本執(zhí)行路徑和循環(huán)進(jìn)行測(cè)試可以發(fā)現(xiàn)大量的路徑錯(cuò)誤。(4) 錯(cuò)誤處理測(cè)試? 出錯(cuò)的描述是否難以理解? 出錯(cuò)的描述是否能夠?qū)﹀e(cuò)誤定位? 顯示的錯(cuò)誤與實(shí)際的錯(cuò)誤是否相符? 對(duì)錯(cuò)誤條件的處理正確與否? 在對(duì)錯(cuò)誤進(jìn)行處理之前，錯(cuò)誤條件是否已經(jīng)引起系統(tǒng)的干預(yù)等(5) 邊界測(cè)試? 注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時(shí)出錯(cuò)的可能性。對(duì)這些地方要仔細(xì)地選擇測(cè)試用例，認(rèn)真加以測(cè)試。? 如果對(duì)模塊運(yùn)行時(shí)間有要求的話，還要專門進(jìn)行關(guān)鍵路徑測(cè)試，以確定最壞情況下和平均意義下影響模塊運(yùn)行時(shí)間的因素。2. 單元測(cè)試的步驟? 模塊并不是一個(gè)獨(dú)立的程序，在考慮測(cè)試模塊時(shí)，同時(shí)要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測(cè)模塊相聯(lián)系的其它模塊。– 驅(qū)動(dòng)模塊 (driver) – 樁模塊 (stub) ── 存根模塊驅(qū)動(dòng)模塊 (driver) ── 相當(dāng)于所測(cè)模塊的主程序。它接收測(cè)試數(shù)據(jù)，把這些數(shù)據(jù)傳送給所測(cè)模塊，最后再輸出實(shí)測(cè)結(jié)果。 樁模塊 (stub) ── 存根模塊。用以代替所測(cè)模塊調(diào)用的子模塊。? 如果一個(gè)模塊要完成多種功能，可以將這個(gè)模塊看成由幾個(gè)小程序組成。必須對(duì)其中的每個(gè)小程序先進(jìn)行單元測(cè)試要做的工作，對(duì)關(guān)鍵模塊還要做性能測(cè)試。? 對(duì)支持某些標(biāo)準(zhǔn)規(guī)程的程序，更要著手進(jìn)行互聯(lián)測(cè)試。有人把這種情況特別稱為模塊測(cè)試，以區(qū)別單元測(cè)試。（二）組裝測(cè)試（Integrated Testing）? 組裝測(cè)試 (集成測(cè)試、聯(lián)合測(cè)試）? 通常，在單元測(cè)試的基礎(chǔ)上，需要將所有模塊按照設(shè)計(jì)要求組裝成為系統(tǒng)。這時(shí)需要考慮的問題是：– 在把各個(gè)模塊連接起來的時(shí)侯，穿越模塊接口的數(shù)據(jù)是否會(huì)丟失；– 一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影響；– 各個(gè)子功能組合起來，能否達(dá)到預(yù)期要求的父功能；– 全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題；– 單個(gè)模塊的誤差累積起來，是否會(huì)放大，從而達(dá)到不能接受的程度。在單元測(cè)試的同時(shí)可進(jìn)行組裝測(cè)試，發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)的問題，最終構(gòu)成要求的軟件系統(tǒng)。 ? 子系統(tǒng)的組裝測(cè)試特別稱為部件測(cè)試，它所做的工作是要找出組裝后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。? 通常，把模塊組裝成為系統(tǒng)的方式有兩種– 一次性組裝方式– 增殖式組裝方式1. 一次性組裝方式 (big bang)l 它是一種非增殖式組裝方式。也叫做整體拼裝。l 使用這種方式，首先對(duì)每個(gè)模塊分別進(jìn)行模塊測(cè)試，然后再把所有模塊組裝在一起進(jìn)行測(cè)試，最終得到要求的軟件系統(tǒng)。2. 增殖式組裝方式? 這種組裝方式又稱漸增式組裝? 首先對(duì)一個(gè)個(gè)模塊進(jìn)行模塊測(cè)試，然后將這些模塊逐步組裝成較大的系統(tǒng)? 在組裝的過程中邊連接邊測(cè)試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題? 通過增殖逐步組裝成為要求的軟件系統(tǒng)。(1) 自頂向下的增殖方式? 這種組裝方式將模塊按系統(tǒng)程序結(jié)構(gòu)，沿控制層次自頂向下進(jìn)行組裝。? 自頂向下的增殖方式在測(cè)試過程中較早地驗(yàn)證了主要的控制和判斷點(diǎn)。? 選用按深度方向組裝的方式，可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能。(2) 自底向上的增殖方式? 這種組裝的方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始組裝和測(cè)試。? 因?yàn)槟K是自底向上進(jìn)行組裝，對(duì)于一個(gè)給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)組裝并測(cè)試完成，所以不再需要樁模塊。在模塊的測(cè)試過程中需要從子模塊得到的信息可以直接運(yùn)行子模塊得到。? 自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點(diǎn)。? 一般來講，一種方式的優(yōu)點(diǎn)是另一種方式的缺點(diǎn)。(3) 混合增殖式測(cè)試l 衍變的自頂向下的增殖測(cè)試– 首先對(duì)輸入／輸出模塊和引入新算法模塊進(jìn)行測(cè)試。– 再自底向上組裝成為功能相當(dāng)完整且相對(duì)獨(dú)立的子系統(tǒng)。– 然后由主模塊開始自頂向下進(jìn)行增殖測(cè)試。l 自底向上自頂向下的增殖測(cè)試– 首先對(duì)含讀操作的子系統(tǒng)自底向上直至根結(jié)點(diǎn)模塊進(jìn)行組裝和測(cè)試。– 然后對(duì)含寫操作的子系統(tǒng)做自頂向下的組裝與測(cè)試。l 回歸測(cè)試– 這種方式采取自頂向下的方式測(cè)試被修改的模塊及其子模塊。– 然后將這一部分視為子系統(tǒng)，再自底向上測(cè)試。關(guān)鍵模塊問題l 在組裝測(cè)試時(shí)，應(yīng)當(dāng)確定關(guān)鍵模塊，對(duì)這些關(guān)鍵模塊及早進(jìn)行測(cè)試。l 關(guān)鍵模塊的特征：① 滿足某些軟件需求；② 在程序的模塊結(jié)構(gòu)中位于較高的層次（高層控制模塊）；③ 較復(fù)雜、較易發(fā)生錯(cuò)誤；④ 有明確定義的性能要求（三）確認(rèn)測(cè)試（Validation Testing）l 確認(rèn)測(cè)試又稱有效性測(cè)試。任務(wù)是驗(yàn)證軟件的功能和性能及其它特性是否與用戶的要求一致。l 對(duì)軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認(rèn)測(cè)試的基礎(chǔ)。1. 進(jìn)行有效性測(cè)試（黑盒測(cè)試）? 有效性測(cè)試是在模擬的環(huán)境 (可能就是開發(fā)的環(huán)境) 下，運(yùn)用黑盒測(cè)試的方法，驗(yàn)證被測(cè)軟件是否滿足需求規(guī)格說明書列出的需求。? 首先制定測(cè)試計(jì)劃，規(guī)定要做測(cè)試的種類。還需要制定一組測(cè)試步驟，描述具體的測(cè)試用例。? 通過實(shí)施預(yù)定的測(cè)試計(jì)劃和測(cè)試步驟，確定– 軟件的特性是否與需求相符；– 所有的文檔都是正確且便于使用；– 同時(shí)，對(duì)其它軟件需求，例如可移植性、兼容性、出錯(cuò)自動(dòng)恢復(fù)、可維護(hù)性等，也都要進(jìn)行測(cè)試? 在全部軟件測(cè)試的測(cè)試用例運(yùn)行完后，所有的測(cè)試結(jié)果可以分為兩類：– 測(cè)試結(jié)果與預(yù)期的結(jié)果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受。– 測(cè)試結(jié)果與預(yù)期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報(bào)告。2. 軟件配置復(fù)查? 軟件配置復(fù)查的目的是保證? 軟件配置的所有成分都齊全；? 各方面的質(zhì)量都符合要求； ? 具有維護(hù)階段所必需的細(xì)節(jié)；? 而且已經(jīng)編排好分類的目錄。? 應(yīng)當(dāng)嚴(yán)格遵守用戶手冊(cè)和操作手冊(cè)中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。? 在軟件交付使用之后，用戶將如何實(shí)際使用程序，對(duì)于開發(fā)者來說是無法預(yù)測(cè)的。? α測(cè)試是由一個(gè)用戶在開發(fā)環(huán)境下進(jìn)行的測(cè)試，也可以是公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的測(cè)試。? α測(cè)試的目的是評(píng)價(jià)軟件產(chǎn)品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。尤其注重產(chǎn)品的界面和特色。? α測(cè)試可以從軟件產(chǎn)品編碼結(jié)束之時(shí)開始，或在模塊（子系統(tǒng)）測(cè)試完成之后開始，也可以在確認(rèn)測(cè)試過程中產(chǎn)品達(dá)到一定的穩(wěn)定和可靠程度之后再開始。? β測(cè)試是由軟件的多個(gè)用戶在實(shí)際使用環(huán)境下進(jìn)行的測(cè)試。這些用戶返回有關(guān)錯(cuò)誤信息給開發(fā)者。? 測(cè)試時(shí)，開發(fā)者通常不在測(cè)試現(xiàn)場。因而，β測(cè)試是在開發(fā)者無法控制的環(huán)境下進(jìn)行的軟件現(xiàn)場應(yīng)用。? 在β測(cè)試中，由用戶記下遇到的所有問題，包括真實(shí)的以及主觀認(rèn)定的，定期向開發(fā)者報(bào)告。? β測(cè)試主要衡量產(chǎn)品的FLURPS。著重于產(chǎn)品的支持性，包括文檔、客戶培訓(xùn)和支持產(chǎn)品生產(chǎn)能力。? 只有當(dāng)α測(cè)試達(dá)到一定的可靠程度時(shí)，才能開始β測(cè)試。它處在整個(gè)測(cè)試的最后階段。同時(shí)，產(chǎn)品的所有手冊(cè)文本也應(yīng)該在此階段完全定稿。（Acceptance Testing）l 在通過了系統(tǒng)的有效性測(cè)試及軟件配置審查之后，就應(yīng)開始系統(tǒng)的驗(yàn)收測(cè)試。l 驗(yàn)收測(cè)試是以用戶為主的測(cè)試。軟件開發(fā)人員和QA（質(zhì)量保證）人員也應(yīng)參加。l 由用戶參加設(shè)計(jì)測(cè)試用例，使用生產(chǎn)中的實(shí)際數(shù)據(jù)進(jìn)行測(cè)試。l 在測(cè)試過程中，除了考慮軟件的功能和性能外，還應(yīng)對(duì)軟件