軟件測試中Postgresql回歸測試

軟件測試中Postgresql回歸測試

回歸測試是一套復雜完整的測試， 用來測試嵌入在 PostgreSQL 里的的 SQL 實現。 它同時測試標準 SQL 操作和PostgreSQL的擴展SQL。

運行測試

回歸測試可以就一套已經安裝好并且在運行的服務器進行測試， 也可以就制作樹里面臨時安裝的服務器進行測試。 詳細些說，有"并行"和"串行"運行測試之分。 串行模式順序運行每個測試，而并行模式啟動多個服務器進程，并行地運行一組測試。 并行測試使我們對進程內部通訊和鎖的正確工作有足夠的信心。 由于歷史原因，串行測試通常對一個現存的安裝進行測試，而并行測試是"獨立"的，不過這么做沒有什么技術原因。

制作之后和安裝之前運行回歸測試，你可以在頂級目錄鍵入

gmake check

（或者你可以進入 src/test/regress 然后在那里運行命令。） 這樣將先制作幾個輔助文件，比如一些用戶定義的觸發器函數，然后再運行測試驅動腳本。 最后你會看到類似下面的東西

======================
All 96 tests passed.
======================

或者是一些關于某項測試失敗的信息。先看看下面的 Section 26.2 然后再想想一個"失敗"是否代表嚴重的錯誤。

因為這個測試方法運行臨時的服務器，所以如果你是 root 用戶， 那這個方法不能運行（服務器不能以 root 身份啟動）。 如果你已經以 root 身份制作了，你就什么也干不了。 這時候你應該把測試目錄的權限變成某個用戶可以寫， 然后以那個用戶身份登陸，再開始測試。比如

root# chmod -R a+w src/test/regress
root# chmod -R a+w contrib/spi
root# su - joeuser
joeuser$ cd top-level build directory
joeuser$ gmake check
（這里唯一可能的"安全隱患"就是那個用戶可能會背著你修改回歸測試的結果。用你的常識管理用戶權限。）

如果不是上面那樣，安裝后就可以運行測試．

如果你配置 PostgreSQL 安裝到一個原來安裝有老的 PostgreSQL 的目錄里，然后在安裝新版本之前執行 gmake check， 那么你可能發現測試失敗，因為新程序試圖使用已經存在的共享庫。 （典型的癥狀是抱怨未定義的符號。） 如果你想在覆蓋老版本之間運行測試，那么你需要帶著 configure --disable-rpath 制作。 不過，我們不建議你使用這個選項編譯作為最終安裝的數據庫。

并行的回歸測試會在你的用戶 ID 下啟動相當多的進程。 目前，最大的并發數是 20 給并行測試腳本，這意味著 60 個進程： 一個服務器進程，一個psql以及通常還有一個 shell 父進程用于每個測試腳本的psql。 因此，如果你的系統有每用戶的進程數限制，那么請確保這個限制至少是 75，否則你就可能在并行測試時看到隨機出現的失敗。 如果你沒有辦法提升該限制，那么你可以通過設置 MAX_CONNECTIONS 參數，把大的并行測試程度降低。

在某些系統上，缺省的 Bourne 兼容的 shell（/bin/sh）在管理太多并行的子進程的時候會出亂子。 這可能導致并行測試鎖住或者失敗。 出現這種情況時，請在命令行上聲明另外一個 Bourne 兼容的 shell，比如：

gmake SHELL=/bin/ksh check
如果沒有可以替換的 shell，那么你可以象上面那樣通過限制連接的個數來繞開。

安裝后運行測試， 初始化一個數據區然后啟動服務器，像我們在 Chapter 16 里面描述的那樣，然后鍵入

gmake installcheck

或者是跑一個并行測試

gmake installcheck-parallel

該測試將與在本地主機和缺省端口號上運行的服務器進行聯接， 除非你用PGHOST和PGPORT環境變量設置為其它值。

有一些正確安裝并且具有完整功能的 PostgreSQL可能會在一些回歸測試中"失效"， 這些主要是因為浮點數的形式和時區支持的問題。 目前的測試只是簡單的用 diff 與參考系統的輸出進行比較， 因而對一些細小的系統區別很敏感。 當一項測試報告"失敗"時，只要檢查一下預期和實際的結果， 你就會發現區別并不大。 當然，我們仍然在努力維護所有我們支持的平臺的準確的參考文件， 這樣我們就可以假定所有測試都通過。

回歸測試的實際輸出是在 src/test/regress/results 目錄里的文件里。測試腳本使用 diff 以比較每個輸出文件和存放在 src/test/regress/expected 目錄里的參考輸出。任何區別都存放在 src/test/regress/regression.diffs 里面供你檢查。（或者如果你愿意的話，你也可以自己運行 diff。）

錯誤信息差別

有一些回歸測試涉及到有意的非法輸入值。 錯誤信息可能會來自 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.anti-gravitydesign.com