也談軟件回歸測試

也談軟件回歸測試  自動回歸測試

開發人員對回歸測試應該有所耳聞，但是并非都很清楚它的確切含義，比如我，以前老聽到測試部門的頭兒說回歸回歸，但也沒具體去探討什么叫回歸測試，可能回歸這個詞太熟也太陌生吧，今天終于去探尋一番啥叫回歸。

　　回歸測試英文名叫regression testing，regression是復原退步的意思，當然不能想當然的理解為“退了步的測試”，描述為 “對退步再進行測試”可能較為恰當。既然是退步，那就還存在“原地踏步”這種狀態，相對于“原地”往后退才叫做“退步”，為什么會退步，也就是說測試的緣由是什么，緣由是因為系統、程序或代碼的狀態被改變了。在系統發布前通常會做多次回歸測試，比如第n次發布測試發現了m個bugs（這里假定系統此時處于第n狀態），程序被QA部門reject回到開發部門當中，開發人員根據bug系統進行缺陷修正，修正完畢后提交給QA部門進行回歸測試，這次回歸是針對第n次發布測試，測試目標是m個bugs將得到fixed，回歸結果將得到系統的一個新的狀態（這里假定系統處于第n+1狀態），在第n狀態到第n+1狀態中間，由于開發人員對代碼進行更改，因此這時候系統狀態的未知系數（不穩定性）是非常高的，可以稱之為“退步”(regresssion)，因此第 n+1次測試其實是針對這一“退步”狀態進行，因而叫做回歸，回歸在這里可以有兩重意思，一是回到系統的較低級狀態，二是將系統的狀態“拉回”到新的穩定狀態（第n+1狀態）。

　　回歸測試并非局限于某一種測試，比如發布測試，它可以發生在單元測試(ut)，功能測試(ft)，集成測試(it)等等當中，當代碼發生任何變動的時候，所執行的測試就可以說是一次回歸測試，回歸測試可以是自動的，也可以是手工的，比如前面所舉的發布測試通常是手工完成，當回歸測試可以自動執行的時候，系統可以較快地到達一個新的穩定狀態，比如一個系統如果有良好的ut基礎，那么代碼的變更一旦檢入代碼庫當中，就可以觸發連續構建工具進行build and test（回歸測試），失敗的結果將在第一時間通知變更代碼的程序員，或者通知配置管理員立即處理有問題的代碼，這種just-in-time的處理方式將大大減少bug數目并提高代碼質量，同時使團隊的合作開發更加順暢。

　　測試的自動化的程度越高，回歸的周期就越短，效果越明顯，軟件的質量也越高，測試是否自動化也是開發是否敏捷的一個主要標志。

原文轉自：http://www.anti-gravitydesign.com