敏捷測試的方法和實踐 上

2021-05-23 21:06:21 字數 1961 閱讀 3993

有一次,當開發人員完成當前

sprint

任務的**之後,測試人員與開發人員、產品經理一起來瀏覽產品、從頭到尾走一邊,產品經理發現了問題,認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成**,但測試人員反對這樣做,我們本來只有

5天測試時間,加上這次新做的功能比較多、開發**質量不高,驗收測試已經很緊張。如果再延遲兩天,測試沒法完成。產品經理說,你們不是在用敏捷測試方法,應該測得很快,三天應該能完成測試工作啊!

,如圖1所示。

1 敏捷測試定義的形象描述

在敏捷方法中,需求變化比較快、產品開發周期很短,我們目前採用四周時間,也就是每個月發布乙個新版本。開發周期短,功能不斷累加,給軟體測試帶來很大的挑戰,軟體測試流程要做相應的調整。例如,我們原有的測試規範明確規定,首先要建立專案的主測試計畫書,然後再建立每個功能任務的測試計畫書,測試計畫書有嚴格的模板,而且需要和產品經理、開發人員討論,並和測試團隊其他人員(包括測試經理)討論,最終得到大家的認可和簽字才能通過,僅測試計畫經過「起草、評審和簽發」乙個完整的週期就需要乙個月。在敏捷方法中,不再要求寫幾十頁的測試計畫書,而是在每個迭代週期,寫出一頁紙的測試計畫,將測試要點(包括策略、特定方法、重點範圍等)列出來就可以了。

在原有測試規範中,要求先用

excel

use case

或user story

直接進行驗證,並進行探索性測試。而節約出來的時間,用於開發原有功能的自動化測試指令碼,為回歸測試服務。自動化測試指令碼將代替測試用例,成為軟體組織的財富。原有測試規範還要求進行兩輪回歸測試,在敏捷測試中,只能進行一輪回歸測試。綜合這些考慮,敏捷測試的流程簡單有效,如下圖

2所示。

敏捷測試流程簡要圖

測試中發現的問題及時反饋給產品經理和開發人員,而且某ll

參與**複審(

code review

),並適當輔助開發人員進行單元測試。

l在流程中增加乙個環節

「產品走查(

product work-through

)」——

測試人員和產品經理、開發人員等在一起,從頭到尾將新功能看一遍,可直觀、快速地發現問題。

測試任務簡單地可分為新功能測試和回歸測試。在敏捷方法中,針對這兩部分的測試建立相應的策略,以提高測試的效率,最大限度地降低質量風險。新功能測試的策略主要有:

l不需要測試用例,直接基於用例、基於對需求的理解來完成新功能的驗證。即使要寫測試用例,只要保證各個功能點被覆蓋,不要過於詳細(大顆粒度)。

l持續地進行驗證,一旦某塊新**完成(

code drop),

就開始驗證,而不是等到所有**完成後才開始測試。這也包括參與到單元測試和整合測試中。

l實施端到端(

end-to-end

)的測試,確保完整的業務流程的實現,同時,也容易發現業務邏輯不夠清晰、不夠合理等各方面的問題。

l閱讀**來發現問題,可以和開發人員工作保持同步,消除測試週期的壓力。

l基於經驗,可以實施更多的探索性測試、組合互動性(

interoperation

)測試和使用者場景

(user scenario)

測試,更有效地發現埋藏較深的缺陷。

回歸測試是敏捷測試中需要面對的難點。每次迭代都會增加新的功能,乙個產品可能會經過十幾次、甚至幾十次迭代,回歸測試範圍在不斷增大,而每次迭代週期沒變,可能還是乙個月。這樣驗收測試的時間非常有限,所以回歸測試很大程度上依賴於自動化測試,因為很難將回歸測試控制在非常有限的範圍內。當然,還是有些辦法可以幫助我們減少回歸測試的範圍,例如:

l通過執行

code diff

來了解**變動的所有地方,再做**關聯分析,就可以明確知道要進行哪些地方的回歸測試,回歸測試範圍會大大縮小。

l基於風險和操作面分析來減少回歸測試的範圍,例如回歸測試只是保證主要功能點沒有問題,而忽視一些細節的問題。

l持續測試的過程,只要有時間,就進行測試,包括開發人員、產品設計人員都參與到日常的試用和測試中來。

敏捷測試的方法和實踐

有一次,當開發人員完成當前sprint 任務的 之後,測試人員 開發人員和產品經理一起來瀏覽產品 從頭到尾走一遍,產品經理發現了問題,認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成 但測試人員反對這樣做,我們本來只有5天測試時間,加上這次新做的功能比較多 開發 質量不高,驗收測...

敏捷測試的方法和實踐

有一次,當開發人員完成當前sprint 任務的 之後,測試人員 開發人員和產品經理一起來瀏覽產品 從頭到尾走一遍,產品經理發現了問題,認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成 但測試人員反對這樣做,我們本來只有5天測試時間,加上這次新做的功能比較多 開發 質量不高,驗收測...

敏捷測試的最佳實踐 一敏捷的實質

本文講述了作者在兩年的敏捷測試和開發工作有個非常有意思的遊戲能夠幫助大家理解敏捷和傳統開發的差異。遊戲有兩個角色,乙個是 老闆 另乙個是 員工 在 2 分鐘內,員工 需要在 老闆 的完全指揮下,即 向前一步,向後一步,停,向左一步,向右一步 完成 60 步移動的任務。員工 需要執行 老闆 的每乙個指...