# 30.2\. 測試評估 有一些正確安裝并且具有完整功能的PostgreSQL 可能會在一些回歸測試中"失效"，這主要是因為浮點數的形式和時區支持的問題。 目前的測試只是簡單的用`diff`與參考系統的輸出進行比較， 因而對一些細小的系統區別很敏感。當一項測試報告"失敗"時， 只要檢查一下預期和實際的結果，你就會發現區別并不大。當然， 我們仍然在努力維護所有我們支持的平臺的準確參考文件，這樣我們就可以假定所有測試都通過。 回歸測試的實際輸出在`src/test/regress/results`目錄里的文件里。 測試腳本使用`diff`比較每個輸出文件和存放在`src/test/regress/expected` 目錄里的參考輸出。任何區別都存放在`src/test/regress/regression.diffs` 里面供你檢查。如果你不喜歡默認的`diff`選項，設置環境變量 `PG_REGRESS_DIFF_OPTS`為`PG_REGRESS_DIFF_OPTS='-u'`。 你也可以自己運行`diff`。 如果獲得一個"失敗"的測試結果，但實際上輸出結果是正確的， 你可以通過添加新的比較文件來抑制錯誤報告。參見[Section 30.3](#calibre_link-115)獲取更多細節。 ## 30.2.1\. 錯誤信息差別 有一些回歸測試涉及到有意的非法輸入值。錯誤信息可能會來自PostgreSQL 代碼或來自主機平臺系統過程。對于后者，信息可能在平臺之間區別比較大， 但應該反映相似的信息。這些信息上的差別將會導致一個"失敗"的回歸測試， 我們可以通過檢查文件發現這一點。 ## 30.2.2\. 區域差別 如果你在一臺服務器上運行測試，而該服務器是用一種非 C 區域設置初始化的， 那么可能因為有排序順序和其它類似的差別導致的失敗。 回歸測試套件處理這種問題的方法是提供可選的結果文件，這些文件一起處理一大堆的區域。 當使用臨時安裝在一個不同的區域中運行測試時，在`make` 命令行傳遞適當的區域相關的環境變量，例如： ``` gmake check LANG=de_DE.utf8 ``` 回歸測試驅動附件`LC_ALL`，所以它不使用那個變量選擇區域。 要不使用區域，取消所有區域相關的環境變量（或設置它們為`C`） 或使用下列的特殊調用： ``` gmake check NO_LOCALE=1 ``` 當對一個現有安裝運行測試時，區域設置取決于現有安裝。要改變它， 通過傳遞適當的選項到`initdb`，用一個不同的區域初始化數據庫集群。 通常，作為生產用的區域設置上運行回歸測試是明智的，因為這將練習區域和編碼相關的代碼部分， 并將實際在生產中使用。取決于操作系統環境，你可能會得到錯誤， 但是然后你將至少知道在運行實際應用時，預期什么區域特定的行為。 ## 30.2.3\. 日期和時間差別 大多數日期和時間測試結果依賴于時區設置。參考文件是為`PST8PDT` 時區(伯克利，加州)準備的，因而如果測試沒有設置為那個時區是顯然會失敗的。 回歸測試的驅動器把`PGTZ`環境變量設置為`PST8PDT`， 基本可以保證正確的測試。 ## 30.2.4\. 浮點數差別 有些測試涉及到對表中的數據列進行 64 位浮點數(`double precision`)計算的問題。 我們觀察了涉及到計算`double precision`字段的數學函數的結果差別。 `float8`和`geometry`測試尤其容易在不同平臺， 或者甚至是不同的編譯器最優化設置之間產生小差別。 這時需要肉眼對這些差別進行比較，以判斷這些差別究竟有多大，我們發現是在小數點右邊 10 位左右。 有些系統把負零顯示為`-0`，而其它的只是顯示`0`。 有些系統在`pow()`和`exp()` 出錯時產生的信號與目前PostgreSQL代碼里期望的機制不一樣。 ## 30.2.5\. 行順序差別 你可能會看見同樣的行以與預期文件的不同的順序輸出。在大多數情況下，嚴格說來這不算臭蟲。 大多數回歸測試腳本都不會迂腐到在每個`SELECT`中都使用`ORDER BY`的地步， 因此根據 SQL 規范，它們的結果行順序并非定義得非常好的。實際上， 因為我們是在同樣的數據上用同樣的軟件運行同樣的查詢，所以在所有平臺上通常都獲得同樣的結果， 因此即使缺少`ORDER BY`也不算什么大問題。不過有些查詢的確存在跨平臺的排序問題。 在測試一臺已安裝的服務器的時候，排序的差別也可能因為非 C 區域設置，或者非缺省的參數設置， 比如客戶自己設置的`work_mem`或者規劃器開銷參數設置受影響。 因此，如果你看到一個排序差異，應該不是什么要擔心的問題(除非明確使用了`ORDER BY`)。 不過，如果有這樣的現像，請告訴我們，這樣我們就可以在那條查詢上加一個`ORDER BY` 從而在以后的版本里消除這種偽"失敗"。 你可能會問，為什么我們不對所有回歸測試的 SELECT 進行排序以一次性消滅所有這類問題。 原因是這樣做只能讓回歸測試用處更少，而不是更多， 因為它們會試圖使用那些生成順序結果的查詢規劃，而不再使用那些不排序的查詢規劃。 ## 30.2.6\. 堆棧深度不夠 如果`errors`測試導致在`select infinite_recurse()` 命令的時候服務器崩潰，這就意味著平臺對進程堆棧的限制小于 [max_stack_depth](#calibre_link-1534) 參數值。 我們可以通過在更高的堆棧限制的數值上運行服務器繞開這個問題(缺省 `max_stack_depth`建議值是 4MB)。如果你無法這么做， 那么另外一個方法是減少`max_stack_depth`的值。 ## 30.2.7\. "隨機" 測試 `random`測試腳本的目的是生成隨機結果。在很罕見的情況下， 這會導致回歸測試中的隨機測試失敗。鍵入： ``` diff results/random.out expected/random.out ``` 會產生僅僅一行或幾行差別。你不必擔心這些，除非隨機測試在重復測試中總是失敗。