當前位置:編程學習大全網 - 源碼下載 - 敏捷開發模式用的測試是什麽模型

敏捷開發模式用的測試是什麽模型

編者按敏捷的理念已經深入人心,開發過程已經漸入佳境,測試的處境卻稍顯尷尬。測試從業者應該何去何從,怎樣才能擁抱敏捷,體現出自己新的價值呢?InfoQ特地邀請了來自Google的敏捷測試專家段念,為讀者答疑解惑,希望所有測試從業者可以從中得到自己的答案。更多關於敏捷測試的內容,請訪問InfoQ中文站敏捷測試相關內容。

在與不少測試從業人員討論到敏捷的時候,被問得最多的大約是兩個問題:到底?,敏捷軟件開發還需要測試工程師嗎?。前壹個問題是對於敏捷測試本身定義的疑問,第二個問題則是對敏捷開發將測試工程師排除在外的擔心。其實,在探尋這兩個問題答案的過程中,我們可以更清晰的了解敏捷軟件開發中測試的工作定義,測試價值觀,以及敏捷開發中開發與測試工程師的配合。鑒於這兩個問題的意義,在本敏捷測試專欄的第壹篇文章中,本人嘗試從自己的實踐出發,盡可能清楚的回答這兩個問題。

確實,相對於敏捷開發紅遍大江南北的狀況而言,對敏捷測試的討論則低調得多。敏捷聯盟定義了敏捷的4個價值聲明,以及伴隨的12條支持原則,這12條原則中沒有壹條單獨提到測試。這是不是意味著測試在敏捷開發中並不重要呢?實際上,如果仔細研讀敏捷的12個原則,以及各種不同的敏捷實踐,就會發現,測試在敏捷開發中占有非常重要的地位。無論是原則中的頻繁交付,還是對可工作的軟件的度量,或是敏捷開發實踐中的測試驅動開發,行為驅動開發,都離不開測試的支持。在本人看來,敏捷開發中不把測試單獨拿出來描述的原因,恰恰是因為在敏捷開發中,測試不再是壹個單獨的、和開發獨立的過程,而是變成了驅動開發、衡量產出的主要的手段,成為了敏捷開發中所有工程師在工作時必須時刻考慮和實踐的壹個部分。簡而言之,敏捷軟件測試更多的是壹種理念,而非過程。

既然是這樣,為什麽我們還要在這個專欄中專門來討論敏捷軟件測試?本人接觸過不少軟件開發和測試工程師,他們所處的組織有的正在努力向敏捷開發轉型,有的已經實踐了壹段實踐的敏捷開發,但由於由來已久的工作習慣,他們中的絕大多數並不能自覺的認識到測試在敏捷開發中的關鍵作用,而是有意無意的將測試仍然看作是與開發截然分開的下壹個階段,導致在實踐敏捷開發的過程中遇到種種問題:要麽是忽略了代碼質量,導致在頻繁的叠代過程中,每壹個叠代的問題層出不窮;或是沿用原有的方法安排對系統的系統測試,導致測試團隊疲於奔命,卻總也趕不上開發所要求的進度。在這種情況下,專門來討論敏捷軟件開發中的測試,也就是敏捷軟件測試的話題,對這些工程師應該會有壹些幫助。

那麽,到底?很難給敏捷測試下壹個精確、完善的定義,在本人看來,接納了敏捷的核心價值觀(溝通,簡單,反饋,勇氣,尊重),在敏捷軟件開發過程中開展的測試就可以被稱作是敏捷軟件測試。因此,敏捷軟件測試並不是壹個與敏捷軟件開發同壹層次的劃分,而是敏捷軟件開發中的壹部分,與傳統的測試不同,敏捷軟件測試並不是壹個獨立的過程,相反,它與整個敏捷開發中的其他活動交織在壹起,處處都能看到它的影子。由於敏捷軟件測試並不傾向於壹個單獨的過程定義,本人擬從敏捷軟件測試與傳統測試觀點的比較、敏捷軟件測試中采用的方法、測試工程師在敏捷軟件測試過程中的工作等方面來闡述之。在這篇文章中,我們主要從宏觀的角度來描述敏捷軟件測試,而在本專欄的後續文章中,我們將對敏捷軟件測試中采用的方法、工程師在敏捷軟件測試中的工作內容等進行進壹步的描述。

使用Dashboard、燃盡圖等方式展示當前工作與可交付產品之間的距離

建立單元測試覆蓋率等度量指標

***享質量目標意味著質量責任由所有工程師***同承擔

開發測試應該建立壹定的測試覆蓋率標準,例如,在單元測試這個級別上,建立60%或80%的覆蓋率要求

通過使用TDD、BDD等技術,保證產品和代碼的可測試性

建立足夠多的自動化測試,保證測試能夠滿足快速叠代的要求

檢查表提到了團隊、反饋、質量文化和開發測試四個方面的內容,在本人看來,這四個方面體現的就是敏捷軟件測試與傳統軟件測試的最大的不同。傳統軟件測試關註的是通過盡可能完備的覆蓋去發現盡可能多的問題,把測試和開發當成是兩個獨立的過程,測試是對開發階段產生成果的驗證

。而敏捷軟件測試則建立了壹種不同的質量文化:測試的目的是為了保證產品快速發布,也就是對生產率本身的提高。基於驗證的出發點必然會要求測試與開發的獨立,以及盡可能客觀和完備的度量產品質量;而基於生產率的出發點則要求建立敏捷的團隊,要求測試與開發盡可能緊密,要求建立具有高度可測試性的軟件,以及基於這些的高度自動化測試。

在檢查表列出的所有項目中,質量文化是基礎,團隊是敏捷軟件測試得以實施的條件,反饋和開發測試則是敏捷軟件測試的具體方法。當然,妳可以可以從敏捷的核心價值觀來階段這些項目:團隊關註的是溝通與尊重;反饋直接對應於反饋;質量文化基於勇氣(承擔質量責任的勇氣)與尊重;而開發測試則是反饋與簡單的具體體現。

另壹個在本文最初提出來的問題是:敏捷軟件開發還需要測試工程師嗎?,對這個問題,業界有不同的觀點。有人認為需要,因為總有壹些是需要測試工程師的技能完成的工作;當然,也有人認為不需要,因為敏捷開發中的測試註重開發測試與自動化測試,開發工程師就可以自己搞定與測試相關的工作。在實踐中,那些大規模實踐敏捷開發的公司(例如Google),傾向於在組織中設置數量較少的測試工程師,在項目中分配較少的測試資源,甚至對某些項目,完全不使用測試工程師。

就我的個人實踐經驗,對大部分的項目,尤其是為明確的客戶開發的項目,需要在敏捷開發團隊中設置專職的測試工程師,因為:

測試與開發具有不同的思維方式:測試更註重全面的驗證和檢查壹個系統,而開發工程師往往很難在大的範圍內建立這樣的思維方式。因此,無論是從系統的層面驗證產品,或是從應用系統的角度發現值得測試和驗證的點(access point),專職的測試工程師都更有效。

專職的測試工程師能夠更關註於測試基礎,建立測試需要的基礎架構:由於測試工程師具有更好的對測試的理解,通常他們能夠更多的考慮測試的需求而開發適合項目的測試基礎架構(自動化測試框架),而開發工程師可以使用這些框架來建立面向功能或代碼的測試。

但是,不得不說的是,敏捷開發對開發和測試工程師都提出了更要的要求,尤其是對測試工程師而言,傳統的只能精確模擬用戶操作的測試工程師,因為不能為產品帶來生產率的提升,在敏捷開發的團隊中,很難有所作為。在本專欄的後續文章中,我們會進壹步討論測試工程師在敏捷軟件開發中的工作和任務。

關於作者段念:Google中國高級測試經理,畢業於華中科技大學,先後在通訊、嵌入式軟件、互聯網等多個行業的國內外知名公司中從事軟件開發與測試工作。對軟件測試中的技術和管理工作有獨到見解,對軟件測試團隊管理、自動化測試、性能測試與開發測試有較多研究。

  • 上一篇:在android上查看wifi狀態,代碼如下:
  • 下一篇:這2021年我是壹分鐘也待不下去了——《艾爾登法環》
  • copyright 2024編程學習大全網