敏捷開發：1.敏捷型方法是「適配性」而非「預設性」。重型方法試圖對乙個軟體開發專案在很長的時間跨度內作出詳細的計畫，然後依計畫進行開發。這類方法在計畫制定完成後拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。2.敏捷型方法是「面向人」的(people-oriented) 而非「面向過程」的 (process-oriented)。 它們試圖使軟體開發工作順應人的天性而非逆之。它們強調軟體開發應當是一項愉快的活動。
我認為以上兩個特點很好的概括了敏捷開發方法的核心思想：適應變化和以人為中心。
敏捷開發其實借鑑了大量軟體工程中的方法。迭代與增量開發，這兩種在任何一本軟體工程教材中都會被提到的方法，在敏捷開發模式中扮演了很重要的角色。再向前追溯，我們還也可見到瀑布式與快速原型法的影子，也許還有多。 改善，而非創新。敏捷開發可理解為在原有軟體開發方法基礎上的整合——取其精華，去其糟粕。因此敏捷開發繼承了不少原有方法的優勢。「在敏捷軟體開發的過程中，我們每兩周都會得到乙個可以工作的軟體，」fowler介紹，「這種非常短的迴圈，使終端客戶可以及時、快速地看到他們花錢構建的軟體是乙個什麼樣的結果。」 敏捷開發提出了以下遵循的原則：
· 我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意。
· 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
· 經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。 · 在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。
· 圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。 · 在團隊內部，最具有效果並富有效率的傳遞資訊的方法，就是面對面的交談。 · 工作的軟體是首要的進度度量標準。
· 敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持乙個長期的、恆定的開發速度。
· 不斷地關注優秀的技能和好的設計會增強敏捷能力。 · 簡單是最根本的。
· 最好的構架、需求和設計出於自組織團隊。
· 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。 敏捷測試流程總結：
在敏捷方法中，xp方法強調測試在整個專案開發過程中的重要性。針對敏捷開發方法的敏捷測試不同於以往針對傳統開發模式的測試,在敏捷團隊中,測試是整個專案組的「車頭燈」，它告訴大家現在到哪了，正在往哪個方向走。測試員為專案組提供豐富的資訊，使得專案組基於這些可靠的資訊作出正確的決定。不僅是測試員要保證質量，而是整個專案組的每乙個人都要對質量負責。測試員不跟開發人員糾纏錯誤，而是幫助他們找到目標,共同為達到專案的最終目標而努力。敏捷測試也需要高度迭代工作、頻繁得到客戶的反饋，需要動態調整測試計畫、測試的執行。並且，敏捷測試人員參與到了更多的敏捷生產活動中，積極的影響了團隊做出的決定和計畫。
根據公司專案目前採用的敏捷開發模式，相應的敏捷測試建議採用以下流程： 1. 驗證需求和設計
需求和設計具體來說一般包括：（1）由專案經理根據需求文字而編寫的功能設計文字（functional design specification）；（2）由開發人員根據功能文字而編寫的實施設計文字（implementation design specification）包括(architecture document, project scope statement, use case )。作為測試人員，審核重點是檢查文字對使用者需求定義的完整性、嚴密性和功能設計的可測性.
在測試初期，測試人員要學會做靜態測試，做好需求分析，做好對設計邏輯的分析。測試人員要更多的思考需求的可實現性，將自身作為第一使用者積極參與專案和系統的需求分析，設計和開發。積極地參與前期工作，並迅速反饋給設計和開發其靜態測試結果。要盡早的開始測試，不要等待到功能完全做好才開始。
產出物:測試需要提交評審結果文件,可以讓測試更多的參與db design,框架的評審中來 2. 測試計畫，測試用例 2.1 編寫計畫、測試用例
在敏捷開發的過程中由於是根據每個user story來估算時間的。開發人員將對本次迭代所需要的完成的user story進行評估。開發人員可以和客戶直接溝通，來確定每個user story的優先順序。 好處：
客戶可以很清楚的了解到哪些user story需要花費多長的時間，以及他們的優先順序。
問題：
在user story的時間估算上，開發人員常會估算過少。引起版本無法按時發布或者必須進行加班才能進行發布。 分析：
開發人員估算某個user story編碼的時間需要1.5天，開發人員自己估算了其他時間為半天。於是開發人員給的估算時間是2天。
開發階段實際的花費時間如下，每天花費開例會的時間。在例會中專案的其他成員需要技術上的支援。於是髮費了3個小時進行幫助。在開發的過程中遇到了一些沒有預見到的問題，結果解決問題花費了4個小時。（也許更多）。需要處理一些公司突發性的事務等等。
所以非常建議大家在估算時間上能充分的考慮到以外的因素，某本xp相關的書上寫到，在時間估算上最好的時間是編碼時間的2－3倍。聽起來很嚇人，但是實際的過程中，的確需要這麼多的時間。 測試人員根據已審核通過的需求和設計編制測試計畫，設計測試用例。在前面提到的三種文字中，功能設計文字是主要依據。測試的這兩個文字也要被專案經理和開發人員審核。 2.2 測試用例的審核
為使開發人員能參與到test case的review中來，以保證tc的質量和可行性，確保測試工作的順利進行，讓開發人員迅速地了解測試的重點並給出相應的意見和建議，測試人員在出 tc的同時，應出乙份tc_matrix（test case跟蹤矩陣），其中註明tc已覆蓋了哪些features，具體每個features對應的tc的編號，這樣在測試經理和pm對tc進行 review的時候，能夠對tc的覆蓋率一目了然，對覆蓋率不足（如某個重點feature的test case不夠）的地方能夠及時給出意見。
另外，在每天早上的morning meeting上，測試人員可以簡潔地講述一下當天測試的重點部分，以及專案中存在哪些嚴重的bug，讓開發人員了解當天測試的重點是什麼，怎樣進行測試，並提出自己的意見和建議。這樣做加強了開發與測試人員的交流和溝通，使測試工作能夠更加有效，更加順利地開展。 在迭代後期測試要抽時間更新test case。 3. 實施執行測試
敏捷開發 敏捷測試
敏捷測試的定義 首先敏捷測試是敏捷的一種，原有測試定義中通過執行被測系統發現問題，通過測試這種活動能夠提供對被測系統提供度量等概念還是適用的。在傳統的測試定義上，還需要新增 敏捷測試是遵循敏捷宣言的一種測試實踐 強調從客戶的角度，即使用系統的使用者的角度，來測試系統 重點關注持續迭代的測試新開發的功...
敏捷開發，SIT測試
b 迭代結束後，在正式對外發布前，建議將歷次迭代實現的所有story再做一次測試，測試 的主體在測試人員，包括功能 非功能，並要給出測試報告。這個活動就稱為sit或發布測 試。如果story 測試 迭代sdv測試都自動化了，則本次測試主要是執行自動化用例 如前 面有測試不充分，則補充測試，以及詳細效...
敏捷開發？敏捷測試？你怎麼看？
案列 當開發人員需要對功能進行比較大的修改，估計需要兩天時間才能完成 這時測試人員反對這樣做，本來只有5天測試時間，驗收測試已經很緊張。如果再延遲兩天，測試沒法完成。而產品經理認為，你們不是在用敏捷測試方法，應該測得很快，三天應該能完成測試工作啊 敏捷測試當然不能簡單地理解測得更快，絕對不是比以前用...