軟件測試步驟
• 測試過程按4個(gè)步驟進(jìn)行,，即單元測試,、集成測試,、確認(rèn)測試和系統(tǒng)測試及發(fā)版測試,。
• 開始是單元測試，集中對用源代碼實(shí)現(xiàn)的每一個(gè)程序單元進(jìn)行測試,，檢查各個(gè)程序模塊是否正確地實(shí)現(xiàn)了規(guī)定的功能,。
• 集成測試把已測試過的模塊組裝起來，主要對與設(shè)計(jì)相關(guān)的軟件體系結(jié)構(gòu)的構(gòu)造進(jìn)行測試,。
• 確認(rèn)測試則是要檢查已實(shí)現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求,，以及軟件配置是否完全、正確,。
• 系統(tǒng)測試把已經(jīng)經(jīng)過確認(rèn)的軟件納入實(shí)際運(yùn)行環(huán)境中,，與其它系統(tǒng)成份組合在一起進(jìn)行測試,。
單元測試 (Unit Testing)
• 單元測試又稱模塊測試，是針對軟件設(shè)計(jì)的最小單位 ─ 程序模塊,，進(jìn)行正確性檢驗(yàn)的測試工作,。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯(cuò)。
• 單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測試用例,。多個(gè)模塊可以平行地獨(dú)立進(jìn)行單元測試,。
1. 單元測試的內(nèi)容
• 在單元測試時(shí)，測試者需要依據(jù)詳細(xì)設(shè)計(jì)說明書和源程序清單,，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu),，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例,，使之對任何合理的輸入和不合理的輸入,，都能鑒別和響應(yīng)。
(1) 模塊接口測試
• 在單元測試的開始,，應(yīng)對通過被測模塊的數(shù)據(jù)流進(jìn)行測試,。測試項(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)測試
• 不正確或不一致的數(shù)據(jù)類型說明
• 使用尚未賦值或尚未初始化的變量
• 錯(cuò)誤的初始值或錯(cuò)誤的缺省值
• 變量名拼寫錯(cuò)或書寫錯(cuò)
• 不一致的數(shù)據(jù)類型
• 全局?jǐn)?shù)據(jù)對模塊的影響
(3) 路徑測試
• 選擇適當(dāng)?shù)臏y試用例,，對模塊中重要的執(zhí)行路徑進(jìn)行測試,。
• 應(yīng)當(dāng)設(shè)計(jì)測試用例查找由于錯(cuò)誤的計(jì)算,、不正確的比較或不正常的控制流而導(dǎo)致的錯(cuò)誤,。
• 對基本執(zhí)行路徑和循環(huán)進(jìn)行測試可以發(fā)現(xiàn)大量的路徑錯(cuò)誤,。
(4) 錯(cuò)誤處理測試
• 出錯(cuò)的描述是否難以理解
• 出錯(cuò)的描述是否能夠?qū)﹀e(cuò)誤定位
• 顯示的錯(cuò)誤與實(shí)際的錯(cuò)誤是否相符
• 對錯(cuò)誤條件的處理正確與否
• 在對錯(cuò)誤進(jìn)行處理之前，錯(cuò)誤條件是否已經(jīng)引起系統(tǒng)的干預(yù)等
(5) 邊界測試
• 注意數(shù)據(jù)流,、控制流中剛好等于、大于或小于確定的比較值時(shí)出錯(cuò)的可能性,。對這些地方要仔細(xì)地選擇測試用例,，認(rèn)真加以測試,。
• 如果對模塊運(yùn)行時(shí)間有要求的話,，還要專門進(jìn)行關(guān)鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運(yùn)行時(shí)間的因素,。
2. 單元測試的步驟
• 模塊并不是一個(gè)獨(dú)立的程序,，在考慮測試模塊時(shí),，同時(shí)要考慮它和外界的聯(lián)系,，用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。
– 驅(qū)動模塊 (driver)
– 樁模塊 (stub) ── 存根模塊
• 如果一個(gè)模塊要完成多種功能,，可以將這個(gè)模塊看成由幾個(gè)小程序組成,。必須對其中的每個(gè)小程序先進(jìn)行單元測試要做的工作，對關(guān)鍵模塊還要做性能測試,。
• 對支持某些標(biāo)準(zhǔn)規(guī)程的程序,，更要著手進(jìn)行互聯(lián)測試。有人把這種情況特別稱為模塊測試,，以區(qū)別單元測試。
集成測試（Integrated Testing）
• 集成測試 (集成測試,、聯(lián)合測試）
• 通常,，在單元測試的基礎(chǔ)上,，需要將所有模塊按照設(shè)計(jì)要求組裝成為系統(tǒng),。這時(shí)需要考慮的問題是：
– 在把各個(gè)模塊連接起來的時(shí)侯，穿越模塊接口的數(shù)據(jù)是否會丟失,；
– 一個(gè)模塊的功能是否會對另一個(gè)模塊的功能產(chǎn)生不利的影響,；
– 各個(gè)子功能組合起來，能否達(dá)到預(yù)期要求的父功能,；
– 全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題；
– 單個(gè)模塊的誤差累積起來,，是否會放大，從而達(dá)到不能接受的程度,。
在單元測試的同時(shí)可進(jìn)行集成測試,，
發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)
的問題，最終構(gòu)成要求的軟件系統(tǒng),。
• 子系統(tǒng)的集成測試特別稱為部件測試,，它所做的工作是要找出集成后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。
• 通常,，把模塊集成成為系統(tǒng)的方式有兩種
– 一次性集成方式
– 增殖式集成方式
1. 一次性集成方式(big bang)
• 它是一種非增殖式組裝方式,。也叫做整體拼裝,。
• 使用這種方式,，首先對每個(gè)模塊分別進(jìn)行模塊測試,，然后再把所有模塊組裝在一起進(jìn)行測試,，最終得到要求的軟件系統(tǒng)。
2. 增殖式集成方式
• 這種集成方式又稱漸增式集成
• 首先對一個(gè)個(gè)模塊進(jìn)行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)
• 在集成的過程中邊連接邊測試,，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題
• 通過增殖逐步組裝成為要求的軟件系統(tǒng),。
(1) 自頂向下的增殖方式
• 這種集成方式將模塊按系統(tǒng)程序結(jié)構(gòu),，沿控制層次自頂向下進(jìn)行組裝。
• 自頂向下的增殖方式在測試過程中較早地驗(yàn)證了主要的控制和判斷點(diǎn),。
• 選用按深度方向組裝的方式，可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能,。
(2) 自底向上的增殖方式
• 這種集成的方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始集成和測試,。
• 因?yàn)槟K是自底向上進(jìn)行組裝,，對于一個(gè)給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)組裝并測試完成，所以不再需要樁模塊,。在模塊的測試過程中需要從子模塊得到的信息可以直接運(yùn)行子模塊得到,。
• 自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點(diǎn),。
• 一般來講,，一種方式的優(yōu)點(diǎn)是另一種方式的缺點(diǎn),。
(3) 混合增殖式測試
• 衍變的自頂向下的增殖測試
– 首先對輸入／輸出模塊和引入新算法模塊進(jìn)行測試;
– 再自底向上組裝成為功能相當(dāng)完整且相對獨(dú)立的子系統(tǒng);
– 然后由主模塊開始自頂向下進(jìn)行增殖測試,。
• 自底向上-自頂向下的增殖測試
– 首先對含讀操作的子系統(tǒng)自底向上直至根結(jié)點(diǎn)模塊進(jìn)行組裝和測試;
– 然后對含寫操作的子系統(tǒng)做自頂向下的組裝與測試。
• 回歸測試
– 這種方式采取自頂向下的方式測試被修改的模塊及其子模塊;
– 然后將這一部分視為子系統(tǒng),，再自底向上測試,。
關(guān)鍵模塊問題
• 在組裝測試時(shí),，應(yīng)當(dāng)確定關(guān)鍵模塊，對這些關(guān)鍵模塊及早進(jìn)行測試,。
• 關(guān)鍵模塊的特征：
① 滿足某些軟件需求,；
② 在程序的模塊結(jié)構(gòu)中位于較高的層次（高層控制模塊）,；
③ 較復(fù)雜,、較易發(fā)生錯(cuò)誤；
④ 有明確定義的性能要求,。
確認(rèn)測試（Validation Testing）
• 確認(rèn)測試又稱有效性測試,。任務(wù)是驗(yàn)證軟件的功能和性能及其它特性是否與用戶的要求一致。
• 對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定,。它包含的信息就是軟件確認(rèn)測試的基礎(chǔ),。
1. 進(jìn)行有效性測試（黑盒測試）
• 有效性測試是在模擬的環(huán)境 (可能就是開發(fā)的環(huán)境) 下,，運(yùn)用黑盒測試的方法,，驗(yàn)證被測軟件是否滿足需求規(guī)格說明書列出的需求。
• 首先制定測試計(jì)劃,，規(guī)定要做測試的種類,。還需要制定一組測試步驟，描述具體的測試用例,。
• 通過實(shí)施預(yù)定的測試計(jì)劃和測試步驟,，確定
– 軟件的特性是否與需求相符；
– 所有的文檔都是正確且便于使用,；
– 同時(shí),，對其它軟件需求，例如可移植性,、兼容性,、出錯(cuò)自動恢復(fù)、可維護(hù)性等,，也都要進(jìn)行測試
• 在全部軟件測試的測試用例運(yùn)行完后,，所有的測試結(jié)果可以分為兩類：
– 測試結(jié)果與預(yù)期的結(jié)果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合,，從而這部分程序被接受,。
– 測試結(jié)果與預(yù)期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致,，因此要為它提交一份問題報(bào)告,。
2. 軟件配置復(fù)查
n 軟件配置復(fù)查的目的是保證
u 軟件配置的所有成分都齊全；
u 各方面的質(zhì)量都符合要求,；
u 具有維護(hù)階段所必需的細(xì)節(jié),；
u 而且已經(jīng)編排好分類的目錄。
n 應(yīng)當(dāng)嚴(yán)格遵守用戶手冊和操作手冊中規(guī)定的使用步驟,，以便檢查這些文檔資料的完整性和正確性,。
驗(yàn)收測試（Acceptance Testing）
• 在通過了系統(tǒng)的有效性測試及軟件配置審查之后,，就應(yīng)開始系統(tǒng)的驗(yàn)收測試。
• 驗(yàn)收測試是以用戶為主的測試,。軟件開發(fā)人員和QA（質(zhì)量保證）人員也應(yīng)參加,。
• 由用戶參加設(shè)計(jì)測試用例，使用生產(chǎn)中的實(shí)際數(shù)據(jù)進(jìn)行測試,。
• 在測試過程中,，除了考慮軟件的功能和性能外，還應(yīng)對軟件的可移植性,、兼容性,、可維護(hù)性、錯(cuò)誤的恢復(fù)功能等進(jìn)行確認(rèn),。
• 確認(rèn)測試應(yīng)交付的文檔有：
– 確認(rèn)測試分析報(bào)告
– 最終的用戶手冊和操作手冊
– 項(xiàng)目開發(fā)總結(jié)報(bào)告,。
系統(tǒng)測試（System Testing）
• 系統(tǒng)測試，是將通過確認(rèn)測試的軟件,，作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素,，與計(jì)算機(jī)硬件、外設(shè),、某些支持軟件,、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下,，對計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測試和確認(rèn)測試,。
• 系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較, 發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。
α測試和β測試
• 在軟件交付使用之后,，用戶將如何實(shí)際使用程序,，對于開發(fā)者來說是無法預(yù)測的。
• α測試是由一個(gè)用戶在開發(fā)環(huán)境下進(jìn)行的測試,，也可以是公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的測試,。
• α測試的目的是評價(jià)軟件產(chǎn)品的FLURPS（即功能、局域化,、可使用性,、可靠性、性能和支持）,。尤其注重產(chǎn)品的界面和特色,。
• α測試可以從軟件產(chǎn)品編碼結(jié)束之時(shí)開始，或在模塊（子系統(tǒng)）測試完成之后開始,，也可以在確認(rèn)測試過程中產(chǎn)品達(dá)到一定的穩(wěn)定和可靠程度之后再開始,。
• β測試是由軟件的多個(gè)用戶在實(shí)際使用環(huán)境下進(jìn)行的測試,。這些用戶返回有關(guān)錯(cuò)誤信息給開發(fā)者,。
• 測試時(shí)，開發(fā)者通常不在測試現(xiàn)場,。因而，β測試是在開發(fā)者無法控制的環(huán)境下進(jìn)行的軟件現(xiàn)場應(yīng)用,。
• 在β測試中,，由用戶記下遇到的所有問題，包括真實(shí)的以及主觀認(rèn)定的,，定期向開發(fā)者報(bào)告,。
• β測試主要衡量產(chǎn)品的FLURPS。著重于產(chǎn)品的支持性,，包括文檔,、客戶培訓(xùn)和支持產(chǎn)品生產(chǎn)能力。
• 只有當(dāng)α測試達(dá)到一定的可靠程度時(shí),，才能開始β測試,。它處在整個(gè)測試的最后階段。同時(shí),，產(chǎn)品的所有手冊文本也應(yīng)該在此階段完全定稿,。
測試類型
• 軟件測試是由一系列不同的測試組成,。主要目的是對以計(jì)算機(jī)為基礎(chǔ)的系統(tǒng)進(jìn)行充分的測試,。
功能測試
功能測試是在規(guī)定的一段時(shí)間內(nèi)運(yùn)行軟件系統(tǒng)的所有功能，以驗(yàn)證這個(gè)軟件系統(tǒng)有無嚴(yán)重錯(cuò)誤,。
強(qiáng)度測試
強(qiáng)度測試是要檢查在系統(tǒng)運(yùn)行環(huán)境不正常乃至發(fā)生故障的情況下,，系統(tǒng)可以運(yùn)行到何種程度的測試。例如：
– 把輸入數(shù)據(jù)速率提高一個(gè)數(shù)量級,，確定輸入功能將如何響應(yīng),。
– 設(shè)計(jì)需要占用最大存儲量或其它資源的測試用例進(jìn)行測試。
– 設(shè)計(jì)出在虛擬存儲管理機(jī)制中引起“顛簸”的測試用例進(jìn)行測試,。
– 設(shè)計(jì)出會對磁盤常駐內(nèi)存的數(shù)據(jù)過度訪問的測試用例進(jìn)行測試,。
• 強(qiáng)度測試的一個(gè)變種就是敏感性測試。在程序有效數(shù)據(jù)界限內(nèi)一個(gè)小范圍內(nèi)的一組數(shù)據(jù)可能引起極端的或不平穩(wěn)的錯(cuò)誤處理出現(xiàn),，或者導(dǎo)致極度的性能下降的情況發(fā)生,。此測試用以發(fā)現(xiàn)可能引起這種不穩(wěn)定性或不正常處理的某些數(shù)據(jù)組合。
性能測試
• 性能測試是要檢查系統(tǒng)是否滿足在需求說明書中規(guī)定的性能,。特別是對于實(shí)時(shí)系統(tǒng)或嵌入式系統(tǒng),。
• 性能測試常常需要與強(qiáng)度測試結(jié)合起來進(jìn)行，并常常要求同時(shí)進(jìn)行硬件和軟件檢測,。
• 通常,，對軟件性能的檢測表現(xiàn)在以下幾個(gè)方面：響應(yīng)時(shí)間、吞吐量,、輔助存儲區(qū),，例如緩沖區(qū),，工作區(qū)的大小等、處理精度,，等等,。
恢復(fù)測試
恢復(fù)測試是要證實(shí)在克服硬件故障(包括掉電、硬件或網(wǎng)絡(luò)出錯(cuò)等)后,，系統(tǒng)能否正常地繼續(xù)進(jìn)行工作,，并不對系統(tǒng)造成任何損害。
• 為此,，可采用各種人工干預(yù)的手段,，模擬硬件故障，故意造成軟件出錯(cuò),。并由此檢查：
– 錯(cuò)誤探測功能──系統(tǒng)能否發(fā)現(xiàn)硬件失效與故障,；
– 能否切換或啟動備用的硬件；
– 在故障發(fā)生時(shí)能否保護(hù)正在運(yùn)行的作業(yè)和系統(tǒng)狀態(tài),；
– 在系統(tǒng)恢復(fù)后能否從最后記錄下來的無錯(cuò)誤狀態(tài)開始繼續(xù)執(zhí)行作業(yè),，等等。
– 掉電測試：其目的是測試軟件系統(tǒng)在發(fā)生電源中斷時(shí)能否保護(hù)當(dāng)時(shí)的狀態(tài)且不毀壞數(shù)據(jù),，然后在電源恢復(fù)時(shí)從保留的斷點(diǎn)處重新進(jìn)行操作,。
配置測試
• 這類測試是要檢查計(jì)算機(jī)系統(tǒng)內(nèi)各個(gè)設(shè)備或各種資源之間的相互聯(lián)結(jié)和功能分配中的錯(cuò)誤。
• 它主要包括以下幾種：
– 配置命令測試：驗(yàn)證全部配置命令的可操作性（有效性）,；特別對最大配置和最小配置要進(jìn)行測試,。軟件配置和硬件配置都要測試。
– 循環(huán)配置測試：證明對每個(gè)設(shè)備物理與邏輯的,，邏輯與功能的每次循環(huán)置換配置都能正常工作,。
– 修復(fù)測試：檢查每種配置狀態(tài)及哪個(gè)設(shè)備是壞的。并用自動的或手工的方式進(jìn)行配置狀態(tài)間的轉(zhuǎn)換,。
安全性測試
安全性測試是要檢驗(yàn)在系統(tǒng)中已經(jīng)存在的系統(tǒng)安全性,、保密性措施是否發(fā)揮作用，有無漏洞,。
• 力圖破壞系統(tǒng)的保護(hù)機(jī)構(gòu)以進(jìn)入系統(tǒng)的主要方法有以下幾種：
– 正面攻擊或從側(cè)面,、背面攻擊系統(tǒng)中易受損壞的那些部分；
– 以系統(tǒng)輸入為突破口,，利用輸入的容錯(cuò)性進(jìn)行正面攻擊,；
– 申請和占用過多的資源壓垮系統(tǒng)，以破壞安全措施,，從而進(jìn)入系統(tǒng),；
– 故意使系統(tǒng)出錯(cuò)，利用系統(tǒng)恢復(fù)的過程，竊取用戶口令及其它有用的信息,；
– 通過瀏覽殘留在計(jì)算機(jī)各種資源中的垃圾（無用信息）,，以獲取如口令，安全碼,，譯碼關(guān)鍵字等信息,；
– 瀏覽全局?jǐn)?shù)據(jù)，期望從中找到進(jìn)入系統(tǒng)的關(guān)鍵字,；
– 瀏覽那些邏輯上不存在,，但物理上還存在的各種記錄和資料等。
可使用性測試
• 可使用性測試主要從使用的合理性和方便性等角度對軟件系統(tǒng)進(jìn)行檢查,，發(fā)現(xiàn)人為因素或使用上的問題,。
• 要保證在足夠詳細(xì)的程度下，用戶界面便于使用,；對輸入量可容錯(cuò),、響應(yīng)時(shí)間和響應(yīng)方式合理可行、輸出信息有意義,、正確并前后一致,；出錯(cuò)信息能夠引導(dǎo)用戶去解決問題；軟件文檔全面,、正規(guī),、確切。
安裝測試
安裝測試的目的不是找軟件錯(cuò)誤,，而是找安裝錯(cuò)誤,。
• 在安裝軟件系統(tǒng)時(shí),，會有多種選擇,。
– 要分配和裝入文件與程序庫
– 布置適用的硬件配置
– 進(jìn)行程序的聯(lián)結(jié)。
• 而安裝測試就是要找出在這些安裝過程中出現(xiàn)的錯(cuò)誤,。
• 安裝測試是在系統(tǒng)安裝之后進(jìn)行測試,。它要檢驗(yàn)：
– 用戶選擇的一套任選方案是否相容；
– 系統(tǒng)的每一部分是否都齊全,；
– 所有文件是否都已產(chǎn)生并確有所需要的內(nèi)容,；
– 硬件的配置是否合理，等等,。
容量測試
• 容量測試是要檢驗(yàn)系統(tǒng)的能力最高能達(dá)到什么程度,。例如，
– 對于編譯程序,，讓它處理特別長的源程序,；
– 對于操作系統(tǒng)，讓它的作業(yè)隊(duì)列“滿員”；
– 對于信息檢索系統(tǒng),，讓它使用頻率達(dá)到最大,。
在使系統(tǒng)的全部資源達(dá)到“滿負(fù)荷”的情形下，測試系統(tǒng)的承受能力,。
文檔測試
這種測試是檢查用戶文檔(如用戶手冊)的清晰性和精確性,。
• 用戶文檔中所使用的例子必須在測試中一一試過，確保敘述正確無誤,。
自動測試
• 認(rèn)識自動測試
• 什么時(shí)候使用自動測試
