| PostgreSQL 8.0.0 中文文件（轉譯自 PostgreSQL 中國 製作的簡體中文版本） | ||||
|---|---|---|---|---|
| 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，基本可以保證正確的測試。
有些測試涉及到對資料表中的資料列進行 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
會產生僅僅一行或幾行差別。 您不必擔心這些，除非隨機測試在重複測試中總是失敗。