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