与传统开发过程相比，
敏捷开发能够更好、更快的提供潜在可发布版本，同时需求的变化对产品带来的冲击也降到了最小。那么如何更好，更有效的在这种快速迭代，快速集成的开发思想下做
性能测试也成了大家研究的方向，综合了很多大牛的思想和我对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来评估潜在可交付版本的性能。
最新内容请见作者的GitHub页：http://qaseven.github.io/
