敏捷企业中的性能测试如何实现?

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

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

　　大多数企业已经以某种形式在相对的敏捷中进行性能测试。我之所以说“相对敏捷”是因为企业倾向于将性能测试看作是“不肯定的、易变化的”活动，由个人或者团队组织，对于开发团队来说既是完全隔离的，也是松捆绑的。当这个团队使用非敏捷的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”更多的增加价值。

原文转自：http://www.uml.org.cn/Test/201308222.asp