Postgresql回歸測試(2)

　　錯誤信息差別

　　有一些回歸測試涉及到有意的非法輸入值。 錯誤信息可能會來自 PostgreSQL 代碼或來自主機平臺系統過程。 對于后者，信息可能在平臺之間區別比較大，但應該反映相似的信息。 這些信息上的差別將會導致一個"失敗"的回歸測試， 我們可以通過檢查文件發現這一點。

　　區域差別

　　如果你在一臺已經安裝好了的服務器上運行測試，而該服務器是用一種非 C 的區域設置初始化的， 那么可能因為有排序順序和其它類似的差別導致的失敗?；貧w測試套件處理這種問題的方法是提供可選的結果文件， 這些文件一起處理一大堆的區域。比如，對于 char 測試， 預期的文件 char.out 處理C和POSIX區域， 而文件 char_1.out 處理許多其它區域。 回歸測試驅動將自動選取最接近的文件進行成功檢查以及計算失敗差別。 (這就意味著回歸測試不能檢測該結果對于配置的區域是否合適。 該測試將簡單地選取一個運轉得最好的文件。)

　　如果由于某些原因，現有的預期文件無法覆蓋一些區域，那么你可以增加一個新文件。命名模式是 testname_digit.out。 實際的 digit 是什么并不重要。要記住回歸測試驅動將認為所有這樣的文件都是有效的測試結果。

　　日期和時間差別

　　如果你在夏時制時間切換的那天，或者是之后一天運行測試，那么在 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

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

原文轉自：http://www.uml.org.cn/Test/200805235.asp