軟件缺陷的正式定義
符合下列5個規則才能叫軟件缺陷：
1. 軟件未達到產品說明書標明的功能
2. 軟件出現了產品說明書指明不會出現的錯誤
3. 軟件功能超出產品說明書指明范圍
4. 軟件未達到產品說明書雖未指出但應達到的目標
5. 軟件測試員認為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好。
軟件測試員的目標
盡可能早地找出軟件缺陷，并確保其得以修復。
軟件測試員應具備的素質
－ 探索精神（喜歡拿到新軟件）
－ 故障排除能手（善于發現問題的癥結）
－ 不懈努力（不停嘗試）
－ 創造性（想出富有創意甚至超常的手段來尋找缺陷）
－ 追求完美（但對知道無法企及的東西也不強求）
－ 判斷準確（決定測試內容、測試時間、是否真正的缺陷）
－ 老練穩重（知道如何將壞消息告訴程序員，知道如何跟不夠冷靜的程序員合作）
－ 說服力（善于表達觀點，通過實際演示標明缺陷為何必須修復）
軟件開發模式
從最初構思到公開發行軟件產品的過程稱為軟件開發模式。
－ 大棒式（要么成功，要么失敗）
－ 邊寫邊改式（沒有時間做好，總有時間返工）
－ 流水式（創意、分析、設計、開發、測試、產品一步步進行，不能后退。前一步完成才能進入下一階段）
－ 螺旋式（主要思想是：開始不必詳細定義所有細節。從小開始，定義重要功能，努力實現，接受客戶反饋，然后進入下一階段。一個螺旋包括6個步驟：1.確定目標、可選方案和限制條件；2.指出并解決風險；3.評估方案；4.本階段開發和測試；5.計劃下一階段；6.確定進入下一階段的方法）
術語－準確 vs 精確
－ 準確：參照物是目標。與目標越接近，就越準確
－ 精確：參照物是每次實施的結果。幾次結果相互之間越接近，表示越精確。但與目標可能相去甚遠
術語－驗證 vs 合法性檢查
－ 驗證：保證軟件符合產品說明書的過程
－ 合法性檢查：保證軟件滿足用戶要求的過程。
很多時候產品說明書并沒有完全反映出用戶的要求！
術語－測試 vs 質量評判(QA)
－ 測試：軟件測試員的目標是找出軟件缺陷，盡可能造一些，確保得以修復。
－ 質量評判：軟件質量評判人員的主要指責是創建和加強促進軟件開發并防止軟件缺陷的標準和方法
黑盒測試 vs 白盒測試
－ 黑盒測試：軟件測試員只需知道軟件要做什么，無需知道是如何運作的。只關心輸入和輸出
－ 白盒測試：軟件測試員可以訪問程序員的代碼，并通過檢查代碼來協助測試。
靜態測試 vs 動態測試
－ 靜態測試：只測試不運行的部分——只是檢查和審閱。
－ 黑盒測試：指通常意義上的測試——運行和使用軟件。
對產品說明書進行審查
－ 熟悉軟件應用領域的相關知識
這一點極有好處，設身處地的為客戶著想
－ 研究現有的標準和規范。
軟件測試員要做的，不是定義、而是“檢驗”是否套用了正確的標準，有無遺漏。
如：公司慣用語和約定；行業要求；國家標準；圖形用戶界面；硬件和網絡標準
－ 審查和測試同類軟件
同類軟件有助于制訂測試條件和測試方法，還可能暴露沒想到的潛在問題。
** 低級測試－ 屬性檢查清單（8個）
~ 完整。 完全？單獨使用是否包含全部內容？
~ 準確。 方案正確？目標明確？
~ 精確、不含糊、清晰。 容易看懂和理解？
~ 一致。 功能描述是否自相矛盾？有無沖突？
~ 貼切。 功能陳述是否必要？信息冗余？是否客戶要求？
~ 合理。 以現有人力、物力和資源能否實現？
~ 代碼無關。 定義產品，而不是設計、架構或代碼！
~ 可測試。 是否提供足夠的測試信息？
－ 用語檢查清單
~ 總是、每一種、所有、沒有、從不。
對此類絕對或肯定的切實認定的敘述，應設計針鋒相對的案例。
~ 當然、因此、明顯、顯然、必然。
這些話意圖誘使接受假定情況。小心中了圈套哦。
~ 某些、有時、常常、通常、經常、大多、幾乎、
太過模糊。“有時”發生的功能無法測試。
~ 等等、諸如此類、依此類推、
以這樣的詞結束的功能清單無法測試。功能清單必須絕對、解釋明確。不能推論。
~ 良好、迅速、廉價、高效、穩定、
這些是不確定的說法，不可測試。必須要求進一步指明含義。
~ 已處理、已拒絕、已忽略、已消除、
這些說法可能會隱藏大量需要說明的功能
~ 如果……那么……（沒有否則）。
想想，“如果”沒有發生會怎樣呢？** 高級審查
動態黑盒測試
不深入代碼細節的軟件測試方法。常被稱為行為測試，因為測試的是軟件在使用過程中的實際行為。
首先，從產品說明書獲知測試對象的軟件的輸入和應該得到的輸出。
接下來，開始定義測試案例。 測試案例：指進行實驗用的輸入，以及測試軟件用的程序。
選擇測試案例是軟件測試員最重要的任務。不正確的選擇可能導致測試量過大或者過小，甚至測試目標不對。準確評估風險，把不可窮近的可能性減少到可以控制的范圍是成功的訣竅。
測試基本方法：通過測試 vs 失敗測試
通過測試：確認軟件至少能做什么，而不考驗其能力。
失敗測試：純粹為了破壞軟件而設計和執行的測試案例，也稱為迫使出錯測試。蓄意攻擊軟件的薄弱環節。
在設計和執行測試案例時，總是首先進行通過測試。在破壞性試驗之前看看軟件基本功能是否實現是很重要的，否則在正常使用軟件時就會奇怪為什么有那么多的軟件缺陷。
常見的測試案例就是設法迫使軟件出現錯誤提示信息。產品說明書可能會給出這樣的功能要求，針對這個問題的測試可能是通過測試也可能是失敗測試。可能兩者都是。不用去刻意區分，重要的是找到軟件缺陷！
選擇測試案例：等價分配
等價分配：是指分步驟地把過多（無限）的測試案例減小到同樣有效的小范圍的過程。也稱等價劃分。
等價分配技術提供了一個選擇哪些數值、舍棄哪些數值的系統方法。
等價類別或者等價區間是指測試相同目標或者暴露相同軟件缺陷的一組測試案例。在尋找等價區間時，想辦法把軟件的相似輸入、輸出、操作分成組。這些組就是等價區間。
等價分配的目的是把可能的測試案例組合縮減到仍然足以測試軟件的控制范圍。因為選擇了不完全測試，就要冒一定的風險。如果為了減少測試案例的數量過度進行等價分配，測試的風險就會增加。另外，等價區間的劃分沒有一定的標準，只要足以覆蓋測試對象就行了。
數據測試
軟件由數據（包括鍵盤輸入、鼠標單擊、磁盤文件、打印輸出等等）和程序（可執行的流程、轉換、邏輯和運算）兩個最基本的要素組成。
對數據進行軟件測試，就是在檢查用戶輸入的信息、返回結果以及中間計算結果是否正確。主要根據下列原則來進行等價分配，以合理減少測試案例：邊界條件、次邊界條件和無效數據。
1. 邊界條件測試
程序在處理大量中間數值時都是對的，但是可能在邊界處出現錯誤。比如數組的[0]元素的處理。想要在Basic中定義一個10個元素的數組，如果使用 Dim data(10) As Integer ，則定義的是一個11個元素的數組，在賦初值時再使用 For i =1 to 10 ...來賦值，就會產生權限，因為程序忘記了處理i＝0的0號元素。
邊界條件是指軟件計劃的操作界限所在的邊緣條件。
數據類型：數值、字符、位置、數量、速度、地址、尺寸等，都會包含確定的邊界。
應考慮的特征：第一個/最后一個、開始/完成、空/滿、最慢/最快、相鄰/最遠、最小值/最大值、超過/在內、最短/最長、最早/最遲、最高/最低。這些都是可能出現的邊界條件。
根據邊界來選擇等價分配中包含的數據。然而，僅僅測試邊界線上的數據點往往不夠充分。提出邊界條件時，一定要測試臨近邊界的合法數據，即測試最后一個可能合法的數據，以及剛超過邊界的非法數據。以下例子說明一下如何考慮所有可能的邊界：
如果文本輸入域允許輸入1－255個字符。
嘗試：輸入1個字符和255個字符（合法區間），也可以加入254個字符作為合法測試。
輸入0個字符和256個字符作為非法區間。
如果程序讀寫軟盤
嘗試：保存一個尺寸極小，甚至只有一項的文件。
然后保存一個很大的——剛好在軟盤容量限制之內的文件。
保存空文件。
保存尺寸大于軟盤容量的文件。
如果程序允許在一張紙上打印多個頁面
嘗試：只打印一頁
打印允許的最多頁面
打印0頁
多于所允許的頁面（如果可能的話）
2. 次邊界條件測試
上面所講的是普通的邊界條件，在產品說明書中有定義，或者在軟件的過程中確定。但有些邊界在軟件內部，最終用戶幾乎看不到，但是軟件測試仍有必要檢查，這樣的邊界條件成為次邊界條件或者內部邊界條件。尋找這樣的邊界條件，不要求軟件測試員成為程序員或者具有閱讀源代碼的能力，但是確實要求大體了解軟件的工作方式。2的乘方和ASCII表是這樣的兩個例子： 2的乘方
術語 | 范圍或值 |
位bit | 0或1 |
雙位doublebit | 0～15 |
字節Byte | 0~255 |
字word | 0~65,535或者0～4,294,967,295 |
千K | 1,024 |
兆M | 1,048,576 |
億 | 1,073,741,824 |
萬億 | 1,099,511,627,776 |
計算機和軟件的基礎是二進制數。因此二的乘方是作為邊界條件的重要數據。如：在通訊軟件中，帶寬或者傳輸信息的能力總是受限制，因此軟件工程師會盡一切努力在通訊字符串中壓縮更多數據。其中一個方法就是把信息壓縮到盡可能小的單元中，發送這些小單元中最常用的信息，在必要時再擴展為大一些的單元。假設某種通訊協議支持256條命令。軟件將發送編碼為一個雙位數據的最常用的15條命令；如果用到第16到256之間的命令，軟件就轉而發送編碼為更長字節的命令。這樣，軟件就會根據雙位/字節邊界執行專門的計算和不同的操作。
在建立等價區間的時候，要考慮是否需要包含2的乘方邊界條件。例如：軟件接受1～1000范圍內的數字，那么合法區間除了1和1000，也許還有2和999之外，還應該有臨近2的乘方次邊界：14，15，16以及254，255和256。
ASCII表
ASCII碼表并不是結構良好的連續表。數字0～9對應48～57；斜杠字符(/)在0的前面，冒號(:)在9的后面；大寫字母A～Z對應65～90；小寫字母對應97～122。這些情況都代表次邊界條件。
如果測試進行文本輸入或文本轉換的軟件，在定義數據區間包含哪些值時，參考一下ASCII表是相當明智的。例如：測試的文本框只接受用戶輸入字符A～Z和a～z，就應該在非法區間中包含ASCII表中這些字符前后的值——@，'，[，{。 3. 默認值測試（默認、空白、空值、零值和無）
好的軟件會處理這種情況，常用的方法：一是將輸入內容默認為合法邊界內的最小值，或者合法區間內某個合理值；二是返回錯誤提示信息。
這些值在軟件中通常需要進行特殊處理。因此應當建立單獨的等價區間。在這種默認下，如果用戶輸入0或－1作為非法值，就可以執行不同的軟件處理過程。
4. 破壞測試（非法、錯誤、不正確和垃圾數據）
數據測試的這一類型是失敗測試的對象。這類測試沒有實際規則，只是設法破壞軟件。不按軟件的要求行事，發揮創造力吧！
狀態測試
狀態測試是通過不同的狀態驗證程序的邏輯流程。軟件測試員必須測試軟件的狀態及其轉換。軟件狀態是指軟件當前所處的情況或者模式。軟件通過代碼進入某一個流程分支，觸發一些數據位，設置某些變量，讀取某些變量，從而轉入一個新的狀態。
同數據測試一樣，狀態測試運用等價分配技術選擇狀態和分支。因為選擇不完全測試，所以要承擔一定的風險，但是通過合理選擇減少危險。
1. 建立狀態轉移圖
使用：方框和箭頭；圓圈（泡泡）和箭頭。
應包含的項目：
－ 軟件可能進入的每一種獨立狀態。
如果不能斷定是否獨立，先認為是；以后一旦發現不是，隨時剔除。
－ 從一種狀態轉入另一種狀態所需的輸入和條件。
狀態變化和存在的原因，就是我們要尋找的對象。
－ 進入或退出某種狀態時的設置條件及輸出結果。
包括顯示的菜單和按鈕、設置的標志位、產生的打印輸出、執行的運算等等。
由于是黑盒測試，因而只需從用戶的角度建立狀態圖即可。
2. 減少要測試的狀態及轉換的數量
測試每一種路線的組合，走遍所有分支是不可能的事情。大量的可能性也需要減少到可以操作的測試案例集合。方法有以下5種：
－ 每種狀態至少訪問一次。
無論用什么方法，每種狀態都必須測試。
－ 測試看起來最常見最普遍的狀態轉換
－ 測試狀態之間最不常用的分支。
這些分支是最容易被產品設計者和程序員忽視的。
－ 測試所有錯誤狀態機器返回值。
錯誤是否得到正確的處理、錯誤提示信息是否正確、修復錯誤時是否正確恢復軟件等
－ 測試隨機狀態轉換。
3. 進行具體的測試——定義測試案例
測試狀態及其轉換包括檢查所有的狀態變量——與進入和退出狀態相關的靜態條件、信息、值、功能等等。如：窗口外觀、窗口尺寸定義（固定/上次使用時的尺寸）、顯示的菜單、默認設定值、文檔的名稱等。狀態無論是否可見，都必須進行狀態確定。 狀態變量也許不可見，但是很重要，一個常見的例子時文檔涂改標志（以此判斷退出時是否詢問保存）。
失敗狀態測試
狀態測試的失敗測試的案例，主要是競爭條件、重復、壓迫和重負。
1. 競爭條件和時序錯亂
設計多任務操作系統不是很難，設計充分利用多任務能力的軟件才是艱巨的任務。在真正的多任務環境中軟件設計絕對不能想當然，必須處理隨時被中斷的情況，能夠與其他任何軟件在系統中同時運行，并且共享內存、磁盤、通信設備以及其他硬件資源。
這樣的結果，就是導致競爭條件問題；軟件未預料到的中斷發生，時序就會發生錯亂。
競爭條件測試難以設計，最好是首先仔細查看狀態轉換圖中的每一個狀態，以找出哪些外部影響會中斷該狀態。考慮要使用數據如果沒有準備好，或者在用到時發生了變化，狀態會怎樣。數條弧線或者直線同時相連的情形如何。
一下是要面臨競爭條件的典型情形：
－ 兩個不同的程序同時保存或打開同一個文檔。
－ 共享同一臺打印機、通信端口或者其他外圍設備。
－ 當軟件處于讀取或者修改狀態時按鍵或者單擊鼠標。
－ 同時關閉或者啟動軟件的多個實例。
－ 同時使用不同的程序方位一個共同數據庫。
2. 重復、壓迫和重負
這三個測試的目標是處理那些連程序員都沒有想到的惡劣條件下產生的問題的能力。
－ 重復測試
重復測試是不斷執行同樣的操作。最簡單的是不停地啟動和關閉程序，或者反復讀寫數據或者選擇同一個操作。這種測試的主要目的是看內存是否不足。如果內存被分配進行某項操作，但操作完成時沒有完全釋放，就會產生一個常見的軟件問題。
－ 壓迫測試
壓迫測試是使軟件在不夠理想的條件下運行——內存小、磁盤空間少、CPU速度慢、調制解調器速率低等等。觀察軟件對外部資源的要求和依賴程度。壓迫測試就是將支持降到最低限度，目的在于盡可能的限制軟件的必要條件。
－ 重負測試
重負測試和壓迫測試相反。壓迫測試是盡量限制軟件，而重負測試是盡量提供條件任其發揮。讓軟件處理盡可能大的數據文件。最大限度的發掘軟件的能力，讓它不堪重負。比如：軟件對打印機或通信端口進行操作，就把能連的都連上；服務器可以處理幾千個模擬連接，就按他說的做。
不要忘了，時間也是一種重負測試。
重復、壓迫和重負測試應聯合使用，同時進行。
需要注意的是：
一，項目管理員和小組程序員可能不完全接受軟件測試員這樣打破軟件的做法。但是軟件測試員的任務就是確保軟件在這樣惡劣的條件下正常工作，否則就報告軟件缺陷。如何以最佳方式報告軟件缺陷，使其得到嚴肅對待和修復，也是一門學問。
二，無數次重復和上千次的連接對于手工操作是不可能的。因而需要借助自動化測試工具來實現。
其他黑盒測試方法
1. 像無經驗的用戶那樣做
輸入意想不到的數據；中途變卦而退回去執行其他操作；單擊不應該單擊的東西……
2. 在已經找到軟件缺陷的地方再找找
原因有二：一是軟件缺陷的集中性。如果發現在不同的特性中找出了大量上邊界條件軟件缺陷，那么就應該對所有特性著重上邊界條件。對某個存在的缺陷，應當投入一些案例來保證這個問題不是普遍存在的。二是程序員往往傾向于只修改報告出來的軟件缺陷，不多也不少。比如報告啟動－終止－再啟動255次導致沖突，程序員可能只修復了這個問題。重新測試時，一定要重新執行同樣的測試256次以上。
3. 憑借經驗、直覺和預感
記錄哪些技術有效，哪些不行。嘗試不同的途徑。如果認為有可疑之處，就要仔細探究。按照預感行事，直至證實這是錯誤為止。
經驗是人們對錯誤行為的稱謂。
《軟件測試》讀書筆記（四）
靜態測試是指測試非運行部分——檢查和審查。白盒測試是指訪問代碼，能夠查看和審查。
靜態白盒測試實在不執行的條件下有條理地仔細審查軟件設計、體系結構和代碼，從而找出軟件缺陷的過程。有時也成為結構分析。
靜態白盒測試的原因，首先是盡早發現軟件缺陷；另外可為接受該軟件測試的黑盒測試員提供應用測試案例的思路，他們不必了解代碼細節，根據審查備注就可以確定可能存在問題的特性范圍。
正式審查——進行白盒測試的過程
正式審查含義廣泛，從程序員之間的交談，到代碼的嚴格檢查均屬于此過程。主要有4個基本要素：
－ 確定問題。
審查的目的，不僅是出錯的，還包括遺漏的項目。全部的批評應直指代碼，而不是其創建者。
－ 遵守規則
審查要遵守一套固定的規則，可能設定審查的代碼量、花費時間、備注內容對象，以幫助合作者確定 自己的目標，了解自己的作用。
－ 準備
每個合作者需要了解自己的責任和義務，并積極參與審查。
－ 編寫報告
審查小組必須做出總結審查結果的書面報告，并使報告便于開發小組使用。
正式審查的類型
1. 同事審查
召集小組成員進行初次正式審查是最簡單的方法。大體類似于“各抒己見”類型的討論。常常僅在編寫代碼的程序員和充當審查者的其他一兩個程序員和測試員之間進行。
2. 公開陳述
公開陳述是使同事審查正規化的下一步。編寫代碼的程序員像5人小組或其它類似的程序員或測試員正式表述，逐行或逐個通讀代碼，解釋代碼如何工作的以及為什么。審查人員應該在審查之前接到軟件拷貝，以便檢查并編寫備注和問題，在審查過程中提問。參與人數要多于同事審查。因此，做好準備和遵守規則是十分重要的。
3. 檢驗
檢驗是最正式的審查類型，具有高度組織化，要求每一個參與者都接受訓練。檢驗與同事審查不同之處在于表述代碼的人（表述者或宣讀者），不再是原來的程序員。這就迫使他學習和了解要表述的材料，從而有可能提出不同的看法和解釋。
檢驗員在檢驗中的職責是從不同的角度（如用戶、測試員或產品支持人員）的角度審查代碼，指出軟件缺陷。檢驗會議后，檢驗員可能再次碰頭討論他們發現的不足之處，并與會議主席共同準備一份書面報告，明確解決問題所必須重做的工作。
編碼標準和規范
堅持標準或規范的原因：
－ 可靠性。事實證明，代碼缺陷將更少
－ 可讀性、維護性。
－ 移植性。如果代碼符合設備標準，遷移到另一個平臺就會輕而易舉。
標準由4個主要部分組成：
－ 標題。描述主題。
－ 標準（或規范）。描述內容，解釋哪些允許，哪些不允許。
－ 解釋說明。給出指定該標準的原因。說服程序員。
－ 實例。這不是必需的。
注意：標準/規范和風格不是一回事。后者不是缺陷。
通過代碼審查清單
1. 數據引用錯誤
是指使用未經正確初始化用法和引用方式的變量、常量、數組、字符串或記錄而導致的軟件缺陷。如：變量未初始化、數組和字符串下標越界、對數組的下標操作遺漏[0]、變量與賦值類型不一致、引用的指針未分配內存……
2. 數據聲明錯誤
數據聲明軟件缺陷產生的原因是不正確的聲明或使用變量和常量。
3. 計算錯誤
計算或者運算錯誤是基本的數學邏輯問題。計算無法得到預期結果。如：不同數據類型 或 數據類型相同但長度不同的變量計算、計算過程中或計算結果溢出、賦值的目的變量上界小于賦值表達式的值、除數/模為0、變量的值超過有意義的范圍（如概率的計算結果不在0－1范圍內）……
4. 比較錯誤
小于、大于、等于、不等于、真、假。比較和判斷錯誤很可能是邊界條件問題。如：混淆小于和小于等于、邏輯表達式中的操作數不是邏輯值……
5. 控制流程錯誤
控制流程錯誤的原因是編程語言中循環等控制結構未按預期方式工作。通常由計算或者比較錯誤直接或間接造成。如：模塊或循環無法終止、存在從未執行的代碼、由于變量賦值錯誤而意外進入循環……
6. 子程序參數錯誤
子程序參數錯誤的來源是軟件子程序不正確的傳遞數據。如：實際傳送的參數類型或次序與定義不一致、更改了僅作為輸入值的參數……
7. 輸入/輸出錯誤
包括文件讀取、接受鍵盤或者鼠標輸入以及向打印機或者屏幕等輸出設備寫入錯誤。如：軟件沒有嚴格遵守外部設備讀寫數據的專用格式、文件或外設不存在或者為準備好的錯誤情況發生時沒有相應處理、未以預期的方式處理預計錯誤、錯誤提示信息不正確/不準確……
8. 其他檢查
軟件是否使用其他外語？處理字符集的范圍（ASCII或Unicode）？是否需要移植？是否考慮兼容性？編譯時是否產生警告或提示信息？
動態白盒測試
動態白盒測試是指利用查看代碼功能和實現方式得到的信息來確定哪些要測試，哪些不要測試，如何開展測試。動態白盒測試的另一個常用名稱是結構測試，因為軟件測試員可以查看并使用代碼的內部結構，從而設計和執行測試。
動態白盒測試不僅僅是查看代碼，還包括直接參數和控制軟件。動態白盒測試包括以下4個部分：
－ 直接測試底層功能、過程、子程序和庫。即應用程序接口（API）
－ 以完整程序的方式從頂層測試軟件，但是要根據對軟件運行的了解調整測試案例。
－ 從軟件獲得讀取變量和狀態信息的訪問權，以便確定測試與預期結果是否相符，同時，強制軟件以
正常測試難以實現的方式運行。
－ 估算執行測試時“命中”的代碼量和具體代碼，然后調整測試，去掉多余的，補充遺漏的。
動態白盒測試 vs 調試
白盒測試的目標是尋找軟件缺陷，調試的目的是修復它們。但是二者又有交叉的現象。測試員應該把問題縮減為能夠演示軟件缺陷的最簡化測試案例。在白盒測試中，甚至要包含那些值得懷疑的代碼行信息，以方便程序員有針對性的分析、判斷進而修復。
一定要分清軟件測試員和程序員的工作。程序員編寫代碼，測試員尋找軟件缺陷，可能還要編寫一些代碼來驅
動測試，然后程序員修復軟件缺陷。
要進行這樣的底層測試，就要使用與程序員相同的工具。如果程序已經編譯過，就要使用同樣的編輯器，但是
采用不同的設置，以加強錯誤檢測功能。
分段測試
從測試的角度看，產生高額費用有兩個原因：
－ 難以甚至不可能找出導致問題的原因
－ 某些軟件缺陷掩蓋了其他軟件缺陷。造成核心錯誤很難弄清。
單元測試和集成測試
在底層進行的測試稱為單元測試或者模塊測試。等到單元測試后，底層軟件缺陷被找出并修復之后，就集成在一起，對模塊組進行集成測試。最后直到整個產品（至少是主要部分）集成到一起進行系統測試。
這種測試策略很容易隔離軟件缺陷。主要有兩條途徑：
－ 自底向上
需要編寫測試驅動模塊來測試對象模塊。測試驅動模塊以將來真正模塊同樣的方式掛接，向處于測試底案例發送測試案例數據，接受返回結果，驗證結果是否正確。
－ 自頂向下
這種情況下，可以使用測試存根代碼的編寫，充當下層接口模塊，從文件中直接將參數提供給上層模塊。這樣，就可以從頭到尾試驗各種測試值，驗證上層模塊的操作。
示例：C語言中，將ASCII字符轉換為整數值的函數atoi()。
－ 首先，確定該模塊在程序中的位置——底層模塊，可以由高層模塊調用，但是自己不能調用其他模塊。通過查看內部代碼可以確認這一點。
－ 由上一步判定，確定應編寫一個測試驅動以獨立于程序其他不分的形式測驗該模塊。該測試驅動提
供測試字符串，讀取返回值，與預期結果相比較。編寫測試驅動的語言可以與函數的語言相同也可以不同；形式上，可以是簡單的對話框（交互性和靈活性強），也可以是獨立的程序（可快速的從文件讀寫測試用例）。
－ 分析說明書，確定應該采用的黑盒測試案例，然后運用等價分配技術參少測試案例集合。
－ 研究代碼看函數是如何實現的，利用模塊的白盒知識增減測試用例。
注意：在進行白盒測試之前，一定么根據說明書建立黑盒測試案例。這樣才能夠保證真正測試模塊的用意，完成測試預期的操作，而避免白盒測試中受代碼的影響而偏向模塊工作方式建立測試案例。
白盒測試時，合理的做法也是把軟件分成數據和狀態（或者程序流程）。從同樣的角度看待軟件，可以很輕松的把白盒信息映射到已經寫完的黑盒測試案例上。
數據范圍
數據包括所有的變量、常量、數組、數據結構、鍵盤和鼠標輸入、文件、屏幕輸入/輸出，以及調制解調器、網絡等其他設備的輸入/輸出。
1. 數據流
數據流范圍主要是指在整個軟件中跟蹤一批數據。在單元測試級，數據僅僅通過了一個模塊或者函數。如果在底層測試，就會使用調試器和觀察變量在程序運行時查看代碼，檢查中間值，從而保證質量。
2. 次邊界
白盒測試要仔細檢查代碼，找到次邊界條件，并建立測試他們的案例。除了ASCII碼表和2的乘方之外，常見的例子比如：運算時可能由使用數據表轉向使用公式；數據可能由RAM轉向硬盤；數值分析程序可能根據數字大小采用不同的方程式……
3. 公式和等式
公式和等式通常深藏于代碼中，從外部看，表現和影響不是很明顯。但是，在某些公式中，比如：
A=P(1+r/n)，白盒測試員在看到這個公式之后，就知道選擇n=0作為測試案例將導致除零錯，這樣不需運行測試用例即可預知缺陷。
然而，如果n是計算的結果（即可能會有很多種可能值），那么測試員就應該考慮有沒有n為零值的情形，并指出什么樣的程序輸入會導致它出現。
4. 錯誤強制
在執行測試用例時，不能或不方便使某一變量達到設定值，可通過強制賦值的方式達到目的。
在使用錯誤強制時，小心不要設立現實世界中不可能出現的情況。比如，上例中，如果函數開頭有判斷n值必須大于0，而且n只存在于該公式中，那么將n值強制設為零的測試案例就是不合理的。使用錯誤強制是迫使軟件中所有錯誤提示信息顯示出來的好方法。因為許多錯誤情況是難以建立的，比如掛接2049臺打印機。如果只是想測試錯誤提示信息是否正確，那么使用錯誤強制是最有效的。
代碼范圍
測試程序的狀態以及其中的程序流程，必須設法進入和退出每一個模塊，執行每一行代碼，追蹤每一條邏輯和決策分支。按級別詳細檢查軟件稱為代碼范圍分析。代碼范圍分析要求通過完全訪問代碼查看運行測試案例時經過哪些部分。其最簡單的形式是利用編譯環境的調試器通過單步執行程序查看代碼。對于大程序，需要用到稱為代碼范圍分析器的專用工具。從的得到的數據中可以很容易的獲知：測試案例沒有覆蓋軟件的哪些部分、哪些測試案例是多余的（增加該案例卻未增加代碼覆蓋比例）等，從而判定還需要建立哪些新的測試案例。
程序語句和代碼行范圍
代碼范圍最直接的形式稱為語句范圍或者代碼行范圍。如果在測試軟件的同時監視語句范圍，目標就是保證程序中每一條語句最少執行一次。但是，從某種程度上說，語句范圍是一種誤導，因為即使全部語句被執行了，并不代表走遍了軟件的所有路徑。
分支范圍
試圖覆蓋軟件中的所有路徑稱為路徑測試。路徑測試最簡單的形式稱為分支范圍測試。注意每一個判斷條件（組合）都會產生分支，即每個判斷條件（條件組合）的結果取真或假，都應該執行一次。
條件范圍
條件范圍測試將分支語句的附加條件考慮在內。與分支范圍不同的地方主要體現在多重條件的組合上。分支范圍把條件組合看作一個整體，而條件范圍把這種組合拆開，而對每個具體條件進行分析。保證每個具體條件的真假取值都做一遍。