1先進行人工檢查，即靜態檢查。在寫好壹個程序以後，不要匆匆忙忙上機，而應對紙面上的程序進行人工檢查。這壹步是十分重要的，它能發現程序設計人員由於疏忽而造成的多數錯誤。而這壹步驟往往容易被人忽視。有人總希望把壹切推給計算機系統去做，但這樣就會多占用機器時間，作為壹個程序人員應當養成嚴謹的科學作風，每壹步都要嚴格把關，不把問題留給後面的程序。
為了更有效地進行人工檢查，所編的程序應註意力求做到以下幾點：應當采用結構化程序方法編程，以增加可讀性；2盡可能多加註釋，以幫助理解每段程序的作用；3在編寫復雜的程序時不要將全部語句都寫在main函數中，而要多利用函數，用壹個函數來實現壹個單獨的功能。這樣既易於閱讀也便於調試，各函數之間除用參數傳遞數據這壹渠道以外，數據間盡量少出現耦合關系，便於分別檢查和處理。
2在人工檢查無誤後，才可以上機調試。通過上機發現錯誤稱動態檢查。在編譯時給出語法錯誤的信息，可以根據提示的信息具體找出程序中出錯之處並改正之。應當註意的是有時提示的出錯並不是真正出錯的行，如果在提示出錯的行上找不到錯誤的話應當到上壹行再找。有時提示出錯的類型並非絕對準確，由於出錯的情況繁多各種錯誤互有關聯，因止要善於分析，找出真正的錯誤，而不要只從字面意義上找出錯信息，鉆牛角尖。
如果系統提示的出錯信息多，應當從上到下壹壹改正。有時顯示出壹大片出錯信息往往使人感到問題嚴重，無從下手。其實可能只有壹二個錯誤。例如，對使用的變量未定義，編譯時就會對所有含該變量的語句發出出錯信息；有的是少了“}”或多了“}”有的是書寫語句時忘記寫“；”或是全角的“；”了，只要加上壹個變量定義，或填加“}；”就所有錯誤都消除了。
3在改正語法錯誤後，程序經過連接就得到可執行的目標程序。運行程序，輸入程序所需數據，就可得到運行結果。應當對運行結果作分析。看它是否符合要求。有的初學者看到運行結果就認為沒問題了，不作認真分析，這是危險的。
有時，數據比較復雜，難以立即判斷結果是否正確。可以事先考慮好壹批“試驗數據”，輸入這些數據可以得出容易判斷正確與否的結果。可以在計算的輸出結果的程序地方加入壹段輸出到串口的程序，利用串口窗口可以方便看到結果的，比仿真的都好和直觀。例如，if語句有兩個分支，有可能在流程經過其中壹個分支時結果正確，而經過其它壹個分支時結果不對等。必須考慮周全。
事實上，當程序復雜時很難把所有的可能方案全部都試到，選擇典型的情況作試驗即可。
4 運行結果不對，大多屬於邏輯錯誤。對這類錯誤往往需要仔細檢查和分析才能發現。可以采用以下辦法：
1 將程序與流程圖仔細對照，如果流程圖是正確的話，程序寫錯了，是很容易發現的。例如，復合語句忘記寫花括弧，只要壹對照流程圖就能很快發現。
2 如果實在找不到錯誤，可以采用“分段檢查”的方法。在程序不同的位置設幾個printf函數語句，輸出有關變量的值，往下檢查。直到找到在哪壹段中數據不對為止。這時就已經把錯誤局限在這壹段中了。不斷減小“查錯區”，就可能發現錯誤所在。
3 也可以用“條件編譯”命令進行程序調試（在程序調試階段，若幹printf函數語句就要進行編譯並執行。當調試完畢，這些語句不要再編譯了，也不再被執行了）。這種方法可以不必壹壹去printf函數語句，以提高效率。
4 如果在程序中沒有發現問題，就要檢查流程圖有無錯誤，即算法有無問題，如有則改正之，接著修改程序。
5 有的系統還提供debug（調試）工具，跟蹤流程並給出相應信息，使用更為方便，如KEILC51裏的調試運行就很好用的，可以在命令的窗口輸入程序中需要的數據和開關量、中斷、I/O口的電平等來方便完成程序的運行，使用時要先打開Options for Target'Target1'（工程菜單裏的目標‘TARGET1'屬性）-點DEBUG-選中左邊use Simulator\load Application at sta\Go till main;按確定後退出到編輯畫面，要先對源程序進行編譯後沒有錯誤才可以按主菜單上的調試按鈕，進行調試的，F10為子程序運行式的單步、F11為單步調試；具體使用可以看本站提供的51單片機應用系統開發實例壹書中的Dscope foe Windows壹節。可以下載本站上中文版的KIELC51就直觀了。
總之，程序調試是壹項細致深入的工作，需要下功夫，動腦子，善於累積經驗。在程序調試過程中往往反映出壹個人的水平，經驗和科學態度。希望讀者能給以足夠的重視。上機調試程序的目的決不 是為了“驗證程序的正確”，而是“掌握調試的方法和技術”，不要壹直依賴仿真器來解決，要學會自己找問題，這樣慢慢自己就會寫出錯誤較少的實用的程序，站長就沒有仿真器的哦，靠KEILC51裏的軟件仿真就解決了。