調試的定義:通過一定方法,在程序中找到並減少缺陷的數量,從而使其能正常工作。
這裡說一些如何調試PHP程序的經驗。
一、PHP自帶的調試功能
1、自帶的報錯功能
兩個名詞:開發環境是開發人員在進行開發和調試的環境,生產環境是最終客戶在用的線上環境;
開發環境和生產環境要分開設置報錯功能。
(1)開發環境
開發環境需要打開報錯,以下是php.ini的配置項及其說明:
; This directive sets the error reporting level.
; Development Value: E_ALL | E_STRICT (Show all errors, warnings and notices including coding standards.)
error_reporting = E_ALL | E_STRICT
; This directive controls whether or not and where PHP will output errors,
; notices and warnings too. Error output is very useful during development.
; Development Value: On
display_errors = On
這樣你在開發過程中,能第一時間發現錯誤。
即使是一個低等級的報錯“Notice: Undefined variable: a in E:\phpspace\test.php on line 14”,但一個未定義的變量的使用往往暗藏著bug。
你會問,如果我引進了開源的類庫,他們拋出一堆的低等級錯誤怎麼辦?一般代碼質量好的類庫,也沒有“Notice”級別的報錯的。所以這也是鑒別一個類庫質量的方法。
(2)生產環境
生產環境不能直接將錯誤輸出,而是記入日志,以下是php.ini的配置項及其說明:
; It could be very dangerous in production environments.
; It's recommended that errors be logged on production servers rather than
; having the errors sent to STDOUT.
display_errors = Off
; Besides displaying errors, PHP can also log errors to locations such as a
; server-specific log, STDERR, or a location specified by the error_log
; directive found below. While errors should not be displayed on productions
; servers they should still be monitored and logging is a great way to do that.
; Production Value: On
log_errors = On
; Log errors to specified file.
error_log = /path/to/php_error.log
當然日志寫到文件裡只是一個選擇,還有其他配置可參考手冊。
生產環境是給客戶提供服務的,你不可能在上面進行斷點、打印輸出等操作,所以日志是不錯的選擇。
2、其他一些語言特性、功能的使用
(1)少用錯誤控制運算符“@”
其的作用是,將“@”放置在一個PHP表達式之前,該表達式可能產生的任何錯誤信息都被忽略掉。
如果一個缺陷發生在這個表達式中,從PHP的輸出中看不到任何錯誤,這增加了調試的難度。所以能不用則不用。
(2)有些函數自帶有debug功能
比如這行代碼:
$fp = fsockopen(“www.example.com”, 80, $errno, $errstr, 30);
開發者調試時已經確定,$fp為空,連接失敗,是這一行有問題,但是為什麼連接失敗?
函數是php自帶的,無法進行更深入的調試。所以一般這樣的函數(主要是網絡通信類的),會自己提供調試參數:$errno和$errstr。你可以加一句:
if (!$fp) echo “$errstr ($errno)
\n”;
就能看到連接失敗的原因了。
這些函數有:fsockopen,pfsockopen,stream_socket_server,stream_socket_client 等。
還有些函數是調試一個功能用的,比如:mysql_errno,socket_last_error,socket_strerror 等。
這些只需要了解下,碰到能想到用即可。
二、引進調試工具
在遇到復雜問題時,可以借助調試工具。比較成熟的有Xdebug、ZendDebugger。
以Xdebug為例,它能夠:控制打印輸出的樣式和數組層級、堆棧式的追蹤錯誤、追蹤函數調用、代碼執行覆蓋分析、程序的概要分析(Profiling)、遠程調試。詳見:http://xdebug.org/docs/。
Xdebug前兩個功能是對PHP原有的調試功能做了改進,更方便調試。
復雜的問題,調試不出來的,可能是業務上的的問題,下面也有說業務邏輯的調試。
三、調試業務邏輯錯誤
當PHP腳本跑起來,沒有任何錯誤,只能說它沒有語法上的錯誤,但是不能說明它業務邏輯上沒錯誤。
很多業務邏輯的錯誤並不會反映在語法錯誤上,但調試的思路和PHP自帶調試功能差不多。
下面是一些方法。
1、最基本的調試方法
先確定兩個東西:程序預期的結果、程序現在的不符合預期的結果;
尋找與兩種結果相關的代碼片段;
閱讀這些代碼片段,嘗試以“肉眼”找出錯誤;
找不出,則需要輸出一些關鍵變量,通過檢查它們的值是否正確來判斷是哪裡發生了錯誤;
若干次嘗試,最終你可以確定錯誤發生在哪個點。
你也可以借助Xdebug等工具,查看變量值的變化,或者設置斷點進行調試。
2、記錄運行日志
有些復雜或特殊的業務,用上面的方法不合適,比如:一個不能被打斷的後台運行腳本。這些情況下記錄運行日志比較合適。
記日志的點要有所選擇,除了業務上比較重要的點,通常容易出錯的地方有:網絡連接和通信、系統權限問題等。
3、單元測試
以代碼測試代碼,而不是像第一點一樣調試完會把測試代碼丟掉。以測試驅動開發。
這個話題比較大,但適合放這裡提一下。有興趣的同學可以去了解。
四、調試非功能性的錯誤
非功能性錯誤,比如:內存溢出導致程序掛掉了、效率有問題導致程序非常慢、死循環了等等。
這些問題,用“肉眼”檢查代碼效率太低了。
所以可以借助調試工具做程序的概要分析(Profiling),從中檢查出程序的瓶頸所在。