引言

隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，產(chǎn)品的快速迭代且能適應(yīng)市場(chǎng)需求已經(jīng)成為各大公司的痛點(diǎn)。而傳統(tǒng)的開發(fā)模式已經(jīng)不再適用于快速迭代的產(chǎn)品，在這種情況下，敏捷開發(fā)模式因其高度迭代、頻繁交付以及適應(yīng)變化的特點(diǎn)，已經(jīng)在各個(gè)領(lǐng)域得到廣泛應(yīng)用。與此同時(shí)，敏捷開發(fā)的發(fā)展對(duì)軟件測(cè)試也提出了更高的要求。因此，敏捷測(cè)試對(duì)提高測(cè)試效率進(jìn)而提升產(chǎn)品交付質(zhì)量具有重大意義。

敏捷開發(fā)的發(fā)展與特點(diǎn)

在2001年2月，Martin Fowler和他的同事提出了敏捷宣言，指出：

• 個(gè)體和交互勝過流程和工具;
• 可用的軟件勝過完備的文檔;
• 客戶協(xié)作勝過合同談判;
• 響應(yīng)變化勝過遵循計(jì)劃。

無論什么行業(yè)或產(chǎn)品，軟件開發(fā)的最終目標(biāo)就是為了能滿足客戶的需求，實(shí)現(xiàn)客戶的根本利益。在互聯(lián)網(wǎng)行業(yè)中，市場(chǎng)需求快速變化，這一特性比傳統(tǒng)行業(yè)更為明顯。如何能夠根據(jù)客戶提出的需求及時(shí)調(diào)整開發(fā)的內(nèi)容和進(jìn)度，從而減少在傳統(tǒng)開發(fā)模式下所造成的不必要的浪費(fèi)?這大概是所有互聯(lián)網(wǎng)公司都在思考的問題。敏捷開發(fā)是一個(gè)不斷累加、迭代增長(zhǎng)及時(shí)響應(yīng)的過程。因此，敏捷開發(fā)模式已經(jīng)成為全球范圍最受歡迎的軟件開發(fā)模式。

在敏捷開發(fā)模式中，Scrum是其中一種增量迭代開發(fā)的框架，其以人為核心進(jìn)行迭代和循序漸進(jìn)的開發(fā)方法已經(jīng)被廣泛運(yùn)用。利用這種Scrum敏捷方法，可以將整個(gè)開發(fā)周期劃分成多個(gè)小的迭代周期(Sprint)，每個(gè)周期長(zhǎng)度一般在2 到4 周之間。在Scrum 框架下，產(chǎn)品需求利用Backlog 進(jìn)行管理。Backlog 是一個(gè)按照商業(yè)價(jià)值等原則進(jìn)行排序的列表，根據(jù)用戶故事(User Story)進(jìn)行列表?xiàng)l目的體現(xiàn)。

利用Scrum 敏捷方法進(jìn)行開發(fā)，一般會(huì)先開發(fā)對(duì)客戶具有較高價(jià)值的需求。在每個(gè)迭代周期中，開發(fā)團(tuán)隊(duì)可以從產(chǎn)品中挑選最有價(jià)值的需求優(yōu)先開發(fā)。在Sprint 計(jì)劃會(huì)議上，開發(fā)團(tuán)隊(duì)會(huì)對(duì)需求進(jìn)行分析討論，并且估算得到一個(gè)待辦列表。完成迭代后，Scrum團(tuán)隊(duì)則能夠進(jìn)行潛在可交付的產(chǎn)品增量的交付。

Scrum這種敏捷開發(fā)模式，其特點(diǎn)是在一個(gè)極短的發(fā)布周期內(nèi)交付業(yè)務(wù)價(jià)值的一部分，并在開發(fā)周期內(nèi)不斷的迭代和循序漸進(jìn)。敏捷開發(fā)模式不斷接受需求更新，這樣就能做到及時(shí)并持續(xù)的響應(yīng)客戶的反饋。

敏捷開發(fā)與測(cè)試的運(yùn)用

軟件測(cè)試貫穿于軟件的整個(gè)生命周期，是保證軟件質(zhì)量的基礎(chǔ)。測(cè)試團(tuán)隊(duì)通過選用合適的軟件測(cè)試技術(shù)以及測(cè)試工具，來不斷改善軟件開發(fā)及測(cè)試流程。在敏捷開發(fā)模式得到迅速發(fā)展的同時(shí)，敏捷測(cè)試也成為了軟件開發(fā)與測(cè)試團(tuán)隊(duì)共同關(guān)注的焦點(diǎn)。

敏捷測(cè)試通過持續(xù)對(duì)軟件進(jìn)行測(cè)試并及時(shí)反饋測(cè)試結(jié)果來提高軟件質(zhì)量，滿足用戶需求，其強(qiáng)調(diào)“持續(xù)測(cè)試”和“及時(shí)反饋”。因此，敏捷測(cè)試在一定程度上也可以被認(rèn)為是遵循敏捷宣言的一種測(cè)試實(shí)踐。

圖一：敏捷開發(fā)與測(cè)試流程

從圖一可以看到，在某個(gè)Sprint中整個(gè)敏捷開發(fā)與測(cè)試流程被分成了以下幾個(gè)步驟：

待辦列表

在待辦列表中會(huì)列出所有此Sprint將要開發(fā)的功能，這些列表一般是以User Story的形式來進(jìn)行功能描述，并可能會(huì)隨著項(xiàng)目的迭代而更新。

拆分計(jì)劃

對(duì)待辦列表中的功能進(jìn)行細(xì)化，產(chǎn)生各個(gè)子功能，并列明各子功能的具體需求。在拆分計(jì)劃階段，開發(fā)與測(cè)試都需要熟悉各個(gè)功能的要求。

迭代開發(fā)測(cè)試

圖二：迭代開發(fā)測(cè)試流程

在這個(gè)階段，如圖二所示，開發(fā)人員對(duì)相應(yīng)功能進(jìn)行需求分析，制定開發(fā)迭代計(jì)劃，并進(jìn)行功能開發(fā)與自測(cè)。測(cè)試人員也要進(jìn)行需求分析，并列明測(cè)試計(jì)劃，同時(shí)進(jìn)行測(cè)試用例與腳本的編寫。開發(fā)人員完成功能開發(fā)以及自測(cè)后，會(huì)產(chǎn)生相應(yīng)的可測(cè)版本。測(cè)試人員根據(jù)需求執(zhí)行測(cè)試用例，產(chǎn)生的缺陷由開發(fā)進(jìn)行修復(fù)，繼而進(jìn)行持續(xù)開發(fā)。

圖三：開發(fā)與測(cè)試階段流程

如圖三所示，在開發(fā)與測(cè)試階段，開發(fā)人員進(jìn)行模塊開發(fā)與單元測(cè)試，在TDD(后續(xù)章節(jié)會(huì)有簡(jiǎn)單介紹)的驅(qū)動(dòng)下，對(duì)模塊進(jìn)行重構(gòu)。在模塊開發(fā)完成并集成后，由測(cè)試人員進(jìn)行冒煙、驗(yàn)收測(cè)試，其中產(chǎn)生的bug，會(huì)繼續(xù)由開發(fā)人員進(jìn)行修復(fù)。

功能發(fā)布

在測(cè)試人員完成測(cè)試之后，進(jìn)行測(cè)試小結(jié)，根據(jù)測(cè)試結(jié)果來評(píng)審是否可以交付某功能。

敏捷測(cè)試的主要方法及實(shí)踐

測(cè)試驅(qū)動(dòng)開發(fā)(TDD)

測(cè)試不僅是測(cè)試人員的責(zé)任，開發(fā)人員也必須通過不斷的單元測(cè)試、模塊功能測(cè)試等白盒測(cè)試來重構(gòu)自己的代碼，以此提高軟件的交付質(zhì)量。

TDD要求開發(fā)人員在寫代碼前，先寫好測(cè)試用例，再編寫代碼，并且代碼能夠通過測(cè)試用例。隨著不斷地迭代和重構(gòu)，測(cè)試用例的數(shù)量和覆蓋點(diǎn)也會(huì)不斷增加，程序所實(shí)現(xiàn)的功能也越來越復(fù)雜。開發(fā)人員需要不斷提高單元測(cè)試的覆蓋率，以此來增強(qiáng)代碼的可用性。

不斷地深入溝通

團(tuán)隊(duì)需要密切的溝通，不過多依賴文檔。測(cè)試人員通過與不同角色進(jìn)行溝通，在短時(shí)間內(nèi)對(duì)項(xiàng)目的整體需求有充分的了解，才能設(shè)計(jì)出最適合的測(cè)試用例。為了保證產(chǎn)品質(zhì)量符合客戶預(yù)期，在產(chǎn)品不斷的迭代中，測(cè)試人員需要不斷地修改測(cè)試用例，以達(dá)到精益求精的程度。

• 測(cè)試人員與開發(fā)人員之間的溝通，可以通過閱讀部分源代碼，了解產(chǎn)品的架構(gòu)，從技術(shù)角度探討問題。
• 測(cè)試人員與用戶的交流，使測(cè)試人員能夠站在客戶的角度去考慮一些問題，必要的時(shí)候，還需要對(duì)競(jìng)商的相同類型產(chǎn)品進(jìn)行比較。
• 測(cè)試人員之間的交流，又是一個(gè)共享經(jīng)驗(yàn)及傳遞問題的過程。通過這種交流，個(gè)人經(jīng)驗(yàn)轉(zhuǎn)變成了整個(gè)團(tuán)隊(duì)的經(jīng)驗(yàn)。

模糊界限

在敏捷模式中，強(qiáng)調(diào)團(tuán)隊(duì)的高度協(xié)作，測(cè)試和開發(fā)的角色界限變得模糊。

開發(fā)人員不僅要確保開發(fā)任務(wù)的完成，還要運(yùn)用單元測(cè)試等工作來保證代碼質(zhì)量。而作為敏捷測(cè)試人員，也需要了解項(xiàng)目中客戶的需求、軟件的設(shè)計(jì)框架、軟件語言等。測(cè)試人員可以通過閱讀或編寫一部分產(chǎn)品代碼來熟悉產(chǎn)品的內(nèi)部邏輯。

在測(cè)試人員設(shè)計(jì)測(cè)試用例的過程中，團(tuán)隊(duì)的所有成員都有責(zé)任來共同設(shè)計(jì)符合客戶環(huán)境以及使用情景的測(cè)試方案。在敏捷模式中，團(tuán)隊(duì)可以通過組織測(cè)試用例評(píng)審會(huì)來確保全員的參與。

自動(dòng)化運(yùn)用

在敏捷開發(fā)的過程中，項(xiàng)目不斷地以短周期的形式迭代發(fā)布。那么，測(cè)試人員不僅要保證每次迭代中新功能點(diǎn)的完整實(shí)現(xiàn)，還要保證之前迭代版本的功能不受影響。這樣就會(huì)造成測(cè)試工作量在不斷的增加，而且存在嚴(yán)重的重復(fù)性。

在敏捷項(xiàng)目中，自動(dòng)化測(cè)試的良好實(shí)施會(huì)使測(cè)試人員乃至整個(gè)項(xiàng)目提高效率。一般在項(xiàng)目前期迭代中，測(cè)試人員會(huì)篩選最基本且使用率較高的測(cè)試用例來實(shí)現(xiàn)自動(dòng)化，并且在迭代過程中不斷地完善與優(yōu)化自動(dòng)化腳本，增加功能測(cè)試的覆蓋面。這樣，在項(xiàng)目后期回歸測(cè)試時(shí)，只需要將累積的自動(dòng)化腳本執(zhí)行一遍就可以基本覆蓋大部分功能，從而縮短測(cè)試人員在回歸測(cè)試中驗(yàn)證基本功能所消耗的時(shí)間。測(cè)試人員也可以將更多的時(shí)間投入到一些探索性測(cè)試中，以保證 更好的產(chǎn)品質(zhì)量。

持續(xù)集成

在開發(fā)過程中，開發(fā)人員經(jīng)常會(huì)合入新的代碼。那么，如何檢驗(yàn)新開發(fā)代碼的質(zhì)量?并保證新代碼合入庫之后不會(huì)影響老代碼的功能呢?這就需要通過自動(dòng)化的持續(xù)構(gòu)建(包括編譯，自動(dòng)化測(cè)試)來保證。持續(xù)集成的主要目標(biāo)是更快發(fā)現(xiàn)并解決缺陷，提高軟件質(zhì)量，并減少驗(yàn)證和發(fā)布軟件更新所需的時(shí)間。

如圖四所示，持續(xù)集成的過程大致有如下幾個(gè)方面：

1.  設(shè)定一定的觸發(fā)條件，如定時(shí)、固定周期、手動(dòng)啟動(dòng)等;
2. 啟動(dòng)后，持續(xù)集成框架從版本管理工具中檢查并下載最新代碼，若沒有則結(jié)束集成過程;
3. 代碼編譯成功后啟動(dòng)自動(dòng)化測(cè)試環(huán)境開始自動(dòng)化測(cè)試;
4. 自動(dòng)生成測(cè)試報(bào)告，并通過郵件等形式發(fā)送給相應(yīng)責(zé)任人。

圖四：持續(xù)集成的過程

敏捷測(cè)試該如何開展

在某些項(xiàng)目上，一些團(tuán)隊(duì)已經(jīng)基本能按照敏捷的方式來進(jìn)行開發(fā)管理，但還是會(huì)有一些成員在心理上有一些抵觸，不習(xí)慣這樣的模式。就敏捷測(cè)試而言，在思想上，推動(dòng)全員質(zhì)量意識(shí)，項(xiàng)目團(tuán)隊(duì)的所有成員都應(yīng)該為產(chǎn)品質(zhì)量負(fù)責(zé)，保證產(chǎn)品質(zhì)量不再只是測(cè)試人員的職責(zé)。開發(fā)人員需要通過單元測(cè)試的覆蓋率來保證代碼的正確性。

要保證軟件的內(nèi)建質(zhì)量，在設(shè)計(jì)階段就要對(duì)需求、設(shè)計(jì)邏輯等進(jìn)行全面的分析，提高可測(cè)試性。在敏捷測(cè)試中，測(cè)試人員需要貫穿于軟件的整個(gè)生命周期，并要盡早參與測(cè)試。在充分了解了計(jì)劃中待實(shí)現(xiàn)功能的前提下，制定測(cè)試計(jì)劃，采用迭代的方式完成測(cè)試任務(wù)。建立持續(xù)集成，結(jié)合自動(dòng)化測(cè)試，在每次迭代中快速反饋測(cè)試結(jié)果。并不斷地維護(hù)自動(dòng)化測(cè)試框架，用于后期的回歸測(cè)試和驗(yàn)收測(cè)試。