軟件測試步驟
•    測試過程按4個步驟進行，即單元測試、集成測試、確認測試和系統(tǒng)測試及發(fā)版測試。
•    開始是單元測試，集中對用源代碼實現(xiàn)的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。 
•     集成測試把已測試過的模塊組裝起來，主要對與設計相關的軟件體系結構的構造進行測試。
•     確認測試則是要檢查已實現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求，以及軟件配置是否完全、正確。
•     系統(tǒng)測試把已經(jīng)經(jīng)過確認的軟件納入實際運行環(huán)境中，與其它系統(tǒng)成份組合在一起進行測試。
單元測試 (Unit Testing)
•     單元測試又稱模塊測試，是針對軟件設計的最小單位 ─ 程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。
•     單元測試需要從程序的內(nèi)部結構出發(fā)設計測試用例。多個模塊可以平行地獨立進行單元測試。
1. 單元測試的內(nèi)容
•     在單元測試時，測試者需要依據(jù)詳細設計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結構，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應。 

(1) 模塊接口測試
•    在單元測試的開始，應對通過被測模塊的數(shù)據(jù)流進行測試。測試項目包括：
–   調用本模塊的輸入?yún)?shù)是否正確；
–   本模塊調用子模塊時輸入給子模塊的參數(shù)是否正確；
–   全局量的定義在各模塊中是否一致；

•     在做內(nèi)外存交換時要考慮： 
–   文件屬性是否正確；
–   OPEN與CLOSE語句是否正確；
–   緩沖區(qū)容量與記錄長度是否匹配；
–   在進行讀寫操作之前是否打開了文件；
–   在結束文件處理時是否關閉了文件；
–   正文書寫／輸入錯誤，
–   I／O錯誤是否檢查并做了處理。

(2) 局部數(shù)據(jù)結構測試
•     不正確或不一致的數(shù)據(jù)類型說明
•     使用尚未賦值或尚未初始化的變量
•     錯誤的初始值或錯誤的缺省值
•     變量名拼寫錯或書寫錯
•     不一致的數(shù)據(jù)類型
•     全局數(shù)據(jù)對模塊的影響

(3) 路徑測試
•    選擇適當?shù)臏y試用例，對模塊中重要的執(zhí)行路徑進行測試。
•    應當設計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。
•    對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。

(4) 錯誤處理測試
•     出錯的描述是否難以理解
•     出錯的描述是否能夠對錯誤定位
•     顯示的錯誤與實際的錯誤是否相符
•     對錯誤條件的處理正確與否
•     在對錯誤進行處理之前，錯誤條件是否已經(jīng)引起系統(tǒng)的干預等

(5) 邊界測試
•     注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。
•     如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。
 
2. 單元測試的步驟
•    模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。
–   驅動模塊 (driver)
–   樁模塊 (stub) ── 存根模塊   
•      如果一個模塊要完成多種功能，可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作，對關鍵模塊還要做性能測試。
•      對支持某些標準規(guī)程的程序，更要著手進行互聯(lián)測試。有人把這種情況特別稱為模塊測試，以區(qū)別單元測試。
集成測試（Integrated Testing）
•     集成測試 (集成測試、聯(lián)合測試）
•     通常，在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統(tǒng)。這時需要考慮的問題是：
–   在把各個模塊連接起來的時侯，穿越模塊接口的數(shù)據(jù)是否會丟失；
–   一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；
–   各個子功能組合起來，能否達到預期要求的父功能；
–   全局數(shù)據(jù)結構是否有問題；
–   單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。
在單元測試的同時可進行集成測試，
發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)
的問題，最終構成要求的軟件系統(tǒng)。

•    子系統(tǒng)的集成測試特別稱為部件測試，它所做的工作是要找出集成后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。
•    通常，把模塊集成成為系統(tǒng)的方式有兩種
–   一次性集成方式
–   增殖式集成方式

1. 一次性集成方式(big bang)
•    它是一種非增殖式組裝方式。也叫做整體拼裝。
•    使用這種方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統(tǒng)。
  
2. 增殖式集成方式
•     這種集成方式又稱漸增式集成
•     首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)
•     在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題
•     通過增殖逐步組裝成為要求的軟件系統(tǒng)。

(1) 自頂向下的增殖方式
•      這種集成方式將模塊按系統(tǒng)程序結構，沿控制層次自頂向下進行組裝。
•      自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。
•      選用按深度方向組裝的方式，可以首先實現(xiàn)和驗證一個完整的軟件功能。
  
(2) 自底向上的增殖方式
•     這種集成的方式是從程序模塊結構的最底層的模塊開始集成和測試。
•     因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。
  
•    自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點。
•    一般來講，一種方式的優(yōu)點是另一種方式的缺點。
(3) 混合增殖式測試
•    衍變的自頂向下的增殖測試
–   首先對輸入／輸出模塊和引入新算法模塊進行測試;
–   再自底向上組裝成為功能相當完整且相對獨立的子系統(tǒng);
–   然后由主模塊開始自頂向下進行增殖測試。
  
•    自底向上-自頂向下的增殖測試
–   首先對含讀操作的子系統(tǒng)自底向上直至根結點模塊進行組裝和測試;
–   然后對含寫操作的子系統(tǒng)做自頂向下的組裝與測試。
•    回歸測試
–   這種方式采取自頂向下的方式測試被修改的模塊及其子模塊;
–   然后將這一部分視為子系統(tǒng)，再自底向上測試。
關鍵模塊問題
•     在組裝測試時，應當確定關鍵模塊，對這些關鍵模塊及早進行測試。
•     關鍵模塊的特征：
① 滿足某些軟件需求；
② 在程序的模塊結構中位于較高的層次（高層控制模塊）；
③ 較復雜、較易發(fā)生錯誤；
④ 有明確定義的性能要求。


確認測試（Validation Testing）
•    確認測試又稱有效性測試。任務是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。
•    對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認測試的基礎。
  
1. 進行有效性測試（黑盒測試）
•     有效性測試是在模擬的環(huán)境 (可能就是開發(fā)的環(huán)境) 下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。
•     首先制定測試計劃，規(guī)定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。
  
•    通過實施預定的測試計劃和測試步驟，確定
–   軟件的特性是否與需求相符；
–   所有的文檔都是正確且便于使用；
–   同時，對其它軟件需求，例如可移植性、兼容性、出錯自動恢復、可維護性等，也都要進行測試
  
•     在全部軟件測試的測試用例運行完后，所有的測試結果可以分為兩類：
–   測試結果與預期的結果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受。
–   測試結果與預期的結果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報告。

2. 軟件配置復查
n       軟件配置復查的目的是保證
u  軟件配置的所有成分都齊全；
u  各方面的質量都符合要求；
u  具有維護階段所必需的細節(jié)；
u  而且已經(jīng)編排好分類的目錄。
n  應當嚴格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。
驗收測試（Acceptance Testing）
•     在通過了系統(tǒng)的有效性測試及軟件配置審查之后，就應開始系統(tǒng)的驗收測試。
•     驗收測試是以用戶為主的測試。軟件開發(fā)人員和QA（質量保證）人員也應參加。
•     由用戶參加設計測試用例，使用生產(chǎn)中的實際數(shù)據(jù)進行測試。
  
•    在測試過程中，除了考慮軟件的功能和性能外，還應對軟件的可移植性、兼容性、可維護性、錯誤的恢復功能等進行確認。
•     確認測試應交付的文檔有：
–   確認測試分析報告
–   最終的用戶手冊和操作手冊
–   項目開發(fā)總結報告。

系統(tǒng)測試（System Testing）
•     系統(tǒng)測試，是將通過確認測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認測試。
•     系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較,  發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。

α測試和β測試
•    在軟件交付使用之后，用戶將如何實際使用程序，對于開發(fā)者來說是無法預測的。
•    α測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進行的測試。 
•     α測試的目的是評價軟件產(chǎn)品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。尤其注重產(chǎn)品的界面和特色。
•     α測試可以從軟件產(chǎn)品編碼結束之時開始，或在模塊（子系統(tǒng)）測試完成之后開始，也可以在確認測試過程中產(chǎn)品達到一定的穩(wěn)定和可靠程度之后再開始。


  
•     β測試是由軟件的多個用戶在實際使用環(huán)境下進行的測試。這些用戶返回有關錯誤信息給開發(fā)者。
•     測試時，開發(fā)者通常不在測試現(xiàn)場。因而，β測試是在開發(fā)者無法控制的環(huán)境下進行的軟件現(xiàn)場應用。
•     在β測試中，由用戶記下遇到的所有問題，包括真實的以及主觀認定的，定期向開發(fā)者報告。  
•    β測試主要衡量產(chǎn)品的FLURPS。著重于產(chǎn)品的支持性，包括文檔、客戶培訓和支持產(chǎn)品生產(chǎn)能力。
•    只有當α測試達到一定的可靠程度時，才能開始β測試。它處在整個測試的最后階段。同時，產(chǎn)品的所有手冊文本也應該在此階段完全定稿。
測試類型
•    軟件測試是由一系列不同的測試組成。主要目的是對以計算機為基礎的系統(tǒng)進行充分的測試。
功能測試
  功能測試是在規(guī)定的一段時間內(nèi)運行軟件系統(tǒng)的所有功能，以驗證這個軟件系統(tǒng)有無嚴重錯誤。
  
強度測試
  
  強度測試是要檢查在系統(tǒng)運行環(huán)境不正常乃至發(fā)生故障的情況下，系統(tǒng)可以運行到何種程度的測試。例如：
–   把輸入數(shù)據(jù)速率提高一個數(shù)量級，確定輸入功能將如何響應。
–   設計需要占用最大存儲量或其它資源的測試用例進行測試。
  
–   設計出在虛擬存儲管理機制中引起“顛簸”的測試用例進行測試。
–   設計出會對磁盤常駐內(nèi)存的數(shù)據(jù)過度訪問的測試用例進行測試。
•     強度測試的一個變種就是敏感性測試。在程序有效數(shù)據(jù)界限內(nèi)一個小范圍內(nèi)的一組數(shù)據(jù)可能引起極端的或不平穩(wěn)的錯誤處理出現(xiàn)，或者導致極度的性能下降的情況發(fā)生。此測試用以發(fā)現(xiàn)可能引起這種不穩(wěn)定性或不正常處理的某些數(shù)據(jù)組合。

 
性能測試
•     性能測試是要檢查系統(tǒng)是否滿足在需求說明書中規(guī)定的性能。特別是對于實時系統(tǒng)或嵌入式系統(tǒng)。
•     性能測試常常需要與強度測試結合起來進行，并常常要求同時進行硬件和軟件檢測。
•     通常，對軟件性能的檢測表現(xiàn)在以下幾個方面：響應時間、吞吐量、輔助存儲區(qū)，例如緩沖區(qū)，工作區(qū)的大小等、處理精度，等等。
  
恢復測試
  恢復測試是要證實在克服硬件故障(包括掉電、硬件或網(wǎng)絡出錯等)后，系統(tǒng)能否正常地繼續(xù)進行工作，并不對系統(tǒng)造成任何損害。
•     為此，可采用各種人工干預的手段，模擬硬件故障，故意造成軟件出錯。并由此檢查：
–   錯誤探測功能──系統(tǒng)能否發(fā)現(xiàn)硬件失效與故障；
  
–   能否切換或啟動備用的硬件；
–   在故障發(fā)生時能否保護正在運行的作業(yè)和系統(tǒng)狀態(tài)；
–   在系統(tǒng)恢復后能否從最后記錄下來的無錯誤狀態(tài)開始繼續(xù)執(zhí)行作業(yè)，等等。
–   掉電測試：其目的是測試軟件系統(tǒng)在發(fā)生電源中斷時能否保護當時的狀態(tài)且不毀壞數(shù)據(jù)，然后在電源恢復時從保留的斷點處重新進行操作。

  
配置測試
  
•     這類測試是要檢查計算機系統(tǒng)內(nèi)各個設備或各種資源之間的相互聯(lián)結和功能分配中的錯誤。
•     它主要包括以下幾種：
–   配置命令測試：驗證全部配置命令的可操作性（有效性）；特別對最大配置和最小配置要進行測試。軟件配置和硬件配置都要測試。

–   循環(huán)配置測試：證明對每個設備物理與邏輯的，邏輯與功能的每次循環(huán)置換配置都能正常工作。
–   修復測試：檢查每種配置狀態(tài)及哪個設備是壞的。并用自動的或手工的方式進行配置狀態(tài)間的轉換。
  
安全性測試
  安全性測試是要檢驗在系統(tǒng)中已經(jīng)存在的系統(tǒng)安全性、保密性措施是否發(fā)揮作用，有無漏洞。
•     力圖破壞系統(tǒng)的保護機構以進入系統(tǒng)的主要方法有以下幾種：
–   正面攻擊或從側面、背面攻擊系統(tǒng)中易受損壞的那些部分；
–   以系統(tǒng)輸入為突破口，利用輸入的容錯性進行正面攻擊；

–   申請和占用過多的資源壓垮系統(tǒng)，以破壞安全措施，從而進入系統(tǒng)；
–   故意使系統(tǒng)出錯，利用系統(tǒng)恢復的過程，竊取用戶口令及其它有用的信息；
–   通過瀏覽殘留在計算機各種資源中的垃圾（無用信息），以獲取如口令，安全碼，譯碼關鍵字等信息；
–   瀏覽全局數(shù)據(jù)，期望從中找到進入系統(tǒng)的關鍵字；
–   瀏覽那些邏輯上不存在，但物理上還存在的各種記錄和資料等。
  
可使用性測試
  
•     可使用性測試主要從使用的合理性和方便性等角度對軟件系統(tǒng)進行檢查，發(fā)現(xiàn)人為因素或使用上的問題。
•     要保證在足夠詳細的程度下，用戶界面便于使用；對輸入量可容錯、響應時間和響應方式合理可行、輸出信息有意義、正確并前后一致；出錯信息能夠引導用戶去解決問題；軟件文檔全面、正規(guī)、確切。
  
安裝測試
  安裝測試的目的不是找軟件錯誤，而是找安裝錯誤。
•    在安裝軟件系統(tǒng)時，會有多種選擇。
–   要分配和裝入文件與程序庫
–   布置適用的硬件配置
–   進行程序的聯(lián)結。
•    而安裝測試就是要找出在這些安裝過程中出現(xiàn)的錯誤。
  
  
•    安裝測試是在系統(tǒng)安裝之后進行測試。它要檢驗：
–   用戶選擇的一套任選方案是否相容；
–   系統(tǒng)的每一部分是否都齊全；
–   所有文件是否都已產(chǎn)生并確有所需要的內(nèi)容；
–   硬件的配置是否合理，等等。

  
容量測試
  
•      容量測試是要檢驗系統(tǒng)的能力最高能達到什么程度。例如，
–    對于編譯程序，讓它處理特別長的源程序；
–    對于操作系統(tǒng)，讓它的作業(yè)隊列“滿員”；
–    對于信息檢索系統(tǒng)，讓它使用頻率達到最大。
  在使系統(tǒng)的全部資源達到“滿負荷”的情形下，測試系統(tǒng)的承受能力。

  
文檔測試
  
  這種測試是檢查用戶文檔(如用戶手冊)的清晰性和精確性。
•    用戶文檔中所使用的例子必須在測試中一一試過，確保敘述正確無誤。
  
自動測試
•     認識自動測試
•     什么時候使用自動測試