與傳統開發過程相比，
敏捷開發能夠更好、更快的提供潛在可發布版本，同時需求的變化對產品帶來的沖擊也降到了最小。那么如何更好，更有效的在這種快速迭代，快速集成的開發思想下做
性能測試也成了大家研究的方向，綜合了很多大牛的思想和我對Agile開發的理解，做一個個人總結：
性能測試的階段：每個Sprint
在Sprint Planning之初，首先需要明確需要性能測試的Story，定義可量化的性能測試目標，然后添加性能測試的任務，性能測試是否需要單獨創建user story要依產品而定：
1. 對于即刻發布的版本（以
移動應用為例）：最好在將性能測試與user story放到一塊，這樣才能更好地track user story的是否可交付（是否做完性能測試）。
2. 對于周期長，潛在可發布版本不會立即到用戶手中的項目：建議單獨為性能測試創建user story。原因之一是這種項目比較龐大，各個user story之間的集成比較復雜，同一個性能測試關聯的user story非常多，單獨創建能夠更清晰，也不會影響user story的commit。
測試對象：由于一個個的story相對獨立，所以測試的對象可以是小到一個個函數或接口，達到一一個端到端的場景（這種情況下需要考慮其他模塊或第三方軟件對性能的影響）。
測試的執行：對與單個的性能測試任務，流程基本和傳統性能測試相同，但整個流程需要對該story的每一個改動后的可測版本執行：
1. 定義性能場景
2. 選取監控指標（可參考Acceptance Criteria）
3. 模擬負載（可以通過自動化腳本和工具產生）
4. 收集數據和生成報表。
驗收：主要是參照sprint planning中定義的性能acceptance criteria來評估潛在可交付版本的性能。
版權聲明：本文出自 AlvinXu 的51Testing軟件測試博客：http://www.51testing.com/?554494