敏捷驗收測試驅動開發:敏捷認證


驗收測試驅動開發 (ATDD) 是測試驅動開發 (TDD) 的擴充套件版本,它促進了不同使用者的協作以驗證系統的功能。它是一種受敏捷方法論啟發的專案管理系統。它培養了開發人員、測試人員、利益相關者和客戶之間的聯絡,以從使用者的角度理解系統的功能和需求。在這篇文章中,我們將深入瞭解 ATDD,包括其實施方法、用途等。繼續閱讀。

什麼是敏捷驗收測試驅動開發?

與您可能從名稱中推斷的不同,ATDD 並不是嚴格意義上的測試過程。它是一種程式設計技術。它與 TDD 的區別在於,該概念更側重於將一群人(與軟體開發專案相關)聚集在一起以準備驗收測試。

它使用簡單的英語編寫,並在協作討論後製定。在此階段,開發人員、測試人員和利益相關者討論他們正在解決的問題、如何解決以及測試。它幫助團隊確定系統是否會按照行業標準執行。如果討論中的每個成員都同意,團隊可能會決定自動執行驗收測試。

ATDD 的階段

這個過程可能看起來非正式且靈活,但它分為四個必須按正確順序執行的階段。結果取決於這些階段的執行情況。

討論

ATDD 從整個敏捷團隊和利益相關者參與的討論開始。在此階段,團隊詳細討論了從使用者角度來看系統的功能。根據結論,團隊自動或手動開發驗收測試。適當的討論降低了誤解的風險,誤解可能會導致軟體中的錯誤。請注意,在討論階段識別潛在的錯誤比在軟體開發完成後識別它們要便宜得多且更容易。團隊也可能會發現,看似簡單使用者問題實際上是一個複雜的問題。

提煉

下一步是將驗收測試實施到專案中。團隊評估驗收測試的有效性,以瞭解它們是否可以實施到特定專案中,或者是否需要更改。換句話說,在第二階段,團隊應該將討論的規範轉換為與測試工具相容的格式。這可能包括表格格式、程式碼或 Wiki 頁面。結果,您將獲得驗收測試。但請確保它們尚未準備好執行。

開發

第三步是執行。在這一點上,開發人員將執行測試以檢查哪些有效,哪些無效。更準確地說,團隊根據討論階段確定的規範進行編碼。在開發階段,利益相關者將建議應引入驗收測試的更改。可以進行進一步的手動測試以找出以後可能出現的更多問題。

演示

敏捷驗收測試驅動開發的最後一個階段是演示,敏捷團隊準備簡報並將其展示給利益相關者。它展示了他們已經完成的測試、發現和漏洞。

這個概念類似於 TDD,因為它具有相同的流程和需求。團隊應該在編寫程式碼之前建立驗收測試。唯一的區別是 TDD 基於單元測試,而 ATDD 則側重於小組討論,首先確定可用性、開發過程、使用者問題和解決方案。根據這些規範,開發人員和測試人員協作建立有助於透過測試的程式碼。它不僅幫助您的團隊以清晰易懂的語言理解專案的規範,而且還確保團隊構建客戶想要的內容。

ATDD 與 TDD

通常,ATDD 與 TDD 相比較,因為這兩個概念都源自敏捷方法論,並且有很多相似之處。在測試驅動開發中,開發人員建立一個失敗的單元程式碼,隨後將其更改為可以透過測試的程式碼。TDD 的目的是建立簡單、易於理解和乾淨的程式碼。它更多地關注單元測試,這涉及將錯誤的功能實施到系統中的風險。

這可能會導致軟體以後出現代價高昂的錯誤。因此,專家提出了這種 TDD 擴充套件,即 ATDD。與 TDD 不同,它不是以開發人員為中心的模型。它更像是開發人員、利益相關者、客戶、測試人員以及參與專案的其他人員之間的協作。ATDD 包括精通技術和不精通技術的人,他們對編碼一無所知。

為了簡化流程,大多陣列織採用 TDD 和 ATDD 的混合方法。他們在與利益相關者和開發人員討論後建立驗收測試。一旦開發出生產程式碼以使測試透過,就可以實施 TDD 方法來測試程式碼的效率和準確性。

如何開始?

ATDD 的實施從培訓開始。確保團隊的每個成員都能獲得正確的培訓材料,這些材料是學習這種驗收測試和生產編碼基礎知識所必需的。培訓不僅僅是解釋方法,同樣重要的是,參與 ATDD 的每個成員都瞭解自己的角色。ATDD 在編寫規範時使用使用者故事格式。

確保團隊所有成員都理解該格式並在編寫軟體需求時遵循相同的方法。最後,選擇合適的框架並部署驗收測試。必須定期評估此方法以確保它沒有漏洞並提供最佳結果。

底線

這就是關於敏捷驗收測試驅動開發及其遵循的過程的所有內容。您可以學習敏捷認證課程,例如 PMI-ACP,以更好地瞭解這些方法。它將教會您敏捷的基本到高階概念,這種方法如何在不同的專案中實施,以及如何在您的組織內提高專案的成功率。

更新於: 2022年12月14日

163 次瀏覽

啟動您的 職業生涯

透過完成課程獲得認證

開始
廣告