你不敏捷
将软件性能工程与敏捷软件开发方法相结合。这应该很容易吧？这两种方法并非天生适合彼此。
性能工程有严谨
s 和定义的方法来定义开发周期中的非功能需求，而性能测试需要像测试系统一样的生产，具有适当的事务工作负载组合和大型数据库。当应用程序的设计和开发没有明确定义的性能和可伸缩性要求时，性能测试可能会在发布计划中引入更多时间。性能工程方法的价值在于管理风险以及设计和构建支持业务增长的高度可扩展的系统。
敏捷方法从故事和主题、定义的系统架构和所需功能的部分列表开始。团队负责人定义了由一系列 Scrum 组成的一系列发布。每个版本都会有部分特性和功能，每个scrum可能无法完成scrum中列出的所有特性，需要添加到特性积压中。时间表支配着决策，敏捷方法的价值在于将新功能快速投入生产。
挑战
企业正在为越来越大的软件开发项目采用敏捷方法。这些项目正在从以部门为中心转向以企业为中心。团队越来越大，越来越分散。系统的非功能需求变得越来越严格。最终用户体验至关重要。
我们如何在敏捷方法中实施性能工程和性能测试任务和活动？ PE/PT的引入不能违背Agile的初衷，更快、更合理地交付软件。敏捷方法的目标是生成系统的频繁工作副本，但功能不完整。每个版本都引入了功能。传统的性能测试发生在所有功能都已开发并且应用程序即将投入生产之后。
这不是关于将敏捷方法融入性能工程，而是关于使性能工程适应敏捷方法。企业正在使用敏捷来实现业务目标，该目标是加快上市速度。
绩效团队必须以与开发团队相同的方式处理项目。人们在过程中，多学科，学习和适应。性能工程师和性能测试人员/脚本人员必须非常了解性能测试过程。在敏捷性能冲刺期间，性能团队将不得不调整和适应时间线。他们将不得不与开发团队沟通性能问题，以便他们可以将修复程序放入下一个 Sprint 待办事项列表中。
将绩效条款修改为敏捷条款
为项目定义绩效主题。这是一个项目范围的消息，让每个人都知道该项目关注性能和可扩展性，并且与项目相关的风险需要 PE 任务、活动和人员。这必须传达给架构师和首席技术人员，该项目必须使用性能和可扩展性的最佳实践、技巧和技术。
性能案例——项目的性能测试、工作负载模型和测试类型。您如何将性能需求添加到故事中？
性能积压——需要执行的性能测试。发现的性能问题。当发现性能问题时，必须将其放入 scrum/release backlog 中。
Spike – 如何在发布计划和 Sprint 的上下文中执行性能测试？是否会有集中的带外性能测试集？
完成的定义——明确定义性能测试的退出标准。
敏捷团队的新角色。架构审查、代码审查、数据库审查和测试计划的性能工程师。
开发团队
由于项目已设置为性能主题，因此开发团队在开发代码/服务时必须使用性能最佳实践。设计和构建高性能系统所需的技能组合和技术必须传达给团队。一个关键的成功因素要求开发团队从一开始就将性能融入系统。这将有助于消除由于代码性能不佳而导致的返工或技术债务。 性能是设计到应用程序中的，而不是测试到应用程序中的 。如果开发团队为性能而构建，性能测试过程将会容易得多。
性能测试
发布和冲刺有多少种环境可用？是否有专门的性能测试环境准备好立即开始性能测试？环境必须准备好开始测试，以保持敏捷的价值。
PT 是否会有多轮（冲刺），以不同程度的部分功能完成执行一个或多个测试。可能有三个或更多的 PT Sprint，一旦所有功能都已完成，再加上一个最终的 PT。
一轮性能测试将在发布或冲刺结束时完成。性能团队必须充分了解可用于测试的功能。每个功能都需要开发一个或多个测试脚本，并提供支持数据。
性能测试数据库： 跟踪数据准备情况。在冲刺和发布过程中，数据库结构可能会发生变化。性能团队必须充分了解更改并了解对测试计划的影响。如果数据库更改很大，您可能必须重新加载性能数据库。这需要在项目进度表中说明。性能和开发团队应尽可能自动化数据创建过程和重新加载过程，以坚持敏捷方法的价值。
典型的性能测试项目有一个启动阶段，其中计划测试套件、识别测试用例并创建测试脚本。脚本和测试用例经过审查并准备好进行正式测试执行。在敏捷方法中，性能测试用例和性能测试脚本是一路开发的。性能团队也将使用敏捷方法。
Sprint 中的性能测试
性能计划将遵循相同的敏捷方法、前期规划、测试实验室构建（类似于架构阶段），然后是一系列冲刺，直至最终发布。工作负载将在每个冲刺中不断发展。 Sprint 应该是三周，规则是“不做任何改变”，这将是一个仅用于测量的练习。第一周是重新编码新脚本，更新测试用户配置文件，并根据需要修改数据库。然后将进行两周的测试执行，并在报告中列出问题。