| PostgreSQL 7.4 文檔 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 26. 回歸測試 | Fast Forward | Next |
有一些正確安裝並且具有完整功能的 PostgreSQL可能會在一些回歸測試中"失效"， 這些主要是因為浮點數的形式和時區支持的問題。 目前的測試只是簡單的用 diff 與參考系統的輸出進行比較， 因而對一些細小的系統區別很敏感。 當一項測試報告"失敗"時，只要檢查一下預期和實際的結果， 你就會發現區別區別並不大。 當然，我們仍然在努力維護所有我們支持的平台的準確的參考文件， 這樣我們就可以假定所有測試都通過。
回歸測試的實際輸出是在 src/test/regress/results 目錄裡的文件裡。測試腳本使用 diff 以比較每個輸出文件和存放在 src/test/regress/expected 目錄裡的參考輸出。任何區別都存放在 src/test/regress/regression.diffs 裡面供你檢查。（或者如果你願意的話，你也可以自己運行 diff。）
有一些回歸測試涉及到有意的非法輸入值。 錯誤信息可能會來自 PostgreSQL 代碼或來自主機平台系統過程。 對于後者，信息可能在平台之間區別比較大，但應該反映相似的信息。 這些信息上的差別將會導致一個"失敗"的回歸測試， 我們可以通過檢查文件發現這一點。
如果你在一台已經安裝好了的服務器上運行測試，而該服務器是用一種非 C 的區域設置初始化的， 那麼可能因為有排序順序和其它類似的差別導致的失敗。回歸測試套件處理這種問題的方法是提供可選的結果文件， 這些文件一起處理一大堆的區域。比如，對于 char 測試， 預期的文件 char.out 處理C和POSIX區域， 而文件 char_1.out 處理許多其它區域。 回歸測試驅動將自動選取最接近的文件進行成功檢查以及計算失敗差別。 （這就意味著回歸測試不能檢測該結果對于配置的區域是否合適。 該測試將簡單地選取一個運轉得最好的文件。）
如果由于某些原因，現有的預期文件無法覆蓋一些區域，那麼你可以增加一個新文件。命名模式是 testname_digit.out。 實際的 digit 是什麼並不重要。要記住回歸測試驅動將認為所有這樣的文件都是有效的測試結果。 如果測試結果是平台相關的，那麼應該使用在 Section 26.3 裡描述的技巧。
如果你在夏時制時間切換的那天，或者是之後一天運行測試，那麼在 horology 測試中的幾個查詢會失敗，這些查詢假設在昨日午夜，今日午夜和明日午夜之間的差距正好時 24 小時 -- 如果在夏時制切換的時候這個數值時錯誤的。
注意: 因為使用了 USA 的夏時制規則，所以這些問題總是出現在四月的第一個星期天， 和十月的最後一個星期六，以及它們後面的那個星期一---不管你居住的地方的夏時制是從什麼時候開始的。 還要注意這個問題在太平洋時間（UTC-7或者UTC-8）的午夜出現或者消失， 而不是你本地時間的午夜。因此，這些問題可能在星期六的晚上出現， 或者一直到星期二的大部分時間都存在，具體現象取決于你居住的地方。
大多數日期和時間結果依賴于時區環境變量。參考文件是為時區 PST8PDT （伯克利，加州）準備的，因而如果測試沒有設置為那個時區是顯然會失敗的。 回歸測試的驅動器把環境變量 PGTZ 設置為 PST8PDT 以保證正確的測試。 不過，你的操作系統必須為PST8PDT提供庫支持，否則與時區相關的測試將會失敗。
env TZ=PST8PDT date
上面的命令應該返回PST8PDT時區的當前時間。 如果沒有能用的PST8PDT數據庫，那麼你的系統可能會返回 GMT 的形式的時間。 如果缺少PST8PDT時區，那麼你可以明確設置時區規則：
PGTZ='PST8PDT7,M04.01.0,M10.05.03'; export PGTZ
有些系統不能接受我們推薦的明確設置時區的語法； 在這樣的機器上你可能要用不同的 PGTZ設置。
有些使用舊的時區庫的系統在對PDT1970 年前的時間使用夏時制時會出毛病， 導致PDT1970 年以前的時間顯示為PST。 這會導致在測試結果裡的本地化區別。
有些測試涉及到對表中的數據列進行 64位浮點數（double precision）計算的問題。 我們觀察了涉及到計算double precision字段的數學函數的結果的差別。 float8和geometry（幾何類型）測試尤其容易在不同平台之間產生小差別。 這時需要肉眼對這些差別進行比較， 以判斷這些差別究竟有多大，我們發現是在小數點右邊10位數。
有些系統把負零顯示為 -0，而其它的只是顯示 0。
有些系統在pow()和exp() 出錯時產生的信號與目前 Postgres 代碼裡期望的機制不一樣。
你可能會看見同樣的行以與預期文件的不同的順序輸出。在大多數情況下， 嚴格說來這不算臭蟲。大多數回歸測試腳本都不會迂腐到在每個SELECT中都使用ORDER BY的地步， 因此根據 SQL 規範裡的詞匯的說明，它們的結果集的順序並非定義得非常好的。尤其是因為我們是在同樣的數據上運行同樣的查詢， 因此我們在所有平台上通常都獲得同樣的結果， 因此即使缺少ORDER BY也不算什麼大問題。 不過有些查詢的確存在跨平台的排序問題。 （如果你使用了非 C 的區域設置，也可能造成排序差異的問題。）
因此，如果你看到一個排序差異，應該不是什麼要擔心的問題（除非出問題的查詢的確使用了 ORDER BY）。 不過，如果有這樣的現象，請告訴我們，這樣我們就可以在那條查詢上加一個 ORDER BY， 這樣我們就可以在以後版本裡消除著種偽"失敗"。
你可能會問，為什麼我們不對所有回歸測試的 SELECT 進行排序以一次性消滅所有這類問題。 原因是這樣做只能讓回歸測試用處更少，而不是更多，因為它們會試圖使用那些生成順序結果的查詢規劃，而不再使用那些不排序的查詢規劃。
在隨機測試腳本裡至少有一個測試會產生隨機結果。 這會導致回歸測試中的隨機測試失敗（可能每五次到十次出現一次）。 鍵入
diff results/random.out expected/random.out
會產生僅僅一行或幾行差別。 你不必擔心這些，除非隨機測試在重復測試中總是失敗。 （另一方面，如果在多次回歸測試中隨機測試從不失敗，你可能也應該 擔心。）