敏捷測試的核心

2021-10-17 03:43:14 字數 2801 閱讀 7256

q:質量內建跟敏捷測試的關係是什麼?能分開嗎?

a:我認為質量內建是敏捷測試的核心。

敏捷測試是相對於傳統測試而言的,在聊敏捷測試之前,我們先看傳統測試是什麼樣的。傳統測試通常有如下的特點:

敏捷測試的目標也不再是發現更多的bug,而是盡快的交付高質量的軟體。

那麼軟體的高質量怎麼獲得呢?著名質量管理專家指出:質量不是檢測出來的,產品生產出來質量已經在那裡了。因此,通過加強測試保障沒法提高軟體質量,需要將質量內建到軟體產品中。

軟體的缺陷暴露的越晚,修復的成本就越高;前期對缺陷預防的少,後期發現的缺陷就會多;前期做好了缺陷預防,後面暴露的缺陷就會減少。因此,我們需要提前預防缺陷,而不是等開發完成了才發現很多的問題,這就是質量內建。

早在12年前接觸敏捷測試的時候,有三個詞深深的印在了我的腦海裡「test early,test often,test first(盡早測試、頻繁測試、測試先行)」,其實,它們正好對應著質量內建的三個關鍵實踐:測試左移、持續測試、測試驅動開發,是敏捷測試最核心的部分。

測試左移

測試左移要求測試在軟體開發生命週期的左側盡早介入,可以是需求分析階段,也可以是更早的inception階段。左移的測試人員可以做的事情可以有一起挖掘需求、分析需求、澄清需求、評審需求、參與技術方案討論等,主要目的是利用測試人員獨有的視角和對系統的了解,在各個環節進行必要的輸入,確保團隊對於需求理解的一致性,確保團隊能夠做正確的事情。

測試人員參與需求分析的價值主要體現在下面兩個方面:

業務價值

同時,需要測試人員更多的考慮業務價值,在各個需求環節能夠從業務價值的角度提供輸入,包括終端使用者行為、業務流程、業務風險等維度的考慮。可以參考我的文章《敏捷測試如何優化業務價值》。

使用者故事

使用者故事作為敏捷開發過程中傳遞業務需求的載體,非常重要。對於使用者故事的拆分和使用者故事驗收條件的描寫都有很高的要求,測試人員參與可以幫助評審使用者故事,提公升使用者故事的質量,以更清晰的方式在團隊傳遞需求。要求測試人員能夠透徹的理解使用者故事拆分的「invest」原則,並利用這些原則來評審使用者故事:

持續測試

測試左移是為了讓團隊清晰一致的理解需求,從而做正確的事情;而持續測試則是在整個開發生命週期裡(生命週期的最左側開始,延續到最右側的生產環境)的各個環節的測試活動,以幫助快速收集反饋,從而正確的做事情。

持續測試的內容包括對持續功能測試,也包括效能、安全等的內建、持續測試;形式可以是靜態分析、評審,也可以是動態的測試,包括手動執行的各種測試,以及持續整合流水線上的持續執行的自動化測試。下面我們從使用者故事生命週期為例來看可以有哪些持續的測試活動:

故事分析:這個階段主要是對故事的拆分、故事裡的ac(acceptance criteria,驗收標準)等內容進行評審,包括功能和跨功能需求的確認,看是否有需求遺漏或者不合適的需求,同時可以重點標註一些開發或者後期驗證需要特別注意的點。

故事啟動:故事啟動是在開發人員開始實現使用者故事之前對需求進行澄清,確保業務、開發和測試對該使用者故事要實現的需求達成一致的認識,包括功能和跨功能需求(安全、效能等)。

故事開發:開發人員開始開發使用者故事,並完成底層自動化測試(單元測試和介面層測試等);測試人員可以開始設計相應的測試用例和ui層功能自動化測試,同時可以將在測試設計過程中發現/想到的使用者故事相關的問題反饋給團隊。

故事驗收:故事驗收是開發人員開發完成乙個使用者故事之後,對系統實現進行驗收的環節,這個環節跟「故事啟動」環節是對應的,同樣包括對功能需求和跨功能需求的驗證。

故事測試:完成相應的功能自動化測試,讓其在持續整合流水線上按需執行;同時,需要基於該使用者故事執行相應的探索性測試。

故事演示:將開發完的功能演示給客戶,一般以特性為單位,需求、開發或測試人員來負責演示都可以,目的是盡早收集到客戶的反饋,是客戶驗收的環節。

測試驅動開發

單元測試驅動開發(utdd):在編寫產品**之前,先寫單元測試,由單元測試驅動出產品功能**,主要是為了保證設計的完備性,更好的實現質量內建。單元測試一般都是開發人員來實現的,測試人員不參與實現,但可以在故事驗收階段對開發編寫的單元測試進行評審,確保單元測試覆蓋的有效性。

驗收測試驅動開發(atdd):除了單元測試之外,還可以先實現自動化的功能驗收測試,在功能開發完成之後,要求所有驗收測試都是能通過的。這樣做可以盡早利用功能自動化測試收集反饋,更好的保證功能需求實現的正確性。驗收測試可以由開發人員和測試人員結對完成或者測試人員獨自完成。

說到atdd,我們通常很容易聯想到行為驅動開發(bdd),常被人們混為一談,有必要再次說明一下。其實,bdd強調的是不同角色之間的協作,更好的理解和澄清需求,確保需求理解的一致性。bdd不是關於測試的,可以沒有測試,但是可以指導測試,我們通常可以基於bdd的方式實現自動化測試。而atdd是關於測試的,必須有測試。更多關於bdd的內容,可以參考我的文章《說起bdd,你會想到什麼》。

敏捷測試的核心是質量內建,而質量內建就是缺陷預防;

測試左移、全階段的持續測試、測試驅動開發是質量內建成功的關鍵。

文/thoughtworks 林冰玉

敏捷的核心價值

對於敏捷來說,態度勝過過程,環境勝過方法。我們要建立出色的產品,就要有出色的人員 如果我們要吸引並留住出色的人員,就要有出色的組織。1 響應變化 實際上是在執行計畫之上響應變化。每個專案都有已知的和未知的,確定的和不確定的,所以每個專案都要在計畫和變化之間進行平衡。生產型的專案中,不確定性較低,而對...

敏捷開發 敏捷測試

敏捷測試的定義 首先敏捷測試是敏捷的一種,原有測試定義中通過執行被測系統發現問題,通過測試這種活動能夠提供對被測系統提供度量等概念還是適用的。在傳統的測試定義上,還需要新增 敏捷測試是遵循敏捷宣言的一種測試實踐 強調從客戶的角度,即使用系統的使用者的角度,來測試系統 重點關注持續迭代的測試新開發的功...

敏捷測試 傳統測試

敏捷測試 首先敏捷測試 agile testing 是測試的一種,敏捷測試的理念是,和編碼一樣,測試是開發的乙個關鍵部分。在敏捷中,測試被直接整合到軟體開發過程中,以便盡早 頻繁地發現bug。因此,測試人員可以在開發過程的每乙個節點上發現問題,從而使產品快速走向發布。敏捷測試的特點 傳統測試 傳統測...