【讀書筆記】之軟體測試

文章目錄

• 2.3.1 黑箱測試法(功能測試法)
• 2.3.2 黑箱測試方案的設計
• 2.3.3 白盒測試法（邏輯覆蓋法，結構測試法）
• 2.3.4 白盒測試方案的設計
• 3.1.1 單元測試的內容
• 3.1.2 單元測試的過程
• 3.2.1 自頂向下
• 3.2.2 自底向上

0.參考教材

《軟體工程原理及應用》 陳世鴻，朱福喜，黃水松，陳磊主編；武漢大學出版社

1.引論1.1 什麼是軟體測試

軟體測試主要是對製作的軟體產品進行檢查和測試，及時地發現程式中的故障和邏輯錯誤，以保障軟體產品的可靠性。軟體測試是保證軟體品質的關鍵步驟，也是提高軟體可靠性的重要手段，因此它是軟體工程的的重要重要組成部分之一。

軟體測試的內容包括兩個方面，即文檔和程式。

軟體測試的宗旨是要採用費用最少而效果最好的方法提高軟體產品的品質。

Dijkstra關於軟體測試有一句極精闢的話“測試只能證明程式有錯，不能保證程式無錯”。

 

1.2 軟體測試的目標

G.Myers在他的優秀著作《軟體測試技巧》中，精闢的闡述測試的目的或定義：

1. 程式測試是為了發現錯誤而執行程式的過程；
2. 好的測試方案是極可能發現迄今為止尚未發現的錯誤；
3. 成功的測試是能夠發現以前尚未發現的錯誤。

由此可見，傳統觀念“程式測試是為了證明程式中不存在錯誤”，“成功的測試是一個未能發現錯誤的測試”是不正確的。

1.3 軟體測試的原則

1. 預先確定測試結果
2. 軟體的開發人員（或部門）不應該測試自己的程式
3. 制定嚴格的測試計劃，防止測試的隨意性
4. 設計和選擇測試方案要有利於發現錯誤
5. 集中力量測試容易出錯的程式段
   • 在許多程式中，錯誤好像是成群出現的，這些錯誤往往比較集中在一段程式中。存在錯誤的機率與這段程式中發現的錯誤成比列。這就是所謂群集現象。
6. 儲存好測試計劃，測試方案，錯誤資料統計和分類，以及最終的分析報告。

2.軟體測試方法

軟體測試通常有三種方法，第一種是程式正確性證明，即驗證；第二種是靜態測試，即不執行被測試的程式而發先程式中的錯誤；第三種是動態測試。

2.1 程式正確性證明

程式正確性證明是從理論上對程式的正確性進行論證，通過證明可以得出程式邏輯上是否正確。

在許多情況下，一個完全的形式證明可能是不必要的。在某些情況下，若不能實現完全測試，則也不可能實現完全的形式證明。然而，我們常常用程式正確性證明所開發的推理風格來指導測試過程，以增強對程式的信任,有時可以把某些性質的程式證明和其他性質的測試結合起來。

2.2 靜態測試

所謂靜態測試是指不執行程式而找出程式存在錯誤的方法。這種方法以人工的，非形式化的方法對程式進行分析和測試,它是不依賴於電腦的測試。實踐表明，靜態測試可以發現大約30%-70%的邏輯設計錯誤和編碼錯誤。

2.2.1 功能檢查（自我測試）

功能檢查也叫自我測試，由程式員將模組功能（說明，演算法，文法規則），流程圖和編碼對照起來反覆閱讀，檢查程式的文法和邏輯錯誤。

2.2.2 群體檢查

群體檢查是由自於人聽社記者對功能說明，流程圖，程式編碼的自我測試等情況的彙報之後，對程式進行動態分析的過程。

2.2.3 人工運行檢查

人工運行檢查是由人扮演電腦來執行程式，將測試方案按程式的邏輯結構執行一遍，從而找出程式的錯誤供測試者分析。

2.3 動態測試

靜態測試主要是檢查程式的邏輯設計和編碼錯誤，但在理論上和實踐上還存在局限性，所以還比尋進行動態測試。

所謂動態測試，就是把程式看作函數，取函數定義域中的每一個元素作為輸入，實際運行程式，檢查程式的執行結果是否全部落在函數的範圍之內，以此來檢查程式的正確性，可靠性和有效性。

1. 如果產品要實現的功能是已知的，就可以分別測試是否達到每個功能要求，稱之為“黑箱測試”
2. 如果知道產品的內部邏輯結構和處理過程，可以根據規格說明來完成內部操作的測試，稱之為“白盒測試”

2.3.1 黑箱測試法(功能測試法)

黑箱測試法又稱為功能測試法，它是在軟體介面上進行測試，根據對軟體功能的分析，推演出函數定義域中有代表性的元素組成測試方案。測試者使用這種方法時，把程式看成一個黑盒,完全不考慮程式內部的結構和處理過程。其目的是用來證明與程式內部工作無關的功能需求的有效性，很少考慮軟體的內部邏輯結構。

2.3.2 黑箱測試方案的設計2.3.2.1 劃分等價類別

1. 劃分等價類別的規則
   • 值的範圍
   • 值的個數
   • 值約束
   • 值的規則（如檔案名稱以字母開頭）
   • 等價類別的進一步劃分
2. 測試方案

劃分等價類別後，應根據等價類別設計測試方案，主要步驟如下：

1.  
   1. 為每個等價類別規定一個唯一的編號。
   2. 包含合理的等價類別。設計一個新的測試方案時，應選取儘可能多的測試方案覆蓋尚未被包含的合理等價類別。
   3. 包含一個不合理的等價類別。設計一個新的測試方案，使它僅包含一個尚未被包含的不合理的等價類別。否則，多個不合理的等價類別交叉在一起會影響測試效果。

2.3.2.2 邊界值分析

程式中大量的錯誤常常會出現在輸入欄位的邊界位置，而非“中間”。這裡所說的邊界值是指相對於輸入等價類別和輸出等價類別而言的。

使用邊界值分析法設計測試方案時，首先應去頂邊界條件，選取剛好等於，稍小於和稍大於等價類別邊界的資料作為測試資料。以下幾點可供參考：

1. 如果輸入條件規定了取值的範圍，首先選取這個範圍的邊界測試條件，然後編寫一些剛好超過此範圍的測試條件的例子。
2. 如果輸入條件規定了輸入資料的個數，則應分別為最小個數，最大個數，比最小個數少一，比最大個數多一設計測試方案。
3. 除考慮輸入等價類別之外，還應考慮輸出等價類別來選取測試方案。
4. 如果程式的輸入和輸出是個有序集（如線性表），則應把注意力集中在集合的第一個和最後一個元素上。

用邊界值分析法設計的測試方案更全面，更具有代表性，發現錯誤的機率更高。但找出邊界條件時很困難，需要實踐經驗和創造性勞動。

邊界值分析法和等價類別劃分法的主要區別如下：

1. 邊界值分析法不是從某個等價類別中任意選取一個作為代表，而是選取一個或幾個元素，等價類別中每個邊界值都是測試對象。
2. 邊界值分析法不僅要考慮輸入條件，還要把輸出等價類別作為測試方案。

2.3.2.3 錯誤推測法

所謂錯誤推測法，就是通過人們的經驗或直覺，推測程式中可能存在的某些錯誤類型和容易發生的特殊情況，並依此選擇測試方案檢查這些錯誤。錯誤推測法主要是憑藉測試者在實踐中積累的經驗，所以沒有確定的測試步驟。

2.3.3 白盒測試法（邏輯覆蓋法，結構測試法）

白盒測試法又稱邏輯覆蓋法或結構測試法，它是根據對軟體內部邏輯結構的分析到處測試方案，用來對軟體的過程性細節細緻檢查。測試者把程式看作一個透明的盒子，利用過程設計的控制結構檢查內部的邏輯結構和處理過程。使用白盒測試，測試方案對程式邏輯覆蓋的成都決定測試完全性的程度。

2.3.4 白盒測試方案的設計

使用白盒測試到處的測試方案可以做到：

1. 確保模組的所有獨立路徑至少測試一次
2. 所有邏輯判斷的真假兩種情況都被測試
3. 在迴圈的邊界和運行界限內執行所有的迴圈
4. 測試內部資料結構以確保它們的有效性

下面例舉一些常用的白盒測試方案：

1. 語句覆蓋：選擇足夠的測試資料，使程式中的每個可執行檔語句至少執行一次。
2. 判定覆蓋（分支覆蓋）：一種較強的邏輯覆蓋，測試時設計出足夠多的測試資料，使得程式中的每一個判斷的取真分支和取假分支至少執行一次。
3. 條件覆蓋：使用足夠多的測試資料，使得判定中的每個條件的所有可能的結果至少出現一次。
4. 判定—條件覆蓋：既滿足判定覆蓋的標準又滿足條件覆蓋的標準。
5. 條件組合覆蓋：選取足夠多的測試資料，使得每個判定運算式中的條件的各種可能的組合至少執行一次。

說明：

1. 在一個判定運算式中常常包含多個條件。
2. 條件覆蓋不一定包含判定覆蓋，判定覆蓋也不一定包含條件覆蓋。
3. 滿足條件組合覆蓋的測試資料一定能滿足判定覆蓋，條件覆蓋和判定—條件覆蓋。

3.軟體測試的步驟和策略

1. 單元測試
2. 聯合測試
3. 有效性測試
4. 系統測試
5. 驗收測試

3.1 單元測試

單元測試是指被測試程式是單個子程式，過程的邏輯測試。單元測試的主要任務是驗證其功能和介面說明是否有不符合的情況，以及編碼錯誤。

單元測試集中在每個單獨的程式塊中，消除快內的邏輯，功能上的缺陷和錯誤，保證每個塊作為一個單元能正確執行並為上一級測試作準備。

經過靜態測試之後，應該集中注意力逐一測試程式中的每一個單元，而不是把程式作為一個整體來測試，理由如下：

1. 易於排錯。
2. 利於聯合測試。
3. 利用單元測試確認詳細說明書。
4. 可並行測試。

在單元測試中主要使用白盒測試法，儘可能達到徹底測試；黑盒法協助工具功能測試，要達到對任何合理和不合理的輸入都能夠鑒別和響應。

3.1.1 單元測試的內容

1. 單元介面。在進行單元測試前，首先應對單元介面的資料流進行測試，因為介面測試是其它測試的基礎，如果資料流不能正確的進入和退出，其它的測試就無法進行。
2. 局部資料結構的測試。對局部資料結構應進行仔細測試，因為局部資料結構常常事錯誤的策源地。
3. 重要路徑測試。由於測試具有不可窮盡性，因此選擇適當的測試方案對單元中重要執行路徑充分測試是十分必要的。其目的是為了發現計算錯誤，比較錯誤或控制流程錯誤。
4. 錯誤處理。錯誤處理應該是程式功能的一部分，一旦出現粗無時應執行相應的出錯處理路徑，或終止程式運行。
5. 邊界測試。邊界測試是單元測試中最後的也可能是最重要的工作。

3.1.2 單元測試的過程

單元一般不是一個獨立完整的程式，在進行單元測試之前，還必須為每個單元測試編寫驅動程式和支撐程式。

在通常的應用中，驅動程式與“主程式”並無區別，它接收測試資料，將這些資料傳送給被測試的單元，並列印有關的結果。

支撐程式則代替被測試的單元所調用的單元，有時也將支撐程式成為“虛子程式”，它提供由它代替的單元介面，資料處理儘可能少，列印並檢查入口資訊，將控制返回給調用它的單元。

驅動程式和支撐程式都是要另外編寫的，需要花費不少的精力和時間。因為應盡量設計的簡單些，意減少軟體開發的開銷。然後許多單元卻不能用“簡單的”低開銷來充當單元測試。在這種情況下，測試工作就要延遲到聯合測試時進行，當然，這時仍需要編寫少量的驅動程式和支撐程式。

3.2 聯合測試

在單元測試的基礎上，要把每個單元按照設計要求逐步聯結起來進行聯合測試，主要目的是發現與介面有關的錯誤。

單元的聯合整合測試有兩種方式，非增式測試和增式測試。

非增式測試就是先分別測試每個單元，再把所有單元按設計要求聯結成完整的程式系統。

增式測試是把一個要測試的單元同已經測試好的單元聯結起來進行測試，測試完畢後，再把下一個應該測試的單元聯結起來進行測試，每次只增加一個單元。這種方法實際上同時完車單元測試和聯合測試。

 

這兩種方法的主要優缺點如下：

1. 增式測試工作量小。非增式測試需要對每個單元編寫驅動程式和支撐程式，工作量較大。而增式測試可利用已測試過的單元作為部分驅動和支撐程式，其工作量小。
2. 增式測試發現錯誤早。增式測試可以較早的發現單元介面錯誤，而非增式測試只有等到各單元聯結在一起後才能發現單元之間的介面錯誤。
3. 增式測試的徹底性。增式測試把已經測試好的單元與心膽原連接起來進行測試，在新環境下，又要對已經測試好的單元進行測試，隨著單元數的不斷增加，有些單元要經受多次測試，顯然這種方式對程式的測試更徹底。
4. 增式測試需要較多的機器時間。
5. 非增式測試可並行進行測試。

總的來說，增式測試是更適合的測試方案。

 

對增式測試其單元的增加有自頂向下和自底向上兩種單元聯結方法。

3.2.1 自頂向下

自頂向下測試是一種增式整合軟體結構的方法，從主單元（主程式）開始，沿著軟體的控制層次向下移動，從而逐漸把各個單元連接起來，已經測試過的單元和新單元的聯結有兩種策略，即深度優先和廣度優先。

3.2.1.1 決定測試順序的基本原則

1. 儘早測試關鍵單元。
2. 儘早測試包含輸入輸出操作的單元。因為測試了具有這些功能的單元後，有利於測試資料的輸入和測試結果的輸出。

3.2.1.2 測試步驟

1. 把主控單元作為測試驅動程式，其直屬員工單元用支撐程式代替。
2. 根據選擇的聯結策略（深度優先或廣度優先），用實際的單元逐個代替下屬的支撐單元。
3. 每聯結一個單元就測試一個單元
4. 可以進行迴歸測試，即部分地或全部地重複測試曾經測試過的單元，保證不斷髮現新的錯誤
5. 重複1-4，直至完成整個軟體系統為止。

3.2.1.3 優點

1. 能夠較早發現並糾正主要介面的錯誤。
2. 不需要編寫驅動程式。
3. 使用者能夠在早起看到系統的主要功能。
4. 測試所佔的機器時間在軟體開發的整個期間能夠保持一定的穩定性。

3.2.1.4 缺點

1. 要求編寫支撐程式，且支援程式複雜，測試方案設計困難；
2. 建立測試條件和判定測試結果困難；
3. 容易遺忘必要的測試；
4. 並行測試困難。

3.2.2 自底向上

自底向上和自頂向下的測試正好相反，它是根據自底向上開發技術而來的，一般在程式設計完成後才能開始測試，從軟體結構最底層的單元開始聯結和測試。

3.2.2.1 測試步驟

自底向上測試通常是在系統開發的後期進行，即在系統分析，系統設計，程式設計完成之後開始進行測試，此時系統的所有單元均已存在。實現步驟如下：

1. 將底層單元組合成實現某個特定的軟體子功能；
2. 編寫一個驅動程式（測試控製程序）來協調測試的輸入和輸出；
3. 測試資料格集
4. 沿著軟體結構向上去掉驅動程式，將新單元聯結起來。

3.2.2.2 優點

1. 不需要編寫支撐程式；
2. 可儘早進行並行測試；
3. 可儘早發現關鍵單元的錯誤；
4. 容易建立測試條件；
5. 容易判斷測試結果。

3.2.2.3 缺點

1. 要編寫驅動程式；
2. 要求先整合為子系統；
3. 介面出錯發現遲；
4. 系統輪廓形成晚。

3.3 有效性測試

軟體的功能和效能能夠滿足使用者合理的要求，則軟體是有效。

軟體的有效性測試一般使用黑箱測試法。

有效性測試需要驗證軟體是否與使用者要求一致的測試方案。此外還必須驗證文檔資料是否完整準確，軟體的可移植性，相容性和可維護性。

有效性測試過程的一個重要內容是對軟體的配置進行複查，其目的是保證所有的軟體配置的所有成分（如使用者檔案，設計檔案代碼錶，測試檔案等）齊全，其品質符合要求，支援維護階段所必須的細節，而且還要編排好目錄。

3.4 系統測試

系統測試是通過有效性測試的軟體作為整個電腦系統的一部分，與硬體，外設等其它系統結合起來，對電腦系統進行一系列的聯合測試和有效性測試。

系統測試的目的是，將軟體與系統需求定義進行比較，發現軟體與定義不符合或相矛盾的地方。

系統測試的種類有：

1. 功能測試。逐步對照規格說明，檢查程式是否滿足了“做什麼”。
2. 容量測試。其目的是通過讓程式處理大量的資料，考慮這些程式是否能處理規定數量的任務。
3. 強度測試。強度測試是指程式能否在單位時間內完成規定的最大工作容量（數），讓程式咋高負荷情況下工作。
4. 便利性測試。對介面結構，輸出結果是否無法理解，出錯資訊是否簡明易懂，操作是否方便等。
5. 安全性測試。精心設計一些測試方案檢查程式的安全性。
6. 儲存容量測試。測試的內容有記憶體和外存的容量，臨時檔案或檔案溢出及大小等。
7. 配置測試。主要是對程式所需的資源進行測試，例如測試輸入/輸出裝置，作業系統，語言等的要求。
8. 相容/轉換效能測試。特別對那些新版本的程式的測試，既要測試新的版本與舊版本的相容性，又要考慮將來版本更新後的擴充問題。
9. 可安裝性測試。對安裝步驟的考核測試，特別一些系統軟體，對其安裝過程進行測試是十分重要的。
10. 可靠性測試。所謂軟體的可靠性,是指給定的時間內 ,特定的環境下軟體正確啟動並執行機率
11. 恢複測試。當硬體故障，引起程式和資料出現錯誤之後，測試整個系統能否恢複正常工作。
12. 維護性測試。對系統提供的可供維護的手段進行測試，例如對診斷程式，儲存空間中的轉儲程式，維護規程等進行測試。
13. 文檔資料測試。檢查提供給使用者的文檔資料是否齊全和準確。
14. 規程測試。測試各類人員（如系統操作人員，資料庫管理員等）應遵循的規程是否合理可行。

3.5 驗收測試

驗收測試是在使用者參與的情況下進行的，主要使用實際資料進行測試，其目的是驗證系統確實能夠滿足使用者的需要，測試的內容與聯合測試基本相同，測試中發現的錯誤往往是系統要求說明書中的錯誤。

 

 

2010.9.21 （中秋前夜，寫了4個多小時，好累呀：））

-END-

4 相關名詞解釋

1. 迴歸測試是在軟體維護階段,對軟體修改之後進行的測試.其目的是檢驗對軟體進行的修改是否正確.
2. 所謂軟體的可靠性,是指給定的時間內 ,特定的環境下軟體正確啟動並執行機率 .
3. 簡述軟體生命週期模型中的瀑布模型.
   問題定義——>可行性分析——>需求分析——>概要設計——>詳細設計——>編碼——>測試——>維護
4. 負載測試通常是指類比多個使用者同時使用系統的服務來模仿一個軟體程式期望用途的做法.