測試敏捷化 vs 敏捷測試

測試敏捷化 vs 敏捷測試

本文首發(fā)于網(wǎng)站【 林子的空間 】

大家可能關(guān)注到雙態(tài)IT聯(lián)盟前一陣發(fā)布了一個 測試敏捷化成熟度評估模型，不斷有小伙伴問到我關(guān)于這個成熟度評估的問題，我發(fā)現(xiàn)大家很自然地把這個跟敏捷測試成熟度畫上了等號，不過這不是Thoughtworks開發(fā)的，我也不是很清楚。為此，我特地進(jìn)行了一番調(diào)研，希望我這篇文章的解讀能解答大伙大部分的疑問。

我們先嘗試從字面意思來理解一下，對于以下兩個術(shù)語大家都比較熟悉：

這兩個例子，相信大家都能理解沒有問題。關(guān)于測試敏捷化，類似地，從字面意思可以這樣理解：

那么，“敏捷的測試”是否等同于“敏捷測試”呢？從字面意思來看，似乎是等同的。但事實(shí)如何，需要對兩者有深入的理解才可以下定論。

為了更好地解釋，有必要先介紹什么是敏態(tài)與穩(wěn)態(tài)。

在數(shù)字化轉(zhuǎn)型時代，企業(yè)一方面需要適應(yīng)數(shù)字化時代快速變化的市場需求，另一方面需要保持關(guān)鍵業(yè)務(wù)的安全可靠和穩(wěn)定性，傳統(tǒng)的IT需要同時適應(yīng)這兩種業(yè)務(wù)形態(tài)，面臨很大的挑戰(zhàn)。為了應(yīng)對這種挑戰(zhàn)，Gartner公司提出 雙模IT（Bimodal IT） 的理念：

傳統(tǒng)企業(yè)數(shù)字化轉(zhuǎn)型的常規(guī)做法是可預(yù)見性的業(yè)務(wù)使用傳統(tǒng)瀑布式開發(fā)，稱之為 穩(wěn)態(tài) ；探索性的業(yè)務(wù)使用敏捷開發(fā)，稱之為 敏態(tài)。Thoughtworks洞見安輝的文章 《敏捷轉(zhuǎn)型中的敏態(tài)與穩(wěn)態(tài)》 對此有比較詳細(xì)的介紹。

當(dāng)然，穩(wěn)態(tài)和敏態(tài)的這種做法在業(yè)界也存在爭議。Thoughtworks數(shù)字化專家肖然在文章 《數(shù)字化時代的科技雙模，雙模IT成為過去式》 中指出：

盡管如此，傳統(tǒng)企業(yè)轉(zhuǎn)型過程中，基本都會長期經(jīng)歷敏態(tài)和穩(wěn)態(tài)共存的階段，對轉(zhuǎn)型有著積極的意義。從長遠(yuǎn)來看，最終還是需要轉(zhuǎn)型到組織級的敏捷，實(shí)現(xiàn)真正的全流程端到端敏捷的。

關(guān)于敏捷測試，引用Wikipedia的兩段話：

從Wikipedia的定義可以看到：

同時，Thoughtworks的資深QA們基于多年敏捷團(tuán)隊(duì)開發(fā)實(shí)踐經(jīng)驗(yàn)提煉出的 敏捷測試宣言，非常清晰的表述了敏捷測試的價(jià)值觀：

敏捷測試是 基于敏捷價(jià)值觀“快速高效地交付更大的價(jià)值”這個目標(biāo)，所開展的所有質(zhì)量相關(guān)活動，是從團(tuán)隊(duì)的角度去思考如何實(shí)現(xiàn)這個目標(biāo)，而不再是以測試這個活動/角色的角度出發(fā)，不能簡單地理解為“敏捷的測試”或“敏捷地測試”。

關(guān)于敏捷測試的更多詳細(xì)內(nèi)容，歡迎參考劉冉老師的 《Thoughtworks的敏捷測試》 文章和我的 《敏捷測試》系列 文章。

測試敏捷化這個概念來自于雙態(tài)IT聯(lián)盟發(fā)布的 《測試敏捷化白皮書》 （以下簡稱“白皮書”），這里直接引用該白皮書中的內(nèi)容來解釋測試敏捷化。

從前面引用的內(nèi)容來看，測試敏捷化是將測試作為 獨(dú)立主體，從測試的角度出發(fā)來考慮優(yōu)化和改進(jìn)。

基于白皮書的內(nèi)容，雙態(tài)IT聯(lián)盟還發(fā)布了相應(yīng)的成熟度評估模型，這個成熟度評估也是 基于測試的幾個維度 進(jìn)行的：

到此，我們可以比較清晰地看到測試敏捷化是圍繞測試在解決問題，考慮的更多是測試價(jià)值的體現(xiàn)。

了解了概念，再來從背景、目標(biāo)、主體、關(guān)注點(diǎn)和適用范圍這幾個維度集中對比一下測試敏捷化與敏捷測試：

從上表我們不難看出測試敏捷化與敏捷測試具備較大差異：

敏捷測試是產(chǎn)生于敏捷軟件開發(fā)模式，在這種新型開發(fā)模式下需要考慮如何滿足質(zhì)量保障的需求，自然而然產(chǎn)生了敏捷測試。敏捷測試是遵循敏捷價(jià)值觀的，其目標(biāo)也是跟敏捷開發(fā)一致，那就是快速高效地交付更大的價(jià)值。

測試敏捷化則是在數(shù)字化轉(zhuǎn)型過程中敏穩(wěn)兩態(tài)共存的情形下，傳統(tǒng)IT穩(wěn)態(tài)模式的測試團(tuán)隊(duì)面臨轉(zhuǎn)型挑戰(zhàn)，旨在幫助測試團(tuán)隊(duì)實(shí)現(xiàn)轉(zhuǎn)型。因此，測試敏捷化的目標(biāo)主要是為了體現(xiàn)測試的價(jià)值，提升測試團(tuán)隊(duì)的敏捷能力。

為了實(shí)現(xiàn)目標(biāo)，敏捷測試以全功能的敏捷開發(fā)團(tuán)隊(duì)為主體，關(guān)注軟件開發(fā)全生命周期的質(zhì)量相關(guān)活動。敏捷測試不再是以測試這個檢驗(yàn)環(huán)節(jié)/活動為主，不會強(qiáng)調(diào)某個獨(dú)立角色，而是要求團(tuán)隊(duì)整體為質(zhì)量負(fù)責(zé)，實(shí)現(xiàn)測試左移、持續(xù)測試和測試右移，快速獲取反饋，從而真正實(shí)現(xiàn)軟件產(chǎn)品的質(zhì)量內(nèi)建。

而測試敏捷化是以測試作為獨(dú)立主體，以測試的角度出發(fā)考慮優(yōu)化改進(jìn)，主要關(guān)注點(diǎn)包括測試需求、測試計(jì)劃、測試設(shè)計(jì)、測試執(zhí)行等測試過程，以及環(huán)境、數(shù)據(jù)、技術(shù)、工具等測試的支撐。

如上面數(shù)字化轉(zhuǎn)型示意圖所示：

敏捷測試產(chǎn)生于敏捷開發(fā)模式，必然適用于純敏態(tài)的開發(fā)團(tuán)隊(duì)。同時，敏捷測試的一些方法和實(shí)踐，也可以被穩(wěn)態(tài)團(tuán)隊(duì)所借鑒并適當(dāng)采用。

測試敏捷化由于背景、目標(biāo)、主體和關(guān)注點(diǎn)都不同于敏捷測試，是不宜用于敏態(tài)開發(fā)環(huán)境的，只適用于穩(wěn)態(tài)環(huán)境。

數(shù)字化轉(zhuǎn)型的確給傳統(tǒng)測試團(tuán)隊(duì)帶來很大的挑戰(zhàn)，一方面要配合敏態(tài)團(tuán)隊(duì)實(shí)現(xiàn)測試開發(fā)融合，另一方面還要面臨穩(wěn)態(tài)測試如何優(yōu)化改進(jìn)的問題。

測試敏捷化雖然在一定程度上幫助轉(zhuǎn)型中的穩(wěn)態(tài)測試團(tuán)隊(duì)，但是不能從根本上幫助轉(zhuǎn)型的實(shí)現(xiàn)。另外，前面提到敏穩(wěn)雙態(tài)共存模式不過是轉(zhuǎn)型中的一個過渡階段，是否要為這種過渡時期的穩(wěn)態(tài)模式投入較多精力，請深思而前行。

測試要實(shí)現(xiàn)轉(zhuǎn)型以適應(yīng)敏捷開發(fā)模式，不能只是測試人員的轉(zhuǎn)型、也不能只是測試工作方式的轉(zhuǎn)型，只有改變文化理念和認(rèn)知方式、調(diào)整組織架構(gòu)和溝通方式、優(yōu)化流程和策略、采用有利于快速反饋的工具與實(shí)踐，按照由內(nèi)而外的“道”->“法”->“術(shù)”->“器”方向?qū)崿F(xiàn)徹底的轉(zhuǎn)型，才有可能實(shí)現(xiàn)真正的敏捷測試。這個內(nèi)容我在文章 《數(shù)字化轉(zhuǎn)型背景下的測試轉(zhuǎn)型》 里有非常詳細(xì)的介紹，請移步閱讀。

敏捷測試不是“敏捷的測試”，也不是“敏捷地測試”，而測試敏捷化是“敏捷地測試”，兩者不等同。

由于測試敏捷化的背景、目標(biāo)、主體和關(guān)注點(diǎn)都不同于敏捷測試，是不宜用于敏捷開發(fā)模式的，只適用于傳統(tǒng)企業(yè)的穩(wěn)態(tài)模式，也不能幫助穩(wěn)態(tài)團(tuán)隊(duì)實(shí)現(xiàn)敏捷轉(zhuǎn)型。而敏態(tài)、穩(wěn)態(tài)共存本身就是數(shù)字化轉(zhuǎn)型的過渡階段的產(chǎn)物，因此在穩(wěn)態(tài)測試團(tuán)隊(duì)采用也需要謹(jǐn)慎前行。

傳統(tǒng)測試的真正敏捷轉(zhuǎn)型需要遵循“道”->“法”->“術(shù)”->“器”方向、實(shí)現(xiàn)由內(nèi)而外的轉(zhuǎn)變才能實(shí)現(xiàn)。

敏捷測試與傳統(tǒng)測試的區(qū)別

首先敏捷測試(Agile testing)是測試的一種，敏捷測試的理念是，和編碼一樣，測試是開發(fā)的一個關(guān)鍵部分。在敏捷中，測試被直接集成到軟件開發(fā)過程中，以便盡早、頻繁地發(fā)現(xiàn)bug。因此，測試人員可以在開發(fā)過程的每一個節(jié)點(diǎn)上發(fā)現(xiàn)問題，從而使產(chǎn)品快速走向發(fā)布。

敏捷測試的特點(diǎn)有以下幾點(diǎn)：

傳統(tǒng)測試即基于瀑布模型開發(fā)的測試，瀑布模型將軟件生命周期劃分為 制定計(jì)劃、需求分析、軟件設(shè)計(jì)、程序編寫、軟件測試 和 運(yùn)行維護(hù) 六項(xiàng)基本活動，其過程是將上一項(xiàng)活動接收的工作對象作為輸入，當(dāng)該項(xiàng)活動完成后會輸出該項(xiàng)活動的工作成果，并將該項(xiàng)成果作為下一項(xiàng)活動的輸入。該模型規(guī)定這六項(xiàng)基本活動自上而下、固定相互銜接的次序，如同瀑布流水，逐級下落。從本質(zhì)上講，它是一個軟件開發(fā)架構(gòu)，開發(fā)過程是通過一系列階段順序展開的，從需求分析直到產(chǎn)品發(fā)布和維護(hù)。如果在其中某個階段有信息未被覆蓋或有問題，那么就得返回到上一個階段，并對這些階段進(jìn)行適當(dāng)?shù)男薷牟拍苓M(jìn)入下一個階段，這樣每個階段都會產(chǎn)生循環(huán)反饋，開發(fā)過程從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來。

瀑布模型的優(yōu)點(diǎn)如下：

增量迭代應(yīng)用于瀑布模型，迭代1 解決最大的問題，每次迭代產(chǎn)生一個可運(yùn)行的版本，同時增加更多的功能，但每次迭代必須經(jīng)過嚴(yán)格的質(zhì)量和集成測試。

瀑布模型有以下缺點(diǎn)：

搞清楚了什么是敏捷測試，什么是傳統(tǒng)測試，最后我們來對比一下他們之間的區(qū)別，整理如下：

敏捷測試0：開發(fā)和測試打架，怎么辦？

開發(fā)和測試是怎么打架的？

線上出了 Bug 召集會議復(fù)盤，開發(fā)指責(zé)測試沒測出來，沒把好質(zhì)量關(guān)；測試抱怨開發(fā)不做單元測試，要不早發(fā)現(xiàn)了。

結(jié)果往往是大家寫個改進(jìn)報(bào)告，測試保證添加相關(guān)測試用例并補(bǔ)充到回歸測試集，開發(fā)承諾以后做好自測，提交了事。
這就是我工作中經(jīng)常遇到的事情，怎么破？

用敏捷測試的方法來解決。具體怎么解決，我們以后說。

什么是敏捷測試？

究竟什么是“敏捷測試”？敏捷測試是指敏捷開發(fā)模式下的一套完整的軟件測試解決方案。它強(qiáng)調(diào)“與開發(fā)協(xié)作”、“自動化測試”、“客戶思維”和“動態(tài)的測試策略調(diào)整”。

不變的是它的價(jià)值觀、理念以及思維方式；變的是持續(xù)改進(jìn)的敏捷測試方法、技術(shù)和工具。

敏捷測試課程主要內(nèi)容有哪些？

一、什么是敏捷測試

二、如何管理敏捷測試中的人

三、如何搭建敏捷測試框架

四、如何逐步實(shí)施敏捷測試

從今天開始記錄敏捷測試課程學(xué)習(xí)筆記，用輸出倒逼輸入。

現(xiàn)實(shí)世界中出現(xiàn)問題了，我這里有個解決方法，我將從四個方面為你講述這個方法。
如果你也遇到這種問題了，那過來一起學(xué)習(xí)吧！

什么是敏捷軟件測試

【編者按】敏捷的理念已經(jīng)深入人心，開發(fā)過程已經(jīng)漸入佳境，測試的處境卻稍顯尷尬。測試從業(yè)者應(yīng)該何去何從，怎樣才能擁抱敏捷，體現(xiàn)出自己新的價(jià)值呢？InfoQ特地邀請了來自Google的敏捷測試專家段念，為讀者答疑解惑，希望所有測試從業(yè)者可以從中得到自己的答案。更多關(guān)于敏捷測試的內(nèi)容，請?jiān)L問InfoQ中文站敏捷測試相關(guān)內(nèi)容。在與不少測試從業(yè)人員討論到敏捷的時候，被問得最多的大約是兩個問題：到底？，敏捷軟件開發(fā)還需要測試工程師嗎？。前一個問題是對于敏捷測試本身定義的疑問，第二個問題則是對敏捷開發(fā)將測試工程師排除在外的擔(dān)心。其實(shí)，在探尋這兩個問題答案的過程中，我們可以更清晰的了解敏捷軟件開發(fā)中測試的工作定義，測試價(jià)值觀，以及敏捷開發(fā)中開發(fā)與測試工程師的配合。鑒于這兩個問題的意義，在本敏捷測試專欄的第一篇文章中，本人嘗試從自己的實(shí)踐出發(fā)，盡可能清楚的回答這兩個問題。確實(shí)，相對于敏捷開發(fā)紅遍大江南北的狀況而言，對敏捷測試的討論則低調(diào)得多。敏捷聯(lián)盟定義了敏捷的4個價(jià)值聲明，以及伴隨的12條支持原則，這12條原則中沒有一條單獨(dú)提到測試。這是不是意味著測試在敏捷開發(fā)中并不重要呢？實(shí)際上，如果仔細(xì)研讀敏捷的12個原則，以及各種不同的敏捷實(shí)踐，就會發(fā)現(xiàn)，測試在敏捷開發(fā)中占有非常重要的地位。無論是原則中的頻繁交付，還是對可工作的軟件的度量，或是敏捷開發(fā)實(shí)踐中的測試驅(qū)動開發(fā)，行為驅(qū)動開發(fā)，都離不開測試的支持。在本人看來，敏捷開發(fā)中不把測試單獨(dú)拿出來描述的原因，恰恰是因?yàn)樵诿艚蓍_發(fā)中，測試不再是一個單獨(dú)的、和開發(fā)獨(dú)立的過程，而是變成了驅(qū)動開發(fā)、衡量產(chǎn)出的主要的手段，成為了敏捷開發(fā)中所有工程師在工作時必須時刻考慮和實(shí)踐的一個部分。簡而言之，敏捷軟件測試更多的是一種理念，而非過程。既然是這樣，為什么我們還要在這個專欄中專門來討論敏捷軟件測試？本人接觸過不少軟件開發(fā)和測試工程師，他們所處的組織有的正在努力向敏捷開發(fā)轉(zhuǎn)型，有的已經(jīng)實(shí)踐了一段實(shí)踐的敏捷開發(fā)，但由于由來已久的工作習(xí)慣，他們中的絕大多數(shù)并不能自覺的認(rèn)識到測試在敏捷開發(fā)中的關(guān)鍵作用，而是有意無意的將測試仍然看作是與開發(fā)截然分開的下一個階段，導(dǎo)致在實(shí)踐敏捷開發(fā)的過程中遇到種種問題：要么是忽略了代碼質(zhì)量，導(dǎo)致在頻繁的迭代過程中，每一個迭代的問題層出不窮；或是沿用原有的方法安排對系統(tǒng)的系統(tǒng)測試，導(dǎo)致測試團(tuán)隊(duì)疲于奔命，卻總也趕不上開發(fā)所要求的進(jìn)度。在這種情況下，專門來討論敏捷軟件開發(fā)中的測試，也就是敏捷軟件測試的話題，對這些工程師應(yīng)該會有一些幫助。那么，到底？很難給敏捷測試下一個精確、完善的定義，在本人看來，接納了敏捷的核心價(jià)值觀（溝通，簡單，反饋，勇氣，尊重），在敏捷軟件開發(fā)過程中開展的測試就可以被稱作是敏捷軟件測試。因此，敏捷軟件測試并不是一個與敏捷軟件開發(fā)同一層次的劃分，而是敏捷軟件開發(fā)中的一部分，與傳統(tǒng)的測試不同，敏捷軟件測試并不是一個獨(dú)立的過程，相反，它與整個敏捷開發(fā)中的其他活動交織在一起，處處都能看到它的影子。由于敏捷軟件測試并不傾向于一個單獨(dú)的過程定義，本人擬從敏捷軟件測試與傳統(tǒng)測試觀點(diǎn)的比較、敏捷軟件測試中采用的方法、測試工程師在敏捷軟件測試過程中的工作等方面來闡述之。在這篇文章中，我們主要從宏觀的角度來描述敏捷軟件測試，而在本專欄的后續(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)隊(duì)、反饋、質(zhì)量文化和開發(fā)測試四個方面的內(nèi)容，在本人看來，這四個方面體現(xiàn)的就是敏捷軟件測試與傳統(tǒng)軟件測試的最大的不同。傳統(tǒng)軟件測試關(guān)注的是通過盡可能完備的覆蓋去發(fā)現(xiàn)盡可能多的問題，把測試和開發(fā)當(dāng)成是兩個獨(dú)立的過程，測試是對開發(fā)階段產(chǎn)生成果的驗(yàn)證。而敏捷軟件測試則建立了一種不同的質(zhì)量文化：測試的目的是為了保證產(chǎn)品快速發(fā)布，也就是對生產(chǎn)率本身的提高?；隍?yàn)證的出發(fā)點(diǎn)必然會要求測試與開發(fā)的獨(dú)立，以及盡可能客觀和完備的度量產(chǎn)品質(zhì)量；而基于生產(chǎn)率的出發(fā)點(diǎn)則要求建立敏捷的團(tuán)隊(duì)，要求測試與開發(fā)盡可能緊密，要求建立具有高度可測試性的軟件，以及基于這些的高度自動化測試。在檢查表列出的所有項(xiàng)目中，質(zhì)量文化是基礎(chǔ)，團(tuán)隊(duì)是敏捷軟件測試得以實(shí)施的條件，反饋和開發(fā)測試則是敏捷軟件測試的具體方法。當(dāng)然，你可以可以從敏捷的核心價(jià)值觀來階段這些項(xiàng)目：團(tuán)隊(duì)關(guān)注的是溝通與尊重；反饋直接對應(yīng)于反饋；質(zhì)量文化基于勇氣（承擔(dān)質(zhì)量責(zé)任的勇氣）與尊重；而開發(fā)測試則是反饋與簡單的具體體現(xiàn)。另一個在本文最初提出來的問題是：敏捷軟件開發(fā)還需要測試工程師嗎？，對這個問題，業(yè)界有不同的觀點(diǎn)。有人認(rèn)為需要，因?yàn)榭傆幸恍┦切枰獪y試工程師的技能完成的工作；當(dāng)然，也有人認(rèn)為不需要，因?yàn)槊艚蓍_發(fā)中的測試注重開發(fā)測試與自動化測試，開發(fā)工程師就可以自己搞定與測試相關(guān)的工作。在實(shí)踐中，那些大規(guī)模實(shí)踐敏捷開發(fā)的公司（例如Google），傾向于在組織中設(shè)置數(shù)量較少的測試工程師，在項(xiàng)目中分配較少的測試資源，甚至對某些項(xiàng)目，完全不使用測試工程師。就我的個人實(shí)踐經(jīng)驗(yàn)，對大部分的項(xiàng)目，尤其是為明確的客戶開發(fā)的項(xiàng)目，需要在敏捷開發(fā)團(tuán)隊(duì)中設(shè)置專職的測試工程師，因?yàn)椋簻y試與開發(fā)具有不同的思維方式：測試更注重全面的驗(yàn)證和檢查一個系統(tǒng)，而開發(fā)工程師往往很難在大的范圍內(nèi)建立這樣的思維方式。因此，無論是從系統(tǒng)的層面驗(yàn)證產(chǎn)品，或是從應(yīng)用系統(tǒng)的角度發(fā)現(xiàn)值得測試和驗(yàn)證的點(diǎn)（access point），專職的測試工程師都更有效。專職的測試工程師能夠更關(guān)注于測試基礎(chǔ)，建立測試需要的基礎(chǔ)架構(gòu)：由于測試工程師具有更好的對測試的理解，通常他們能夠更多的考慮測試的需求而開發(fā)適合項(xiàng)目的測試基礎(chǔ)架構(gòu)（自動化測試框架），而開發(fā)工程師可以使用這些框架來建立面向功能或代碼的測試。但是，不得不說的是，敏捷開發(fā)對開發(fā)和測試工程師都提出了更要的要求，尤其是對測試工程師而言，傳統(tǒng)的只能精確模擬用戶操作的測試工程師，因?yàn)椴荒転楫a(chǎn)品帶來生產(chǎn)率的提升，在敏捷開發(fā)的團(tuán)隊(duì)中，很難有所作為。在本專欄的后續(xù)文章中，我們會進(jìn)一步討論測試工程師在敏捷軟件開發(fā)中的工作和任務(wù)。關(guān)于作者段念：Google中國高級測試經(jīng)理，畢業(yè)于華中科技大學(xué)，先后在通訊、嵌入式軟件、互聯(lián)網(wǎng)等多個行業(yè)的國內(nèi)外知名公司中從事軟件開發(fā)與測試工作。對軟件測試中的技術(shù)和管理工作有獨(dú)到見解，對軟件測試團(tuán)隊(duì)管理、自動化測試、性能測試與開發(fā)測試有較多研究。

敏捷團(tuán)隊(duì)中的測試策略

這篇文章主要總結(jié)了我對于敏捷項(xiàng)目中總體測試策略的理解，主要來自于工作上的實(shí)踐和思考。

先看下維基百科上關(guān)于 test strategy 的定義

歸納上面的定義，我們可以得出測試策略的最終目的是通過定義項(xiàng)目會采用的測試活動，盡可能得暴露和消除產(chǎn)品缺陷，減輕產(chǎn)品風(fēng)險(xiǎn)。除此之外，由于軟件開發(fā)時常伴有交付壓力，測試的時間和資源都是無法保證甚至可能被壓縮的，所以測試策略還會從最低成本揭露產(chǎn)品質(zhì)量風(fēng)險(xiǎn)出發(fā)，選擇出最合理的測試方法和測試過程。

基于上面的定義，可見測試策略解決了兩個大問題：

在詳細(xì)點(diǎn)就是：

要說不同，先看定義上的不同。

由上可見，其實(shí)測試策略的內(nèi)容已經(jīng)被包含在測試計(jì)劃里面了。測試策略定義應(yīng)該做什么樣的測試而測試計(jì)劃包含所有關(guān)于測試策略該如何執(zhí)行的信息，這些信息在測試計(jì)劃里面被很好的組織起來。

一個公式可以進(jìn)一步說明他們的關(guān)系 test plan = test strategy + test logistics。所以test strategy可以被看做是test plan的一部分。Test logistics 是指測試環(huán)境設(shè)置以及人力資源等等。

在James Bach的博客 A Question about Test Strategy 中，他把三者描述如下

讓我們先來看下QA在敏捷項(xiàng)目中的主要工作，如下圖所示

那你可能問“咦，怎么沒有測試策略相關(guān)內(nèi)容呢”。其實(shí)，整個開發(fā)測試流程就體現(xiàn)了測試策略的內(nèi)容。上圖所示的迭代開發(fā)流程里面包含了"Automated Acceptance Tests" & “Story Testing” & “System Testing”這些測試活動，那么為什么項(xiàng)目需要這些測試活動？這些活動如何具體如何開展？分別在哪一個項(xiàng)目階段進(jìn)行？這些問題都屬于測試策略的范疇，是由測試策略定義和落地的。

敏捷開發(fā)模型下，迭代式的開發(fā)具有周期短和交付壓力大的特點(diǎn)，對于如何快速響應(yīng)新需求，保障新需求的質(zhì)量以及已實(shí)現(xiàn)需求的回歸測試都將是測試的挑戰(zhàn)。如果沒有一個匹配項(xiàng)目上下文，合理規(guī)劃了測試活動的測試策略，這些挑戰(zhàn)就會持續(xù)困擾著團(tuán)隊(duì)，所以標(biāo)題的答案是當(dāng)然需要。測試策略在敏捷開發(fā)模型下，通過詳細(xì)定義項(xiàng)目的測試活動，能夠更加合理地利用測試資源和統(tǒng)一項(xiàng)目對測試的認(rèn)知。

此外，測試策略也是敏捷項(xiàng)目質(zhì)量保障體系中重要的一節(jié)。

在傳統(tǒng)瀑布開發(fā)模式下，測試計(jì)劃test plan被認(rèn)為是項(xiàng)目測試流程的關(guān)鍵部分，因?yàn)樗笇?dǎo)著整個測試活動的開展，既然被認(rèn)為是項(xiàng)目中的一個must have，于是有人會花很多時間很多精力去把測試計(jì)劃給寫好寫完整。那么我們真的在敏捷開發(fā)模式的項(xiàng)目里需要一份測試計(jì)劃嗎？這真的能給項(xiàng)目質(zhì)量帶來價(jià)值嗎？

敏捷宣言說過：

在敏捷項(xiàng)目中，產(chǎn)品范圍也就是發(fā)布內(nèi)容在spring進(jìn)行之前就被討論，所以QA們對于測試對象和測試范圍一直都是清楚的，不需要特別地花時間去寫一個詳細(xì)的文檔來闡述。同樣地，agile ceremony會讓QA們清楚地知道測試對象是什么，范圍是什么，重點(diǎn)是什么，測試環(huán)境是什么而不需要一個單獨(dú)的文檔來進(jìn)行詳細(xì)的描述。甚至，所有關(guān)于測試的信息還可以被記錄被故事卡中。在開發(fā)進(jìn)行編碼實(shí)現(xiàn)功能的時候，QA們會進(jìn)行測試用例設(shè)計(jì)以及自動化測試編寫，因?yàn)闀r間的緊迫，QA除了這兩項(xiàng)測試活動，再去寫一個詳細(xì)測試計(jì)劃是不經(jīng)濟(jì)的且價(jià)值不大，這兩項(xiàng)測試活動才是敏捷項(xiàng)目中價(jià)值最高的，況且隨著迭代的進(jìn)行，測試計(jì)劃的維護(hù)還需要時間精力。

綜上所述，在敏捷項(xiàng)目中因?yàn)闀r間緊迫和避免重復(fù)勞動，價(jià)值不高的測試計(jì)劃不是一個must have，個人甚至認(rèn)為也不是一個nice to have。但是這并不是代表我們不需要"planning"，而是不是需要"document planning"，"planning"的實(shí)施發(fā)生在迭代中的各類活動。

最終我們還是需要一個“計(jì)劃”來指導(dǎo)迭代中的測試流程和方法，這就是測試策略是一個must have的原因。在敏捷項(xiàng)目中，“小而精”的測試策略比起“大而全”的測試計(jì)劃而言，最大的優(yōu)勢就是測試策略定義的內(nèi)容(“怎么測”)是不會輕易受影響改變的，并且在迭代中沒有類似的重復(fù)活動。

具體到項(xiàng)目里，測試策略推薦在項(xiàng)目剛啟動的時候制定。測試策略需要在項(xiàng)目早期就制定下來，用來指導(dǎo)項(xiàng)目的測試活動和方法，從而確定需要的測試資源和保證質(zhì)量體系的建立。但也不能在產(chǎn)品和技術(shù)都還沒有確定的時候就制定，因?yàn)橹挥性诋a(chǎn)品需求范圍，技術(shù)架構(gòu)和交付計(jì)劃大致確認(rèn)的情況，測試策略才能更加準(zhǔn)確，從而減少維護(hù)成本。

因?yàn)闇y試策略會涉及到很多具體的測試技術(shù)和方法，也會要求制定人員具有對質(zhì)量和測試非常深的理解，所以QA在敏捷團(tuán)隊(duì)中應(yīng)該承擔(dān)制定測試策略的主要責(zé)任，但是這并不意味“只有”QA來編寫制定測試策略，測試策略的制定是一個團(tuán)隊(duì)活動，QA需要從不同角色收集到不同的信息

從多方收集信息能夠保證業(yè)務(wù)、技術(shù)和質(zhì)量三者對齊，避免誤解和沖突，共同發(fā)揮最大的作用。

當(dāng)測試策略制定完成以后，還需要給項(xiàng)目團(tuán)隊(duì)進(jìn)行講解，確保團(tuán)隊(duì)所有相關(guān)人員對項(xiàng)目中的測試活動和測試方法有著一致的理解,這樣才能保證實(shí)施階段的順利。

接下來會涉及到QA制定測試策略的具體活動及流程?？偟膩碚f，大體流程可以如下

上面提到了QA可以從不同角色收集到不同的信息，除此之外，使用啟發(fā)式測試計(jì)劃語境模型 Heuristic Test Planning Context Model和啟發(fā)式測試策略模型 Heuristic Test Strategy Model也是一個有效的渠道。具體如何使用這兩個模型，請參考 htsm 和 htcpm。

通過分析 htsm 中“項(xiàng)目環(huán)境”和“產(chǎn)品元素”的關(guān)鍵詞和啟發(fā)式問題，QA可以了解關(guān)于產(chǎn)品和項(xiàng)目的各類信息來幫助制定測試策略。htcpm 也提供了大量的關(guān)鍵詞來啟發(fā)QA去分析了解產(chǎn)品需求、項(xiàng)目環(huán)境、測試小組和測試資源。

可以收集的信息大致可分類如下

只有從不同的維度收集到足夠的項(xiàng)目信息并且很好的理解這些信息對項(xiàng)目質(zhì)量和測試活動的影響，才能幫助我們少走彎路，制定出適合項(xiàng)目和團(tuán)隊(duì)的測試策略。

在具體思考“怎么測”之前，我們需要確定項(xiàng)目的質(zhì)量目標(biāo)。這個質(zhì)量目標(biāo)會對齊項(xiàng)目所有相關(guān)人員對于項(xiàng)目質(zhì)量的理解和期望，明確質(zhì)量范圍也就是測試策略會覆蓋的范圍。同時，質(zhì)量目標(biāo)也要與產(chǎn)品目標(biāo)對齊，因?yàn)橘|(zhì)量的最終目的也是保證產(chǎn)品的成功。根據(jù)產(chǎn)品在不同階段都有不一樣的目標(biāo)，質(zhì)量目標(biāo)有會隨之變化。

那質(zhì)量目標(biāo)如何設(shè)定？主要是參考軟件質(zhì)量特征列表和軟件質(zhì)量模型，建立符合項(xiàng)目上下文的產(chǎn)品質(zhì)量模型，從而確定項(xiàng)目質(zhì)量目標(biāo)

要建立項(xiàng)目產(chǎn)品的質(zhì)量模型首先就需要先知道一個軟件產(chǎn)品的質(zhì)量屬性或特征分別有什么，對應(yīng)的質(zhì)量模型是什么樣的。幸運(yùn)的是現(xiàn)在已經(jīng)有很多可以參考的模型了

ISO/IEC_25010的質(zhì)量模型大致如下：

從上面的質(zhì)量特征列表或是模型可以看出，一個軟件產(chǎn)品的質(zhì)量由多個質(zhì)量特征或標(biāo)準(zhǔn)組成，每個質(zhì)量特征又可以進(jìn)一步分解為子特征。通過這些已有的質(zhì)量模型來啟發(fā)哪些質(zhì)量特征是對項(xiàng)目產(chǎn)品重要的，哪些質(zhì)量標(biāo)準(zhǔn)適用于本項(xiàng)目產(chǎn)品，最后得出符合項(xiàng)目上下文的產(chǎn)品質(zhì)量模型。

比如 我們創(chuàng)建的產(chǎn)品質(zhì)量模型可以包含以下粗粒度特征：

上面的質(zhì)量模型定義了產(chǎn)品質(zhì)量特征和標(biāo)準(zhǔn)，而這些特征和標(biāo)準(zhǔn)就是我們應(yīng)該完成的目標(biāo)！除了上面說到的質(zhì)量模型，一些具體的metrics也可以被引入來保證項(xiàng)目質(zhì)量，成為項(xiàng)目質(zhì)量目標(biāo)的一部分。舉個例子

上面提到的標(biāo)準(zhǔn)都是可以通過集成到持續(xù)集成流水線的質(zhì)量工具或測試框架來實(shí)現(xiàn)。

此外，還有團(tuán)隊(duì)也會使用測試策略目標(biāo)宣言來打造團(tuán)隊(duì)文化。

有了質(zhì)量目標(biāo)，接下來我們要考慮要怎么達(dá)成這個目標(biāo)了！也就是說，我們應(yīng)該有哪些測試類型來覆蓋每一個質(zhì)量目標(biāo)？

測試類型按照不同維度可以有很多種分類，比如說

當(dāng)然，上面只是列出了一部分。

此外，HTSM中的 Test Techniques 提供了九種通用的九種測試技術(shù)來啟發(fā)對可應(yīng)用的測試類型的思考。敏捷測試四象限也提供了敏捷項(xiàng)目可以參考的測試類型,這個測試技術(shù)分類系統(tǒng)可以幫助我們快速定位某測試類型在軟件開發(fā)中的位置，根據(jù)項(xiàng)目產(chǎn)品情況選擇合適的測試類型。
就以我們上面假設(shè)的質(zhì)量目標(biāo)為例，我們來看看可以應(yīng)用哪些測試類型

值得注意的是，并不是每一個項(xiàng)目都需要覆蓋上面所列出的測試類型。我們應(yīng)該根據(jù)產(chǎn)品的目標(biāo)和特點(diǎn)以及其他實(shí)際情況選擇與之對應(yīng)的測試覆蓋類型，也就是說，不同項(xiàng)目根據(jù)測試類型的不同，測試廣度是不一樣的。同事，根據(jù)測試的難點(diǎn)和重點(diǎn)，測試深度也是不同的。所以，一切都要基于項(xiàng)目的上下文來思考和制定。

自動化測試金字塔用來指導(dǎo)敏捷項(xiàng)目中自動化測試的策略。

根據(jù)金字塔理論，項(xiàng)目應(yīng)該在底層的單元測試和集成測試(API測試)投入更多的精力。

自動化測試項(xiàng)目會被集成在持續(xù)集成流水線里面，由上游項(xiàng)目自動觸發(fā)。為了減少持續(xù)集成的反饋時間，一個普遍的做法是把龐大的自動化測試套件集依據(jù)重要性優(yōu)先級放在不同的流水線里面，可以被上游項(xiàng)目觸發(fā)也可以定時觸發(fā)，下面描述了一個比較好的實(shí)踐：

確定測試類型之后，我們就知道了整個項(xiàng)目的測試活動會有哪些。對于某些測試類型，特別是自動化相關(guān)的測試，我們需要對應(yīng)的測試工具或是框架來支撐我們的測試。所以我們需要對每一個測試類型都去思考下如何進(jìn)行測試，是否需要相應(yīng)的測試工具和框架的支持。

拿一個web程序來舉例

這個環(huán)節(jié)我們需要確定在項(xiàng)目開發(fā)生命周期的每個階段做什么樣的測試，使得測試類型與項(xiàng)目的開發(fā)流程充分結(jié)合，這樣就能最大發(fā)揮所有測試活動的效果來達(dá)到我們的質(zhì)量目標(biāo)。因此，我們可以做出類似下面這樣的表格來表現(xiàn)每個階段的測試類型及其實(shí)施方法。

至此，測試策略解決的兩個問題“測什么”和“怎么測”都可以找到大致答案了。

那如何衡量測試策略的有效性呢？質(zhì)量度量可以告訴我們產(chǎn)品的質(zhì)量情況和用戶滿意度，從而反應(yīng)出測試策略是否有效和高效。

軟件質(zhì)量的度量沒有什么最佳實(shí)踐，也沒有最準(zhǔn)確和科學(xué)的度量，有的只是項(xiàng)目上積累的成功經(jīng)驗(yàn)；但是這些成功經(jīng)驗(yàn)又由于項(xiàng)目差異化太大而變得復(fù)用性很差。所以根據(jù)項(xiàng)目的上下文，我們需要制定出自己的質(zhì)量度量標(biāo)準(zhǔn)。結(jié)合本文敏捷項(xiàng)目的背景，我們可以大致使用下面常用的度量：

同時，實(shí)例化的質(zhì)量目標(biāo)也是很好的項(xiàng)目質(zhì)量的工具。對于質(zhì)量模型，我們可以看下每一個質(zhì)量元素我們是否做到；對于具體的指標(biāo)metrics，要隨時監(jiān)控反饋。

一旦測試策略被確定，一般來講不會經(jīng)常變化，因?yàn)闇y試策略設(shè)置了一些測試標(biāo)準(zhǔn)。如果測試標(biāo)準(zhǔn)頻繁地變動，這會讓具體計(jì)劃的執(zhí)行變得困難，同時帶來更多的資源浪費(fèi)，最終影響了項(xiàng)目的質(zhì)量。

在項(xiàng)目中我們會經(jīng)常遇到“變化”：比如說

這些變化對測試的影響是被測對象的范圍以及項(xiàng)目資源的調(diào)配。對于項(xiàng)目的質(zhì)量目標(biāo)、測試類型、測試階段影響不大。所以，測試策略一旦被制定出來，變化不會太大。

不過這不代表測試策略的一成不變和缺乏改進(jìn)，QA需要在每個迭代中觀察測試策略實(shí)施的效果來決定當(dāng)前的測試類型和實(shí)施手段是否滿足項(xiàng)目需求。比如當(dāng)項(xiàng)目集成測試(API Testing)經(jīng)常fail，且協(xié)調(diào)工作耗時費(fèi)力，QA可以考慮采用契約測試來代替現(xiàn)有的集成測試，提高整個項(xiàng)目組的生產(chǎn)率和質(zhì)量；比如發(fā)現(xiàn)Internet Edge突然用戶量增多且有關(guān)于Internet Edge的production bug被raise，QA需要把Internet Edge加到兼容性測試中，并且設(shè)置相關(guān)的測試環(huán)境；比如測試進(jìn)度落后，交付壓力增大，QA需要及時調(diào)整測試范圍和測試重點(diǎn)，進(jìn)行風(fēng)險(xiǎn)分析。

在實(shí)際項(xiàng)目中，往往會出現(xiàn)各種各樣的問題來阻礙測試策略的順利落地和執(zhí)行。這些問題有些是測試策略自身的問題，但也有項(xiàng)目帶來的問題。這時候，風(fēng)險(xiǎn)分析顯得格外重要。

對于測試策略的風(fēng)險(xiǎn)分析，這個是應(yīng)該貫穿整個測試策略制定周期里面的，我們需要通過項(xiàng)目風(fēng)險(xiǎn)清單提前識別項(xiàng)目中可能阻塞測試的風(fēng)險(xiǎn)，并通過風(fēng)險(xiǎn)優(yōu)先級(風(fēng)險(xiǎn)暴露的概率*風(fēng)險(xiǎn)暴露的損失)來評估風(fēng)險(xiǎn)，最終基于風(fēng)險(xiǎn)調(diào)整測試策略，把測試重點(diǎn)放到風(fēng)險(xiǎn)高優(yōu)先級高的地方。

測試策略是影響質(zhì)量的重要因素，但不是全部，下面列出了部分會影響質(zhì)量的因素作為參考，在此文中不會展開來講

上面詳細(xì)闡述了我如何理解敏捷項(xiàng)目中的測試策略以及制定測試策略的具體步驟。由于IT項(xiàng)目的多樣性和復(fù)雜性，這個總結(jié)不可能適用于有著不同上下文的項(xiàng)目，因地制宜地制定測試策略才能保證測試策略在項(xiàng)目中的可用性和合理性。

敏捷測試的指導(dǎo)性原則

? ? ? ? ?1） 產(chǎn)品的質(zhì)量不是測試出來的，是軟件生產(chǎn)出來就是這樣的。

? ? ? ? ? 2）但現(xiàn)實(shí)很殘酷，上線前最緊張的還是QA，我們也很無奈...
1.QA就是一個角色。

團(tuán)隊(duì)中任何一個人被賦予這個角色就要承擔(dān)QA的職責(zé)，承擔(dān)QA要做的事情，eg:BA 也可以被賦予這個角色。

2.能力要求
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -----學(xué)習(xí)自《ThoughtWorks》

怎么做敏捷測試人員？

1、敏捷測試人員的定義
我們這樣定義敏捷測試人員：專業(yè)的測試人員，適應(yīng)變化，與技術(shù)人員和業(yè)務(wù)人員展開良好協(xié)作，并理解利用測試記錄需求和驅(qū)動開發(fā)的思想。敏捷測試人員往往具有優(yōu)秀的技術(shù)能力，知道如何與他人合作以實(shí)現(xiàn)自動化測試，同時也擅長探索性測試。他們希望了解客戶在做什么，以此更好地理解客戶的軟件需求。
誰是敏捷測試人員？她是驅(qū)動敏捷測試的團(tuán)隊(duì)成員。我們知道許多敏捷測試人員剛開始的時候在從事其他工作。開發(fā)人員可能會愛上測試而超越單元測試的范疇。習(xí)慣以敏捷方式工作的探索型測試人員也會被敏捷團(tuán)隊(duì)吸引。其他角色的專業(yè)人士，比如業(yè)務(wù)或者功能分析師，也可能具有同樣的特質(zhì)并做同樣的工作。
技能很重要，但態(tài)度更值得關(guān)注。Janet總是說：“如果態(tài)度不好，那么技能則一無是處”。既然我們要為敏捷團(tuán)隊(duì)招募大量的測試人員，那么必須慎重考慮這一點(diǎn)，并與敏捷社區(qū)的其他朋友進(jìn)行相關(guān)討論。測試人員往往可以總覽全局。他們更多時候是以客戶的角度看待應(yīng)用程序，這意味著他們一般以客戶為中心。
2、敏捷測試思想
如何使一個團(tuán)隊(duì)變得“敏捷”？對我們而言，敏捷團(tuán)隊(duì)持續(xù)關(guān)注如何最出色地工作并發(fā)布最優(yōu)秀的產(chǎn)品。根據(jù)我們的經(jīng)驗(yàn)，這需要大量的訓(xùn)練、學(xué)習(xí)、時間、實(shí)驗(yàn)和協(xié)同工作。這并不適合所有人，但是對那些希望自己團(tuán)隊(duì)充滿活力并關(guān)注持續(xù)改進(jìn)的人來說非常適合。
成功的項(xiàng)目總是因?yàn)閮?yōu)秀的人才完成了出色的工作。在敏捷團(tuán)隊(duì)中做一名成功的測試人員所需要的特質(zhì)可能與在任何團(tuán)隊(duì)做一名高水平的測試人員所需要的相同。
敏捷測試人員不會把自己看作是質(zhì)量管理辦公室的主管以保護(hù)客戶避免受到缺陷代碼的傷害。她會樂于收集和分享信息，與客戶或者產(chǎn)品負(fù)責(zé)人協(xié)作以幫助他們充分展示自己的需求，從而得到他們需要的功能，同時向所有人提供項(xiàng)目進(jìn)展的反饋。

（來源：培訓(xùn)啦 http://faa912.cn）文章共14190字

985大學(xué) 211大學(xué) 全國院校對比 專升本