現在嵌入式技術也已經非常的成熟，那麼，軟體測試工程師如何測試嵌入式軟體呢？達內南寧軟體測試培訓部老師將從以下三點來講述。
第一、當兩個或更多獨立執行緒同時訪問同一資源時，就出現了競爭條件。競爭條件的影響多種多樣，取決於具體的情況。清單1解釋了一個潛在的競爭條件。函式Update_Sensor()通過呼叫get_raw()來讀取感測器的原始資料。在處理過程中，該資料被乘上一個定標因子，並加上一個偏移量。處理是在該資料的一個臨時副本上進行的，然後，該臨時副本被寫入共享變數。
如果在資料寫入之前，使用shared_sensor的另一個執行緒或ISR先佔(preempt)了這個執行緒，它將得到原來的感測器讀數。使用臨時副本可以防止先佔執行緒讀取只經過部分處理的資料。不過，如果這些程式碼在一個數據匯流排不足32位的處理器上執行，就會存在競爭條件。
消除競爭條件通常很簡單，但找出隱藏在程式碼中的競爭條件則需要仔細的分析。
對於由一個迴圈程式和不同ISR組成的簡單系統，分析競爭條件很簡單，只需檢查每個ISR並識別它引用的所有共享變數。共享變數通常是這些系統中的全域性資料，一旦這些共享變數被找出來之後，就可以檢查它們在程式碼中的各次使用情況。每次訪問都必須按需要進行保護，以避免潛在的衝突。 對於使用了優先順序不同的多個執行緒的更為複雜的系統，其分析也非常相似。上述規則仍然適用於ISR使用的所有資料。此外，還必須識別出每個執行緒使用的共享資料。首先從系統中優先順序最高的執行緒開始，找出它與任何優先順序較低的執行緒共享的所有資料，然後按照上述四條規則進行保護。對於軟體使用的其它每個優先順序，再重複這一過程。
第二、多執行緒系統通常使用某種型別的作業系統，它能夠提供多種保護選擇。可以使用互斥或訊號量，或者鎖定排程器。有時也可使用其它程序間通訊(IPC)基本技術：通過向訊息佇列傳送訊息(而非修改共享變數)來表示資料已經改變。在許多情況下，最好由單一執行緒來管理共享資源，它負責處理所有的讀寫請求，並在內部防止訪問衝突。
在複雜的程式碼中辨認潛在的競爭條件可能是一項乏味而又耗時的工作。相應的輔助工具從用來識別全域性資料訪問的簡單指令碼到先進的動態分析程式如Polyspace Verifier。雖然比較困難，但詳盡的程式碼分析是識別這類錯誤的唯一途徑。測試不大可能能夠建立重複觸發競爭條件所需的精確時序序列。
在共享資源的系統中，防止訪問衝突極為重要，但這有可能導致另一個問題：死鎖。當通過"鎖定"一個資源來防止任何其它執行緒訪問這個資源，以避免競爭條件時，必須對設計進行評估，確保絕對不會發生死鎖。死鎖測試通常沒有什麼效果，因為只有某種特定順序的資源鎖定才可能產生死鎖，而一般的測試不大可能導致這種順序。
第三、在一些型別的系統中，預先確定每一個共享資源並建立分配圖是不實際或不可能的。此時可以增加一些額外的程式碼，以便在系統執行時檢測出潛在的死鎖。許多不同的演算法都致力於優化這個檢測過程，但本質上它們幾乎都動態地建立某種資源分配圖。只要有執行緒請求、分配或釋放資源，分配圖就會被修改和檢測，以確定是否存在表明潛在死鎖的迴圈路徑。
檢測到某個死鎖之後，唯一的克服方法是強迫執行緒釋放關鍵的資源。通常，這意味著中斷正保持著所需資源的執行緒。對於某些應用，這種方法可能是無法接受的。另一個有趣的解決方案是在執行時收集資源分配情況並進行事後分析處理，以確定在程式執行過程中是否有死鎖情況發生。儘管這種方法並不能防止在執行時發生死鎖，但它確實有助於在死鎖出現後發現問題並進行修復。
通過以上三點，軟體測試工程師會很快掌握嵌入式軟體測試的3個技巧，成為嵌入式測試行業中的高手。