大話敏捷測試 | IDCF

敏捷測試

• 從廣義上來說，測試是整個敏捷團隊的活動，而不只僅是測試同窗的活動，由於原則上咱們指望的敏捷團隊的產出是通過代碼編寫+代碼集成+代碼測試以後的增量，因此開發同窗也須要在這個目標指引下，若是測試有積壓，開發同窗須要針對故事進行測試，以便完成整個敏捷團隊的交付承諾，而不只僅是編碼，僅僅編碼不是用戶和公司指望的，而通過測試的代碼纔是指望的；
• 而從狹義上來說，敏捷測試，首先從測試同窗角度，在敏捷開發的環境和上下文下，如何進行測試，思惟和方法有何轉變。

1、什麼是敏捷測試？

來源：老話題新解說：究竟什麼是敏捷測試？

在敏捷環境裏，測試要想生存，須要轉變認知，測試再也不是傳統意義上的測試階段，而是變成了測試活動，從而才能夠進行持續測試。

來源：https://www.luxoft-training.c...

2、敏捷測試人員

《敏捷測試》：

• 敏捷測試人員：專業的測試人員，適應變化，與技術人員和業務人員展開良好協做，並理解利用測試記錄需求和驅動開發的思想。
• 敏捷測試人員每每具備優秀的技術能力，知道如何與他人合做以實現自動化測試，同時也擅長探索性測試。他們但願瞭解客戶在作什麼，一次更好地理解客戶的軟件需求。

敏捷測試人員成爲敏捷團隊中的一員，一般敏捷團隊採用最流行的Scrum框架，那麼團隊包括負責產品方向和ROI的產品負責人，負責引領敏捷Scrum的團隊服務型領導Scrum Master，負責將產品願景和需求實現的開發團隊（包含所需各類技能的團隊成員，例如開發前端技能，開發服務端技能，測試技能，測試自動化技能等等）。

3、敏捷測試思想

《敏捷測試》：以客戶爲中心，注重結果，勤於耕做、協做、富有創造力、樂於學習和適時地創造業務價值。

敏捷測試前提是敏捷開發，那麼須要在認同和執行敏捷宣言的價值觀和12原則前提下，從測試技能、測試活動角度，應該具有的思想，就是敏捷測試思想。

4、敏捷測試十大法則

來源：《敏捷測試》，強調態度和心態比特定技術能力更重要。

一、提供持續反饋

• 反饋需求以便描述清楚每一個用戶故事；
• 和團隊共同將每一個用戶故事轉化成可執行的測試；
• 和同隊共同執行測試，不斷接收有價值的反饋

二、爲客戶創造價值

• 聚焦關鍵路徑，確保最小核心功能首先完成，邊邊角角複雜完美功能逐漸迭代上線。
• 敏捷測試人員不只從利益相關者角度考慮軟件系統，也會了解開發面對的技術限制和實施細節。儘早常常地向客戶、產品負責人、開發提出問題，把他們的答案塑形成正確的測試。
• 自動化黃金流程/經常使用路徑的測試；稍後增長負面測試和邊界測試。
• 若是一個應用關注安全性，增長負面測試是必要的；
• 在迭代計劃會議上，須要評估測試時間，確保迭代按計劃發佈安全可靠的應用

三、進行面對面溝通

• 敏捷測試人員和開發，產品負責人，業務表明甚至用戶，面對面溝通

四、勇氣

• 有勇氣避免等待全部功能代碼完成再測試，有勇氣推進敏捷轉型，一個用戶故事一個用戶故事測試。
• 有勇氣踐行測試先行，推動測試自動化和持續集成，不管是自動化單元測試，仍是自動化其餘各類類型測試，每一個迭代持續積累自動化測試腳本。
• 有勇氣容許犯錯，從而持續改進。
• 有勇氣說咱們，而不是說我，說你。

五、簡單化

• 從簡單着手，開發進行簡單設計編寫簡潔代碼，測試人員採用輕量的工具和技術恰到好處地進行測試。
• 對測試分層，採起必要的測試策略。

六、持續改進

• 持續改進是整個敏捷團隊的核心，也是敏捷測試人員的核心，持續學習，持續改進，嘗試更出色的工做，只要能可持續的高效的爲用戶、客戶的創造價值、交付價值，而且提高測試的專業。

七、響應變化

• 測試人員和開發人員一塊兒適應和響應變化，在專一和變化之間找到平衡，自動化測試是一個關鍵。

八、自我組織

• 全部的產品實施交付活動都是團隊的職責，敏捷團隊貫徹敏捷測試理念，持續關注測試和自動化測試。最高優先級的問題須要整個團隊解決。

九、關注人

• 敏捷團隊成員互相尊重並承認我的成就，並有機會提升和發展各自領域的技能，也進行跨界擴展技能領域的廣度，全部人是平等的，僅僅是具備不一樣技能的人而已，整個敏捷團隊關注一個一個的用戶故事的交付，任何人只有具有相應的技能，均可以貢獻。只要測試工做獲得執行，不必定要指定某些成員爲測試人員。

十、享受樂趣

• 全部成員協做，整個團隊負責質量和測試，從而激發和珍視敏捷測試人員對工做的激情，由於從測試角度，對團隊和客戶產生了真正的價值，而不是成爲最後甩鍋對象，出現問題，被各類人逼問，爲啥測試沒有把關好，把問題測試出來？

5、敏捷過程的測試策略

由於敏捷中落地實踐最直接的是迭代，而且在迭代中是圍繞一個故事一個故事進行開發和測試：故事設計->故事開發->故事測試->故事驗收->故事上線 。

因此就能夠避免在迭代內作成小瀑布，測試人員在迭代後期等待大批量故事累積在一塊兒以後再進行測試。這樣就很好的踐行了測試左移、持續測試、測試先行的敏捷理念。

這裏的test first，是說測試先行，或者說測試動做/活動先行，而沒必要等到迭代後期測試。而TDD, Test Driven Development測試驅動開發，是開發人員先寫函數/單元的測試代碼，致使測試失敗，再寫功能代碼，讓測試經過，再重構成簡潔代碼的過程。

從用戶視角，ATDD（驗收測試驅動開發，Acceptance Test Driven Development）/BDD（行爲驅動開發，Behavior Driven Development），是整個敏捷團隊一塊兒進行的測試用例識別和測試用例自動化的方法。

那麼什麼叫作一個故事一個故事進行開發測試呢？以下圖最下邊的狀況，跨職能特性團隊進行迭代，針對每一個故事進行DBT，定義產品方案、構建開發、測試。

迭代內的進一步描述以下：

來源：《敏捷測試》

來源：《深刻敏捷測試》

6、敏捷測試和傳統測試的對比

來源：究竟什麼是敏捷測試和探索式測試？

來源：爆肝全面分享什麼是敏捷測試？

7、敏捷測試象限

來源：你被「敏捷測試四象限」矇蔽多少年了？

8、自動化測試金字塔

自從Mike Cohn在2003年提出測試自動化金字塔以後，在自動化測試領域，對測試自動化的計劃頗有幫助，咱們須要考慮在哪一層進行自動化測試。

來源：《深刻敏捷測試》

Alister Scott爲了更增強調探索性測試，在自動化測試金字塔上增長了上帝之眼（探索式測試）。

來源：《深刻敏捷測試》

Sharon Robson擴展了測試金字塔，展示了多種質量維度、工具和測試類型。

一、在右邊增長了針對測試類型和測試人員選擇出來的測試工具。

• 用戶驗收測試：透明、易安裝、易於從新運行，好比捕捉回放
• 系統：特定的活動或技術、打樁和驅動、命令行
• 單元：特定的技術，集成到持續集成環境

二、在左邊，增長了測試類型或系統屬性，保證能夠考慮到解決方案所需測試的各個方面，例如功能性、非功能性。

• 用戶交互的易用性、功能性
• 底層的可靠性、性能、易維護性

三、同時在最外圍，對任何系統屬性進行迴歸，把迴歸做爲測試的一部分來考慮。

來源：《深刻敏捷測試》

9、敏捷測試宣言

來源：http://www.growingagile.co.za...

來源：敏捷測試宣言與原則解讀

來源：老話題新解說：究竟什麼是敏捷測試？

來源：敏捷測試宣言與原則解讀

來源：老話題新解說：究竟什麼是敏捷測試？

做者：IDCF社區特約講師 趙衛