《軟體測試 第 2 版》讀書筆記

前兩部分 1~7章

• (第一部分 軟體測試綜述)
• 第 1 章 軟體測試的背景
• • 1.1 臭名昭著的軟體錯誤用例研究
  • 1.2 軟體缺陷是什麼
  • 1.3 為什麼會出現軟體缺陷
  • 1.4 軟體缺陷的修複費用
  • 1.5 軟體測試員究竟做些什麼
  • 1.6 軟體測試員應具備的素質
• 第 2 章 軟體開發的過程
• • 2.1 産品的組成部分
  • 2.2 軟體項目成員
  • 2.3 軟體開發生命周期模式
• 第 3 章 軟體測試的實質
• • 3.1 測試的原則
  • 3.2 軟體測試的主語和定義
• (第二部分 測試基礎)
• 第 4 章 檢查産品說明書（靜态黑盒測試）
• • 4.1 開始測試
  • • 4.1.1 黑盒測試和白盒測試
    • 4.1.2 靜态測試和動态測試
    • 4.1.3 靜态黑盒測試、測試産品說明書
  • 4.2 對産品說明書進行進階審查
  • 4.3 産品說明書的低層次測試技術
  • • 4.3.1 産品說明書屬性檢查清單
    • 4.3.2 産品說明書術語檢查清單
• 第 5 章 戴上眼罩測試軟體（動态黑盒測試 / 行為測試）
• • 5.1 動态黑盒測試：戴上眼罩測試軟體
  • 5.2 通過性測試和失效性測試
  • 5.3 等價類劃分
  • 5.4 資料測試
  • 5.5 狀态測試
  • 5.6 其他黑盒測試技術
• 第 6 章 檢查代碼（靜态白盒測試 / 結構化分析）
• • 6.1 靜态白盒測試：檢查設計和代碼
  • 6.2 正式審查
  • • 6.2.1 同僚審查 / 夥伴審查
    • 6.2.2 走查
    • 6.2.3 檢驗
  • 6.3 編碼标準和規範
  • 6.4 通用代碼審查清單
• 第 7 章 帶上 X 光眼鏡測試軟體（動态白盒測試 / 結構化測試）
• • 7.1 動态白盒測試
  • 7.2 動态白盒測試和調試
  • 7.3 分段測試
  • • 7.3.1 單元測試和內建測試
    • 7.3.2 單元測試示例
  • 7.4 資料覆寫
  • 7.5 代碼覆寫

(第一部分 軟體測試綜述)

第 1 章 軟體測試的背景

本章重點：

（1）軟體缺陷如何影響我們的生活

（2）軟體缺陷是什麼，為什麼會出現

（3）軟體測試員是誰，他們在做什麼

1.1 臭名昭著的軟體錯誤用例研究

1.2 軟體缺陷是什麼

• 軟體失敗的術語

  缺點、故障、失敗、異常、事件、偏差、問題、錯誤、缺陷、沖突、特殊等。描述軟體缺陷的術語很多，完全取決于公司的文化和開發軟體的過程。在用詞上過多計較是沒有意義的。

  本書中，所有軟體問題都稱為 缺陷（bug）。

• 軟體缺陷 的官方定義

  産品說明書：又稱說明或産品說明，是軟體開發小組的一個協定。它對開發的産品進行定義，給出了 産品的細節、如何做、做什麼、不能做什麼。（詳見第 2 章）

  至少滿足下列 5 個規則之一才稱發生了一個 軟體缺陷（software bug）：

  （1）軟體未實作産品規格說明書要求的功能

  （2）軟體出現了産品規格說明書指明不應該出現的錯誤

  （3）軟體實作了産品規格說明書未提到的功能

  （4）軟體未實作産品規格說明書雖未明确提及但應該實作的目标

  （5）軟體難以了解、不易使用、運作緩慢、或者（從測試員的角度看）最終使用者會認為不好

  注： 第（4）條，其目的是為了捕獲産品說明書上的遺漏之處。第（5）條，并非所有測試發現的缺陷都要修改，要全面，最重要的是要客觀。

1.3 為什麼會出現軟體缺陷

（1）最大的原因是 産品說明書。沒有寫、不夠全面且經常更改、整個開發小組沒有很好地溝通（随意、易變、溝通不足）

（2）第二大來源是 設計。這是程式員規劃軟體的過程（随意、易變、溝通不足）

（3）編碼。許多看上去是程式設計錯誤的軟體缺陷實際上是由産品說明書和設計方案造成的

（4）其他

1.4 軟體缺陷的修複費用

從開始到計劃、程式設計、測試，到公開使用的過程中，都有可能發現軟體缺陷。修複軟體缺陷的費用呈 指數級 地增長（即，随着時間的推移，費用呈 十倍 地增長）

1.5 軟體測試員究竟做些什麼

軟體測試員的目标： 盡可能早地找出缺陷，并確定其得以修複

1.6 軟體測試員應具備的素質

（1）喜歡探索，喜歡拿到一個新的軟體安裝在自己的機器上，觀看結果

（2）故障排除員，善于發現問題的症結，喜歡解謎

（3）不放過任何蛛絲馬迹，喜歡不停地嘗試，去發現軟體缺陷

（4）具有創造性，創造新的手段來發現缺陷

（5）追求完美，但當知道某些無法企及時，不去苛求，而是盡力接近

（6）判斷準确，要決定測試内容、測試時間，以及看到的問題是否是真的缺陷

（7）注重政策和外交

（8）善于說服

第 2 章 軟體開發的過程

本章重點：

（1）軟體産品構成的主要部分

（2）軟體産品中包含哪些人的勞動和技術

（3）軟體從構想到最終産品的過程

2.1 産品的組成部分

• 軟體産品需要多少投入

  

1. 客戶需求。 通過問卷調查、收集軟體以前的版本回報資訊、收集競争産品資訊、收集期刊評論、收集焦點人群意見等方式
2. 産品說明書。 綜合上述資訊以及沒有提出但必須要實作的需求，來定義産品是什麼、有哪些功能、外觀如何
3. 進度表。 Gantt 圖表或項目管理軟體，制定進度的目的：了解哪項工作完成了、還有多少工作要做、何時全部完成

4. 軟體設計文檔。 設計規劃軟體如何編寫

   常用的軟體設計文檔清單：

   （1）結構文檔： 描述軟體整體設計的文檔，包括軟體所有主要部分的描述，以及互相之間的互動方式。

   （2）資料流圖： 表示資料在程式中如何流動的正規示意圖。有時被稱為泡泡圖。

   （3）狀态轉換圖： 把軟體分解成基本狀态或者條件的另一種正規示意圖，表示不同狀态間的轉換方式。

   （4）流程圖： 用圖形描述程式邏輯的傳統方式。根據流程圖編寫程式代碼是很簡單的。

   （5）代碼注釋： 便于維護代碼的程式員輕松掌握代碼的内容和執行方式。

5. 測試文檔。

   測試送出清單：

   （1）測試計劃： 包括品質目标、資源需求、進度表、任務配置設定、方法等。

   （2）測試用例： 列舉測試的項目，描述驗證軟體的詳細步驟。

   （3）缺陷報告： 描述執行測試用例時找出的問題。

   （4）測試工具和自動測試： （第 15 章）

   （5）度量、統計和總結： 測試過程的彙總。采用圖形、表格和報告等形式。

• 軟體産品由哪些部分組成

  産品釋出時，不僅僅釋出代碼，還包含許多支援，這些部分也需要測試。

  

2.2 軟體項目成員

• 項目經理、程式經理 或者 監制人員：自始至終驅動整個項目，負責編寫産品說明書、管理制度、進行重大決策
• 體系架構師 或者 系統工程師：産品小組中的技術專家，設計整個系統的體系架構或軟體
• 程式員、開發人員 或者 代碼制作者：設計、編寫并修複軟體中的缺陷。與項目經理和設計師密切合作制作軟體，與項目經理和測試人員密切合作修複缺陷
• 測試員 或 品質保證員：找出并報告産品的問題。與開發小組全部成員在開發過程中密切合作
• 技術作者、使用者協助專員、使用者教育訓練專員、手冊編寫員 或者 文案專員：編制軟體産品附帶的檔案和聯機文檔
• 配置管理者 或 建構員：把程式員編寫的代碼及技術作者寫的全部文檔資料組合在一起，合成為一個軟體包

2.3 軟體開發生命周期模式

軟體産生從最初構思到公開發行的過程稱為 軟體開發生命周期模式 ：

（1）大爆炸模式

模式簡單，幾乎沒有計劃、進度安排、正規開發過程，幾乎沒有什麼測試。即使有測試，也是在産品已經完工準備傳遞之前進行，這時測試工作會妨礙傳遞，測試工作越深入，就會發現越多的軟體缺陷，争吵就越多。盡量避免在此模式下進行測試。

（2）邊寫邊改模式

最初隻有粗略的想法，接着進行一些簡單的設計，然後開始漫長的 來回編寫、測試、修改缺陷 的過程。

（3）瀑布模式

每一個步驟結束時，項目小組組織審查，并決定是否進入下一步。如果項目未準備好進入下一步，就停滞下來直到準備好。

特點：非常強調産品的定義，各步驟是分立的、沒有交叉，每一個步驟都 無法回溯。

優點：編寫代碼之前解決所有的未知問題并明确所有細節；測試小組可以制定精确的計劃和進度，測試對象非常明确，在分辨是功能還是缺陷上也沒有一點問題

缺點：軟體産品在仔細考慮和定義時，可能當初制造他的理由已經變了；軟體修複費用會指數式增加

（4）螺旋模式

一開始不必詳細定義所有的細節，先定義重要功能，努力實作這些功能，接收客戶回報，然後進入下一階段。

每一階段包括 6 個步驟：

（1）确定目标、可選方案和限制條件

（2）明确并化解風險

（3）評估可選方案

（4）目前階段開發和測試

（5）計劃下一階段

（6）确定進入下一階段的方法

軟體測試員喜歡這個模式，因為他們很早就參與開發過程，有機會盡早發現問題，為項目節省時間和金錢。

第 3 章 軟體測試的實質

本章重點：

（1）軟體為什麼永遠不會完美

（2）軟體測試為什麼不僅僅是技術問題

（3）軟體測試員的常用術語

3.1 測試的原則

• 1. 完全測試程式是不可能的

  主要原因：

  （1）輸入量太大。

  （2）輸出結果太多。

  （3）軟體執行路徑太多。

  （4）軟體說明書是主觀的，從旁觀者角度來看是缺陷。

• 2. 軟體測試是有風險的行為

  如果不測試所有的情況，就是選擇了冒險。測試量和發現的軟體缺陷數量之間的關系：

  

• 3. 測試無法顯示潛伏的軟體缺陷

  軟體測試工作可以報告軟體缺陷存在，但不能報告軟體缺陷不存在。

• 4. 找到的缺陷越多，說明軟體缺陷越多

  原因：

  （1）程式員也有心情不好的時候

  （2）由于習慣，程式員往往犯同樣的錯誤

  （3）某些軟體缺陷實乃冰山一角。某些軟體缺陷可能開始毫無聯系，但可能是由一個嚴重的主要原因造成的

• 5. 殺蟲劑怪事

  軟體會有“抗藥性”。軟體測試員必須不斷編寫不同的、新的測試程式，對不同的部分進行測試。

• 6. 并非所有軟體缺陷都要修複

  根據第 1 章軟體測試員應具備的素質（5），進行良好的判斷，搞清楚在什麼情況下不能追求完美。

  不需要修複軟體缺陷的原因：

  （1）沒有足夠的時間

  （2）不算真正的軟體缺陷

  （3）修複的風險太大。修複一個軟體缺陷可能導緻其他軟體缺陷出現

  （4）不值得修複。不常出現的缺陷、不常用功能中出現的缺陷、使用者有辦法預防或避免的缺陷等，通常不用修複，這些都歸結為商業風險決策。

• 7. 什麼時候才叫缺陷難以說清

  根據第 1 章軟體缺陷的定義去判定。

  沒有看見就不能說存在缺陷。尚未發現或未觀察到的軟體缺陷隻能說是潛在缺陷。

• 8. 産品說明書沒有最終版本

• 9. 軟體測試員在産品小組中不受歡迎

  保持小組成員和睦的建議：

  （1）早點找出缺陷

  （2）控制情緒

  （3）不要總是報告壞消息

• 10. 軟體測試是一項講究條理的技術專業

3.2 軟體測試的主語和定義

• 1. 精确和準确

  

  軟體測試要精度還是準度很大程度上取決于 産品是什麼，最終取決于 開發小組的目标。

• 2. 确認和驗證

  确認：保證軟體符合産品說明書的過程

  驗證：保證軟體滿足客戶要求的過程

• 3. 品質和可靠性

  可靠性僅僅是品質的一個方面。

  軟體産品品質高就是指它能夠滿足客戶要求，客戶感到該産品性能卓越，優于其他産品。

  為了確定程式品質高而且可靠性強，軟體測試員必須在整個産品開發過程中進行确認和驗證。

• 4. 測試和品質保證

  軟體測試員的目标：盡可能早地找出軟體缺陷，并確定缺陷的已修複

  軟體品質保證人員：建立和執行 改進軟體開發過程并防止軟體缺陷發生的 标準和方法

  雙方的工作是交叉的。

(第二部分 測試基礎)

第 4 章 檢查産品說明書（靜态黑盒測試）

本章重點：

（1）什麼是黑盒測試和白盒測試

（2）靜态測試和動态測試有何差別

（3）審查産品說明書有哪些進階技術

（4）在詳細審查産品說明書時應注意哪些特殊問題

4.1 開始測試

確定最終産品符合客戶要求 以及 正确計劃測試投入 的唯一方法是 在産品說明書中完整描述産品。

編寫詳細産品說明書的另一好處：軟體測試員可以将其作為測試項目的書面材料，據此可以在編寫代碼之前找出軟體缺陷。

4.1.1 黑盒測試和白盒測試

黑盒測試（功能測試、行為測試）	白盒測試
隻需知道軟體要做什麼，無法知道軟體是如何運作的	可以通路程式員的代碼，并通過檢查代碼來協助測試

4.1.2 靜态測試和動态測試

靜态測試	動态測試
隻是檢查和稽核	使用和運作軟體

4.1.3 靜态黑盒測試、測試産品說明書

測試産品說明書屬于靜态黑盒測試，因為：

（1）産品說明書是書面文檔，而不是可執行程式，是以是靜态的；

（2）産品說明書是利用各種資源獲得的資料，不必了解怎樣和為什麼要擷取這些資訊，以及擷取這些資訊的途徑，隻需要知道它們最終構成産品說明書就可以了，是以是黑盒。

4.2 對産品說明書進行進階審查

測試産品說明書的第一步：站在一個高度上進行審查

1. 假設自己是客戶

   （1）了解客戶所想（牢記，品質的定義是 “滿足客戶要求” ），但同時不要忘記軟體安全性問題，因為客戶可能會假設軟體是安全的，但軟體測試員不能這樣。

   （2）假設什麼知識也沒有。要搞懂産品說明書的任何細節。

2. 研究現有的标準和規範

   标準比規範更加嚴格。标準必須嚴格遵守，規範可選。

   項目經理 ：定義軟體要符合何種标準和規範

   軟體測試員：觀察、檢查采用的标準是否正确、有無遺漏；在對産品進行确認和驗收時，還要注意是否與标準和規範相抵觸，把标準和規範視為産品說明書的一部分。

3. 審查和測試類似軟體

   類似軟體有助于設計測試條件和測試方法，還可能暴露意想不到的潛在問題。

4.3 産品說明書的低層次測試技術

4.3.1 産品說明書屬性檢查清單

（1）完整

（2）準确

（3）精确、不含糊、清晰

（4）一緻

（5）貼切

（6）合理

（7）代碼無關

（8）可測試性

4.3.2 産品說明書術語檢查清單

第 5 章 戴上眼罩測試軟體（動态黑盒測試 / 行為測試）

本章重點：

（1）動态黑盒測試是什麼

（2）如何通過等價類劃分減少測試用例的數量

（3）如何判别故障邊界條件

（4）使用良好資料引入缺陷

（5）如何測試軟體狀态和狀态轉換

（6）如何使用重複、壓迫和重負的方法找出缺陷

（7）缺陷的一些秘密隐藏之處

5.1 動态黑盒測試：戴上眼罩測試軟體

輸入資料 ——> 接受輸出 ——> 檢驗結果

動态黑盒測試 又稱 行為測試，因為測試的是軟體在使用過程中的實際行為。

測試用例：進行測試時使用的特定輸入，以及測試軟體的過程步驟。選擇測試用例是軟體測試員最重要的一項任務。

5.2 通過性測試和失效性測試

通過性測試： 确認軟體至少能做什麼，僅僅運用最簡單、最直覺的測試用例。在設計和執行測試用例時，總是先進行通過性測試

失效性測試 / 錯誤強制性測試： 為了破壞軟體而設計和執行的測試用例。失效性測試通常不會出現

5.3 等價類劃分

一個等價類：指的是 測試相同目标 或 暴露相同軟體缺陷 的一組測試用例。

等價類劃分的目标：把可能的測試用例集縮減到可控制且仍然足以測試軟體的小範圍内。要注意，過分劃分等價類就有漏掉那些可能暴露軟體缺陷的測試的風險。

5.4 資料測試

對資料進行測試，就是在檢查使用者輸入的資訊、傳回的結果、中間計算結果是否正确。使所有的資料得以測試的技巧：等價類劃分，以合理減少測試用例。

等價類劃分的原則：邊界條件、次邊界條件、空值、無效資料

1. 邊界條件

   如果軟體能在其邊界運作，那麼正常情況下就應該不會有什麼問題。

   （1）邊界條件類型

   邊界條件是指：軟體運作在計劃操作界限的邊界的情況。

   可能出現的邊界條件：

   

   （2）測試邊界

   從等價劃分中選擇測試資料時，從邊界條件中選擇，往往會找出更多的軟體缺陷。

   注意：要測試臨近邊界的有效資料，同時測試剛超過邊界的無效資料。（越界測試）

   

2. 次邊界條件

   次邊界條件 / 内部邊界條件：在軟體内部的最終使用者幾乎看不到的邊界。

   （1）2的幂

   （2）ACSII表

3. 預設值、空白、空值、零值、無輸入

4. 非法、錯誤、不正确、垃圾資料

   邊界測試、次邊界測試、預設值測試等——都屬于通過性測試

   垃圾資料——屬于失效性測試（這類測試沒有實際的規則，隻是設法破壞軟體，要發揮創造力、會走偏門）

5.5 狀态測試

軟體狀态：軟體目前所處的條件或者模式

例如：Windows畫圖程式中，鉛筆繪畫狀态、噴塗狀态等。一旦選中全部選項（工具、菜單、顔色）中的任一項，使軟體改變了外觀、菜單或是某些操作，就是改變了該軟體的狀态。

1. 測試軟體的邏輯流程

   運用等價劃分技術選擇狀态和分支。

   （1）建立狀态轉換圖

   狀态轉換圖如果作為産品說明的一部分被提供出來，那麼可以用第 4 章檢查産品說明書的技術進行靜态測試。

   否則，需要建立一個狀态圖，例如：

   

   狀态轉換圖應包含：

   （1）軟體可能進入的每一種獨立狀态。不确定的也可以視為獨立狀态，若之後發現不是，随時可以剔除。

   （2）從一種狀态進入另一種狀态所需的輸入和條件。

   （3）進入或者推出某種狀态時的設定條件及輸出結果。包括顯示的菜單按鈕、設定的标志位、産生的列印輸出、執行的運算等。

   （2）減少要測試的狀态及轉換的數量

   将大量的可能性減少到可以操作的測試用例集合，有以下 5 種實作方法：

   （1）每種狀态至少通路一次。

   （2）測試看起來最常見和最普遍的狀态轉換。

   （3）測試狀态之間最不常用的分支。（容易被忽略）

   （4）測試所有錯誤狀态及其傳回值。

   （5）測試随機狀态轉換。（見第 15 章，自動測試和測試工具）

   （3）怎樣進行具體的測試

   确定要測試的 狀态 及其 轉換 之後，就可以定義 測試用例 了。

   測試 狀态 及其 轉換 包括檢查所有的 狀态變量——與進入和退出狀态相關的靜态條件、資訊、值、功能等。

2. 失敗狀态測試

   （1）競争條件和時序錯亂

   指的是幾個事件恰巧擠在一起，由于軟體未預料到運作過程會被中斷，以緻造成混亂。也就是說，時序發生錯亂。

   

   （2）重複、壓迫、重負

   重複測試：不斷執行同樣的操作。不停地啟動、關閉同一個程式，反複讀寫資料等。主要是為了檢查是否存在 記憶體洩漏。

   如果一個程式在開始啟動時工作狀态良好，但是随後變得越來越慢，或者經過一段時間就表現不穩定，原因就可能是存在記憶體洩漏缺陷，重複測試就可以暴露這些問題。

   壓迫測試：使軟體在不夠理想的條件下運作。觀察軟體對外部資源的要求和依賴程度。壓迫測試就是将支援降到最低限度，目的在于盡可能地限制軟體的必要條件。

   重負測試：與壓迫測試相反，盡量提供條件任其發揮。讓軟體處理盡可能大的資料檔案。如果軟體對列印機或者通信端口之類的外設進行操作，就把可能的都連上。如果測試正在測試的網際網路伺服器可以處理幾千個并發連接配接，就按它說的做。長時間運作也是重負測試。

5.6 其他黑盒測試技術

1 像笨拙的使用者那樣做

2 在已經找到軟體缺陷的地方再找找

3 像黑客一樣考慮問題

4 憑借經驗、直覺和預感

第 6 章 檢查代碼（靜态白盒測試 / 結構化分析）

本章重點：

（1）靜态白盒測試的好處

（2）各種類型的靜态白盒測試綜述

（3）編碼規範和标準

（4）如何從整體審查代碼錯誤

6.1 靜态白盒測試：檢查設計和代碼

靜态白盒測試：不執行軟體的條件下有條理地仔細審查軟體設計、體系結構和代碼，進而找出軟體缺陷的過程，有時稱為結構化分析。

靜态白盒測試的原因：（1）盡早發現軟體缺陷，以找出 動态黑盒測試 難以發現或隔離的軟體缺陷。（2）為黑盒測試員在接受軟體進行測試時設計和應用測試用例提供思路。

6.2 正式審查

正式審查 就是進行靜态白盒測試的過程。

正式審查的 4 個基本要素：

（1）确定問題。 面向問題而不是面向個人。

（2）遵守規則。

（3）準備。

（4）編寫報告。

正式審查的作用：發現問題。除此之外還有一些間接的效果：

（1）交流。正式報告中未包含的資訊得以交流

（2）品質。可以使得程式員對自己的代碼更加仔細

（3）小組同志化。可以建立測試員和程式員之間的互相尊重，并了解互相的工作需求

（4）解決方案。

6.2.1 同僚審查 / 夥伴審查

初次正式審查。（聚集起來讨論代碼，但仍然要盡量遵守正式審查的 4 個基本要素）

人員組成：編寫代碼或設計體系結構的程式員、充當審查者的其他一兩個程式員。

6.2.2 走查

比同僚審查更正規化的下一步。 同樣要遵守正式審查的 4 個基本要素

人員組成：編寫代碼的程式員、5 人小組或其他程式員和測試員組成的小組。前者向後者做正式陳述。

6.2.3 檢驗

最正式的審查類型。

人員組成：表述者、檢驗員

與同僚審查和走查不同之處： 表述代碼的人不是原來的程式員。這就迫使表述者學習和了解要表述的材料，進而有可能在會議上提出不同的看法和解釋。

檢驗員的職責是從不同的角度（使用者、測試員、産品支援人員等）審查代碼，還可能被任為會議協調員和會議記錄員，以保證檢驗過程遵守規則及審查有效進行。

6.3 編碼标準和規範

有三個重要的原因要堅持标準或規範：

（1）可靠性。 按照某種标準或規範編寫的代碼比不這樣做的代碼更加可靠和安全

（2）可讀性 / 維護性。 符合裝置标準或規範的代碼易于閱讀、了解和維護

（3）移植性。 如果代碼符合裝置标準，遷移到另一平台就會輕而易舉，甚至完全沒有障礙

6.4 通用代碼審查清單

（1）資料引用錯誤。使用未經正确聲明和初始化的變量、常量、數組、字元串或記錄而導緻的軟體缺陷。

（2）資料聲明錯誤

（3）計算錯誤

（4）比較錯誤

（5）控制流程錯誤。程式設計語言中循環等控制結構未按預期方式工作。

（6）子程式參數錯誤

（7）輸入/輸出錯誤。包括檔案讀取、接受鍵盤輸入或滑鼠輸入、向列印機或者螢幕等輸出裝置輸出錯誤。

（8）其他檢查

第 7 章 帶上 X 光眼鏡測試軟體（動态白盒測試 / 結構化測試）

本章重點：

（1）什麼是動态白盒測試

（2）調試和動态白盒測試之間的差別

（3）單元和內建測試是什麼

（4）如何測試底層功能

（5）底層測試所需的資料範圍

（6）如何強制軟體以某種方式運作

（7）衡量測試完整性的各種方法

7.1 動态白盒測試

動态白盒測試：檢視代碼功能（做什麼）和實作方式（怎麼做）得到的資訊來确定哪些需要測試、哪些不需要測試、如何展開測試。（軟體測試員可以檢視并使用代碼的内部結構，進而設計和執行測試，了解軟體的運作方式有助于選擇合适的測試方法。）

動态白盒測試包括以下 4 個部分：

（1）直接測試底層函數、過程、子程式、庫

（2）以完整程式的方式從頂層測試軟體，根據對軟體運作的了解調整測試用例

（3）從軟體獲得讀取變量和狀态資訊的通路權，以便确定測試與預期結果是否相符。

（4）估算測試覆寫率，調整測試，去掉多餘測試用例，補充遺漏的測試用例

7.2 動态白盒測試和調試

都包括處理軟體缺陷和檢視代碼，但 目标 不同。

動态測試的目标： 尋找軟體測試

調試的目标： 修複缺陷

但他們在隔離軟體缺陷的位置和原因上有交叉。

7.3 分段測試

7.3.1 單元測試和內建測試

代碼分段建構和測試，最後合并在一起形成更大的部分，形成産品。

• 在底層進行的測試稱為單元測試 或子產品測試。
• 對子產品間的內建進行的測試稱為內建測試。
• 最後對整個産品（至少是産品的主要部分）進行的測試稱為系統測試。
• 自底向上測試：需要編寫測試驅動子產品來代替上層子產品，調用正在測試的子產品。測試驅動子產品向處于測試的子產品發送測試用例資料、接受傳回結果、驗證結果是否正确
• 自頂向下測試：編寫樁子產品來代替下層子產品。

7.3.2 單元測試示例

（1）首先确定此子產品屬于程式中的底層子產品，可以由其他子產品調用，但自己不能調用其他子產品。是以需要編寫一個驅動子產品

（2）分析說明書，确定應該采用黑盒測試用例

（3）運用等價類劃分法減少測試用例集合

（4）研究代碼看函數是如何實作的，利用白盒測試知識增減測試用例，其實是根據程式内部的資訊對等價類劃分的進一步提煉

7.4 資料覆寫

檢視代碼決定如何調整測試用例合理的方法是，把軟體分成資料和狀态（或程式流程）。

**資料：**包括變量、常量、數組、資料結構、鍵盤和滑鼠的輸入、檔案、螢幕輸入輸出，以及數據機、網絡等裝置的輸入輸出。

• 資料流

  資料流覆寫：是指在軟體中完全跟蹤一批資料

  黑盒測試隻能知道變量開始和結束時候的值，動态白盒測試可以在程式運作期間檢查變量的中間值，進而更改測試用例，保證變量取得感興趣的、甚至具有風險的值。

• 次邊界

  進行白盒測試需要仔細檢查代碼找到次邊界條件，并建立能測試它們的測試用例。

• 公式和等式

  撇開代碼中的公式和等式，檢視它們使用的變量，在程式中正常輸入和輸出之外，為其建立測試用例和等價類劃分。

• 錯誤強制

  ？？？沒懂

7.5 代碼覆寫

測試程式的狀态以及程式流程。代碼覆寫是設法進入和退出每一個子產品，執行每一行代碼，進入軟體每一條邏輯呵呵決策分支。

對于小程式或單獨子產品，可以利用編譯環境的調試器通過單步執行程式檢視代碼。

但對大多數程式進行代碼覆寫要用到代碼覆寫分析器。利用代碼覆寫分析器可以得到：

（1）測試用例沒有覆寫軟體的哪些部分

（2）那些測試用例是多餘的

（3）為了使覆寫率更好，需要建立什麼樣的新測試用例

（4）還可以得到軟體品質的大緻情況。

• 語句覆寫/代碼行覆寫

  保證程式中每一條語句最少執行一次。

  但是，即使全部語句都被執行了，不能說明走遍了軟體的所有路徑

• 分支覆寫/路徑覆寫

  試圖覆寫軟體中的所有路徑。

  大多數代碼覆寫率分析器将根據代碼分支，分别報告語句覆寫和分支覆寫的結果，使軟體測試員更加清楚測試結果

• 條件覆寫

  将分支語句的條件考慮在内。

  代碼覆寫率分析器可以被設定為将條件考慮在内。如果測試條件覆寫，就能達到分支覆寫，順便也能達到語句覆寫