敏捷軟件測試方法(什么是敏捷軟件測試)

1.什么是敏捷軟件測試

【編者按】敏捷的理念已經(jīng)深入人心，開發(fā)過程已經(jīng)漸入佳境，測試的處境卻稍顯尷尬。

測試從業(yè)者應(yīng)該何去何從，怎樣才能擁抱敏捷，體現(xiàn)出自己新的價值呢？InfoQ特地邀請了來自Google的敏捷測試專家段念，為讀者答疑解惑，希望所有測試從業(yè)者可以從中得到自己的答案。更多關(guān)于敏捷測試的內(nèi)容，請訪問InfoQ中文站敏捷測試相關(guān)內(nèi)容。

在與不少測試從業(yè)人員討論到敏捷的時候，被問得最多的大約是兩個問題：到底？，敏捷軟件開發(fā)還需要測試工程師嗎？。前一個問題是對于敏捷測試本身定義的疑問，第二個問題則是對敏捷開發(fā)將測試工程師排除在外的擔(dān)心。

其實，在探尋這兩個問題答案的過程中，我們可以更清晰的了解敏捷軟件開發(fā)中測試的工作定義，測試價值觀，以及敏捷開發(fā)中開發(fā)與測試工程師的配合。鑒于這兩個問題的意義，在本敏捷測試專欄的第一篇文章中，本人嘗試從自己的實踐出發(fā)，盡可能清楚的回答這兩個問題。

確實，相對于敏捷開發(fā)紅遍大江南北的狀況而言，對敏捷測試的討論則低調(diào)得多。敏捷聯(lián)盟定義了敏捷的4個價值聲明，以及伴隨的12條支持原則，這12條原則中沒有一條單獨提到測試。

這是不是意味著測試在敏捷開發(fā)中并不重要呢？實際上，如果仔細(xì)研讀敏捷的12個原則，以及各種不同的敏捷實踐，就會發(fā)現(xiàn)，測試在敏捷開發(fā)中占有非常重要的地位。無論是原則中的頻繁交付，還是對可工作的軟件的度量，或是敏捷開發(fā)實踐中的測試驅(qū)動開發(fā)，行為驅(qū)動開發(fā)，都離不開測試的支持。

在本人看來，敏捷開發(fā)中不把測試單獨拿出來描述的原因，恰恰是因為在敏捷開發(fā)中，測試不再是一個單獨的、和開發(fā)獨立的過程，而是變成了驅(qū)動開發(fā)、衡量產(chǎn)出的主要的手段，成為了敏捷開發(fā)中所有工程師在工作時必須時刻考慮和實踐的一個部分。簡而言之，敏捷軟件測試更多的是一種理念，而非過程。

既然是這樣，為什么我們還要在這個專欄中專門來討論敏捷軟件測試？本人接觸過不少軟件開發(fā)和測試工程師，他們所處的組織有的正在努力向敏捷開發(fā)轉(zhuǎn)型，有的已經(jīng)實踐了一段實踐的敏捷開發(fā)，但由于由來已久的工作習(xí)慣，他們中的絕大多數(shù)并不能自覺的認(rèn)識到測試在敏捷開發(fā)中的關(guān)鍵作用，而是有意無意的將測試仍然看作是與開發(fā)截然分開的下一個階段，導(dǎo)致在實踐敏捷開發(fā)的過程中遇到種種問題：要么是忽略了代碼質(zhì)量，導(dǎo)致在頻繁的迭代過程中，每一個迭代的問題層出不窮；或是沿用原有的方法安排對系統(tǒng)的系統(tǒng)測試，導(dǎo)致測試團(tuán)隊疲于奔命，卻總也趕不上開發(fā)所要求的進(jìn)度。在這種情況下，專門來討論敏捷軟件開發(fā)中的測試，也就是敏捷軟件測試的話題，對這些工程師應(yīng)該會有一些幫助。

那么，到底？很難給敏捷測試下一個精確、完善的定義，在本人看來，接納了敏捷的核心價值觀（溝通，簡單，反饋，勇氣，尊重），在敏捷軟件開發(fā)過程中開展的測試就可以被稱作是敏捷軟件測試。因此，敏捷軟件測試并不是一個與敏捷軟件開發(fā)同一層次的劃分，而是敏捷軟件開發(fā)中的一部分，與傳統(tǒng)的測試不同，敏捷軟件測試并不是一個獨立的過程，相反，它與整個敏捷開發(fā)中的其他活動交織在一起，處處都能看到它的影子。

由于敏捷軟件測試并不傾向于一個單獨的過程定義，本人擬從敏捷軟件測試與傳統(tǒng)測試觀點的比較、敏捷軟件測試中采用的方法、測試工程師在敏捷軟件測試過程中的工作等方面來闡述之。在這篇文章中，我們主要從宏觀的角度來描述敏捷軟件測試，而在本專欄的后續(xù)文章中，我們將對敏捷軟件測試中采用的方法、工程師在敏捷軟件測試中的工作內(nèi)容等進(jìn)行進(jìn)一步的描述。

使用Dashboard、燃盡圖等方式展示當(dāng)前工作與可交付產(chǎn)品之間的距離建立單元測試覆蓋率等度量指標(biāo)共享質(zhì)量目標(biāo)意味著質(zhì)量責(zé)任由所有工程師共同承擔(dān)開發(fā)測試應(yīng)該建立一定的測試覆蓋率標(biāo)準(zhǔn)，例如，在單元測試這個級別上，建立60%或80%的覆蓋率要求通過使用TDD、BDD等技術(shù)，保證產(chǎn)品和代碼的可測試性建立足夠多的自動化測試，保證測試能夠滿足快速迭代的要求檢查表提到了團(tuán)隊、反饋、質(zhì)量文化和開發(fā)測試四個方面的內(nèi)容，在本人看來，這四個方面體現(xiàn)的就是敏捷軟件測試與傳統(tǒng)軟件測試的最大的不同。傳統(tǒng)軟件測試關(guān)注的是通過盡可能完備的覆蓋去發(fā)現(xiàn)盡可能多的問題，把測試和開發(fā)當(dāng)成是兩個獨立的過程，測試是對開發(fā)階段產(chǎn)生成果的驗證。

而敏捷軟件測試則建立了一種不同的質(zhì)量文化：測試的目的是為了保證產(chǎn)品快速發(fā)布，也就是對生產(chǎn)率本身的提高?；隍炞C的出發(fā)點必然會要求測試與開發(fā)的獨立，以及盡可能客觀和完備的度量產(chǎn)品質(zhì)量；而基于生產(chǎn)率的出發(fā)點則要求建立敏捷的團(tuán)隊，要求測試與開發(fā)盡可能緊密，要求建立具有高度可測試性的軟件，以及基于這些的高度自動化測試。

在檢查表列出的所有項目中，質(zhì)量文化是基礎(chǔ)，團(tuán)隊是敏捷軟件測試得以實施的條件，反饋和開發(fā)測試則是敏捷軟件測試的具體方法。當(dāng)然，你可以可以從敏捷的核心價值觀來階段這些項目：團(tuán)隊關(guān)注的是溝通與尊重；反饋直接對應(yīng)于反饋；質(zhì)量文化基于勇氣（承擔(dān)質(zhì)量責(zé)任的勇氣）與尊重；而開發(fā)測試則是反饋與簡單的具體體現(xiàn)。

另一個在本文最。

2.如何用敏捷方法做測試

敏捷測試應(yīng)該是適應(yīng)敏捷方法而采用的新的測試流程、方法和實踐，對傳統(tǒng)的測試流程有所剪裁，有所不同的側(cè)重，例如減少測試計劃、測試用例設(shè)計等工作的比重，增加與產(chǎn)品設(shè)計人員、開發(fā)人員的交流和協(xié)作。在敏捷測試流程中，參與單元測試，關(guān)注持續(xù)迭代的新功能，針對這些新功能進(jìn)行足夠的驗收測試，而對原有功能的回歸測試則依賴于自動化測試。由于敏捷方法中迭代周期短，測試人員盡早開始測試，包括及時對需求、開發(fā)設(shè)計的評審，更重要的是能夠及時、持續(xù)的對產(chǎn)品質(zhì)量進(jìn)行反饋。

在敏捷方法中，需求變化比較快、產(chǎn)品開發(fā)周期很短，我們目前采用四周時間，也就是每個月發(fā)布一個新版本。開發(fā)周期短，功能不斷累加，給測試帶來很大的挑戰(zhàn)，測試流程要做相應(yīng)的調(diào)整。

在對新功能進(jìn)行app功能測試和回歸測試策略上，測試任務(wù)簡單地可分為新功能測試和回歸測試。在敏捷方法中，針對這兩部分的測試建立相應(yīng)的策略，加上自動化測試，以提高測試的效率，最大限度地降低質(zhì)量風(fēng)險。

TestBird - 手游和App自動化測試

3.敏捷項目測試應(yīng)該怎么做

1、敏捷測試人員的定義

我們這樣定義敏捷測試人員：專業(yè)的測試人員，適應(yīng)變化，與技術(shù)人員和業(yè)務(wù)人員展開良好協(xié)作，并理解利用測試記錄需求和驅(qū)動開發(fā)的思想。敏捷測試人員往往具有優(yōu)秀的技術(shù)能力，知道如何與他人合作以實現(xiàn)自動化測試，同時也擅長探索性測試。他們希望了解客戶在做什么，以此更好地理解客戶的軟件需求。

誰是敏捷測試人員？她是驅(qū)動敏捷測試的團(tuán)隊成員。我們知道許多敏捷測試人員剛開始的時候在從事其他工作。開發(fā)人員可能會愛上測試而超越單元測試的范疇。習(xí)慣以敏捷方式工作的探索型測試人員也會被敏捷團(tuán)隊吸引。其他角色的專業(yè)人士，比如業(yè)務(wù)或者功能分析師，也可能具有同樣的特質(zhì)并做同樣的工作。

技能很重要，但態(tài)度更值得關(guān)注。Janet總是說：“如果態(tài)度不好，那么技能則一無是處”。既然我們要為敏捷團(tuán)隊招募大量的測試人員，那么必須慎重考慮這一點，并與敏捷社區(qū)的其他朋友進(jìn)行相關(guān)討論。測試人員往往可以總覽全局。他們更多時候是以客戶的角度看待應(yīng)用程序，這意味著他們一般以客戶為中心。

2、敏捷測試思想

如何使一個團(tuán)隊變得“敏捷”？對我們而言，敏捷團(tuán)隊持續(xù)關(guān)注如何最出色地工作并發(fā)布最優(yōu)秀的產(chǎn)品。根據(jù)我們的經(jīng)驗，這需要大量的訓(xùn)練、學(xué)習(xí)、時間、實驗和協(xié)同工作。這并不適合所有人，但是對那些希望自己團(tuán)隊充滿活力并關(guān)注持續(xù)改進(jìn)的人來說非常適合。

成功的項目總是因為優(yōu)秀的人才完成了出色的工作。在敏捷團(tuán)隊中做一名成功的測試人員所需要的特質(zhì)可能與在任何團(tuán)隊做一名高水平的測試人員所需要的相同。

敏捷測試人員不會把自己看作是質(zhì)量管理辦公室的主管以保護(hù)客戶避免受到缺陷代碼的傷害。她會樂于收集和分享信息，與客戶或者產(chǎn)品負(fù)責(zé)人協(xié)作以幫助他們充分展示自己的需求，從而得到他們需要的功能，同時向所有人提供項目進(jìn)展的反饋。

4.如何用敏捷方法做測試

敏捷測試應(yīng)該是適應(yīng)敏捷方法而采用的新的測試流程、方法和實踐，對傳統(tǒng)的測試流程有所剪裁，有所不同的側(cè)重，例如減少測試計劃、測試用例設(shè)計等工作的比重，增加與產(chǎn)品設(shè)計人員、開發(fā)人員的交流和協(xié)作。

在敏捷測試流程中，參與單元測試，關(guān)注持續(xù)迭代的新功能，針對這些新功能進(jìn)行足夠的驗收測試，而對原有功能的回歸測試則依賴于自動化測試。由于敏捷方法中迭代周期短，測試人員盡早開始測試，包括及時對需求、開發(fā)設(shè)計的評審，更重要的是能夠及時、持續(xù)的對產(chǎn)品質(zhì)量進(jìn)行反饋。

在敏捷方法中，需求變化比較快、產(chǎn)品開發(fā)周期很短，我們目前采用四周時間，也就是每個月發(fā)布一個新版本。開發(fā)周期短，功能不斷累加，給測試帶來很大的挑戰(zhàn)，測試流程要做相應(yīng)的調(diào)整。

在對新功能進(jìn)行app功能測試和回歸測試策略上，測試任務(wù)簡單地可分為新功能測試和回歸測試。在敏捷方法中，針對這兩部分的測試建立相應(yīng)的策略，加上自動化測試，以提高測試的效率，最大限度地降低質(zhì)量風(fēng)險。

TestBird - 手游和App自動化測試。

5.敏捷開發(fā)方式有哪些

敏捷開發(fā)包括一系列的方法，主流的有如下七種：

XP

XP（極限編程）的思想源自 Kent Beck和Ward Cunningham在軟件項目中的合作經(jīng)歷。XP注重的核心是溝通、簡明、反饋和勇氣。因為知道計劃永遠(yuǎn)趕不上變化，XP無需開發(fā)人員在軟件開始初期做 出很多的文檔。XP提倡測試先行，為了將以后出現(xiàn)bug的幾率降到最低。

SCRUM

SCRUM是一種迭代的增量化過程，用于產(chǎn)品開發(fā)或工作管理。它是一種可以集合各種開發(fā)實踐的經(jīng)驗化過程框架。SCRUM中發(fā)布產(chǎn)品的重要性高于一切。

該方法由Ken Schwaber和 Jeff Sutherland 提出，旨在尋求充分發(fā)揮面向?qū)ο蠛蜆?gòu)件技術(shù)的開發(fā)方法，是對迭代式面向?qū)ο蠓椒ǖ母倪M(jìn)。

Crystal Methods

Crystal Methods（水晶方法族）由Alistair Cockburn在20實際90年代末提出。之所以是個系列，是因為他相信不同類型的項目需要不同的方法。雖然水晶系列不如XP那樣的產(chǎn)出效率，但會有更多的人能夠接受并遵循它。

FDD

FDD (Feature-Driven Development，特性驅(qū)動開發(fā))由Peter Coad、Jeff de Luca 、Eric Lefebvre共同開發(fā)，是一套針對中小型軟件開發(fā)項目的開發(fā)模式。此外，F(xiàn)DD是一個模型驅(qū)動的快速迭代開發(fā)過程，它強(qiáng)調(diào)的是簡化、實用、易于被開發(fā)團(tuán)隊接受，適用于需求經(jīng)常變動的項目。

ASD

ASD(Adaptive Software Development，自適應(yīng)軟件開發(fā))由Jim Highsmith在1999年正式提出。ASD強(qiáng)調(diào)開發(fā)方法的適應(yīng)性（Adaptive），這一思想來源于復(fù)雜系統(tǒng)的混沌理論。ASD不象其他方法那樣 有很多具體的實踐做法，它更側(cè)重為ASD的重要性提供最根本的基礎(chǔ)，并從更高的組織和管理層次來闡述開發(fā)方法為什么要具備適應(yīng)性。

DSDM

DSDM（動態(tài)系統(tǒng)開發(fā)方法）是眾多敏捷開發(fā)方法中的一種，它倡導(dǎo)以業(yè)務(wù)為核心，快速而有效地進(jìn)行系統(tǒng)開發(fā)。實踐證明DSDM是成功的敏捷開發(fā)方法之一。在英國，由于其在各種規(guī)模的軟件組織中的成功，它已成為應(yīng)用最為廣泛的快速應(yīng)用開發(fā)方法。

DSDM不但遵循了敏捷方法的原理，而且也適合那些成熟的傳統(tǒng)開發(fā)方法有堅實基礎(chǔ)的軟件組織。

輕量型RUP

RUP其實是個過程的框架，它可以包容許多不同類型的過程， Craig Larman 極力主張以敏捷型方式來使用RUP。他的觀點是：目前如此眾多的努力以推進(jìn)敏捷型方法，只不過是在接受能被視為RUP 的主流OO開發(fā)方法而已。

6.常用的軟件測試方法有哪些

軟件測試的方法根據(jù)軟件工程的組織和實現(xiàn)方式，有很大差別，有些是比較技術(shù)化的方法，有些則是工程方法，主要分為： 黑盒測試方法群：等價類劃分、邊界值、因果圖、基路徑法、專家測試法、smoking、場景測試等 白盒測試方法群：同行評審、需求審查、代碼審查、接口測試（調(diào)用測試和返回測試，需要結(jié)合等價類和因果圖方法）等。

當(dāng)在單元層面黑盒而在集成層面白盒時，基本上兩類方法就會有結(jié)合了，就會出現(xiàn)習(xí)慣上說的灰盒測試（說實話，不做到純產(chǎn)品級開發(fā)，基本上都是用的灰盒測試）。

7.最新軟件測試技術(shù)有哪些啊

可能在軟件測試技術(shù)的概念上，你不太熟悉，敏捷測試和自動化測試，不是測試技術(shù)，是一種測試類型。比如你參與的項目是敏捷開發(fā)，那么你做的測試就成為敏捷測試，而自動化測試，是相對于手工測試而言的。

軟件測試的技術(shù)，有很多，畢竟軟件測試人員要做的工作涉及范圍很廣，相對應(yīng)的，要懂的技術(shù)也很懂，根據(jù)用途，我做了以下分類，希望對你有所幫助吧：

1、進(jìn)行數(shù)據(jù)庫測試，那么就要掌握數(shù)據(jù)庫的操作語句和數(shù)據(jù)庫相關(guān)知識，如sql、觸發(fā)器、內(nèi)/外連接、單表/多表操作；

2、進(jìn)行客戶端測試，就要考慮各種測試方法；

3、進(jìn)行產(chǎn)品的網(wǎng)絡(luò)性能測試，就要具備一定的網(wǎng)絡(luò)知識。

相對于手工測試而言，自動化測試要掌握的東西就更多了，除了以上幾點外，還要掌握：

1、性能測試工具/功能測試工具，如loadrunner和QTP;

2、掌握自動化腳本語言，因為腳本語言有很多種，要看你做的是什么測試，用的是什么工具，不過各個語言都是想通的，如果你掌握了java，基本上那些東西都是能夠用起來的。

8.軟件測試方法的分類有哪些

1）按照測試技術(shù)劃分

黑盒測試：功能測試，必須

白盒測試：邏輯結(jié)構(gòu)測試，代碼的邏輯、算法、結(jié)構(gòu)是否正確，要求必須懂得代碼，需要編寫測試用例，可選

灰盒測試：介于中間

注意：在單元測試時，白盒應(yīng)用相對較多，在集成測試時，灰盒測試應(yīng)用相對較多，在系統(tǒng)、驗收測試時一般就不會使用白盒測試和灰盒測試了。

2）按是否需要運(yùn)行代碼劃分

靜態(tài)測試：界面測試，文檔測試，代碼測試【重點關(guān)注代碼的規(guī)范性，一般檢查變量的命名，注釋的頻率，編程的規(guī)范性，不需要寫測試用例，一般只需要有代碼審查單】

注意：一般經(jīng)常把白盒測試和靜態(tài)測試的要素結(jié)合在一起，形成靜態(tài)白盒測試

動態(tài)測試：運(yùn)行程序進(jìn)行檢查，檢查實際輸出結(jié)果和預(yù)期結(jié)果是否相符

3）按軟件特性分類

功能測試

性能測試

9.敏捷開發(fā)方式有哪些

敏捷開發(fā)包括一系列的方法，主流的有如下七種：XPXP（極限編程）的思想源自 Kent Beck和Ward Cunningham在軟件項目中的合作經(jīng)歷。

XP注重的核心是溝通、簡明、反饋和勇氣。因為知道計劃永遠(yuǎn)趕不上變化，XP無需開發(fā)人員在軟件開始初期做 出很多的文檔。

XP提倡測試先行，為了將以后出現(xiàn)bug的幾率降到最低。SCRUMSCRUM是一種迭代的增量化過程，用于產(chǎn)品開發(fā)或工作管理。

它是一種可以集合各種開發(fā)實踐的經(jīng)驗化過程框架。SCRUM中發(fā)布產(chǎn)品的重要性高于一切。

該方法由Ken Schwaber和 Jeff Sutherland 提出，旨在尋求充分發(fā)揮面向?qū)ο蠛蜆?gòu)件技術(shù)的開發(fā)方法，是對迭代式面向?qū)ο蠓椒ǖ母倪M(jìn)。Crystal MethodsCrystal Methods（水晶方法族）由Alistair Cockburn在20實際90年代末提出。

之所以是個系列，是因為他相信不同類型的項目需要不同的方法。雖然水晶系列不如XP那樣的產(chǎn)出效率，但會有更多的人能夠接受并遵循它。

FDDFDD (Feature-Driven Development，特性驅(qū)動開發(fā))由Peter Coad、Jeff de Luca 、Eric Lefebvre共同開發(fā)，是一套針對中小型軟件開發(fā)項目的開發(fā)模式。此外，F(xiàn)DD是一個模型驅(qū)動的快速迭代開發(fā)過程，它強(qiáng)調(diào)的是簡化、實用、易于被開發(fā)團(tuán)隊接受，適用于需求經(jīng)常變動的項目。

ASDASD(Adaptive Software Development，自適應(yīng)軟件開發(fā))由Jim Highsmith在1999年正式提出。ASD強(qiáng)調(diào)開發(fā)方法的適應(yīng)性（Adaptive），這一思想來源于復(fù)雜系統(tǒng)的混沌理論。

ASD不象其他方法那樣 有很多具體的實踐做法，它更側(cè)重為ASD的重要性提供最根本的基礎(chǔ)，并從更高的組織和管理層次來闡述開發(fā)方法為什么要具備適應(yīng)性。DSDMDSDM（動態(tài)系統(tǒng)開發(fā)方法）是眾多敏捷開發(fā)方法中的一種，它倡導(dǎo)以業(yè)務(wù)為核心，快速而有效地進(jìn)行系統(tǒng)開發(fā)。

實踐證明DSDM是成功的敏捷開發(fā)方法之一。在英國，由于其在各種規(guī)模的軟件組織中的成功，它已成為應(yīng)用最為廣泛的快速應(yīng)用開發(fā)方法。

DSDM不但遵循了敏捷方法的原理，而且也適合那些成熟的傳統(tǒng)開發(fā)方法有堅實基礎(chǔ)的軟件組織。輕量型RUPRUP其實是個過程的框架，它可以包容許多不同類型的過程， Craig Larman 極力主張以敏捷型方式來使用RUP。

他的觀點是：目前如此眾多的努力以推進(jìn)敏捷型方法，只不過是在接受能被視為RUP 的主流OO開發(fā)方法而已。