设计

　　这是性能测试团队向业务部门搜集性能需求的主要阶段。需求可以被认为分为四个方面—业务，技术，系统和团队需求。

　　业务需求一般通过与主题专家（SME,subject matter expert）的会议来搜集。这些人可以是业务分析师和最终用户。当下面内容准备好后，一套全面的业务需求就形成了：

　　应用概要：系统用法的演示使得性能团队得到更高层次的理解，应用是如何被使用的。
　　业务过程列表：最终用户在系统上所执行的关键业务过程列表。
　　业务流程：Word文档，详尽记录每个业务过程的精确步骤和屏幕。
　　事务列表：业务过程中关键活动的列表—例如登录或转移资金—需要在负载下测量。
　　业务过程图：业务流程图说明业务流程的分支条件。
　　技术需求可以通过与系统管理员和数据库管理员（DBA）的会议来搜集。这些人可以隶属于开发或运营部门，或者隶属于两者。一套全面的技术需求仅当以下内容齐备时完成：

　　环境评审：按照测试体系结构由系统或基础设施组进行走查评审。
　　系统范围的会议：召开会议，讨论和确认在测试过程中系统需要排出的部分。
　　生产图：一个生产基础设施图，用于说明测试与生产环境的差异，当从QA向生产迁移时可能对性能造成影响。
　　最后，重要的是，必须收集系统需求。这些是系统的高层次目标，决定着负载测试过程的通过/失败状态。这些一般在与LOB的项目经理工作中达成一致。系统需求包括对以下问题的回答：

　　系统在正常和最高峰时期必须支持多少用户？
　　每秒钟它必须处理多少个事务？
　　对于可业务关键事务最大和最小可接受的响应时间是多少？
　　用户群体如何联系？
　　生产中系统承受的工作负载是什么？以及混合的事务？
　　团队需求是进展到构建阶段前需要解决的最后一个问题。这只不过是决定适合的性能团队成员来参与到未来的负载测试。最初，这也许被自动的确定（例如，当只有一个团队）。然而，如果性能测试成为卓越中心（CoE）的一部分，那么资源分配，内部后勤就应该在设计阶段考虑和解决。

　　预先收集一套完整的业务，技术，系统，和团队需求是使负载测试有效和成功的基础。

构建

　　构建阶段将在设计阶段确定的业务过程和工作负载转变为自动化组件，这部分可以驱动可重复的，实际的负载。这可以分为两个方面：自动化设置和环境设置。自动化设置是由性能工程师完成的一系列连续的工作。

　　脚本：将确定的业务过程记录为自动脚本。
　　事务：插入定时器来产生业务所需的逻辑计时。
　　参数化：用一个池替代所有的输入数据，例如ID和密码，这样每个虚拟用户用唯一的数据访问应用。
　　场景：通过给用户组分配不同的脚本，连通性和用户行为等方法，创建生产工作负载。
　　监测器：确定负载下所要监控的服务器或机器。
　　环境设置由执行成功，现实的负载测试所需的硬件，软件，和数据组成。这些可能涉及到系统，DBA，运营和业务团队。

　　构建阶段的最终成果就是可以执行在可用的，已配置的环境上的一系列自动化“资产”。

 执行

　　对于刚接触性能测试的新手来说，经常存在一个误解，就是执行是一个单一事件。实际上，它是一个由多种类型的性能测试组成的多步骤的过程。每种测试都提供了理解发布应用所带来风险的必要信息。负载测试的类型包括：

　　基线测试验证了系统和其周围环境可在合理的技术参数下运行。性能测试按5到10个用户执行，作为最终用户事务性能的基线。这些测试应该在性能测试的开始和结束时执行，来测量响应时间的绝对改进。
　　性能测试在环境中模仿负载，并确定系统可以支撑的最佳和最大用户数量。这些测试应该仿效平均和峰值时间的生产用法，他们应当最大限度地仿真用户的真实行为，例如思考时间，调制解调器的仿真，和各种类型的浏览器。同时，采用其它专用的监控和诊断工具，有效地查看系统内部行为，诊断系统衰变和瓶颈。
　　基准测试被设计来测量和对比理想情况下的各种机器类型，环境，或应用的版本。当系统经过扩展性测试后，执行这些测试可以帮助了解不同体系结构的影响。
　　渗透测试被设计用于在长时间的负载下检测系统的执行情况。
　　峰值测试被设计用于模拟系统在峰值负载下运行一段时间来保证应用和其硬件可以在合理的时间段内支持高负载分析，诊断，和调整
　　如何确定性能测试的 ROI
　　良好的性能测试的ROI有双重意义：

　　缓解风险保证项目达到正确的扩展性和性能。缓解风险是标准的性能测试好处。大多数自动化性能测试的用户可以向开发部门或项目团队反馈清晰的，可量化的信息，预测系统在生产环境的扩展和性能情况。
　　性能最优化以量化方式改善系统的性能，通过测量改进的最终用户响应时间，或者通过减少所需的全面硬件基础设施
如何优化性能
　　在性能测试后的阶段中，提供了很多有利于改善系统性能的有价值信息。

　　监测性能测试期间的监测显示出基础设施中每一层发生的情况，在性能测试期间提供了数据库服务器，Web服务器，应用服务器，或单独的应用和过程的更加清晰的记录。例如，这些信息可以快速表明应用服务器的CPU使用率在200用户的时候达到100%，而不能达到300用户的目标。这意味着要么需要更多的应用服务器容量要么需要优化应用自身。
　　分析：在负载测试完成之后，用户可以关联分析—例如创建虚拟用户对抗CPU或应用服务器CPU到Web服务器—来测定应用行为更深一层次的信息。
　　调整：许多公司在应用部署的前中后期使用压力测试工具来实施自动化性能测试。同时可以采用其它工具允许用户通过修改系统配置设置系统地识别，隔离，和解决基础设施的性能瓶颈。通过反复实施解决基础设施的瓶颈的过程，用户可以建立当前最优的黄金配置。
　　诊断：当前的技术可以允许，性能工程师在负载条件下对各个层，组件和SQL语句如何影响整个业务过程性能有一个统一的认识。诊断时，性能工程师使用诊断工具可以看到最终用户事务当前涉及到的所有组件。此外，用户也可以看到每一个组件花费的时间和被调用的次数。依靠这些信息，项目和QA经理可以定位到最重要的Web，应用，和数据库服务器瓶颈，集中资源来改善用户体验。它为开发者提供了如此有效的实际数据以至于用户把它称为“性能测试的圣杯。”
　　良好的性能测试涉及到哪些人？
项目经理
　　协调多个性能项目，管理测试进度，获得必要的硬件或软件，处理资源和资金问题。
业务分析师
　　负责从业务的角度对系统性能作出评价和结论。帮助开发性能测试中的混合事务和期望时间。
性能经理
　　负责协调性能支持团队的工作，作为小组的联系人。负责管理日常性能工作。
性能测试人员
　　负责创建和执行自动测试和收集测试结果。
应用构造师
　　接受负载测试的诊断和分析的信息，来最优化应用性能和解决性能问题。
基础设施专家：DBA,网络管理员，系统架构师
　　接受负载测试调整和分析的信息，来最优化应用性能和解决性能问题。