敏捷模型下的回歸測試

吳揚科

摘 要 敏捷模型是針對傳統瀑布模型的弊端而產生的一種新的軟件開發模型，目標是提高開發效率和響應能力。它是一種基于用戶的需求進化，迭代、循序漸進的開發方法。Scrum是敏捷開發模型的一種，它最大的特點是迅速響應需求變化。Scrum是在最近兩年中流行起來，它逐漸取代了傳統模型在開發過程中的地位，成為主流的開發模型。在實際工作中，當代碼更新后，我們往往要執行一次回歸測試。在Scrum模式下，由于其自身迭代十分頻繁，所以對回歸測試的執行速度和頻率都要求十分高。這就要求回歸測試不僅要對測試用例進行自動化，而且還要準備一套穩定的持續集成的環境，實現每天執行自動化測試用例。本文針對敏捷模型的特點，對回歸測試的實現做出了一些改進。

關鍵詞敏捷模型 Scrum 回歸測試 持續集成

中圖分類號：TP3 文獻標識碼：A

近年來隨著IT行業的迅速發展，軟件已經在人們日常生活中隨處可見，而軟件行業的競爭也日趨激烈。在激烈的競爭環境中，越來越多的軟件企業都期望采用一種開發周期短，質量穩定，投資回報高的軟件開發模型。于是敏捷模型逐漸走入人們的視野，并受到越來越過的開發團隊的青睞。敏捷開發是一種基于用戶需求的，循序漸進的迭代式的開發方法。相對于傳統的瀑布式模型來說，敏捷模型具有如下優點：

傳統的瀑布模型要求用戶需求明確，而且一旦確定下來，在后續開發過程中便不能更改。但是對大多數軟件項目來說，用戶的需求往往是不斷變化的。尤其是項目的初期，用戶需求很難明確，甚至有時用戶自身也很難有一個清晰的需求。而敏捷模式正是以用戶需求為核心的一種開發模式，用戶可以在敏捷模式的每一個迭代周期中，不斷提出自己新的需求（user story），以不斷接近最終的需求目標。

瀑布模型往往開發周期比較長，而且團隊成員的利用率不高，比如在設計階段往往只有設計人員和架構師參與其中，開發和測試人員的參與率很低。而敏捷模式由于其周期短，全體參與者在每個迭代周期內往往各司其職，充分參與到項目中，這就大大提高了開發效率。

敏捷模式可以較早推出可以運行的產品，并在用戶的使用中發現問題，改進需求，合理的規避風險。在這一點上瀑布模型是無法做到的，如果一旦瀑布模型生產出的產品最終無法被用戶所接受，那么產品將不得不重新設計，從而大大增長整個產品的成本和周期。這種返工的代價是巨大的，而且頻繁的返工往往會使整個項目面臨失敗的風險。

瀑布模型中，測試的階段往往比較滯后，這就導致有時很嚴重的問題往往到項目快臨近結束的時候才被發現出來。更有甚者，有的項目為了追趕時間進度，會把測試周期縮短以保證產品的按時發布，從而導致產品質量低下，嚴重影響用戶滿意度。但在敏捷模式中，每一個迭代周期都會對產品進行集成測試，而且自動化的集成測試可以極大的提高測試效率，使產品的質量得到持續性的保證。敏捷模式經常可以把嚴重的、優先級比較高的缺陷在早期發現并得到修復，保證上線的產品質量穩定，故障率通常較低。

Scrum是敏捷模型中最常用的一種開發模式。Scrum是橄欖球運動中的一個專業術語，表示爭球。 我們可以想象當一個項目團隊像打橄欖球一樣在開發一個項目，那是一件多么快速，多么富有激情的事情。在Scrum模式下，每一次迭代周期（一般為4個星期）定義為一個Sprint，中文意思即為沖刺，也就是說團隊成員要在迭代周期內，以最快的速度完成它。這里我們就不對Scrum的具體流程作詳細介紹了， 讀者有興趣可以參閱相關資料。

下面我們來看一下，在Scrum模式下測試通常是如何進行的。首先，在產品開發的過程中，新需求和新功能在迭代中不斷涌現，每次迭代結束都會產生一個可工作的軟件。這就要求測試人員要盡可能早的展開工作，等待開發人員完全開發完畢在Scrum中屬于一種錯誤的概念。

其次，測試用例要盡可能多地采用自動化。Scrum項目初期，產品停留在初步設計中，產品功能不多，復雜度小，手動測試就可以保證質量。而到了中后期，因不斷有新需求、新功能的加入，產品復雜度明顯增大。若仍然采用手動測試，恐怕難以覆蓋產品的各個功能、非功能點，而且手工測試在面對功能諸多的產品時，就會暴露出執行耗時長，易遺忘等缺點。因此，可以用自動化測試來提高工作效率。

然后就是，測試人員要學會做好需求分析，做好對設計邏輯的分析。測試人員要更多的思考需求的可實現性，將自身作為第一用戶積極參與項目和系統的需求分析，設計和開發。積極地參與前期工作，并迅速反饋給設計和開發人員。

回歸測試（Regression Test）簡單來說就是重復測試之前的測試用例。這個環節在很多項目，尤其是那些迭代相對頻繁的項目往往會被忽視，或者說做得不夠充分，究其原因是由于項目開發周期短，產品上線緊急，從而擠壓了回歸測試的時間。但是不得不說這個環節對保證產品質量和產品功能穩定是十分重要的。當一個新的功能加入到產品中或是一個已有的功能被修改，往往涉及很多模塊的變動，尤其是基類和公共類的改變，這時候就非常容易導致新的功能加入進來，已有的功能卻無法正常運行的情況，在耦合度相對較大的項目中這類問題更是尤為突出。

回歸測試重要性很明顯，但是在敏捷模型下，它執行起來卻沒有那么輕松。由于敏捷模型自身的特點：開發周期短，迭代頻繁，所以相對于傳統的瀑布模型，會使測試的壓力大大增加。其困難主要集中在兩個方面，首先是測試用例的數量，一般來說測試覆蓋率和測試用例的數量成正比，因此測試人員會在功能測試中會引入大量的測試用例來提高覆（下轉第33頁）（上接第31頁）蓋率，從而提高對產品質量和測試流程的信心。但是在測試用例增加的同時，測試時間也會延長，這就給回歸測試帶來了難度，測試人員很難在有限的時間里執行大量回歸測試。其次，當項目迭代次數很多時，大量的測試用例維護也會占用測試人員很多的時間和精力。一旦維護不及時，往往會使一個缺陷影響很多個迭代周期而不被人們發現。

由于回歸測試需要執行大量的測試用例，而這些測試用例的驗證步驟往往會有些共同的特點，所以人們往往用編程自動化的方法來實現回歸。自動化的回歸測試的好處主要有如下幾個方面：

減少手動回歸的測試量，縮短回歸測試的時間。

減少人為執行測試用例時的干擾因素，避免人為執行不充分的影響。

結合持續集成測試方法，保證回歸測試持續進行。

對復雜的測試用例可以進行分解，自動化每個單獨測試點。

對于測試用例中常用的步驟可以封裝成通用的方法，讓公共的測試步驟可以復用。

自動化還可以執行一些手動測試很難執行的測試用例，比如對于大量用戶和并發用戶的模擬。

在敏捷模型中，自動化的回歸測試幾乎是每個項目都會使用到，但是敏捷模型卻有一個特點是自動化的回歸測試往往陷入困境。那就是在敏捷模型下，需求的變動非常頻繁，測試人員經常需要對已有的測試用例進行修改。針對這個特點，在我們創建自動化測試用 例時，最好可以做到如下幾個方面：

將測試用例中的測試數據和測試用例本身分開。

盡量將常用方法封裝成公共方法。

將經常變化的參數提取到配置文件中。

減少硬編碼和重復的代碼量。

這樣做不僅能讓自動化測試代碼在需求變化時，修改程度最小化，而且還能讓測試代碼變得簡潔便于維護。

由于在敏捷模式下，迭代周期很短，有時候甚至會每周就發生一次迭代。這就要求測試人員經常對測試用例進行檢查，也就是說我們要經常地執行回歸測試。上面我們已經提到了自動化回歸測試的方法，現在我們再看一下這種方法應該如何執行，以及它執行的頻率。在敏捷模型的項目里，有兩種執行自動化回歸測試的策略，一種是在代碼簽入時，另一種是以天為單位來執行。具體選用哪種策略，我們通常是看代碼簽入的頻率，如果代碼簽入頻率很高話，按天執行回歸將是很好的選擇。測試人員只需要每天檢查測試結果的報告就可以發現哪些測試用例出了問題，具體是測試用例需要調整，還是產品功能發生了異常，需要測試人員進行分析。當然如果測試用例的日志足夠詳細的話，將有助于對問題的分析和定位。

綜上所述，回歸測試在敏捷模式下的作用非常重要，其測試方法也越來越偏重于自動化的實現方案，相較于過去的開發模型，敏捷模型對測試人員的編程能力要求更高。在敏捷模型下的項目，測試人員要從事大量的自動化編程工作，在一些項目中測試人員和開發人員甚至可以做到角色互換。希望測試人員在敏捷模型下可以轉變過去傳統模型所固有的思路，將回歸測試做得更好。

參考文獻

[1] Lisa Crispin and Janet Gregory. 敏捷軟件測試：測試人員與敏捷團隊的實踐指南. 清華大學出版社. 2010年.

[2] Robert C Martin. 敏捷軟件開發：原則、模式與實踐. 清華大學出版社. 2003年.

[3] 陳能技. QTP自動化測試最佳實踐. 電子工業出版社. 2012年.