引言

軟件測試按測試用例設計(TEST CASE DESIGN)方法分為白盒測試(WHITE-BOX TESTING)和黑盒測試(BLACK-BOX TESTING)。 按測試過程或測試策略，軟件測試分為單元測試(UNIT TESTING)，集成測試（INTEGRATION TESTING〕，確認測試（VALIDATION TESTING〕和系統測試（SYSTEM TESTING〕。在以前的有關文檔中，我們已經對白盒和黑盒測試中的測試用例設計方法進行了詳細的講解。同時也對單元測試進行了講解和培訓。本文將從測試策略方面講解軟件測試中的集成測試，確認測試和系統測試策略。

軟件測試的 策略方法

測試是一系列有計劃地系統性的活動。為了實行測試活動，人們提出了許多測試策略方法。

一個軟件測試策略不僅要包括低層測試（LOW LEVEL TESTING〕而且要包含高層測試〔HIGH LEVEL TESTING〕。低層測試是為了驗證原代碼的正確性。高層測試是為了證實主要系統功能滿足用戶需求性。

驗證與確認（VERFICATION AND VALIDATION〕

在廣義上，軟件測試是驗證和確認VERFICATION AND VALIDATION （V﹠V〕。驗證指保證軟件正確地實現了一特定功能的一系列活動。確認是指保證所生產的軟件可追溯到用戶需求的一系列活動。BOEHM對V﹠V的解釋是：

VEIFICATION：“Are we building the product right?”

VALIDATION: “ Are we building the right product?”

V&V的定義包含了許多活動，即軟件質量保證SQA。圖2-1 示出實現軟件質量的這些活動。軟件工程方法提供了質量建立的基礎。分析、設計和編碼方法通過提供統一的技術和可預測的結果來提高質量。正規檢視和評審有助于保證軟件工程各個階段產品的質量。度量和控制被應用到軟件配置的每一個部件中。標準和過程有助于保證開發的一致性。一個正規的 SQA過程加強整體質量。測試是保證質量的最后一道措施。但是不能把測試看作一個安全網。質量是貫穿于軟件過程的每一個階段。因此盡管測試在V&V中起著非常重要的作用，但是許多其它活動也是必要的。為了提高軟件的全員質量，應該重視V&V中的每一個活動.

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

軟件質量

軟件工程

方法

標準和步驟

正規檢視與評審

度量

測試

SQA

SCM

圖2-1 實現軟件質量的活動

軟件測試策略

軟件工程過程可以看成一螺旋狀。軟件測試策略也可以看成一螺旋狀。如圖2-2示測試策略圖。

從圖2-2可看出軟件測試策略: 起始于代碼階段的單元測試，然后是向外延伸到設計階段的集成測試，再擴展到需求分析階段的確認測試，最后是系統工程階段的系統測試。從系統過程的角度看，測試策略有四個步驟：單元測試，集成測

試,確認測試和系統測試。圖2-3示軟件測試步驟。

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

單元測試

測試方向

代碼

集成測試

高階測試

High-order Test

Integration Test 設計

需求

圖2-3 軟件測試步驟

從圖2-3可看出，初始測試集中在每個模塊上，由于每個模塊完成一個功能單元，因此該階段的測試稱為單元測試。單元測試主要應用白盒測試方法。接下來是模塊組裝和集成以便組成完整的軟件包。集成測試集中在證實和程序構成問題上，集成測試主要采用黑盒測試方法，附之以白盒測試方法。軟件集成后，需要完成一系列高階測試（確認和系統測試〕。確認標準必須被測試。確認測試提供軟件滿足所有功能、性能需求的最后保證。確認測試僅僅應用黑盒測試用例設

計方法。

測試完成的標準

軟件測試中，人們經常會提出這樣的問題：“什么時候測試完成？－－怎樣知道測試足夠充分？”。很遺憾，對該問題還沒有一個確定的答案，但是可提供一些統計和經驗上的答案或指導。為了確定何時算測試進行的足夠充分，軟件工程師需要更嚴格的標準。MUSA和ACKERMAN建議基于統計準則來回答這些問題。應用統計模型和軟件可靠性理論，軟件失效/故障（測試中未發現的〕的模型可以以執行時間函數形式建立。例如，一個軟件故障模型，稱為對數泊松執行時間模型。有關軟件可靠性和軟件測試強度方面的知識和模型建立將在以后相關文檔

中介紹。

單元測試（UNIT TESTING)

單元測試是基于程序模塊進行正確性驗證的測試。這方面的內容，我們已經準備出了充分的資料，并進行了多期培訓。因此這里將不在講述。

集成測試（INTEGRATION TESTING〕

集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求）如根據結構圖〕組裝成為子系統或系統，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現。也就是應該考慮以下問題：

（1〕在把各個模塊連接起來的時候，穿越模塊接口的數據是否會丟失；

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

（2〕各個子功能組合起來，能否達到預期要求的父功能；

（3〕一個模塊的功能是否會對另一個模塊的功能產生不利的影響；

（4）全局數據結構是否有問題；

（5〕單個模塊的誤差積累起來，是否會放大，從而達到不可接受的程度。

因此，單元測試后，有必要進行集成測試，發現并排除在模塊連接中可能發生的上述問題，最終構成要求的軟件子系統或系統。對子系統，集成測試也叫部件測試。任何合理地組織集成測試，即選擇什么方式把模塊組裝起來形成一個可運行的系統,直接影響到模塊測試用例的形式、所用測試工具的類型、模塊編號和測試的次序、生成測試用例和調試的費用。通常，有兩種不同的組裝方式：一次性組裝方式和增值式組裝方式。

一次性組裝方式（BIG BANG〕

一次性組裝方式是一種非增值組裝方式（NON－INCREMENTAL INTEGRATION〕，也叫整體拼裝。按這種組裝方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統。例如，有一塊系統結構，如圖4-1(a)所示。其單元測試和組裝順序如圖4-1(b)所示。

A

B C D

E F

d1 d2 d3 d4 d5

D B C

s1 s2

E F

A A

B C D

F E

s3 s4 s5

(a)

(b)

圖4-1 一次性組裝方式

在圖中，模塊d1,d2,d3,d4,d5是對各個模塊做單元測試時建立的驅動模塊，s1,s2,s3,s4,s5是為單元測試而建立的樁模塊。這種一次性組裝方式試圖在輔助模塊的協助下，在模塊單元測試的基礎上，將所測模塊連接起來進行測試。但是由于程序中不可避免地存在模塊間接口、全局數據結構等方面的問題，所以一次試運行成功的可能性并不很大。其結果發現有錯誤，但茫然找不到原因。查錯和改錯都會遇到困難。

增殖式組裝方式(Incremental Integration)

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

增值式組裝方式又稱漸增式組裝。首先是對一個個模塊進行模塊單元測試，然后將這些模塊組裝成較大系統，在組裝的過程中邊連接邊測試，以發現連接過程中產生的問題。最后增殖逐步組裝成為要求的軟件系統。

自頂向下的增殖方式(Top-Down Integration)

這種組裝方式是將模塊按系統程序結構，沿控制層次自頂向下進行組裝。其步驟如下：

(1)以主模塊為所測模塊兼驅動模塊，所有直屬于主模塊的下屬模塊全部用樁模塊對主模塊進行測試。

(2)采用深度優先(depth-first)(如圖4-2）或寬度優先(breadth-first)的策略，用實際模塊替換相應樁模塊，再用樁代替它們的直接下屬模塊，與已測試的模塊或子系統組裝成新的子系統。

(3)進行回歸測試（即重新執行以前做過的全部測試或部分測試），排除組裝過程中引起的錯誤的可能。

(4)判斷是否所有的模塊都已組裝到系統中？是則結束測試，否則轉到(2)去執行。

A A A A

s1 s2 s3

s4

s2 s2 s3 s3 B B B

E E

C s3

測試A 加入B 加入E 加入C

A

B C D

E s5

A

B C D

E F

加入D 加入F

按深度方向組裝

圖4-2 自頂向下增殖方式（按深度方向組裝)

自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。在一個功能劃分合理的程序模塊結構中，判斷常常出現在較高的層次里，因而較早就能遇到。如果這主要控制有問題，盡早發現它能夠減少以后的返工，所以這是十分必要的。如果選用按深度方向組裝的方式，可以首先實現和驗證一個完整的軟件功能，可先對邏輯輸入的分支進行組裝和測試，檢查和克服潛藏的錯誤和缺陷，驗證其功能的正確性，就為其后對主要加工分支的組裝和測試提供了保證。此外，功能可行性較早得到證實，還能夠給開發者和用戶帶來成功的信心。自頂各下的組裝和測試存在一個邏輯次序問題。在為了充分測試較高層的處理而需要較低層

處理的信息時，就會出現這類問題。在自頂向下組裝階段，還需要用樁模塊代替較低層的模塊，

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

所以關于樁模塊的編寫，根據情況可能不同有如下圖4-3所示的幾種選擇。

樁模塊stub 樁模塊stub 樁模塊stub 樁模塊stub

A B C D

顯示跟蹤信息顯示傳遞的信息從一個表(或外部文件)返回一個值進行一項表查詢以根據輸入參數返回輸出參數表示傳遞的數據消息

圖4-3 樁模塊的幾種選擇

為了能夠準確地實施測試，應當讓樁模塊正確而有效地模擬子模塊的功能和合理的接口，不能是只包含返回語句或只顯示該模塊已調用信息，不執行任何功能的啞模塊。如果不能使樁模塊正確地向上傳遞有用的信息，可以采用以下解決辦法。

(1)將很多測試推遲到樁模塊用實際模塊替代了之后進行；

(2)進一步開發能模擬實際模塊功能的樁模塊；

(3)自底向上組裝和測試軟件；

自底向上的增殖方式

這種組裝的方式是從程序模塊結構的最底層的模塊開始組裝和測試。因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊(包括子模塊的所有下屬模塊)已經組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。自底向上增殖的步驟如下：

(1)由驅動模塊控制最底層模塊的并行測試；也可以把最底層模塊組合成實現某一特定軟件功能的簇，由驅動模塊控制它進行測試。

(2)用實際模塊代替驅動模塊，與它已測試的直屬子模塊組裝成為子系統。

(3)為子系統配備驅動模塊，進行新的測試。

(4)判斷是否已組裝到達主模塊。是則結束測試，否則執行(2)。

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

以圖4-1(a)所示的系統結構為例，用下圖4-4來說明自底向上組裝和測試的順序。

d1 d2 d3 d4 d5

E E

C C F D D B B E

F F

A

圖4-4 自底向上增值組裝方式

自底向上進行組裝和測試時，需要為所測模塊或子系統編制相應的驅動模塊。常見的幾種類

型的驅動模塊如圖4-5所示：

驅動程序driver 驅動程序driver 驅動程序driver 驅動程序driver

A B C D

調用從屬模塊

從表(或外部文件)

中傳送參數

顯示參數兼有驅動程序B、

C的功能

圖4-5 驅動模塊的幾種選擇

表示傳送的參數信息

隨著組裝層次的向上移動，驅動模塊將大為減少。如果對程序模塊結構的最上面兩層模塊采

用自頂向下進行組裝和測試，可以明顯地減少驅動模塊的數目，而且可以大大減少把幾個系統組

裝起來所需要做的工作。

混合增殖式測試

自頂向下增殖的方式和自底向上增殖的方式各有優缺點。一般來講，一種方式的優點是另一

種方式的缺點。

自頂向下增殖方式的缺點是需要建立樁模塊。要使樁模塊能夠模擬實際子模塊的功能十分困

難，因為樁模塊在接收了所測模塊發送的信息后需要按照它所代替的實際子模塊功能返回應該回

送的信息，這必將增加建立樁模塊的復雜度，而且導致增加一些附加的測試。同時涉及復雜算法

和真正輸入/輸出的模塊一般在底層，它們是最容易出問題的模塊，到組裝和測試的后期才遇到這

些模塊，一旦發現問題，導致過多的回歸測試，而自頂向下增殖方式的優點能夠較早地發現在主

要控制方面的問題。

自底向上增殖方式的缺點是“程序一直未能作為一個實體存在，直到最后一個模塊加上去后

才形成一個實體”。就是說，在自底向上組裝和測試的過程中，對主要的控制直到最后才接觸

到。但這種方式的優點是不需要樁模塊，而建立驅動模塊一般比建立樁模塊容易，同時由于涉及

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

到復雜算法和真正輸入/輸出的模塊最先得到組裝和測試，可以把最容易出問題的部分在早期解

決。此外自底向上增殖的方式可以實施多個模塊的并行測試，提高測試效率。因此，通常是把以

上兩種方式結合起來進行組裝和測試。下面簡單介紹三種常見的綜合的增殖方式。

(1)衍變的自頂向下的增殖測試：它的基本思想是強化對輸入/輸出模塊的和引入新算法模塊

的測試，并自底向上組裝成為功能相當完整且相對獨立的子系統，然后由主模塊開始自頂向下進

行增殖測試。

(2)自底向上-自頂向下的增殖測試：它首先對含讀操作的子系統自底向上直至根結點模塊進

行組裝和測試，然后對含寫操作的子系統做自頂向下的組裝與測試。

(3)回歸測試：這種方式采取自頂向下的方式測試所修改的模塊及其子模塊，然后將這一部

分視為子系統，再自底向上測試，以檢查該子系統與其上級模塊的接口是否適配。

在組裝測試時，測試者應當確定關鍵模塊，對這些關鍵模塊及早進行測試。關鍵模塊至少應

具有以下幾種特征之一：(1)滿足某些軟件需求；(2)在程序的模塊結構中位于較高的層次(高層控制

模塊)；(3)較復雜、較易發生錯誤；(4)有明確定義的性能要求。

在做回歸測試時，也應該集中測試關鍵模塊的功能。

集成測試的組織和實施

集成測試是一種正規測試過程，必須精心計劃，并與單元測試的完成時間協調起來。在制定

測試計劃時，應考慮如下因素：

1)是采用何種系統組裝方法來進行組裝測試；

2)組裝測試過程中連接各個模塊的順序；

3)模塊代碼編制和測試進度是否與組裝測試的順序一致

4)測試過程中是否需要專門的硬件設備；

解決了上述問題之后，就可以列出各個模塊的編制、測試計劃表，標明每個模塊單元測試完成的日期、首次集成測試的日期、集成測試全部完成的日期、以及需要的測試用例和所期望的測試結果。在缺少軟件測試所需要的硬件設備時，應檢查該硬件的交付日期是否與集成測試計劃一致。例如，若測試需要數字化儀和繪圖儀，則相應測試應安排在這些設備能夠投入使用之時，并需要為硬件的安裝和交付使用保留一段時間，以留下時間余量。此外，在測試計劃中需要考慮測試所

需軟件（驅動模塊、樁模塊、測試用例生成程序等）的準備情況。

集成測試完成的標志

怎樣判定集成測試過程完成了, 可按以下幾個方面檢查:

1)成功地執行了測試計劃中規定的所有集成測試；

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

2)修正了所發現的錯誤；

3)測試結果通過了專門小組的評審。

集成測試應由專門的測試小組來進行，測試小組由有經驗的系統設計人員和程序員組成。整個測試活動要在評審人員出席的情況下進行。在完成預定的組裝測試工作之后，測試小組應負責對測試結果進行整理、分析，形成測試報告。測試報告中要記錄實際的測試結果、在測試中發現的問題、解決這些問題的方法以及解決之后再次測試的結果。此外還應提出目前不能解決、還需要管理人員和開發人員注意的一些問題，提供測試評審和最終決策，以提出處理意見。集成測試需要提交的文檔有：集成測試計劃、集成測試規格說明、集成測試分析報告。

確認測試(Validation Testing)

確認測試又稱為效性測試。它的任務是驗證軟件的功能和性能及其特性是否與用戶的要求一致。對軟件的功能和性能要求在軟件需求規格說明中已經明確規定。在軟件需求規格說明中描述了全部用戶可見的軟件屬性，其中有一節叫做有效性準則，它包含的信息就是軟件確認測試的基礎。集成測試完成以后，分散開發的模塊被聯接起來，構成完整的程序。其中各模塊之間接口存在的種種問題都已消除。于是測試工作進入最后階段--確認測試(Validation testing)。什么是確認測

試，說法眾多，其中最簡明、最嚴格的解釋是檢驗所開發的軟件是否能按顧客提出的要求運行。若能達到這一要求，則認為開發的軟件是合格的。因而有的軟件開發部門把確認測試稱為合格性

測試(qualification testing)。這里所說的顧客要求通常指的是在軟件規格說明書中確定的軟件功能和技術指標，或是專門為測試所規定的確認準則。在確認測試階段需要做的工作如下圖5-1所示。首先要進行有效性測試以及軟件配置復審，然后進行驗收測試和安裝測試，在通過了專家鑒定之后，才能成為可交付的軟件。選擇測試人員

構造測試用例

實際運行測試

軟件計劃

用戶文檔

開發文檔

源程序文本

支持環境

測試報告

軟件配置

有效性

測試

軟件

配置

審查

管理

機構

裁決

專家鑒定會

交用戶

運行維護

圖5-1 確認測試的步驟

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

確認測試的準則

怎樣來判斷被開發的軟件是成功的？為了確認它的功能、性能以及限制條件是否達到了要求，應進行怎樣的測試？在需求規格說明書中可能作了原則性規定，但在測試階段需要更詳細、更具體地在測試規格說明書(Test specification)中作進一步說明。例如，制定測試計劃時，要說明確認測試應測試哪些方面，并給出必要的測試用例。除了考慮功能、性能以外，還需檢驗其它方面的要求。例如，可移植性、兼容性、可維護性、人機接口以及開發的文件資料等是否符合要求。經過確認測試，應該為已開發的軟件作出結論性評價。這也無非是兩種情況之中的一個：

（1）經過檢驗的軟件功能、性能及其它要求均已滿足需求規格說明書的規定，因而可被接受。認為是合格的軟件。（2）經過檢驗發現與需求說明書有相當的偏離，得到一個各項缺陷清單。對于第二種情況，往往很難在交付期以前把發現的問題糾正過來。這就需要開發部門和顧客進行協商，找出解決的辦法。

進行有效性測試（黑盒測試）

有效性測試是在模擬的環境（可能是就是開發的環境）下，運用黑盒測試的方法，驗證所測試件是否滿足需求規格說明書列出的需求。為此，需要首先制定測試計劃，規定要做測試的種類，還需要制定一組測試步驟，描述具體的測試用例。通過實施預定的測試計劃和測試步驟，確定軟件的特性是否與需求相符，確保所有的軟件功能需求都能得到滿足，所有的軟件性能需求能達到，所有的文檔都是正確且便于使用。同時，對其他軟件需求，例如可移植性、兼容性，自動恢復、可維護性等，也都要進行測試，確認是否滿足。在全部軟件測試的測試用例運行完后，所有的測試結果可以分為兩類：

1)測試結果與預期的結果相符。這說明軟件的這部分功能或性能特征與需求規格說明一致，因此要為它提交一份問題報告。

2)測試結果與預期的結果不符。這說明軟件的這部分功能或性能特征與需求規格說明不一致，因此要為它提交一份問題報告。

軟件配置審查

軟件配置審查是確認測試過程的重要環節. 其的目的是保證軟件配置的所有成分都齊全，各方面的質量都符合要求，維護階段所必需的細節，而且已經編排好分類的目錄。除了按合同規定的內容和要求，由工人審查軟件配置之外，在確認測試的過程，應當嚴格遵守用戶手冊和操作手冊中規定的使用步驟，以便檢查這些文檔資料的完整性和正確性。必須仔細記錄發現的遺漏和錯誤，并且適當地補充和改正。

α測試和β測試

在軟件交付使用之后，用戶將如何實際使用程序，對于開發者來說是無法預測的。因為用戶在使用過程中常常會發生對使用方法的誤解、異常的數據組合，以及產生對某些用戶來說似乎是清晰的但對另一些用戶來說卻難以理解的輸出等等。

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

當軟件是為特定用戶開發的時候，需要進行一系列的驗收，讓用戶驗證所有的需求是否已經滿足。這些測試是以用戶為主，而不是以系統開發者為主進行的。驗收測試可以是一次簡單的非正式的“測試運行”。也可以是一組復雜的有組織有計劃的測試活動。事實上，驗收測試可能持續幾個星期到幾個月。但是如果軟件是為多個用戶開發的產品的時候，讓每個用戶逐個執行正式的驗收測試是不切

實際的。很多軟件產品生產者采用一種稱之為a測試和b測試的測試方法，以發現可能只有最終用戶才能發現的錯誤。

α測試是由一個用戶在開發環境下進行的測試，也可以是開發機構枘部的用戶在模擬實際操作環境下進行的測試。軟件在一個自然設置狀態下使用。開發者坐在用戶旁邊，隨時記下錯誤情況和使用中的問題。這是在受控制的環境下進行的測試，α測試的目的是班次價軟件產品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。尤其注重產品的界面和特色。a測試人員是除開產品開發人員之外首先見到產品的人，他們提出的功能和修改意見是特別有價值的。

a測試可以從軟件產品編碼結束之時開始，或在模塊（子系統）測試完成之后開始，也可以在確認測試過程中產品達到一定的穩定和可靠程序之后再開始。有關的手冊（草稿）等應事先準備好。

β測試是由軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。這些用戶是與公司簽定了支持產品預發行合同的外部客戶，他們要求使用該產品，并愿意返回有關錯位錯誤信息給開發者。與α測試不同的是，開發者通常不在測試現場。因而，β測試是在開發者無法控制的環境下進行的軟件現場應用。在β測試中，由用戶記下遇到的所有問題，包括真實的以及主觀認定的，定期向開發者報告，開發者在綜合用戶的報告之后，做出修改，最將軟件產品交付給全

體用戶使用。 β測試主要衡量產品的FLURPS。著重于產品的支持性，包括文檔、客戶培訓和支持產品生產能力。只有當α測試達到一定的可靠程度時，才能開始β測試。由于它處在整個測試的最后階段，不能指望這時發現主要問題。同時，產品的所有手冊文本也應該在此階段完全定稿。

由于β測試的主要目標是測試可支持性，所以β測試應盡可能由主持產品發行的人員來管理。

驗收測試(Acceptance Testing)

在通過了系統的有效性測試及軟件配置審查之后，就應開始系統的驗收測試。驗收測試是以用戶為主的測試。軟件開發人員和QA(質量保證)人員也應參加。由用戶參加設計測試用例，使用用戶界面輸入測試數據，并分析測試的輸出結果，一般使用生產中的實際數據進行測試。在測試過程中，除了考慮軟件的功能和性能外，還應對軟件的可移植性、兼容性、可維護性、錯誤的恢復功能等進行確認。

驗收測試實驗上是對整個測試計劃進行一種“走查(Walkthrough)”。

確認測試的結構

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

確認測試的結果有兩種情況：

1)功能和性能與用戶的要求一致，軟件可以接受；

2)功能和性能與用戶的要求有差距。

出現后一種情況，通常與軟件需求分析階段的差錯有關。這時需要開列一張軟件各項缺陷表或軟件問題報告，通過與用戶的協商，解決所發現的缺陷和錯誤。確認測試應交付的文檔有：確認測試分析報告、最終的用戶手冊和操作手冊、項目開發總結報告。

系統測試(System Testing)

系統測試是將通過確認測試的軟件，作為整個基于計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行（使用）環境下，對計算機系統進行一系列的組裝測試和確認測試。系統測試的目的在于通過與系統的需求定義作比較，發現軟件與系統定義不符合或與之矛盾的地方。系統測試的測試用例應根據需求分析說明書來設計，并在實際使用環境下來運行。由于軟件只是計算機系統中的一個組成部分，軟件開發完成以后，最終還要與系統中其它部分配套運行。系統在投入運行以前各部分需完成組裝和確認測試，以保證各組成部分不僅能單獨地受到檢驗，而且在系統各部分協調工作的環境下也能正常工作。這里所說的系統組成部分除去軟件外，還可能包括計算機硬件及其相關的外圍設備、數據及其收集和傳輸機構、掌握計算機系

統運行的人員及其操作等，甚至還可能包括受計算控制的執行機構。顯然，系統的確認測試已經完全超出了軟件工作的范圍。然而，軟件在系統中畢竟占有相當重要的位置，軟件的質量如何，軟件的測試工作進行得是否扎實勢必與能否順利、成功地完成系統測試關系極大。另一方面，系統測試實際上是針對系統中各個組成部分進行的綜合性檢驗。盡管每一個檢驗有著特定的目標，然而所有的檢測工作都要驗證系統中每個部分均已得到正確的集成，并能完成指定的功能。以下

分別簡要說明幾種系統測試：

恢復測試

恢復測試是要采取各種人工干預方式使軟件出錯，而不能正常工作，進而檢驗系統的恢復能力。如果系統本身能夠自動地進行恢復，則應檢驗：重新初始化，檢驗點設置機構、數據恢復以及重新啟動是否正確。如果這一恢復需要人為干預，則應考慮平均修復時間是否在限定的范圍以內。

安全測試

安全測試的目的在于驗證安裝在系統內的保護機構確定能夠對系統進行保護，使之不受各種非常的干擾。系統的安全測試要設置一些測試用例謀略實在系統的安全保密措施，檢驗系統是否有安全保密的漏洞。

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

強度測試

檢驗系統的能力最高實際限度。進行強度測試時，讓系統的運行處于資源的異常數量、異常頻率和異常批量的條件下。例如，如果正常的中斷平均頻率為每秒一到二次，強度測試設計為每秒10次中斷。又如某系統正常運行 可支持10個終端并行工作，強度測試則檢驗15個終端并行工作的情況。

性能測試

性能測試檢驗安裝在系統內的軟件運行性能。這種測試常常與強度測試結合起來進行。為記錄性能需要在系統中安裝必要的量測儀表或是為度量性能而設置的軟件(或程序段)。

參考資料：1.《計算機軟件測試技術》鄭人杰，清華大學出版社，1992。

2.《Software Engineering--A Practioner’ s Approach》,R. S. Pressman, 1998.

3. 《實用軟件工程》，鄭人杰，殷人昆，陶永雷，清華大學出版社，1997。

軟件集成、確認和系統測試方法 www.51testing.com

博為峰軟件制作 BWF SOFTWARE

總結

以上是生活随笔為你收集整理的软件集成、确认和系统测试方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。