前兩部分 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 產品的組成部分

• 軟件產品需要多少投入
  

客戶需求。 通過問卷調查、收集軟件以前的版本反饋信息、收集競爭產品信息、收集期刊評論、收集焦點人群意見等方式

產品說明書。 綜合上述信息以及沒有提出但必須要實現的需求，來定義產品是什么、有哪些功能、外觀如何

進度表。 Gantt 圖表或項目管理軟件，制定進度的目的：了解哪項工作完成了、還有多少工作要做、何時全部完成

軟件設計文檔。 設計規劃軟件如何編寫
常用的軟件設計文檔清單：
（1）結構文檔： 描述軟件整體設計的文檔，包括軟件所有主要部分的描述，以及相互之間的交互方式。
（2）數據流圖： 表示數據在程序中如何流動的正規示意圖。有時被稱為泡泡圖。
（3）狀態轉換圖： 把軟件分解成基本狀態或者條件的另一種正規示意圖，表示不同狀態間的轉換方式。
（4）流程圖： 用圖形描述程序邏輯的傳統方式。根據流程圖編寫程序代碼是很簡單的。
（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）了解客戶所想（牢記，質量的定義是 “滿足客戶要求” ），但同時不要忘記軟件安全性問題，因為客戶可能會假設軟件是安全的，但軟件測試員不能這樣。
（2）假設什么知識也沒有。要搞懂產品說明書的任何細節。

研究現有的標準和規范
標準比規范更加嚴格。標準必須嚴格遵守，規范可選。
項目經理 ：定義軟件要符合何種標準和規范
軟件測試員：觀察、檢查采用的標準是否正確、有無遺漏；在對產品進行確認和驗收時，還要注意是否與標準和規范相抵觸，把標準和規范視為產品說明書的一部分。

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

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）邊界條件類型
邊界條件是指：軟件運行在計劃操作界限的邊界的情況。
可能出現的邊界條件：

（2）測試邊界
從等價劃分中選擇測試數據時，從邊界條件中選擇，往往會找出更多的軟件缺陷。
注意：要測試臨近邊界的有效數據，同時測試剛超過邊界的無效數據。（越界測試）

次邊界條件
次邊界條件 / 內部邊界條件：在軟件內部的最終用戶幾乎看不到的邊界。
（1）2的冪
（2）ACSII表

默認值、空白、空值、零值、無輸入

非法、錯誤、不正確、垃圾數據
邊界測試、次邊界測試、默認值測試等——都屬于通過性測試
垃圾數據——屬于失效性測試（這類測試沒有實際的規則，只是設法破壞軟件，要發揮創造力、會走偏門）

5.5 狀態測試

軟件狀態：軟件當前所處的條件或者模式
例如：Windows畫圖程序中，鉛筆繪畫狀態、噴涂狀態等。一旦選中全部選項（工具、菜單、顏色）中的任一項，使軟件改變了外觀、菜單或是某些操作，就是改變了該軟件的狀態。

測試軟件的邏輯流程
運用等價劃分技術選擇狀態和分支。
（1）建立狀態轉換圖
狀態轉換圖如果作為產品說明的一部分被提供出來，那么可以用第 4 章檢查產品說明書的技術進行靜態測試。
否則，需要創建一個狀態圖，例如：

狀態轉換圖應包含：
（1）軟件可能進入的每一種獨立狀態。不確定的也可以視為獨立狀態，若之后發現不是，隨時可以剔除。
（2）從一種狀態進入另一種狀態所需的輸入和條件。
（3）進入或者推出某種狀態時的設置條件及輸出結果。包括顯示的菜單按鈕、設置的標志位、產生的打印輸出、執行的運算等。
（2）減少要測試的狀態及轉換的數量
將大量的可能性減少到可以操作的測試用例集合，有以下 5 種實現方法：
（1）每種狀態至少訪問一次。
（2）測試看起來最常見和最普遍的狀態轉換。
（3）測試狀態之間最不常用的分支。（容易被忽略）
（4）測試所有錯誤狀態及其返回值。
（5）測試隨機狀態轉換。（見第 15 章，自動測試和測試工具）
（3）怎樣進行具體的測試
確定要測試的 狀態 及其 轉換 之后，就可以定義 測試用例 了。
測試 狀態 及其 轉換 包括檢查所有的 狀態變量——與進入和退出狀態相關的靜態條件、信息、值、功能等。

失敗狀態測試
（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）還可以得到軟件質量的大致情況。

• 語句覆蓋/代碼行覆蓋
  保證程序中每一條語句最少執行一次。
  但是，即使全部語句都被執行了，不能說明走遍了軟件的所有路徑
• 分支覆蓋/路徑覆蓋
  試圖覆蓋軟件中的所有路徑。
  大多數代碼覆蓋率分析器將根據代碼分支，分別報告語句覆蓋和分支覆蓋的結果，使軟件測試員更加清楚測試結果
• 條件覆蓋
  將分支語句的條件考慮在內。
  代碼覆蓋率分析器可以被設置為將條件考慮在內。如果測試條件覆蓋，就能達到分支覆蓋，順便也能達到語句覆蓋

總結

以上是生活随笔為你收集整理的《软件测试 第 2 版》读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

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