這一步主要確定在不跑業務應用的情況下，系統及內核層面是否穩定運行。
正常狀態下，系統負載應該處於平穩狀態，如果出現過高或者忽高忽地，都屬於不正常狀態。這一方面可能是內核工作隊列中有任務堆積，另一方面，也可能是內核調度出現了問題。
產品開發中，我們通常都會認爲內核應該沒有問題。但是，嵌入式開發有其特殊性，內核一般都會根據板載硬件做裁剪，也會針對板載硬件做一些驅動方面的開發，這就給內核的穩定性帶來了潛在的不利因素。鑑於內核的龐大及整體的複雜性，就進一步放大了這種不利因素的影響。結果就是，開發人員能力水平是否過關、測試是否充分完備以及開發管理是否到位都會影響到內核的穩定性和系統性能的發揮。特別是驅動的修改或者增加，對驅動對象是否深入瞭解、對內核框架機制是否充分掌握顯得尤爲重要，稍有不慎，就可能對內核穩定性和性能產生不良影響。
舉幾個本人在實際產品開發中遇到過的例子。
第一個是一款三星芯片產品。買的開發板，前期使用中，就發現串口命令行中連續回車，比如按住回車鍵不放，輸出#的過程中，一會就卡頓一下。剛開始還沒在意，但是在後面移植應用後，產品表現不正常，之前流暢的音頻，現在就總是過一會卡一下。看ALSA打印，報pipe超時錯誤。在整體應用負載不高的情況下，說明內核被某個東西非正常佔住了，比如在驅動中不正確的使用udelay，就很可能導致這樣的問題。後來換了一家的開發板，還是同一款CPU，就不存在上述問題。
第二個是一款IPTV產品。前期測試一直都正常，最後都出貨了，結果在部分用戶家出現聯網問題。跟蹤驗證，發現協議棧報了一個奇怪的錯誤，通過分析，原因是網絡數據包可以接收，但是發送錯誤。當問題範圍縮小後，就到內核網卡驅動中查找，最後確定是驅動中發送計數有問題，運行一段時間後，導致邏輯判斷出問題，數據無法發送。
第三個也是與網絡有關。抓包看，數據發送是正常的，但是接收每過一段時間就會延遲幾百毫秒。因爲上層業務是接收後轉發，這就導致轉發後看到的視頻畫面每過一會就卡頓一下。反反覆覆排查，發現網絡接收的中斷計數會突然集中增加，最後根據這個線索，將問題鎖定在了網卡驅動接收中斷處理中。
通過上面幾個例子，我們看到，實際產品開發中可能會遇到各種奇奇怪怪的問題，在問題源上，內核並不能想當然的排除在外。但是，話又說回來，內核的問題一般比較隱蔽，不好排查，那有沒有什麼比較好的辦法來規避呢？或者出現問題後，有好的查找策略？
其實查找BUG就如同給人看病，找到原因，一切都好辦。古代名醫扁鵲聲名在外，卻說這是因爲自己治的都是末期之病，動輒扎針放血，人們以爲自己很厲害，其實不然。自己的大哥能在病未有形時就發現併除之，自己的二哥也能在疾病初起之時將其清除，所以他們才更厲害。內核的穩定性也是同樣道理，與其後期辛苦治療，不如前期選擇治未病，這纔是高明之舉。那有哪些措施可以在前期幫助我們篩選穩定的系統或檢測系統的穩定性呢？下面列舉一些，供大家在實際中參考：
1 建議大家儘量選擇大廠商的平臺。一般大廠的產品，測試會比較完善，質量相對可靠，尤其是選擇這種偏底層基礎的東西。
2 如果產品比較特殊，無法選擇大廠通用平臺，那就需要做充分的測試，儘早暴露問題，將問題扼殺在搖籃中。否則，每往後走一步，帶來的損失就可能十倍百倍的增加。所謂基礎不牢，地動山搖，不要指望到最後有彌補的措施。
3 如果有驅動開發，儘量選用成熟的設備及芯片，在此基礎上儘量選用設備或芯片廠家的驅動，哪怕是在demo基礎上修改，也比重新從頭開始寫要強。當然，如果開發人員經驗非常豐富，就另說了。
4 內核非常龐大、複雜，即使自己做測試驗證，也要有所聚焦，收斂，避免盲目的攤開式的測試。這就需要分析業務特點，縮小範圍，有重點的測試驗證。比如開發一些基準測試程序，做benchmark類的測試。這種方法對專門的驅動進行驗證也是很有用的。
5 通過/proc/loadavg 可以“定量”的統計系統負載，在上述基準測試中，可以以此作爲系統穩定性的參考指標。
6 通過top命令可以“定量”的統計CPU佔用較高的線程，在不跑任何業務程序的情況下，可以對整個系統的運行情況作一個初步的評判。
7 程序內存佔用過高或者內存泄漏，也會導致系統卡頓，可以通過內存分析工具，“定量”的分析系統內存使用情況，進一步的評判系統穩定性。
8 對系統CPU和內存定量分析後，接下來就需要對IO指標進行測試。上述驅動相關、業務相關的IO，要重點測試。比如，模擬業務場景，做超壓測試，最好是能做到翻倍。
9 通過內核提供的perf工具，分析熱點調用，這對於降低系統負載是有很大幫助的。
10 完成系統的整體測試後，爲了獲取更好的可靠性，還需要做一個長時間運行測試，俗稱拷機測試。通過該測試，不僅可以規避一些時間和內存相關的問題，對硬件部分也是很好的驗證。