簡介
回歸測試是一套複雜完整的測試，用來測試嵌入在PostgreSQL裡的的SQL實現．它同時測試标準SQL操作和PostgreSQL的擴展SQL．這個套件最初是JollyChen和AndrewYu開發的，并且由MarcFournier和ThomasLockhart進行了大量的改進和重新封裝。自PostgreSQL6.1以上開始，這個回歸測試包含在每個正式發布版本裡。
回歸測試可以就一套已經安裝好并且在運行的服務器進行測試，也可以就制作樹裡面臨時安裝的服務器進行測試．詳細些說，有"并行"和"串行"運行測試之分．串行模式順序運行每個測試，而并行模式激活多個服務器進程，并行地運行一組測試．并行測試使我們對進程内部通訊和鎖的正确工作有足夠的信心．由于曆史原因，串行測試通常對一個現存的安裝進行測試，而并行測試是"獨立"的，不過這麼做沒有什麼技術原因。
每當一個新的模塊被當作集成測試的一部分加進來的時候，軟件就發生了改變。新的數據流路徑建立起來，新的I/O操作可能也會出現，還有可能激活了新的控制邏輯。這些改變可能會使原本工作得很正常的功能産生錯誤。在集成測試策略的環境中，回歸測試是對某些已經進行過的測試的某些子集再重新進行一遍，以保證上述改變不會傳播無法預料的副作用。
在更廣的環境裡，（任何種類的）成功測試結果都是發現錯誤，而錯誤是要被修改的，每當軟件被修改的時候，軟件配置的某些方面（程序、文檔、或者數據）也被修改了，回歸測試就是用來保證（由于測試或者其他原因的）改動不會帶來不可預料的行為或者另外的錯誤。
回歸測試可以通過重新執行所有的測試用例的一個子集人工地進行，也可以使用自動化的捕獲回放工具來進行。捕獲回放工具使得軟件工程師能夠捕獲到測試用例，然後就可以進行回放和比較。回歸測試集（要進行的測試的子集）包括三種不同類型的測試用例：
·能夠測試軟件的所有功能的代表性測試用例。
·專門針對可能會被修改影響的軟件功能的附加測試。
·針對修改過的軟件成分的測試。
在集成測試進行的過程中，回歸測試可能會變得非常龐大。因此，回歸測試應當設計為隻包括那些涉及在主要的軟件功能中出現的一個或多個錯誤類的那些測試，每當進行一個修改時，就對每一個程序功能都重新執行所有的測試是不實際的而且效率很低。
概述
在軟件生命周期中的任何一個階段，隻要軟件發生了改變，就可能給該軟件帶來問題。軟件的改變可能是源于發現了錯誤并做了修改，也有可能是因為在集成或維護階段加入了新的模塊。該方法容易生成冗餘的測試數據,從而降低了回歸測試的效率.研究了回歸測試的分支覆蓋問題,當軟件中所含錯誤被發現時，如果錯誤跟蹤與管理系統不夠完善，就可能會遺漏對這些錯誤的修改；而開發者對錯誤理解的不夠透徹，也可能導緻所做的修改隻修正了錯誤的外在表現，而沒有修複錯誤本身，從而造成修改失敗；修改還有可能産生副作用從而導緻軟件未被修改的部分産生新的問題，使本來工作正常的功能産生錯誤。
同樣，在有新代碼加入軟件的時候，除了新加入的代碼中有可能含有錯誤外，新代碼還有可能對原有的代碼帶來影響。因此，每當軟件發生變化時，我們就必須重新測試現有的功能，以便确定修改是否達到了預期的目的，檢查修改是否損害了原有的正常功能。同時，還需要補充新的測試用例來測試新的或被修改了的功能。為了驗證修改的正确性及其影響就需要進行回歸測試。
回歸測試在軟件生命周期中扮演着重要的角色，因忽視回歸測試而造成嚴重後果的例子不計其數，導緻阿裡亞娜5型火箭發射失敗的軟件缺陷就是由于複用的代碼沒有經過充分的回歸測試造成的。
策略
對于一個軟件開發項目來說，項目的測試組在實施測試的過程中會将所開發的測試用例保存到“測試用例庫”中，并對其進行維護和管理。當得到一個軟件的基線版本時，用于基線版本測試的所有測試用例就形成了基線測試用例庫。在需要進行回歸測試的時候，就可以根據所選擇的回歸測試策略，從基線測試用例庫中提取合适的測試用例組成回歸測試包，通過運行回歸測試包來實現回歸測試。保存在基線測試用例庫中的測試用例可能是自動測試腳本，也有可能是測試用例的手工實現過程。
回歸測試需要時間、經費和人力來計劃、實施和管理。為了在給定的預算和進度下，盡可能有效率和有效力地進行回歸測試，需要對測試用例庫進行維護并依據一定的策略選擇相應的回歸測試包。
維護
為了最大限度地滿足客戶的需要和适應應用的要求，軟件在其生命周期中會頻繁地被修改和不斷推出新的版本，修改後的或者新版本的軟件會添加一些新的功能或者在軟件功能上産生某些變化。随着軟件的改變，軟件的功能和應用接口以及軟件的實現發生了演變，測試用例庫中的一些測試用例可能會失去針對性和有效性，而另一些測試用例可能會變得過時，還有一些測試用例将完全不能運行。為了保證測試用例庫中測試用例的有效性，必須對測試用例庫進行維護。同時，被修改的或新增添的軟件功能，僅僅靠重新運行以前的測試用例并不足以揭示其中的問題，有必要追加新的測試用例來測試這些新的功能或特征。因此，測試用例庫的維護工作還應包括開發新測試用例，這些新的測試用例用來測試軟件的新特征或者覆蓋現有測試用例無法覆蓋的軟件功能或特征。
測試用例的維護是一個不間斷的過程，通常可以将軟件開發的基線作為基準，維護的主要内容包括下述幾個方面。
(1)删除過時的測試用例
因為需求的改變等原因可能會使一個基線測試用例不再适合被測試系統，這些測試用例就會過時。例如，某個變量的界限發生了改變，原來針對邊界值的測試就無法完成對新邊界測試。所以，在軟件的每次修改後都應進行相應的過時測試用例的删除。
(2)改進不受控制的測試用例
随着軟件項目的進展，測試用例庫中的用例會不斷增加，其中會出現一些對輸入或運行狀态十分敏感的測試用例。這些測試不容易重複且結果難以控制，會影響回歸測試的效率，需要進行改進，使其達到可重複和可控制的要求。
(3)删除冗餘的測試用例
如果存在兩個或者更多個測試用例針對一組相同的輸入和輸出進行測試，那麼這些測試用例是冗餘的。冗餘測試用例的存在降低了回歸測試的效率。所以需要定期的整理測試用例庫，并将冗餘的用例删除掉。
(4)增添新的測試用例
如果某個程序段、構件或關鍵的接口在現有的測試中沒有被測試，那麼應該開發新測試用例重新對其進行測試。并将新開發的測試用例合并到基線測試包中。
通過對測試用例庫的維護不僅改善了測試用例的可用性，而且也提高了測試庫的可信性，同時還可以将一個基線測試用例庫的效率和效用保持在一個較高的級别上。
方式
在軟件生命周期中，即使一個得到良好維護的測試用例庫也可能變得相當大，這使每次回歸測試都重新運行完整的測試包變得不切實際。一個完全的回歸測試包括每個基線測試用例，時間和成本約束可能阻礙運行這樣一個測試，有時測試組不得不選擇一個縮減的回歸測試包來完成回歸測試。
回歸測試的價值在于它是一個能夠檢測到回歸錯誤的受控實驗。當測試組選擇縮減的回歸測試時，有可能删除了将揭示回歸錯誤的測試用例，消除了發現回歸錯誤的機會。然而，如果采用了代碼相依性分析等安全的縮減技術，就可以決定哪些測試用例可以被删除而不會讓回歸測試的意圖遭到破壞。
選擇回歸測試策略應該兼顧效率和有效性兩個方面。常用的選擇回歸測試的方式包括：
(1)再測試全部用例
選擇基線測試用例庫中的全部測試用例組成回歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏回歸錯誤的風險，但測試成本最高。全部再測試幾乎可以應用到任何情況下，基本上不需要進行分析和重新開發，但是，随着開發工作的進展，測試用例不斷增多，重複原先所有的測試将帶來很大的工作量，往往超出了我們的預算和進度。
(2)基于風險選擇測試
可以基于一定的風險标準來從基線測試用例庫中選擇回歸測試包。首先運行最重要的、關鍵的和可疑的測試，而跳過那些非關鍵的、優先級别低的或者高穩定的測試用例，這些用例即便可能測試到缺陷，這些缺陷的嚴重性也僅有三級或四級。一般而言，測試從主要特征到次要特征。
(3)基于操作剖面選擇測試
如果基線測試用例庫的測試用例是基于軟件操作剖面開發的，測試用例的分布情況反映了系統的實際使用情況。回歸測試所使用的測試用例個數可以由測試預算确定，回歸測試可以優先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級别的風險，有助于盡早發現那些對可靠性有最大影響的故障。這種方法可以在一個給定的預算下最有效的提高系統可靠性，但實施起來有一定的難度。
(4)再測試修改的部分
當測試者對修改的局部化有足夠的信心時，可以通過相依性分析識别軟件的修改情況并分析修改的影響，将回歸測試局限于被改變的模塊和它的接口上。通常，一個回歸錯誤一定涉及一個新的測試盡可能覆蓋受到影響的部分。
再測試全部用例的策略是最安全的策略，但已經運行過許多次的回歸測試不太可能揭示新的錯誤，而且很多時候，由于時間、人員、設備和經費的原因，不允許選擇再測試全部用例的回歸測試策略，此時，可以選擇适當的策略進行縮減的回歸測試。
過程
有了測試用例庫的維護方法和回歸測試包的選擇策略，回歸測試可遵循下述基本過程進行:
(1)識别出軟件中被修改的部分；
(2)從原基線測試用例庫T中，排除所有不再适用的測試用例，确定那些對新的軟件版本依然有效的測試用例，其結果是建立一個新的基線測試用例庫T0。
(3)依據一定的策略從T0中選擇測試用例測試被修改的軟件。
(4)如果必要，生成新的測試用例集T1，用于測試T0無法充分測試的軟件部分。
(5)用T1執行修改後的軟件。
第(2)和第(3)步測試驗證修改是否破壞了現有的功能，第(4)和第(5)步測試驗證修改工作本身。
實踐
在實際工作中，回歸測試需要反複進行，當測試者一次又一次地完成相同的測試時，這些回歸測試将變得非常令人厭煩，而在大多數回歸測試需要手工完成的時候尤其如此，因此，需要通過自動測試來實現重複的和一緻的回歸測試。通過測試自動化可以提高回歸測試效率。為了支持多種回歸測試策略，自動測試工具應該是通用的和靈活的，以便滿足達到不同回歸測試目标的要求。
在測試軟件時，應用多種測試技術是常見的。當測試一個修改了的軟件時，測試者也可能希望采用多于一種回歸測試策略來增加對修改軟件的信心。不同的測試者可能會依據自己的經驗和判斷選擇不同的回歸測試技術和策略。
回歸測試并不減少對系統新功能和特征的測試需求，回歸測試包應包括新功能和特征的測試。如果回歸測試包不能達到所需的覆蓋要求，必須補充新的測試用例使覆蓋率達到規定的要求。
回歸測試是重複性較多的活動，容易使測試者感到疲勞和厭倦，降低測試效率，在實際工作中可以采用一些策略減輕這些問題。例如，安排新的測試者完成手工回歸測試，分配更有經驗的測試者開發新的測試用例，編寫和調試自動測試腳本，做一些探索性的或ad hoc測試。還可以在不影響測試目标的情況下，鼓勵測試者創造性地執行測試用例，變化的輸入、按鍵和配置能夠有助于激勵測試者又能揭示新的錯誤。
在組織回歸測試時需要注意兩點，首先是各測試階段發生的修改一定要在本測試階段内完成回歸，以免将錯誤遺留到下一測試階段。其次，回歸測試期間應對該軟件版本凍結，将回歸測試發現的問題集中修改，集中回歸。
在實際工作中，可以将回歸測試與兼容性測試結合起來進行。在新的配置條件下運行舊的測試可以發現兼容性問題，而同時也可以揭示編碼在回歸方面的錯誤。
