敏捷開發

現今軟體產品豐富多彩， 任何產品都有其競爭與替代產品，產品釋出與更新週期也越來越短，敏捷開發正是在這樣市場環境而誕生並流行，其迭代反饋、擁抱變化的理念和方法，能夠使得團隊更能開發出符合市場和客戶的高質量軟體。在敏捷軟體開發領域，更注重的以人為核心，迭代，循序漸進的開發方法，通過一系列的方法把市場和客戶的需求和期望分散到個整個軟體的生命週期中，從而使軟體產品質量風險降低，能夠最大可能的符合市場和客戶的需求。而傳統的開發模式基於中央控制的計劃，沒有足夠的迭代和反饋理念和方法，猶如把所有錢都投資到一件事上，導致風險很大。

敏捷開發的最突出特性就是擁抱變化，需求的變動是必不可少的，每次的決定和需求的調整都是將產品開發推向更正確的方向。而在接受變化的同時，會對軟體架構、編碼、測試、文件都會造成很大影響，這就要求有嚴格的質量控制流程，否則，最終將可能使質量出現大問題。如可擴充套件性、架構、可用性、測試穩定性

敏捷測試

軟體質量概念

質量就是軟體產品對於某個（或某些）人的價值”（某個或某些人文章中統稱之為使用者），這裡麵包含兩個層次的質量含義，即“正確的軟體”及“軟體執行正確”：

• “正確的軟體”是說，一個軟體要能夠滿足使用者的需求，為使用者創造價值。此處的價值可以體現在兩個方面，即為使用者創造利潤或者減少成本。如果一個軟體能夠滿足需求的使用者群體越大、創造的利潤越大或減少的成本越大，則該軟體產品的質量越高。反之，一個產品儘管執行良好，沒有 Bug，擴充套件性很強，效能很好，但如果沒有服務的使用者人群，沒有為使用者創造價值，則這樣的軟體儘管執行良好，也無任何質量可言。
• “軟體執行正確”是說軟體沒有或很少 Bug，擴充套件性很強，效能良好，易用性高等。這樣的軟體是一個執行良好的軟體，但還不能稱之為高質量的軟體。只有在軟體符合使用者的需求的基礎上，執行良好的軟體，才是一個高質量的軟體。當然，如果軟體完全符合使用者需求，但不易使用，經常出錯，效能很差，這樣的軟體也不是一個高質量的軟體。

“正確的軟體”及“軟體執行正確”二者相輔相成，前者關係到軟體的成敗，後者關係到軟體的好壞。

敏捷測試

敏捷測試人員

在敏捷開發流程中，測試不再是瀑布試開發流程的一個環節，而是全程參與整個開發流程。測試人員應該持續的反饋、溝通、分享與學習在這個過程中。

一個良好的敏捷測試人員除了應該具備測試的基本技能，也應具有批判性思維，分析和調查技能。他們瞭解風險，對軟體中的錯誤有深刻的理解與分析，擅長探索性測試。他們有良好的溝通技巧，希望瞭解客戶在做什麼，以此更好地理解客戶的軟體需求。同時敏捷測試人員應該具有優秀的技術能力，如系統管理，資料庫，網路等等。對於程式設計能力，我個人認為還是很必要的，這樣才能與開發人員進行平等的對話，也才能知道如何與他人合作實現自動化測試。

TDD

測試驅動開發(Test-driven development TDD)，只涉及到開發者，基本流程如下：

• 增加測試新的用例
• 執行所有用例，然後檢視是否有新失敗的用例
• 開發程式碼
• 執行測試用例
• 重構程式碼
• 另一個新的測試開始，迴圈重複推進功能

• 開發人員對需求理解不準備，這意味著寫的用例也會不準確
• 通常 開發人員還是會先寫程式碼，然後再增加單元測試用例，裡面許多測試資料都是Hardcode. 不能真實反應測試場景。
• 測試狀態與錯誤資訊記錄不完整。

後來我們做了一些改進，作為測試人員我們對所有SERVICES業務邏輯是非常熟悉的，我們建立資料生成器根據實際業務場景，然後開發人員在他們測試用例引用動態生成的資料物件，我們也建立了一系列的DRIVEN, STUB 模組，去模擬真實的呼叫環境 。在這裡我想說的是，做這些事是需要時間的，所以對於一個大而且複雜，週期長的專案，這些時間成本的付出我認為是非常值得的，否則就得不償失了。更多細節，請看

ATDD

“高質量”的軟體，可以認為是：能為客戶在最少時間內，帶來最大價值的軟體。測試人員在測試軟體的時候，所有的測試標準也將圍繞這個“高質量”的衡量標準進行，一個高質量的軟體，不僅要能夠按照既定的設計良好執行，還應該是一個很好用的軟體。只有客戶能夠方便的使用軟體，軟體才能為客戶創造價值，也才能稱該軟體為一個高質量的軟體。所以測試團隊在軟體測試的過程中，要時刻站在客戶的角度思考問題，設計測試用例，以及測試產品。

這裡就不得不說Acceptance Test-Driven Development(ATDD), 在開發之前，業務人員，測試以及開發人員，甚至包括客戶一起討論需求，確定使用者想要軟體做什麼與不做什麼。然後擬定驗收標準，規劃制定驗收測試用例。這些測試用例不一定要自動化。其實在實際工作中，驗收測試用例都是最為核心功能，通常我們會把P1,P2的用例都自動化。在敏捷開發過程中，測試用例自動化的過程與開發是類似的，也是在不斷增加新功能與重構中進行的。

這種測試方法的思路就是通過積極討論挖掘需求上的細節，使使用者深入思考他們到底什麼是他們想要的，比如邊界條件，配置或者使用者操作順序等等，而不必等到測試過程中提交了一大堆BUG後才達到共識。提取的驗收標準表示為自然語言，而不是程式語言，這能使我們完全從任何技術細節與依賴中脫離而與期望值直接銜接。在自動測試框架中，我們也能慢慢理順核心的業務流程，然後使我們用例基於業務模型進行測試。

具體的實施細節，請參考下面的文件，講得非常詳細

除此以外，我們可能看到一些其它概念,比如TDR,FTDD, BDD, and STDD， 我覺得與ATDD大同小異，只是叫的名稱不同而已。