记录点点滴滴

Agile Performance Testing

上一篇 / 下一篇  2010-08-24 23:19:26 / 精华(1) / 置顶(1) / 个人分类:Agile

    AgilePerformanceTesting


    AuthorAlexander Podelko

    Article  http://www.alexanderpodelko.com/docs/Agile_Performance_Testing_STP09.pdf

     

    Over the last ten years Alexander Podelko supported major performance initiatives for Oracle, Hyperion, Aetna, and Intel in different roles including performance tester, performance analyst, performance architect, and performance engineer.

     

    Flexibility andIterative ProcessesAre Key to KeepingTests on Track

     

    敏捷软件开发包含迭代、开放协作、过程适应性,它们贯穿于整个项目生命周期。

    同样的方式也完全适用于性能测试项目,因此,我们更需要一个具备延展性的测试计划。测试计划变成了迭代的过程,涉及到与各方(DEVSADBA etc.)密切合作的迭代测试调优过程。

     

    为了达成高效的性能测试,我们通常的测试过程为:测试执行->结果分析->调优->测试执行,基本上是一个循环的过程。此时,当我们有20个测试用例时,当我们运行某一个测试后,发现了性能瓶颈(如:线程数过高),那么在我们解决该瓶颈之前,余下的测试用例可能都无法顺利进行下去。并且,为了定位该性能瓶颈,我们不得不改变测试场景。

     

    敏捷-迭代的方式可以帮助我们更快、更高效的达成目标,并且能帮助我们对被测系统更加了解。

     

    WHY THE ‘WATERFALL’ APPROACH DOESN'TWORK

     

    瀑布模型主要是一个顺序过程(并且逆向成本非常高),包括:需求、设计、编码、测试、集成、维护各阶段。在这种模式下,性能测试主要包括以下步骤:

  1. 环境准备
  2. 脚本开发
  3. 运行脚本(以被要求的组合方式)
  4. 结果分析(与需求相比较)
  5. 配合开发进行调优
  6.  

    初看觉得这是一个很成熟完备的过程了,但存在一些潜在的严重问题:

  7. 性能测试需要所有组件都准备好,只能在项目后期进行。
  8. 脚本处理存在时间风险,脚本不仅仅是“录制-回放”过程。(关联、参数化、检查点、请求逻辑等)
  9. 同时运行所有脚本会给性能调优带来困难。
  10. 运行单个或多个大型测试,只能提供很少的系统行为信息以供后续分析。
  11.  

    从以上的问题中我们可以发现,瀑布模型下的性能测试可能会给我们带来很多额外的工作量,并且性能调优也会处于项目生命周期的尾端。更不用说,大型场景或混合场景会给我们的性能调优带来很多"噪音"

     

    但是,运用"敏捷-迭代"的方式,并不是意味着需要重新定义软件开发过程,而它仅是指在我们现有的过程中发现一些提高效率的机会。

     

    TEST EARLY

     

    单元性能测试:单元可以理解为组件、服务或设备。众所周知,越接近开发生命周期尾期,变更的成本越高,那么为什么我们要等待系统集成之后才实施性能测试呢?

    主要的问题可能在于系统是一个无法分割的整体,另外,由于使用了大量第三方组件,造成系统成为黑盒。

    解决方式:解耦、Mock

     

    THE IMPORTANCE OFWORKLOAD GENERATION

     

  12. 搜集并验证需求:
    • 业务方不了解性能测试,所以无法期望从他们那获取完全准确的需求。
    • 获取需求是一个迭代的过程。
    • 需求有时来自于数据,有时只来自于估算,了解它们的可靠性是非常重要的。
  13. 确保被测系统配置正确,测试结果对生产系统有用。
    • 数据准备:真实数据、人造数据
    • 并发用户数
    • 测试环境与生产环境差异(当然是越接近越好,但“Real Life”中的行为是无法预计的)
  14. 系统洞察力:
    • 脚本录制时,ClientServer的交互过程
    • 事务计时
    • 事务对应的资源消耗
  15. 注意做好脚本关联、参数化、检查点、请求逻辑
  16.  

    TUNE AND TROUBLESHOOT

     

    一般而言,性能测试、诊断调优、容量规划都是不同的过程,如果测试计划中缺少其中任意一项,都会使得测试从一开始就变得不切实际。

     

    性能调优也是一个迭代的过程:修改->运行测试->分析结果->修改。

    但是,与功能测试缺陷管理方式不同,性能测试不太适用优先级的方式进行修复。原因如下:

  17. 性能问题可能是阻塞式的,如果不及时解决,会对后续测试产生很大影响。
  18. 环境准备代价较大。
  19. 解决问题的过程中,需要测试工程师(测试+分析结果)与开发工程师(Profile+修改代码)密切配合。
  20.  

    BUILD AMODEL

     

  21. 验证结果正确性&定位系统问题
  22. 估算系统容量
  23.  

    模型视角:

  24. 并发数-吞吐量
  25. 并发数-相应时间
  26. 并发数- CPU使用率
  27.  

    queuing model:定位性能瓶颈

    linear model:在出现性能瓶颈之前,吞吐率与CPU使用率成正比,相应时间缓慢增长。

     

    当测试环境与线上环境存在较大差异时,模型曲线可能会有巨大变化。此时,需要考虑如何将线下结果映射到生产环境。

     

    THE PAYOFF

     

    运用敏捷的最终目标是为了提高效率,在DeadLineBudgets下确保更好产品质量。


TAG:

 

评分:0

我来说两句

Open Toolbar