敏捷測試的定義
首先敏捷測試是敏捷的一種，原有測試定義中通過執行被測系統發現問題，通過測試這種活動能夠提供對被測系統提供度量等概念還是適用的。在傳統的測試定義上，還需要新增
敏捷測試是遵循敏捷宣言的一種測試實踐：
強調從客戶的角度，即使用系統的使用者的角度，來測試系統
重點關注持續迭代的測試新開發的功能，而不再強調傳統測試過程中嚴格的測試階段。
建議盡早開始測試，一旦系統某個層面可測，比如提供了模組功能，就要開始模組層面的單元測試，同時隨著測試深入，持續進行回歸測試保證之前測試過內容的正確性。
敏捷開發
人與人之間的互動是複雜的，並且其效果從來都是難以預期的，但卻是工作中最重要的方面。-- tom demacro和timothy lister
敏捷軟體開發宣言：
● 個體和互動 勝過 過程和工具
● 可以工作的軟體 勝過 面面俱到的文件
● 客戶合作 勝過 合同談判
● 響應變化 勝過 遵循計畫
雖然右項也有價值，但是我們認為左項具有更大的價值。
敏捷宣言遵循的原則：
● 我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意。
● 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
● 經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
● 在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。
● 圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。
● 在團隊內部，最具有效果並富有效率的傳遞資訊的方法，就是面對面的交談。
● 工作的軟體是首要的進度度量標準。
● 敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持乙個長期的、恆定的開發速度。
● 不斷地關注優秀的技能和好的設計會增強敏捷能力。
● 簡單是最根本的。
● 最好的構架、需求和設計出於自組織團隊。
● 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。
當軟體開發需求的變化而變化時，軟體設計會出現壞味道，當軟體中出現下面任何一種氣味時，表明軟體正在腐化。
● 僵化性： 很難對系統進行改動，因為每個改動都會迫使許多對系統其他部分的其它改動。
● 脆弱性： 對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。
● 牢固性： 很難解開系統的糾結，使之成為一些可在其他系統中重用的元件。
● 粘滯性： 做正確的事情比做錯誤的事情要困難。
● 不必要的複雜性： 設計中包含有不具任何直接好處的基礎結構。
● 不必要的重複性： 設計中包含有重複的結構，而該重複的結構本可以使用單一的抽象進行統一。
敏捷團隊依靠變化來獲取活力。團隊幾乎不進行預先設計，因此，不需要乙個成熟的初始設計。他們更願意保持設計盡可能的乾淨、簡單，並使用許多單元測試和驗收測試作為支援。這保持了設計的靈活性、易於理解性。團隊利用這種靈活性，持續地改進設計，以便於每次迭代結束生成的系統都具有最適合於那次迭代中需求的設計。
為了改變上面軟體設計中的腐化味，敏捷開發採取了以下物件導向的設計原則來加以避免，這些原則如下：
● 單一職責原則（srp）
就乙個類而言，應該僅有乙個引起它變化的原因。
● 開放-封閉原則（ocp）
軟體實體應該是可以擴充套件的，但是不可修改。
● liskov替換原則（lsp）
子型別必須能夠替換掉它們的基型別。
● 依賴倒置原則（dip）
抽象不應該依賴於細節。細節應該依賴於抽象。
● 介面隔離原則（isp）
不應該強迫客戶依賴於它們不用的方法。介面屬於客戶，不屬於它所在的類層次結構。
● 重用發布等價原則（rep）
重用的粒度就是發布的粒度。
● 共同封閉原則（ccp）
包中的所有類對於同一類性質的變化應該是共同封閉的。乙個變化若對乙個包產生影響，則將對該包中的所有類產生影響，而對於其他的包不造成任何影響。
● 共同重用原則（crp）
乙個包中的所有類應該是共同重用的。如果重用了包中的乙個類，那麼就要重用包中的所有類。
● 無環依賴原則（adp）
在包的依賴關係圖中不允許存在環。
● 穩定依賴原則（sdp）
朝著穩定的方向進行依賴。
● 穩定抽象原則（sap）
包的抽象程度應該和其穩定程度一致。
上述中的包的概念是：包可以用作包容一組類的容器，通過把類組織成包，我們可以在更高層次的抽象上來理解設計，我們也可以通過包來管理軟體的開發和發布。目的就是根據一些原則對應用程式中的類進行劃分，然後把那些劃分後的類分配到包中。
敏捷設計是乙個過程，不是乙個事件。它是乙個持續的應用原則、模式以及實踐來改進軟體的結構和可讀性的過程。它致力於保持系統設計在任何時間都盡可能得簡單、乾淨和富有表現力。
敏捷開發與敏捷測試
敏捷開發 1.敏捷型方法是 適配性 而非 預設性 重型方法試圖對乙個軟體開發專案在很長的時間跨度內作出詳細的計畫，然後依計畫進行開發。這類方法在計畫制定完成後拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。2.敏捷型方法是 面向人 的 peop...
敏捷開發，SIT測試
b 迭代結束後，在正式對外發布前，建議將歷次迭代實現的所有story再做一次測試，測試 的主體在測試人員，包括功能 非功能，並要給出測試報告。這個活動就稱為sit或發布測 試。如果story 測試 迭代sdv測試都自動化了，則本次測試主要是執行自動化用例 如前 面有測試不充分，則補充測試，以及詳細效...
敏捷開發？敏捷測試？你怎麼看？
案列 當開發人員需要對功能進行比較大的修改，估計需要兩天時間才能完成 這時測試人員反對這樣做，本來只有5天測試時間，驗收測試已經很緊張。如果再延遲兩天，測試沒法完成。而產品經理認為，你們不是在用敏捷測試方法，應該測得很快，三天應該能完成測試工作啊 敏捷測試當然不能簡單地理解測得更快，絕對不是比以前用...