在集成敏捷性能测试之前需要考虑的因素

　　为了更详尽地了解如何将性能测试集成到敏捷流程，我们将分析性能测试中需要考虑的一些关键因素。

　　服务级别目标

　　服务级别目标 (SLO) 可推动敏捷环境中性能规划要求的设定。通过SLO，业务和 IT 经理就应用程序业务吞吐量、响应时间、并发支持用户数和影响最终用户体验的其他因素等要求达成一致意见。在应用程序投入生产环境之前，必须满足这些要求（这些要求将成为应用程序待完成工作的一部分）。

　　这些示例设定了应用程序的要求，而这些要求反过来定义验收标准，并推动测试脚本的编写。从一开始，应用程序所有者和利益相关者就应该关注应用程序性能方面的问题。他们确定这些 SLO 要求的优先顺序。例如，对应用程序（甚至扩展到业务）影响最大的那些要求在开发过程中的优先级更高。

　　例如，应用程序所有者可能提供下面的用户案例：“作为用户，我想在两秒钟内刷新我们网站的所有页面，以便我可以将更多的时间用于提高我们网站的生产率。”下面是另一个示例案例：“作为一个应用程序所有者，我想让此应用程序一次支持多达 100,000 个用户，而不会使应用程序性能降级，因此，我可以向我公司全球的所有员工推用此应用程序。”

　　关注性能测试

　　SLO 介绍了应用程序的预期行为。但在实际中，开发和测试团队及业务部门总是在了解应用程序在生产环境中的性能之后才知道应用程序的准确要求。鉴于此，敏捷流程依靠生产可用性生命周期 (PAL) 来了解应用程序在现实中的实际性能。来自生产环境的反馈有助于开发人员和测试人员将精力投入到应用程序的特定问题领域，从而在短暂的sprint 周期内增加资源投入。

　　这是敏捷开发过程中非常重要的一个步骤。它可为开发人员和测试人员提供实际的度量标准和使用趋势。然后，在开发下一版本的应用程序时，就可以将这些问题考虑进去。现实的度量标准可推动效果更好的测试 — 最终交付质量更高的软件。

　　测试数据准备

　　在敏捷环境中，一个 sprint 比较短暂 — 通常只有两到四周 — 因此测试时间也很短。这会使下面的操作更加重要：将测试数据准备纳入规划阶段，以便有足够的时间进行性能测试。测试数据准备可在业务线 (LOB) 或一些其他业务领域（在这些领域中，对数据保护和私密性进行测试非常重要）的指导下完成。例如，利益相关者可能想要屏蔽数据集合，以保护机密客户或员工信息的私密性。

　　越早进行测试数据准备，可用于测试的时间就越多。因此，在规划阶段，性能测试人员应该与利益相关者协作，以准备测试和测试数据。这种协作是在相对较短的 sprint 中完成大量工作的关键因素之一。必须同时开展不同类型的工作。

　　在这种情况下，敏捷软件开发有点像即时 (JIT) 制造。您可以根据需求进行详细规划，然后在需要时增加资源。

　　发展趋势

　　在敏捷环境中，应用程序所有者能够在各个连续的 sprint 中看到应用程序不断改进，这点很重要。他们想看到符合期望的发展趋势，那就是，应用程序的每次迭代都要比上一版本更好。

　　这使得根据 SLO 要求监控应用程序性能发展趋势变得更加重。发展趋势报告将允许您让利益相关者定期看到性能改进的状况概要，最好是表明性能稳步提高，或性能至少没有降级。此外，通过查看发展趋势报告，您不必对每次测试运行的分析数

　　据进行研究。

　　可重复使用和共享的测试资产要加速测试和开发进度，敏捷流程应该充分利用可重复使用和共享的测试资产库。此测试脚本库可为虚拟开发团队的每个人（包括基于外包业务的合同工）提供对相同测试资产的访问权限。

　　对于其他优势，此库可提供“全天候式”测试带来的高效率。可以在一个地理区域中一天内任何时间创建测试脚本，然后将其提供给另一个地理区域内的测试人员，这些测试人员将在其工作日当天运行此测试。

　　在测试周期时间有限时，重复使用和共享资产的功能对于敏捷开发变得越来越重要。它可以实现在可用的时间范围内完成更多的工作。

　　自动化测试

　　使用自动化测试工具可以加速性能测试过程。在开发人员没有更改测试的代码时，通过正确部署此软件，您可以创建脚本、使其可重复使用，然后规划在下班时间内的测试运行。这样可以用更少的时间获得更高质量的软件。

　　自动化测试可帮助您在时间紧迫（两周到四周）的 sprint 内实现回归和性能测试目标。在交付构建 (build) 以待测试之前，考虑到开发人员通常要占用 60% 的 sprint 时间，这没有为测试留下许多时间，此时自动化测试变得更为重要。

　　持续分析

　　在敏捷流程中，持续分析非常重要。贡献者（scrum 术语称为“猪”）和利益相关者（scrum 术语称为“鸡”）需要密切关注项目进度，特别是针对应用程序功能和性能时。为了向他们提供所需的视图，性能分析应该是持续且全面的。此持续分析有助于找出应用程序中的所有问题方面。

　　将对 scrum 日常工作的所有内容进行分析，其中包括 IT 基础设施和性能测试人员，作为贡献者和应用程序利益相关者。贡献者是参与每日 scrum 工作的 sprint 团队的活动成员，为所有利益相关者提供最新的开发状况信息。在所有相关的团队成员都知道每个sprint 的性能后，他们就能够更好地履行职责，确保整个应用程序的高质量。越快发现问题，就能越快解决问题。

　　组件测试

　　在敏捷环境中，并不是每个 sprint 都有端到端应用程序。这使能够仅对应用程序的某个部分或组件进行测试变得非常重要。挡板程

　　序提供了一种测试组件的方法。挡板程序模拟尚未编写或不可用的应用程序部分。如果应用程序使用外部的第三方数据源 — 通常出现在 Web 2.0 世界中 — 则性能测试人员和质量保证 (QA) 专家需要挡板程序，因为他们无法将负载添加到第三方生产服务器中。

　　通过对每个 sprint 内部的组件进行性能测试，您可以帮助推进开发过程，以产生端到端性能良好的高质量应用程序。

　　最后检查

　　在敏捷流程中，增强 sprint 是可选的最后一步。这一 sprint 专用于最终检查，如最后一轮测试、端到端性能检查和用于验证 SLO 符合性的测试。虽然它可以找出需要解决的问题，但是，在应用程序投入生产中之前，此增强 sprint 确实可以提供每个人对应用程序的信心。如果所有部署均已完成 — 并且使性能测试成为整个敏捷 SDLC 的一部分 — 您应该不会感到意外。此增强 sprint 不应该是首次执行性能测试。（wy）