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