qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

敏捷开发(Agile)中的性能测试

与传统开发过程相比,敏捷开发能够更好、更快的提供潜在可发布版本,同时需求的变化对产品带来的冲击也降到了最小。那么如何更好,更有效的在这种快速迭代,快速集成的开发思想下做性能测试也成了大家研究的方向,综合了很多大牛的思想和我对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

posted on 2014-02-11 10:39 顺其自然EVO 阅读(544) 评论(0)  编辑  收藏 所属分类: 敏捷测试


只有注册用户登录后才能发表评论。


网站导航:
 
<2014年2月>
2627282930311
2345678
9101112131415
16171819202122
2324252627281
2345678

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜