吳揚(yáng)科

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

關(guān)鍵詞敏捷模型 Scrum 回歸測試 持續(xù)集成

中圖分類號：TP3 文獻(xiàn)標(biāo)識碼：A

近年來隨著IT行業(yè)的迅速發(fā)展，軟件已經(jīng)在人們?nèi)粘Ｉ钪须S處可見，而軟件行業(yè)的競爭也日趨激烈。在激烈的競爭環(huán)境中，越來越多的軟件企業(yè)都期望采用一種開發(fā)周期短，質(zhì)量穩(wěn)定，投資回報(bào)高的軟件開發(fā)模型。于是敏捷模型逐漸走入人們的視野，并受到越來越過的開發(fā)團(tuán)隊(duì)的青睞。敏捷開發(fā)是一種基于用戶需求的，循序漸進(jìn)的迭代式的開發(fā)方法。相對于傳統(tǒng)的瀑布式模型來說，敏捷模型具有如下優(yōu)點(diǎn)：

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

瀑布模型往往開發(fā)周期比較長，而且團(tuán)隊(duì)成員的利用率不高，比如在設(shè)計(jì)階段往往只有設(shè)計(jì)人員和架構(gòu)師參與其中，開發(fā)和測試人員的參與率很低。而敏捷模式由于其周期短，全體參與者在每個(gè)迭代周期內(nèi)往往各司其職，充分參與到項(xiàng)目中，這就大大提高了開發(fā)效率。

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

瀑布模型中，測試的階段往往比較滯后，這就導(dǎo)致有時(shí)很嚴(yán)重的問題往往到項(xiàng)目快臨近結(jié)束的時(shí)候才被發(fā)現(xiàn)出來。更有甚者，有的項(xiàng)目為了追趕時(shí)間進(jìn)度，會(huì)把測試周期縮短以保證產(chǎn)品的按時(shí)發(fā)布，從而導(dǎo)致產(chǎn)品質(zhì)量低下，嚴(yán)重影響用戶滿意度。但在敏捷模式中，每一個(gè)迭代周期都會(huì)對產(chǎn)品進(jìn)行集成測試，而且自動(dòng)化的集成測試可以極大的提高測試效率，使產(chǎn)品的質(zhì)量得到持續(xù)性的保證。敏捷模式經(jīng)?？梢园褔?yán)重的、優(yōu)先級比較高的缺陷在早期發(fā)現(xiàn)并得到修復(fù)，保證上線的產(chǎn)品質(zhì)量穩(wěn)定，故障率通常較低。

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

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

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

然后就是，測試人員要學(xué)會(huì)做好需求分析，做好對設(shè)計(jì)邏輯的分析。測試人員要更多的思考需求的可實(shí)現(xiàn)性，將自身作為第一用戶積極參與項(xiàng)目和系統(tǒng)的需求分析，設(shè)計(jì)和開發(fā)。積極地參與前期工作，并迅速反饋給設(shè)計(jì)和開發(fā)人員。

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

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

由于回歸測試需要執(zhí)行大量的測試用例，而這些測試用例的驗(yàn)證步驟往往會(huì)有些共同的特點(diǎn)，所以人們往往用編程自動(dòng)化的方法來實(shí)現(xiàn)回歸。自動(dòng)化的回歸測試的好處主要有如下幾個(gè)方面：

減少手動(dòng)回歸的測試量，縮短回歸測試的時(shí)間。

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

結(jié)合持續(xù)集成測試方法，保證回歸測試持續(xù)進(jìn)行。

對復(fù)雜的測試用例可以進(jìn)行分解，自動(dòng)化每個(gè)單獨(dú)測試點(diǎn)。

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

自動(dòng)化還可以執(zhí)行一些手動(dòng)測試很難執(zhí)行的測試用例，比如對于大量用戶和并發(fā)用戶的模擬。

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

將測試用例中的測試數(shù)據(jù)和測試用例本身分開。

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

將經(jīng)常變化的參數(shù)提取到配置文件中。

減少硬編碼和重復(fù)的代碼量。

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

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

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

參考文獻(xiàn)

[1] Lisa Crispin and Janet Gregory. 敏捷軟件測試：測試人員與敏捷團(tuán)隊(duì)的實(shí)踐指南. 清華大學(xué)出版社. 2010年.

[2] Robert C Martin. 敏捷軟件開發(fā)：原則、模式與實(shí)踐. 清華大學(xué)出版社. 2003年.

[3] 陳能技. QTP自動(dòng)化測試最佳實(shí)踐. 電子工業(yè)出版社. 2012年.