性能测试过程分类哪几个阶段？

        性能测试过程分为四个阶段：设计，构建，执行和分析、诊断和调节。如图 16-5 所示。

        四个阶段的任务分别如下：  设计阶段定义待测试的业务流程、业务的平均处理量、业务处理量的最高峰值、组合业 务流程、系统的整体用户和响应时间目标。  构建阶段涉及设置和配置测试系统及基础设施、使用自动化性能测试解决方案构建测试 脚本和负载方案。  执行阶段包括运行负载方案和测量系统性能。  分析、诊断和调节阶段主要测量系统性能并使负载测试进入下一级别，重点查找问题原 因以帮助开发工程师迅速解决问题，并实时调节系统参数以提高性能。 各阶段详细任务分别如下。

        （1）设计阶段。 设计阶段是性能测试团队与业务领域的经理合作以收集性能要求的主要业务响应时间。可以将 需要关注的问题分为四个方面：业务需求、技术需求、系统要求和团队要求。业务要求需通过业务 分析师或最终用户收集。一个全面的业务要求应该考虑以下问题：  应用程序情况：创建系统使用演示，让性能测试团队从整体上了解应用程序如何被使用。  业务流程列表：创建关键业务流程列表，以便反映最终用户在系统上执行的活动，见表 16-1。

         业务流程列表：创建 Word 文档，以便详细记录每个业务流程的正确步骤。 交易混合表：汇编业务流程中需要负载测量（如“登录”或“转移资金”等）的关键活 动的列表，见表 16-2。  

         业务流程图：创建业务流程图，以便描绘业务流程的分支情况。 技术要求应该通过系统管理员和数据库管理员（DBA）进行收集并确认。这些人员可能是企 业开发组或运营部门的成员，或同时隶属这两个部门。一个全面的技术要求应该考虑以下问题：  环境预排工作：与系统或基础设施团队开展测试架构的预排工作。  系统范围会议：举行会议来讨论系统的哪些部分应该排除在测试流程之外，并达成一致 见解。  生产图：创建生产基础设备的图表，以标记出从 QA 迁移到生产过程中可能影响性能的 因素。 收集系统的要求至关重要，这些是管控负载测试流程通过/未通过状态的系统高级目标，这些 通常与来自业务的经理合作而达成一致，一个全面的系统要求应该考虑以下问题：  系统在正常和高峰期必须支持的用户数量为多少？  系统每秒必须处理的交易量是多少？常用的一种估算方法为 80/20 原理法。 80/20 原理是指每个工作日中 80%的业务在 20%的时间内完成。每年业务量集中在 8 个月，每 个月 20 个工作日，每个工作日 8 小时，每天 80%的业务在 1.6 小时完成。 【实例】如去年全年处理业务约 100 万笔，其中 15%的业务处理中每笔业务需对应用服务器 提交 7 次请求；70%的业务处理中每笔业务需对应用服务器提交 5 次请求；其余 15%的业务处理中 每笔业务需对应用服务器提交 3 次请求。根据以往统计结果，每年的业务增量为 15%，考虑到今 后 3 年业务发展的需要，测试需按现有业务量的两倍进行。 ①每年总的请求数为： (100×15%×7+100×70%×5+100×15%×3)×2=1000 万次/年 ②每天请求数为：1000/160=6.25 万次/天 ③每秒请求数为：(62500×80%)/(8×20%×3600)=8.68 次/秒 即服务器处理请求的能力应达到约 9 次/秒。  对于所有的关键业务交易，可接受的最低和最高的响应时间是多少？ 用户社区如何连接到系统？  生产中需要承载的系统工作量如何？交易组合如何？ 最后是团队要求阶段，需要确定性能测试团队成员。提前收集完整的业务、技术、系统和团队 要求，是有效和成功地进行负载测试的基础。 （2）构建阶段。 在构建阶段，需要将设计阶段所确定的业务流程和工作量转变为用来推动可重复、真实负载的 自动化组件。可以从两个方面来关注：自动化设置和环境设置。 自动化设置包括一系列由性能工程师执行的序列任务： 第一，制作脚本：将存档的业务流程记录到自动化脚本中。 第二，交易：插入计时器来产生业务所需要的逻辑计时。 第三，参数化：用数据池来代替所有的输入数据（如登录用户名和密码），以便每个虚拟用户 使用唯一的数据访问应用程序。 第四，方案：通过为不同的用户组分配不同的脚本、连接性和用户行为来创建生产工作量。 第五，监视：确定要监视哪些负载服务器或机器。 环境设置包括组装硬件、软件和数据，这些都是执行成功及真实负载测试所必需的，这可能要 与系统人员、DBA、操作人员和业务团队协作。环境设置中最重要的是准备数据，数据来源有两 种方式：历史数据和创建数据。 ①历史数据指真实存在的数据，只要从数据库抽取出来即可。 ②创建数据则是测试过程中通过一些方法生成批量数据，创建数据的方法通常包括 UltraEdit 结合 Excel 制作数据、数据库、Shell 编程和 Java 编程等。所有创建的数据都应该满足数据模型的 要求，否则数据在调用过程中会产生错误。 构建阶段的最终结果是得到一套自动化的方案，可在配置好的可用环境中随意执行。 （3）执行阶段。 刚刚接触性能测试的人员，常常误认为执行只是一个单一事件，而事实上它是一个多步骤的流 程，包括多种类型的性能测试。每种类型的测试所提供的信息对于了解发布应用程序的业务风险都 是必不可少的。 常见的几类负载测试如下：  基线测试：用于验证系统及其周围的环境是否在合理的技术参数下运行。性能测试仅运 行 5～10 名用户来对最终用户交易性能进行基线测试，这些测试应该在性能测试流程的 开始和结束时执行，以测量绝对响应时间的提高量。  性能测试：可模拟环境中的负载，从而提供有关系统可处理多少用户的信息，这些测试 应该模拟平均和高峰时的生产用量，它们应该使用真实的用户行为（如思考时间）、调制 解调器模拟和多个浏览器类型，以获得最高的准备度，应该运行所有的监视程序和诊断 程序，以便最大限度地了解系统的性能降低和瓶颈。  基准测试：用于在理想的情况下测量和比较每种机器的类型、环境或应用程序版本的性能，这些测试是系统进行了可扩展测试后运行的，旨在了解不同架构的性能影响。  渗入测试：其目的在于长时间在负载下运行系统，从而检验系统的性能状况。  峰值测试：其目的在于模拟一段时间内系统上的峰值负载，以帮助演示应用程序和底层 硬件是否能够在合理的时间内处理高负荷。 （4）分析、诊断和调节阶段。 在完成负载测试的设计、构建和执行阶段后，项目将进入分析、诊断和调节阶段，这些阶段是 实时和反复进行的，负载测试解决方案应该提供有关最终用户、系统级别和代码性能数据的全面信 息，同时查找导致性能降低的可能原因，这些信息能使你确定是否已经达到性能目标。 在监控、分析、诊断和调节过程中可以获取大量的信息：  监控：性能测试过程中的监控可显示基础设备每个层上所发生的一切，同时会更清晰地 提供有关测试中数据库服务器、Web 服务器、应用程序服务器、单个应用程序或流程的 信息。监控可快速获取有价值的信息，例如应用程序服务器的处理器（CPU）只能支持 150 名用户并发，远低于目标值。  分析：完成负载测试后，可将各种指标（如虚拟用户、CPU 或服务器 CPU）关联起来， 以获取有关应用程序行为不端的其他信息。  诊断：高效的性能测试解决方案应该向性能工程师提供有关层、组件、SQL 语句是如何 影响负载条件业务流程整体性能的单个统一视图，性能工程师应该能够看到由最终用户 交易所接触到的所有组件，然后确定各组件使用的处理时间及调用的次数。有了这些信 息，就可以针对 Web 服务器、应用程序和数据服务器瓶颈进行调优。  调节：许多企业都在应用程序部署前、中和后三个阶段进行自动化性能测试。有些自动 化性能测试解决方案可系统地识别并分离基础实施性能瓶颈，然后通过修改系统配置设 定来解决它们，通过反复解决基础设施瓶颈，可以不断改进配置。