|
結構測試或白盒測試能有效地發(fā)現代碼中的邏輯、控制流、計算和數據錯誤。這項測試要求對軟件的內部工作能夠一覽無(wú)遺(因此稱(chēng)為"白盒"或"玻璃盒")，以便了解軟件結構的詳細情況。它檢查每個(gè)條件表達式、數學(xué)操作、輸入和輸出。由于需要測試的細節眾多，結構測試每次檢查一個(gè)軟件單元，通常為一個(gè)函數或類(lèi)。 代碼審查也使用與實(shí)現缺陷和潛在問(wèn)題查找同樣復雜的技術(shù)。與白盒測試一樣，審查通常針對軟件的各個(gè)單元進(jìn)行，因為一個(gè)有效的審查過(guò)程要求的是集中而詳盡的檢查。 與審查和白盒測試不同，功能測試或黑盒測試假設對軟件的實(shí)現一無(wú)所知，它測試由受控輸入所驅動(dòng)的輸出。功能測試由測試人員或開(kāi)發(fā)人員所編寫(xiě)的測試過(guò)程組成，它們規定了一組特定程序輸入對應的預期程序輸出。測試運行之后，測試人員將實(shí)際輸出與預期輸出進(jìn)行比較，查找問(wèn)題。黑盒測試可以有效地找出未能實(shí)現的需求、接口問(wèn)題、性能問(wèn)題和程序最常用功能中的錯誤。 雖然將這些技術(shù)結合起來(lái)可以找出隱藏在一個(gè)特定軟件程序中的大部分錯誤，但它們也有局限。代碼審查和白盒測試每次只針對一小部分代碼，忽視了系統的其它部分。黑盒測試通常將系統作為一個(gè)整體來(lái)處理，忽視了實(shí)現的細節。一些重要的問(wèn)題只有在集中考察它們在整個(gè)系統內相互作用時(shí)的細節才能被發(fā)現；傳統的方法無(wú)法可靠地找出這些問(wèn)題。必須整體地檢查軟件系統，查找具體問(wèn)題的特定原因。由于詳盡徹底地分析程序中的每個(gè)細節和它與代碼中所有其它部分之間的相互作用通常是不大可能的，因此分析應該針對程序中已經(jīng)知道可能導致問(wèn)題的特定方面。本文將探討其中三個(gè)潛在的問(wèn)題領(lǐng)域： * 堆棧溢出 * 競爭條件 * 死鎖 讀者可在網(wǎng)上閱讀本文的第二部分，它將探討下列問(wèn)題： * 時(shí)序問(wèn)題 * 可重入條件 在采用多任務(wù)實(shí)時(shí)設計技術(shù)的系統中，以上所有問(wèn)題都相當普遍。 處理器使用堆棧來(lái)存儲臨時(shí)變量、向被調函數傳遞參數、保存線(xiàn)程“狀態(tài)”，等等。如果系統不使用虛擬內存(換句話(huà)說(shuō)，它不能將內存頁(yè)面轉移到磁盤(pán)上以釋放內存空間供其它用途)，堆棧將固定為產(chǎn)品出廠(chǎng)時(shí)的大小。如果由于某種原因堆棧越出了編程人員所分配的數量范圍，程序將變得不確定。這種不穩定可能導致系統發(fā)生嚴重故障。因此，確保系統在最壞情況下能夠分配到足夠的堆棧至關(guān)重要。 確保永不發(fā)生堆棧溢出的唯一途徑就是分析代碼，確定程序在各種可能情況下的最大堆棧用量，然后檢查是否分配了足夠的堆棧。測試不大可能觸發(fā)特定的瞬時(shí)輸入組合進(jìn)而導致系統出現最壞情況。 堆棧深度分析的概念比較簡(jiǎn)單： 1. 為每個(gè)獨立的線(xiàn)程建立一棵調用樹(shù)。 2. 確定調用樹(shù)中每個(gè)函數的堆棧用量。 3. 檢查每棵調用樹(shù)，確定從樹(shù)根到外部“樹(shù)葉”的哪條調用路徑需要使用的堆棧最多。 4. 將每個(gè)獨立線(xiàn)程調用樹(shù)的最大堆棧用量相加。 5. 確定每個(gè)中斷優(yōu)先級內各中斷服務(wù)程序(ISR)的最大堆棧用量并計算其總和。但是，如果ISR本身沒(méi)有堆棧而使用被中斷線(xiàn)程的堆棧，則應將ISR使用的最大堆棧數加到各線(xiàn)程堆棧之上。 6. 對于每個(gè)優(yōu)先級，加上中斷發(fā)生時(shí)用來(lái)保存處理器狀態(tài)的堆棧數。 7.如果使用RTOS，則加上RTOS自身內部用途需要的最大堆棧數(與應用代碼引發(fā)的系統調用不同，后者已包含在步驟2中)。 除此之外，還有兩個(gè)重要事項需要考慮。首先，僅僅從高級語(yǔ)言源代碼建立的調用樹(shù)很可能并不完善。大部分編譯器采用運行時(shí)庫(run-time library)來(lái)優(yōu)化常用計算任務(wù)，如大值整數的乘除、浮點(diǎn)運算等，這些調用只在編譯器產(chǎn)生的匯編語(yǔ)言中才可見(jiàn)。運行時(shí)庫函數本身可能使用大量的堆�？臻g，在分析時(shí)必須將它們包括進(jìn)去。如果使用的是C++語(yǔ)言，則以下所有類(lèi)型的函數(方法)也都必須包含到調用樹(shù)內：結構器、析構器、重載運算符、復制結構器和轉換函數。所有的函數指針也都必須進(jìn)行解析，并且將它們調用的函數包含進(jìn)分析之中。 第二，編譯器使用一個(gè)C庫來(lái)實(shí)現memcpy()、cos()和atof ()等標準函數，而這些例程的源代碼可能無(wú)法得到。如果能夠得到它們的源代碼，就有可能確定程序用到的每個(gè)庫調用在最壞情況下的堆棧使用數量。如果這些庫只包含在目標文件中，則編譯器廠(chǎng)商必須提供每個(gè)庫例程使用的堆棧數。如果沒(méi)有這些信息，就無(wú)法通過(guò)分析來(lái)確定最壞情況下程序使用的最大堆棧數。幸運的是，許多面向嵌入式系統的編譯器廠(chǎng)商都提供這些信息。 通常，每次一個(gè)函數被調用時(shí)，編譯器將使用堆棧來(lái)保存返回地址并傳遞函數參數。函數的自動(dòng)(局部)變量通常也在堆棧當中。不過(guò)，由于編譯器會(huì )盡可能通過(guò)將參數或局部變量放入寄存器來(lái)優(yōu)化代碼，因此檢查匯編語(yǔ)言以精確地確定堆棧用量非常重要。編譯器也有可能在代碼中的其它地方選擇使用堆棧，如用堆棧來(lái)保存中間計算結果。 有些與編譯器一起打包銷(xiāo)售的開(kāi)發(fā)環(huán)境包含生成調用樹(shù)的工具，還有許多第三方的調用樹(shù)生成工具。但是，除非它們能夠對匯編語(yǔ)言進(jìn)行分析，否則這些工具可能會(huì )遺漏運行時(shí)庫和C庫的調用。不過(guò)無(wú)論在哪種情況下，開(kāi)發(fā)分析匯編語(yǔ)言文件并提取函數名稱(chēng)以及各函數內部調用的腳本都比較簡(jiǎn)單。分析的結果可寫(xiě)入一個(gè)文件，而這個(gè)文件能夠方便地輸入到表格之中。 確定了各個(gè)函數的堆棧用量之后，必須計算每個(gè)線(xiàn)程所需的最大堆棧數。由于一般程序通常涉及數百個(gè)函數，調用跨越多層深度，處理這些信息的一種簡(jiǎn)便方法就是采用分析表格。如表1所示，表格的各行包含了函數名稱(chēng)、該函數使用的最大堆棧數(包括調用其它函數所需的堆棧數)，以及它調用的所有函數的清單。通過(guò)編程控制，這個(gè)表格從每個(gè)函數的"根"開(kāi)始迭代循環(huán)，計算該函數及其調用的所有函數需要的堆棧。這些信息存放在堆棧路徑列中，這樣，采用每個(gè)線(xiàn)程根函數(如main)的堆棧路徑數據就可以方便地計算出需要的最大堆棧數了。這個(gè)過(guò)程包含了先前介紹的堆棧分析過(guò)程中的前四個(gè)步驟。 有時(shí)候，采用堆棧深度分析過(guò)程可能是無(wú)法做到，或者是不實(shí)際的。如果無(wú)法得到運行時(shí)庫或C庫的源代碼，而編譯器廠(chǎng)商又沒(méi)有提供任何堆棧使用信息，就不可能進(jìn)行完整的堆棧分析。在這種情況下，有兩種選擇： 1. 在測試期間，觀(guān)察堆棧所能達到的深度，并保證有較大的堆�？臻g余量。 2. 檢測堆棧溢出，并采取改進(jìn)措施。 觀(guān)察堆棧深度的方法很簡(jiǎn)單: * 向整個(gè)內存堆棧區寫(xiě)入一個(gè)特定的數據圖案符號，如55AA。 * 在預期使用最大堆�？臻g的條件下運行系統。 * 使用仿真器或其它工具檢查堆棧存儲區，看有多少符號圖案由于堆棧的使用而被改寫(xiě)了。 當然，這些步驟并不能保證在一些不同條件下不會(huì )需要更多的堆棧，但確實(shí)可以表明所需要的最小堆棧數。 使用帶內存管理單元(MMU)的處理器時(shí)，有可能檢測出運行時(shí)的堆棧溢出現象。MMU將內存劃分為多個(gè)區域，用一個(gè)受保護的內存段來(lái)“警戒”堆棧區域。發(fā)生堆棧溢出時(shí)，處理器將訪(fǎng)問(wèn)這個(gè)受保護段。這個(gè)操作將引發(fā)一個(gè)異常事件(如產(chǎn)生SIGSEGV信號)，可被程序捕獲到。創(chuàng )建線(xiàn)程時(shí)，與實(shí)時(shí)POSIX標準兼容的RTOS提供有這種堆棧警戒功能選項，大大簡(jiǎn)化了編程人員的工作。GNU工具等其它開(kāi)發(fā)環(huán)境包含有編譯器開(kāi)關(guān)，可在程序中添加實(shí)現堆棧警戒功能所需的代碼，但它們仍然依靠底層操作系統來(lái)有效地處理堆棧溢出。但是，按照這種方式檢測溢出還只是問(wèn)題的一部分。為了使這類(lèi)設計更為有效，系統必須能夠從堆棧溢出中恢復過(guò)來(lái)并繼續正確地工作。 在一個(gè)對安全或任務(wù)要求嚴格的應用中，系統運行時(shí)在測試或檢測堆棧溢出期間監視堆棧的深度可能并不是一項足夠的風(fēng)險控制措施。對于一些應用，必須確保系統絕對不會(huì )越出所分配的堆棧范圍；只有通過(guò)完整的堆棧深度分析才能證明這一點(diǎn)。這意味著(zhù)，如果整個(gè)程序在同一內存空間運行，則必須對所有代碼執行這項分析。不過(guò)，如果使用MMU，分析�？珊�(jiǎn)化。在設計系統時(shí)，可將所有關(guān)鍵代碼置于一個(gè)或多個(gè)獨立線(xiàn)程內，而這些線(xiàn)程分別在各自的保護內存段中運行。這樣，只要對這些關(guān)鍵線(xiàn)程進(jìn)行堆棧使用分析就可以了。當然，這項簡(jiǎn)化設計假定當非關(guān)鍵線(xiàn)程溢出其堆棧并失效時(shí)，關(guān)鍵線(xiàn)程仍可正確執行。 由于分析工作所需的堆棧使用數據來(lái)自匯編語(yǔ)言清單，因此修改代碼時(shí)，相應模塊的堆棧使用信息必須予以更新。如果使用不同的編譯器版本，或者改變了優(yōu)化設置，也必須復核整個(gè)分析過(guò)程。在理想情況下，編譯器將提供每個(gè)函數(如果不是每個(gè)線(xiàn)程的話(huà))的堆棧使用數量，因為它擁有計算需要的所有信息。例如，瑞薩公司提供有Call Walker，這是該公司高性能的Embedded Workshop開(kāi)發(fā)環(huán)境的一部分。這個(gè)工具可以圖形化地顯示每個(gè)函數使用的調用樹(shù)和堆棧，包括運行時(shí)庫和C庫的函數。Call Walker也能找出使用堆棧數量最大的路徑。使用這樣的工具可以實(shí)現步驟1到步驟3的自動(dòng)化。 |
