求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
敏捷企业中的性能测试如何实现?
 
火龙果软件    发布于 2013-8-22,作者  张培颖 译
 

在你所在的企业中,你是那个正在做或者是已经做了段时间的敏捷的人?你是否为性能测试所困扰?是否尝试让如何让性能测试在这个新文化中运作?如果是这样的话,这篇文章就是为你而写。

在生命周期中敏捷团队执行性能测试

大多数企业已经以某种形式在相对的敏捷中进行性能测试。我之所以说“相对敏捷”是因为企业倾向于将性能测试看作是“不肯定的、易变化的”活动,由个人或者团队组织,对于开发团队来说既是完全隔离的,也是松捆绑的。当这个团队使用非敏捷的SDLC开发应用,这种情况就会倾向于不理想的状态,但是或多或少还是有用的,因为每个人都接纳了,尽管性能测试由一人管理,或者甚至是两个人,在开发之后构建。

然而,性能测试本身就是敏捷的,因为其持续不断的迭代反馈环。实践证明,每一次性能测试结果都会是三种状态之一,没有新消息、提出新问题或者是下一次性能活动通过这些提前测试的导致的状态完全确定,从而识别新的风险。图一就是一个简单,但是很有用的性能测试循环描述。

图一:性能测试周期

我通常将这幅图描述为性能测试活动、复杂的未知性和金丝估计的循环表示。

将性能测试集成到敏捷开发中并不容易

为了理解为什么集成现有的敏捷性能测试实践到敏捷开发周期中并不容易,我们首先来看一下一个普通敏捷软件开发模型。如图二所示:

图二:普通敏捷开发周期可视化描述

我一般将这幅图描述为核心敏捷活动重复周期。

相当简单不是吗?但是当企业试图集成现有的性能测试模型到敏捷开发周期的时候,事情就复杂了,敏捷开发周期是在最初没有进行性能测试的时候确立的。如图三所示。

图三:集成性能测试到现有的敏捷开发模型中

如果在看过图三之后,你认为“太难了!”那咱们得观点一致。很明显的结论就是在实现敏捷开发时集成性能测试要更有效率。不行的是,这一点只对于哪些计划但还没有开始过度到敏捷方法的企业有价值。

三种方法实现敏捷中性能测试

对于已经钟情于敏捷开发,但还没有完全集成性能测试的企业,我介绍三种方法,这些方法我都亲眼见证了不同程度的成功: on demand(按需)、on retainer(聘用)和full immersion(全部投入)。

On demand(按需)

也被看做是“卓越中心”,这个模型的功能等价于将其外包给一个内部组织。这并不是一个过渡敏捷的模型,但是这个是大多数企业试图一开始集成其性能测试到敏捷开发周期中,因为性能测试已经是敏捷转换开始之前的“on demand”模型了。

对于“On demand”模型的性能测试,要和敏捷开发周期共同运作,有几处需要处理的不同于在非敏捷开发工作。尤其是:

定期利用“On demand”服务,不仅仅是为产品发布候选版构建。

性能目标、目的、宗旨或是预算必须成为每一个用户故事的标准部分。

开发者必须对测试单元层、组件层负责。

全职的团队成员必须管理性能相关工作,包括这些没有明确提到的部分。

“On demand”在性能非常重要的情况下可能并不充分,比如开发者没有进行性能测试并在他们的水平不断调试,或者当非全职团队成员负责协调、支撑以及管理性能相关的任务。

On retainer(聘用)

“On retainer”模型通常是企业所使用的一种“On demand”和“full immersion”之间的过渡模型。因为企业没有足够的性能测试人员、性能测试环境或者是性能测试工具来支持“full immersion”模型。

在这个模型中,每一个开发项目都分配给具体的性能测试人员,但是性能测试人员会被分配给两个或者更多的开发项目。尽管这个模型为每一个项目带来了更多的性能测试专业意见以及为每个性能测试人员带来了更多的项目级知识,但是性能测试人员缺乏与团队的完全整合。结果导致性能测试人员倾向于独立工作,但是提供了周期性地提供建议和指导。为了让这个模型运作并提供比“on-demand”更多的增加价值。

性能测试人员必须能被团队随时利用,这对于项目性能发展是十分重要的。

“on demand”模型的缺陷同样适用于“on retainer”模型。此外,“on retainer”模型通常要求更多的测试人员、环境和工具,但是对于“on retainer”模型最大的原因在于不能提供增长的价值。

Full immersion(全部投入)

这是每一个敏捷企业项目团队的目标,至少如果性能对于产品价值或者是企业声誉来说很重要的话。在“Full immersion”模型中,全职软对成员要擅长交付和测试性能,并对整个开发周期的协调和管理性能相关活动负主要责任,甚至可能是整个产品生命周期。

注意我说的负主要责任,而不是唯一负责。性能人就是每一个人责任的一部分,性能专家将用其专业技能以及项目需求,主要专注于开发流程的其他方面。

企业实现“Full immersion”经常会受挫,因为没有足够拥有正确技能的人才,没有足够的测试环境,没有有效的工具来为每一个开发团队分配自己的资源。

总结

尽管性能测试的迭代性能使其内在的就是敏捷的,但是对于将性能测试完全集成到现有敏捷团队中仍旧是个挑战。这三个性能测试模型在敏捷企业中提供了一些选择,这些企业团队中包含了性能测试资源,确保性能测试在整个开发声明周期中关注需求。

相关文章

微服务测试之单元测试
一篇图文带你了解白盒测试用例设计方法
全面的质量保障体系之回归测试策略
人工智能自动化测试探索
相关文档

自动化接口测试实践之路
jenkins持续集成测试
性能测试诊断分析与优化
性能测试实例
相关课程

持续集成测试最佳实践
自动化测试体系建设与最佳实践
测试架构的构建与应用实践
DevOps时代的测试技术与最佳实践
 
分享到
 
 
     


LoadRunner性能测试基础
软件测试结果分析和质量报告
面向对象软件测试技术研究
设计测试用例的四条原则
功能测试中故障模型的建立
性能测试综述
更多...   


性能测试方法与技术
测试过程与团队管理
LoadRunner进行性能测试
WEB应用的软件测试
手机软件测试
白盒测试方法与技术


某博彩行业 数据库自动化测试
IT服务商 Web安全测试
IT服务商 自动化测试框架
海航股份 单元测试、重构
测试需求分析与测试用例分析
互联网web测试方法与实践
基于Selenium的Web自动化测试
更多...