代碼審查也使用與實現(xiàn)缺陷和潛在問題查找同樣復雜的技術。與白盒測試一樣，審查通常針對軟件的各個單元進行，因為一個有效的審查過程要求的是集中而詳盡的檢查。

與審查和白盒測試不同，功能測試或黑盒測試假設對軟件的實現(xiàn)一無所知，它測試由受控輸入所驅動的輸出。功能測試由測試人員或開發(fā)人員所編寫的測試過程組成，它們規(guī)定了一組特定程序輸入對應的預期程序輸出。測試運行之后，測試人員將實際輸出與預期輸出進行比較，查找問題。黑盒測試可以有效地找出未能實現(xiàn)的需求、接口問題、性能問題和程序最常用功能中的錯誤。

雖然將這些技術結合起來可以找出隱藏在一個特定軟件程序中的大部分錯誤，但它們也有局限。代碼審查和白盒測試每次只針對一小部分代碼，忽視了系統(tǒng)的其它部分。黑盒測試通常將系統(tǒng)作為一個整體來處理，忽視了實現(xiàn)的細節(jié)。一些重要的問題只有在集中考察它們在整個系統(tǒng)內(nèi)相互作用時的細節(jié)才能被發(fā)現(xiàn)；傳統(tǒng)的方法無法可靠地找出這些問題。必須整體地檢查軟件系統(tǒng)，查找具體問題的特定原因。由于詳盡徹底地分析程序中的每個細節(jié)和它與代碼中所有其它部分之間的相互作用通常是不大可能的，因此分析應該針對程序中已經(jīng)知道可能導致問題的特定方面。本文將探討其中三個潛在的問題領域：

* 堆棧溢出

* 競爭條件

* 死鎖

讀者可在網(wǎng)上閱讀本文的第二部分，它將探討下列問題：

* 時序問題

* 可重入條件

在采用多任務實時設計技術的系統(tǒng)中，以上所有問題都相當普遍。

堆棧溢出

處理器使用堆棧來存儲臨時變量、向被調函數(shù)傳遞參數(shù)、保存線程“狀態(tài)”，等等。如果系統(tǒng)不使用虛擬內(nèi)存(換句話說，它不能將內(nèi)存頁面轉移到磁盤上以釋放內(nèi)存空間供其它用途)，堆棧將固定為產(chǎn)品出廠時的大小。如果由于某種原因堆棧越出了編程人員所分配的數(shù)量范圍，程序將變得不確定。這種不穩(wěn)定可能導致系統(tǒng)發(fā)生嚴重故障。因此，確保系統(tǒng)在最壞情況下能夠分配到足夠的堆棧至關重要。

確保永不發(fā)生堆棧溢出的唯一途徑就是分析代碼，確定程序在各種可能情況下的最大堆棧用量，然后檢查是否分配了足夠的堆棧。測試不大可能觸發(fā)特定的瞬時輸入組合進而導致系統(tǒng)出現(xiàn)最壞情況。

堆棧深度分析的概念比較簡單：

1. 為每個獨立的線程建立一棵調用樹。

2. 確定調用樹中每個函數(shù)的堆棧用量。

3. 檢查每棵調用樹，確定從樹根到外部“樹葉”的哪條調用路徑需要使用的堆棧最多。

4. 將每個獨立線程調用樹的最大堆棧用量相加。

5. 確定每個中斷優(yōu)先級內(nèi)各中斷服務程序(ISR)的最大堆棧用量并計算其總和。但是，如果ISR本身沒有堆棧而使用被中斷線程的堆棧，則應將ISR使用的最大堆棧數(shù)加到各線程堆棧之上。

6. 對于每個優(yōu)先級，加上中斷發(fā)生時用來保存處理器狀態(tài)的堆棧數(shù)。

7.如果使用RTOS，則加上RTOS自身內(nèi)部用途需要的最大堆棧數(shù)(與應用代碼引發(fā)的系統(tǒng)調用不同，后者已包含在步驟2中)。