BDD行為驅動開發

ATDD驗收測試驅動開發

TDD測試驅動開發

敏捷測試就是持續地對軟體質量問題進行及時地反饋。

傳統測試團隊如何轉型、敏捷文化下測試團隊如何建設。

敏捷測試既不是一種方法（如黑盒方法、白盒方法等），也不是一種方式（如探索式測試）。

敏捷測試中可以採用已有的各種方法，包括白盒方法、黑盒方法；在敏捷中也可以採用探索式測試（exploratory test），也可以採用基於指令碼的測試（scripted test）。

敏捷測試應該是一套解決方案、一類測試操作與管理的框架、一組實踐或由一定順序的測試活動構成的特定的測試流程。

Scrum可以理解為敏捷方法的具體實現的框架、一組實踐或具體的解決方案。

簡單地說，敏捷測試就是順應敏捷開發方法、力求達到質量和效率平衡的一系列的測試實踐。

敏捷宣言（12條原則）

1) 我們最重要的目標，是通過持續不斷地及早交付有價值的軟體使客戶滿意。

2) 欣然面對需求變化，即使在開發後期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。

3) 經常地交付可工作的軟體，相隔幾星期或一兩個月，傾向於採取較短的週期。

4) 業務人員和開發人員必須相互合作，專案中的每一天都不例外。

5) 激發個體的鬥志，以他們為核心搭建專案。提供所需的環境和支援，輔以信任，從而達成目標。

6) 不論團隊內外，傳遞資訊效果最好效率也最高的方式是面對面的交談。

7) 可工作的軟體是進度的首要度量標準。

8) 敏捷過程倡導可持續開發。責任人、開發人員和使用者要能夠共同維持其步調穩定延續。

9) 堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。

10) 以簡潔為本，它是極力減少不必要工作量的藝術。

11) 最好的架構、需求和設計出自自組織團隊。

12) 團隊定期地反思如何能提高成效，並依此調整自身的舉止表現。

敏捷測試的一些特點：

1) 敏捷測試一定是敏捷開發方法的一部分，應符合敏捷測試宣言的思想，也遵守上面所列的敏捷開發的原則，強調測試人員的個人技能，始終保持與客戶/使用者、其它成員（特別是業務人員、產品設計人員等）的緊密協作，建立良好的測試框架（特別是持續整合測試和自動化迴歸測試的基礎設施）以適應需求的變化，更關注被測系統的本身而不是測試文件（如測試計劃、測試用例等）。

2) 敏捷測試具有鮮明的敏捷開發的特徵，如測試驅動開發（TDD）、驗收測試驅動開發（ATDD），測試驅動開發的思想是敏捷測試的核心，或者說，單元測試是敏捷測試的基礎，如果沒有足夠的單元測試就無法應付將來需求的快速變化、也無法實現持續的交付。這也說明，在敏捷測試中，開發人員承擔更多的測試，這也就是我們說的，在敏捷測試中，是整個團隊的共同努力。在敏捷測試中，可以沒有專職的測試人員，每個人都可以主動去取設計任務、程式碼任務做，也可以去拿測試任務來做。在敏捷測試中，也可以像開發人員的結對程式設計那樣，實踐結對測試——一個測試人員對應一個開發人員、或一個測試人員對應另一個測試人員。

3) 敏捷測試無處不在、無時不在。在傳統測試裡也提倡儘早測試，包括需求和設計的評審；在傳統測試裡也提倡全過程測試。但在傳統測試裡階段性特徵相對突出一些，例如，需求評審，意味著先讓產品人員去寫需求，但需求文件寫好之後，測試人員再參加評審。而在敏捷測試裡，團隊每一天都在一起工作，一起討論需求、一起評審需求。在敏捷測試中，這種持續性更為顯著一些。

Scrum的敏捷測試：

1) Product Backlog （需求定義階段），在定義使用者需求時測試要做什麼？測試需要考慮客戶的價值大小（優先順序）、工作量基本估算之外，需要認真研究與產品相關的使用者的行為模式（如BDD），產品的質量需求，哪些質量特性是我們需要考慮的？有哪些競爭產品？這些競爭產品有什麼特點（優點、缺點等）？

2) Sprint Backlog（階段性任務劃分和安排），這時候需要明確具體要實現的功能特性和任務，作為測試，這時候要特別關注“Definition of Done”，即每項任務結束的要求——即任務完成的驗收標準，特別是功能特性的設計和程式碼實現的驗收標準。ATDD的關鍵一步也體現在這裡，在設計、寫程式碼之前，就要將驗收標準確定下來。一方面符合測試驅動開發思想，第一次就要把事情做對，預防缺陷；另方面持續測試和驗收測試的依據也清楚了，可以快速做出測試通過與否的判斷。

3) 在每個迭代（Sprint）實施階段，主要完成Sprint Backlog所定義的任務，這時除了TDD或單元測試之外，應該進行持續整合測試或通常說的BVT（Build Verification Test）。而且開發人員在設計、寫程式碼時都會認真考慮每一元件或每一程式碼塊都具有可測試性，因為測試任務可能由他們自己來完成。如果有專職的測試人員角色，一方面可以完善單元測試、整合測試框架，協助開發人員進行單元測試；另方面可以按照針對新實現的功能特性進行更多的探索式測試，同時開發驗收測試的指令碼。如果沒有專職的測試人員角色，這些事情也是要完成，只是由整個團隊共同完成。雖沒有工種的分工，但也存在任務的分工。

4) 驗收測試可以由自動化測試工具完成，但一般情況下，不可能做到百分之百的自動化測試。例如易用性測試就很難由工具完成。即使對效能測試，是由工具完成，但還需要人來設計測試場景，包括關鍵業務選擇、負載模式等。敏捷的驗收測試，和傳統的驗收測試不同，側重對“Definition of Done”的驗證，但基本的思想和傳統開發是一致的，任何沒有經過驗證的產品特性是不能直接釋出出去的。

敏捷測試就是符合敏捷宣言思想，遵守敏捷開發原則，在敏捷開發環境下能夠很好地和其整體開發流程融合的一系列的測試實踐，這些實踐具有鮮明的敏捷開發的特徵，如TDD、ATDD、結對程式設計、持續測試等。

敏捷測試和傳統測試的區別：

1) 傳統測試更強調測試的獨立性，將“開發人員”和“測試人員”角色分得比較清楚。而敏捷測試可以有專職的測試人員，也可以是全民測試，即在敏捷測試中，可以沒有“測試人員”角色，強調整個團隊對測試負責。

2) 傳統測試更具有階段性，從需求評審、設計評審、單元測試到整合測試、系統測試等，從測試計劃、測試設計再到測試執行、測試報告等，但敏捷測試更強調持續測試、持續的質量反饋，階段性比較模糊。

3) 傳統測試強調測試的計劃性，認為沒有良好的測試計劃和不按計劃執行，測試就難以控制和管理，而敏捷測試更強調測試的速度和適應性，側重計劃的不斷調整以適應需求的變化。

4) 傳統測試強調測試是由“驗證”和“確認”兩種活動構成的，而敏捷測試沒有這種區分，始終以使用者需求為中心，每時每刻不離使用者需求，將驗證和確認統一起來。

5) 傳統測試強調任何發現的缺陷要記錄下來，以便進行缺陷根本原因分析，達到缺陷預防的目的，並強調缺陷跟蹤和處理的流程，區分測試人員和開發人員的各自不同的責任。而敏捷測試強調面對面的溝通、協作，強調團隊的責任，不太關注對缺陷的記錄與跟蹤。

6) 傳統測試更關注缺陷，圍繞缺陷開展一系列的活動，如缺陷跟蹤、缺陷度量、缺陷分析、缺陷報告質量檢查等，而敏捷測試更關注產品本身，關注可以交付的客戶價值。在快速交付的敏捷開發模式下，缺陷修復的成本很低。

7) 傳統測試鼓勵自動化測試，但自動化測試的成功與否對測試沒有致命的影響，但敏捷測試的基礎就是自動化測試，敏捷測試是具有良好的自動化測試框架支撐的快速測試。