敏捷模型下的回歸測(cè)試

吳揚(yáng)科

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

參考文獻(xiàn)

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

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

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