Postgresql回歸測試(2)

　　注意: 因為使用了 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

　　會產生僅僅一行或幾行差別。 你不必擔心這些，除非隨機測試在重復測試中總是失敗。

原文轉自：http://www.anti-gravitydesign.com