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

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

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

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

图一：性能测试周期

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

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

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

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

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

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

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

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

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

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