當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

『软件工程12』软件工程实践方法——软件测试

發布時間：2023/12/4 编程问答 34 豆豆

生活随笔收集整理的這篇文章主要介紹了『软件工程12』软件工程实践方法——软件测试小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

軟件工程實踐方法—— 軟件測試

一、軟件測試概述
- 1、軟件測試的目的
- - （1）從用戶和開發者角度
  - （2）Myers軟件測試目的
2、軟件測試的原則
- 3、軟件測試的對象
- 4、測試信息流
- 5、測試與軟件開發各階段的關系
二、軟件測試用例
- 1、黑盒測試概述
- 2、白盒測試概述
- 3、白盒測試方法
- 4、條件測試路徑選擇
- 5、循環測試路徑選擇
- - （1）簡單循環
  - （2）嵌套循環
  - （3）連鎖循環
  - （4）非結構循環
- 6、基本路徑測試
- 7、黑盒測試的測試用例設計
三、軟件測試步驟
- 1、單元測試
- - （1）單元測試的定義
  - （2）單元測試的內容
  - （3）單元測試的步驟
- 2、組裝測試
- - （1）組裝測試的什么
  - （2）組裝測試需考慮問題
- 3、確認測試
- - （1）確認測試是什么
  - （2）確認測試的步驟
- 4、系統測試
- - （1）系統測試是什么
四、寫在最后

在一項系統軟件完成之后，且在上線之前，需要經過不斷的軟件測試，找出 bug 和錯誤，不斷修補，才能正式上線。在下面的這篇文章中，將講解軟件測試的一些基礎知識以及測試用例的設計和軟件測試的步驟。

接下來開始進行講解。

一、軟件測試概述

1、軟件測試的目的

（1）從用戶和開發者角度

基于不同的立場，存在著兩種完全不同的測試目的：

從用戶的角度出發，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可接受該產品。
從軟件開發者的角度出發，則希望測試表明軟件產品中不存在錯誤的過程，驗證該軟件已正確地實現了用戶的要求，樹立人們對軟件質量的信心。

（2）Myers軟件測試目的

測試是程序的執行過程，目的在于發現錯誤；
一個好的測試用例在于能發現至今未發現的錯誤；
一個成功的測試是發現了至今未發現的錯誤的測試。

總結來說就是，測試的目的是想以最少的時間和人力，系統地找出軟件中潛在的各種錯誤和缺陷。如果我們成功地實施了測試，我們就能夠發現軟件中的錯誤。測試的附帶收獲是，它能夠證明軟件的功能和性能與需求說明相符合。實施測試收集到的測試結果數據為可靠性分析提供了依據。

2、軟件測試的原則

應當把“盡早地和不斷地進行軟件測試”作為軟件開發者的座右銘。
測試用例應由測試輸入數據和對應的預期輸出結果這兩部分組成。
程序員應避免檢查自己的程序。
在設計測試用例時，應包括合理的輸入條件和不合理的輸入條件。
充分注意測試中的群集現象。經驗表明，測試后程序中殘存的錯誤數目與該程序中已發現的錯誤數目成正比。
嚴格執行測試計劃，排除測試的隨意性。
應當對每一個測試結果做全面檢查。
妥善保存測試計劃，測試用例，出錯統計和最終分析報告，為維護提供方便。

3、軟件測試的對象

軟件測試并不等于程序測試。軟件測試應貫穿于軟件定義與開發的整個期間。

需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都應成為軟件測試的對象。

簡單來說，就是程序、數據和文檔都應該成為測試對象。

4、測試信息流

測試信息的步驟：

軟件配置（對象）：軟件需求規格說明、軟件設計規格說明、源代碼等；
測試配置（方法）：測試計劃、測試用例、測試程序等；
測試工具：測試數據自動生成程序、靜態分析程序、動態分析程序、測試結果分析程序、以及驅動測試的測試數據庫等等。
測試結果分析：比較實測結果與預期結果，評價錯誤是否發生。
排錯（調試）：對已經發現的錯誤進行錯誤定位和確定出錯性質，并改正這些錯誤，同時修改相關的文檔。
修正后的文檔再測試：直到通過測試為止。

得出結論：

通過收集和分析測試結果數據，對軟件建立可靠性模型。

利用可靠性分析，評價軟件質量。

如果測試發現不了錯誤，可以肯定，測試配置考慮得不夠細致充分，錯誤仍然潛伏在軟件中。

5、測試與軟件開發各階段的關系

（1）軟件開發過程是一個自頂向下，逐步細化的過程，主要有以下步驟：

軟件計劃階段定義軟件作用域。
軟件需求分析階段建立軟件信息域、功能和性能需求、約束等。
軟件設計。
把設計用某種程序設計語言轉換成程序代碼。

（2）而測試過程是按照相反順序安排的自底向上，逐步集成的過程。

二、軟件測試用例

1、黑盒測試概述

把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據需求規格說明來檢查程序的功能是否符合。

黑盒測試又叫做功能測試或數據驅動測試。

黑盒測試方法是在程序接口上進行測試，主要是為了發現以下錯誤：

是否有不正確或遺漏了的功能?
在接口上，輸入能否正確地接受? 能否輸出正確的結果?
是否有數據文件訪問錯誤?
性能上是否能夠滿足要求?

用黑盒測試發現程序中的錯誤，必須在所有可能的輸入條件和輸出條件中確定測試數據，來檢查程序是否都能產生正確的輸出。

但這是不可能發生的事情。為什么呢？

假設一個程序P有輸入量X和Y及輸出量Z。在字長為32位的計算機上運行。若X、Y取整數，按照黑盒測試方法進行窮舉測試：

可能采用的測試數據組：2³² x 2³² ＝ 264。

如果測試一組數據需要1毫秒，一年工作365× 24小時，完成所有測試需5億年。

5億年！想想都不太可能。所以說，程序一般沒有辦法引入窮舉測試。

2、白盒測試概述

把測試對象看做一個透明的盒子，它允許測試人員利用程序內部的邏輯結構設計測試用例，對程序所有邏輯路徑進行測試。

通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致。

因此白盒測試又稱為結構測試或邏輯驅動測試。

白盒測試方法，主要對程序模塊作出以下檢查：

對程序模塊的所有獨立的執行路徑至少測試一次；
對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次；
在循環的邊界和運行界限內執行循環體；
測試內部數據結構的有效性等等。

對一個具有多重選擇和循環嵌套的程序，不同的路徑數目可能是天文數字。給出一個小程序的流程圖，它包括了一個執行20次的循環。

包含的不同執行路徑數達5²⁰條，對每一條路徑進行測試需要1毫秒，假定一年工作365 × 24小時，要想把所有路徑測試完，需3170年。

比起窮舉測試的5億年，3170年似乎少了不少。但是呢？3170年會不會也挺太漫長的。

因此，我們要引入一些黑白盒測試方法來解決這些問題。

3、白盒測試方法

白盒測試方法主要有以下6種方法：

語句覆蓋
判定覆蓋
條件覆蓋
判定-條件覆蓋
條件組合覆蓋
路徑覆蓋

白盒測試方法這里篇幅較長，放在另外一篇文章中，有需要的小伙伴自取~

4、條件測試路徑選擇

當程序中的判定條件超過一個時，形成的分支結構可以分為兩類：嵌套型分支結構和連鎖型分支結構。

對于嵌套型分支結構，若有 n 個判定語句，需要 n+1 個測試用例；

對于連鎖型分支結構，若有 n 個判定語句，需要有 2n 個測試用例，覆蓋它的 2n 條路徑。

如下圖所示：

5、循環測試路徑選擇

循環分為4種不同類型：簡單循環、連鎖循環、嵌套循環和非結構循環。如下圖所示：

接下來對這四種循環進行一一介紹。

（1）簡單循環

①零次循環： 從循環入口到出口。

②一次循環： 檢查循環初始值。

③二次循環： 檢查多次循環。

④m次循環： 檢查在多次循環。

⑤最大次數循環： 比最大次數多一次、少一次的循環。

（2）嵌套循環

①對最內層循環做簡單循環的全部測試。所有其它層的循環變量置為最小值。

②逐步外推，對其外面一層循環進行測試。測試時保持所有外層循環的循環變量取最小值，所有其它嵌套內層循環的循環變量取“典型”值。

③反復進行，直到所有各層循環測試完畢。

④對全部各層循環同時取最小循環次數，或者同時取最大循環次數。

（3）連鎖循環

如果各個循環互相獨立，則可以用與簡單循環相同的方法進行測試。但如果幾個循環不是互相獨立的，則需要使用測試嵌套循環的辦法來處理。

（4）非結構循環

這一類循環應該使用結構化程序設計方法重新設計測試用例。

6、基本路徑測試

基本路徑測試法也已經放到白盒測試方法文章當中，有需要的小伙伴自取~

7、黑盒測試的測試用例設計

黑盒測試方法主要有以下8種方法：

等價類劃分法
邊界值分析法
錯誤推測法
因果圖法
判定表驅動法
正交實驗設計法
場景法
功能圖法

黑盒測試方法篇幅較長，已放在另外一篇文章中，有需要的小伙伴自行查閱~

三、軟件測試步驟

測試過程需要按照4個步驟進行，分別是單元測試（模塊）、組裝測試（集成）、確認測試和系統測試。詳細過程如下：

開始是單元測試，集中對使用源代碼實現的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現了規定的功能。
組裝測試把已測試過的模塊組裝起來，主要對與設計相關的軟件體系結構的構造進行測試。
確認測試則是要檢查已實現的軟件是否滿足了需求規格說明中已經確定的各種需求，以及軟件配置是否完全、正確。
系統測試把已經經過確認的軟件納入實際運行環境中，與其它系統成份地組合在一起進行測試。

以下將對這四個測試步驟進行一一講解。

1、單元測試

（1）單元測試的定義

單元測試又稱模塊測試，是針對軟件設計的最小單位 —— 程序模塊，進行正確性檢驗的測試工作。其目的在于發現各模塊內部可能存在的各種差錯。

單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。

（2）單元測試的內容

在單元測試時，測試者需要依據詳細設計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結構，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應。

如下圖所示：

下面對這五個測試內容進行一一講解。

1）模塊接口測試

在單元測試的開始，應該對通過被測模塊的數據流進行測試。測試項目包括：

調用本模塊的輸入參數是否正確；
本模塊調用子模塊時輸入給子模塊的參數是否正確；
全局量的定義在各模塊中是否一致；

在做內外存交換時要考慮：

文件屬性是否正確；
OPEN 與 CLOSE 語句是否正確；
緩沖區容量與記錄長度是否匹配；
在進行讀寫操作之前是否打開了文件；
在結束文件處理時是否關閉了文件；
正文書寫／輸入錯誤，
I/O 錯誤是否檢查并做了處理。

2）局部數據結構測試

不正確或不一致的數據類型說明；
使用尚未賦值或尚未初始化的變量；
錯誤的初始值或錯誤的缺省值；
變量名拼寫錯或書寫錯；
不一致的數據類型；
全局數據對模塊的影響。

3）路徑測試

選擇適當的測試用例，對模塊中重要的執行路徑進行測試；
應當設計測試用例來查找因錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤；
對基本執行路徑和循環進行測試，可以發現到大量的路徑錯誤。

4) 錯誤處理測試

出錯的描述是否難以理解；
出錯的描述是否能夠與具體錯誤相定位；
顯示的錯誤與實際的錯誤是否相符；
對錯誤條件的處理正確與否；
在對錯誤進行處理之前，錯誤條件是否已經引起系統的干預等。

5) 邊界測試

注意數據流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性；
對這些地方要仔細地選擇測試用例，認真加以測試；
如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和正常情況下影響模塊運行時間的因素。

（3）單元測試的步驟

模塊并不是一個獨立的程序，因此，在考慮測試模塊時，同時要考慮它和外界的聯系，用一些輔助模塊去模擬與被測模塊相聯系的其它模塊。其中，輔助模塊包括：

驅動模塊 (driver)；
樁模塊 (stub) —— 存根模塊。

依據驅動模塊和樁模塊，單元測試的步驟如下圖所示：

如果一個模塊要完成多種功能，可以將這個模塊看成是由幾個小的程序組成。必須對其中的每個小的程序先進行單元測試所需要做的工作，對關鍵模塊還要做性能測試。

對支持某些標準規定的程序，更要著手進行互聯測試。有人把這種情況特別稱為模塊測試，以區別單元測試。

2、組裝測試

（1）組裝測試的什么

組裝測試，也稱為集成測試或聯合測試。

（2）組裝測試需考慮問題

通常，在單元測試的基礎上，需要將所有模塊按照設計的要求組裝成為系統。這時需要考慮的問題是：

在把各個模塊連接起來的時侯，穿越模塊接口的數據是否會丟失；
一個模塊的功能是否會對另一個模塊的功能產生不利的影響；
各個子功能組合起來，能否達到預期要求的父功能；
全局數據結構是否有問題；
單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。
在單元測試的同時可進行組裝測試，發現并排除在模塊連接中可能出現的問題，最終構成要求的軟件系統。
子系統的組裝測試特別稱為部件測試，它所做的工作是要找出組裝后的子系統與系統需求規格說明之間的不一致。
通常，把模塊組裝成為系統的方式有兩種：
- 一次性組裝方式
- 增殖式組裝方式

3、確認測試

（1）確認測試是什么

確認測試又稱有效性測試。

任務是驗證軟件的功能和性能和其它特性是否與用戶的要求一致。

在軟件的需求規格說明書中明確規定軟件的功能和性能要求。

它包含的信息就是軟件確認測試的基礎。