工程師講解PCB設計中軟件缺陷的查找

本文將介紹如何避免那些隱藏但常見的錯誤，并介紹幾種幫助工程師發現PCB抄板軟件中隱藏錯誤的技巧。 大多數軟件開發項目依靠代碼檢查、結構測試和功能測試的結合來識別軟件缺陷。 盡管這些傳統技術非常重要并且可以發現大多數軟件問題，但它們無法檢測當今復雜系統中的許多常見錯誤。

結構測試或白盒測試可以有效地發現代碼中的邏輯、控制流、計算和數據錯誤。 這種測試需要清楚地了解軟件的內部工作（因而稱為“白盒”或“玻璃盒”），從而了解軟件結構的細節。 它檢查每個條件表達式、數學運算、輸入和輸出。 由于需要測試的細節很多，結構測試一次檢查一個軟件單元，通常是一個函數或類。

代碼審查還使用復雜的技術來發現實現缺陷和潛在問題。 與白盒測試一樣，評審通常針對每個軟件單元進行，因為有效的評審過程需要集中且詳細的評審。

與評審和白盒測試不同，功能測試或黑盒測試假設不了解軟件實現，并測試由受控輸入驅動的輸出。 功能測試由測試人員或開發人員編寫的測試程序組成，這些測試程序指定與一組特定的程序輸入相對應的預期程序輸出。 測試運行后，測試人員將實際輸出與預期輸出進行比較，以發現問題。 黑盒測試可以有效地找出程序最常用功能中未滿足的需求、接口問題、性能問題和錯誤。

雖然這些技術可以結合起來找到隱藏在特定軟件程序中的大多數錯誤，但它們也有局限性。 代碼審查和白盒測試一次只關注一小部分代碼，而忽略系統的其他部分。 黑盒測試通常將系統視為一個整體，忽略實現的細節。 有些重要的問題只有關注它們在整個系統中的相互作用才能發現； 傳統方法無法可靠地識別這些問題。 必須對軟件系統進行整體檢查，找出特定問題的具體原因。 由于通常不可能徹底分析程序的每個細節及其與代碼所有其他部分的交互，因此分析應重點關注程序中已知會導致問題的特定方面。

本文將探討三個潛在的問題領域：

• 堆棧溢出

• 競爭條件

• 僵局
  

讀者可以在線閱讀本文的第二部分，其中將探討以下問題：

• 時序問題

• 可重入條件
  

所有上述問題在使用多任務實時設計技術的系統中都很常見。

堆棧溢出：

處理器使用堆棧來存儲臨時變量、向被調用函數傳遞參數、保存線程“狀態”等等。 如果系統不使用虛擬內存（換句話說，它無法將內存頁轉移到磁盤以釋放內存空間用于其他用途），則堆棧將固定為產品出廠時的大小。 如果由于某種原因堆棧超出了程序員分配的數量，程序就會變得不確定。 這種不穩定性可能會導致嚴重的系統故障。 因此，確保系統在最壞的情況下能夠分配足夠的堆棧非常重要。

確保永遠不會發生堆棧溢出的唯一方法是分析代碼，確定程序在各種可能情況下的最大堆棧使用量，然后檢查是否分配了足夠的堆棧。 測試不太可能觸發特定的瞬時輸入組合，從而導致系統出現最壞的情況。

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

• 為每個獨立線程創建一個調用樹。

• 確定調用樹中每個函數的堆棧使用情況。
  

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

• 添加每個獨立線程調用樹的最大堆棧使用量。
  

• 確定每個中斷優先級內每個中斷服務例程 (ISR) 的最大堆棧使用量并計算其總和。 但是，如果ISR本身沒有堆棧并使用被中斷線程的堆棧，則應將ISR使用的最大堆棧數添加到每個線程的堆棧中。
  

• 對于每個優先級，添加中斷發生時用于保存處理器狀態的堆棧數量。
  

• 如果使用RTOS，則添加RTOS自身內部使用所需的最大堆棧數（與應用程序代碼引起的系統調用不同，這已包含在步驟2中）。
  

此外，還有兩個重要問題需要考慮。 首先，僅從高級語言源代碼構建的調用樹可能并不完美。 大多數編譯器使用運行時庫來優化常見的計算任務，例如大整數的乘法和除法、浮點運算等。這些調用僅在編譯器生成的匯編語言中可見。 運行時庫函數本身可能會使用大量的堆棧空間，必須將其包含在分析中。 如果使用C++語言，則以下類型的函數（方法）也必須包含在調用樹中：構造函數、析構函數、重載運算符、復制構造函數和轉換函數。 所有函數指針也必須被解析，并且它們調用的函數必須包含在分析中。

---- PCB組裝、PCB設計、PCB加工廠家的介紹工程師講解了PCB設計中軟件缺陷的尋找。