PostgreSQL 10.1 手冊_部分 III. 伺服器管理_第 32 章 回歸測試_32.2. 測試評估

32.2. 測試評估

32.2.1. 錯誤消息差異

32.2.2. 區域差異

32.2.3. 日期和時間差異

32.2.4. 浮點差異

32.2.5. 行序差異

32.2.6. 棧深度不足

32.2.7. “失敗”測試

32.2.8. 配置參數

一些正确安裝的并且全功能的PostgreSQL安裝可能會在這些回歸測試中的某些上“失敗”，其原因是平台相關的因素，例如可變浮點表示和 message wording。這些測試目前采用

diff

指令來比較測試輸出和在參考系統上産生的輸出，這樣測試的結果對小的系統差異也很敏感。當一個測試被報告為“失敗”時，請總是檢查實際結果和期望結果之間的差異，你可能會發現該差異其實并不明顯。不管怎樣，我們将努力維護在所有被支援平台上的準确的參考檔案，以期待所有的測試都能通過。

回歸測試的實際輸出在

src/test/regress/results

目錄中的檔案内。測試腳本會使用

diff

來把每一個輸出檔案與存儲在

src/test/regress/expected

目錄中的參考輸出進行比較。任何差異都被儲存在

src/test/regress/regression.diffs

中便于你的觀察（當運作一個除核心測試之外的測試套件時，這些檔案當然會出現在相關子目錄中，而不是

src/test/regress

）。

如果你不喜歡被預設使用的

diff

選項，請設定環境變量

PG_REGRESS_DIFF_OPTS

，例如

PG_REGRESS_DIFF_OPTS='-u'

（或者如果你願意，你可以自己運作

diff

如果由于某種原因一個特定的平台對一個給定測試産生了“失敗”，而對輸出的檢查卻說明該結果是合法的，你可以增加一個新的比較檔案來讓失敗報告在未來的測試運作中保持沉默。詳見

第 32.3 節

。

32.2.1. 錯誤消息差異

某些回歸測試涉及到故意的非法輸入值。錯誤消息可能來自PostgreSQL代碼或主機平台系統例程。在後一種情況中，消息會随着平台而變化，但是會反映相似的資訊。這些消息中的差異将導緻一次“失敗的”回歸測試，這可以通過檢查來确認。

32.2.2. 區域差異

如果你在一台使用除 C 之外的排序規則順序區域初始化的伺服器上運作測試，那麼可能會出現由于排序順序和後續失敗産生的差異。回歸測試套件被設定為可以處理這種問題，方法是提供替代的結果檔案來處理大量的區域。

要在使用臨時安裝方法時在一種不同的區域中運作測試，可在

make

指令行上傳遞适當的區域相關的環境變量，例如：

make check LANG=de_DE.utf8      

（回歸測試驅動器會取消

LC_ALL

設定，是以使用這個變量選擇區域是不起作用的）。要不使用區域，要麼取消所有區域相關的環境變量設定（或把它們設定為

C

），要麼使用下列特殊調用：

make check NO_LOCALE=1      

當對一個現有安裝運作測試時，區域設定由現有安裝決定。要改變它，通過向

initdb

傳遞合适的選項來使用不同的區域初始化資料庫集簇。

通常，我們建議對将要在生産環境中使用的區域設定運作回歸測試，因為這樣可以測試即将真正被用在生産環境中的與區域和編碼相關的代碼。根據 作業系統環境，你可能會得到失敗，但是那樣你将至少知道在真實應用運作時會得到什麼樣的與區域相關的行為。

32.2.3. 日期和時間差異

大部分的日期和時間結果依賴于時區環境。參考檔案是用時區

PST8PDT

（伯克利，加利福利亞）生成的，并且如果測試不是運作在該時區設定中顯然會出現失敗。回歸測試驅動器會設定環境變量

PGTZ

為 

PST8PDT

，這通常能保證正确的結果。

32.2.4. 浮點差異

某些測試涉及到從表列中計算 64 位浮點數（

雙精度

）。我們已經發現了涉及到

雙精度

列的數學函數的結果中的差異。

float8

和

geometry

測試容易在不同平台之間産生小的差異，甚至對不同的編譯器優化設定也可能産生差異。這些差異通常位于小數點右邊的 10 個位置，決定這些差異的實際意義需要人類眼球比較。

某些系統顯示負零為

-0

，而其他的隻顯示

某些系統标志來自

pow()

exp()

的錯誤的機制不同于目前PostgreSQL代碼所期望的機制。

32.2.5. 行序差異

你可能看到這樣一些差異：一組相同的行在輸出中的順序與參考檔案中的順序不同。嚴格來說，在大部分情況下這不是缺陷。大部分回歸測試腳本沒有為每一個單獨的

SELECT

使用一個

ORDER BY

，并且是以它們的結果行順序根據 SQL 規範是非良定義的。實際上，因為我們考慮的是由相同的軟體在相同的資料上執行相同的查詢，我們通常會在所有平台上得到相同的結果順序，是以缺少

ORDER BY

不是一個問題。但是，某些查詢确實會在不同平台上産生不同的順序。當對一個已經安裝的伺服器運作測試時，順序差異可能由非 C 區域設定或非預設參數設定導緻，例如

work_mem

的自定義值或規劃器代價參數。

是以，如果你看到一個順序差異，沒有什麼可擔心的，除非結果被未被的查詢确實有一個

ORDER BY

。但是，不管怎樣請報告它，這樣我們可以為特定的查詢加上一個

ORDER BY

來在未來的釋出中消除虛假的“失敗”。

你可能好奇為什麼我們不對所有回歸測試查詢進行顯式排序來一次性解決這個問題。其原因是那可能會降低回歸測試的有用性，因為它們已經傾向于測試産生有序結果的查詢計劃類型而排除了那些無法産生有序結果的計劃類型。

32.2.6. 棧深度不足

如果

錯誤

測試導緻了在

select infinite_recurse()

指令上的一次伺服器崩潰，它意味着平台對程序棧尺寸的限制低于

max_stack_depth

參數所指定的值。這可以通過在一個更高的棧尺寸限制（對

max_stack_depth

的預設值，我們推薦 4 MB）下運作該伺服器來修複。如果你不能這樣做，一種可替代的方案是減小

max_stack_depth

的值。

在支援

getrlimit()

的平台上，伺服器應該自動選擇一個

max_stack_depth

的安全值。是以除非你已經手工覆寫了該設定，這類失敗就是一個可報告的缺陷。

失敗

測試腳本用來産生随機結果。在非常少見的情況下，這會導緻回歸測試失敗。輸入：

diff results/random.out expected/random.out      

應當産生一行或少數幾行差異。你不需要擔心，除非随機測試重複地失敗。

32.2.8. 配置參數

當對一個現有安裝運作測試時，某些非預設參數設定可能導緻測試失敗。例如，改變

enable_seqscan

或

enable_indexscan

等參數可能導緻計劃改變，然後影響使用

EXPLAIN

的測試的結果。

本文轉自PostgreSQL中文社群，原文連結：