1.4　性能测试的基本流程

通常情况下，性能测试一般会经历如图1-4-1所示的多个阶段，这些阶段可以和很多性能测试工具对应起来，比如分析性能测试结果可以用LoadRunner的Analysis工具来实现。

1.4.1　性能需求分析

·　熟悉被压测系统的基本业务流程，明确此次性能测试要达到的目标，与产品经理、业务人员、架构师、技术经理一起沟通，找到业务需求的性能点。

·　熟悉系统的应用架构、技术架构、数据架构、部署架构等，找到与其他系统的交互流程，明确系统部署的硬件配置信息、软件配置信息，把对性能测试有重要影响的关键点明确地列举出来，一般包括如下：

　用户发起请求的顺序、请求之间的相互调用关系。

　业务数据流走向、数据是如何流转的、经过了哪些应用服务、经过了哪些存储服务。

　评估被压测系统可能存在的重点资源消耗，是I/O消耗型、CPU消耗型，还是内存消耗型，这样在压测执行时可以重点进行监控。

　关注应用的部署架构。如果是集群部署，压测时需要关注应用的负载均衡转发是否均匀，每台应用服务器资源消耗是否大体一致。

　和技术经理一起沟通，明确应用的并发架构是采用多线程处理还是多进程处理，重点需要关注是否会死锁、数据是否存在不一致、线程同步锁是否合理（锁的粒度一般不宜过大，过大时可能会影响并发线程的处理）等。

·　明确系统上线后可能会达到的最大并发用户数、用户期望的平均响应时间以及峰值时的业务吞吐量，并将这些信息转化为性能需求指标。

1.4.2　制定性能测试计划

性能测试计划是性能测试的指导，是一系列测试活动的依据，在制定性能测试计划时，需要明确系统的上线时间点、当前项目的进度以及所处的阶段、可以供调配的硬件资源和性能测试人员。一个完整的性能测试计划一般包括如下几个部分：

·　性能测试计划编写的目的：主要是作为整个性能测试过程的指导，让性能测试环境搭建、测试策略的选取、任务与进度事项跟踪、性能测试风险分析等事项有序地进行，同时也需要明确此次性能测试预期需要达到的标准，以及明确性能测试完成而退出测试所需的条件。

·　明确各个阶段的具体执行时间点以及对应的责任人：

　预计由谁何时开始性能需求分析，何时结束性能需求分析。

　预计由谁何时完成性能测试方案的编写，何时结束性能测试方案的编写。

　预计由谁何时完成性能测试案例的编写，何时结束性能测试案例的编写。

　预计由谁何时开始搭建性能测试环境，何时结束性能测试环境的搭建。

　预计由谁何时开始准备性能测试需要的数据，何时准备完毕。

　预计由谁何时开始编写性能测试脚本，何时编写完毕。性能测试脚本的编写一般包含如下步骤：

◆　按照性能测试场景，开始录制性能测试脚本或者直接编写性能测试脚本，此时可能用到的常见性能测试工具包括LoadRunner、BadBoy、JMeter、nGrinder等。

◆　根据准备好的测试数据，对性能测试脚本进行参数化，添加集合点、事务分析点等。

◆　对性能脚本进行试运行调试，确保不出现报错，并且可以覆盖到测试场景中所有操作。

　预计由谁何时开始性能测试的执行，何时完成性能测试的执行，此阶段一般需要完成如下事项：

◆　完成每一个性能测试场景和案例的执行，记录相关的性能测试结果，明确性能曲线的变化趋势，获取性能的拐点等。

◆　根据性能测试的结果，评估性能数据是否可以满足预期，从性能测试结果数据中分析存在的性能问题。

◆　针对性能问题，进行性能定位和优化，然后进行二次压测，直至性能数据可以满足预期，性能测试问题得到解决。

◆　完成性能测试分析报告的编写。

·　性能测试风险的分析和控制：评估可能存在的风险和不可控的因素，以及这些风险和因素对性能测试可能产生的影响，针对这些风险因素需要给出对应的短期和长期的解决方案。性能测试风险一般包括如下：

　性能测试环境因素：无法预期完成性能测试环境的搭建，这中间的原因可能是硬件引起也可能是软件引起，硬件原因一般可能包括性能压测服务器无法按时到位、服务器硬件配置无法满足预期（一般要求性能压测服务器硬件配置等同于生产环境，服务器的节点数可以少于生产环境，但是需要保证每个应用服务至少部署了两台节点服务器）。软件原因可能包括性能测试环境软件配置无法和生产环境保持一致（一般要求性能压测环境软件配置，比如软件版本、数据库版本、驱动版本等要和生产环境完全保持一致）。

　性能测试人员因素：性能测试人员无法按时到位参与项目的性能测试，如果出现这样的风险，肯定会导致性能测试无法预期进行，需要立即向项目经理进行汇报，以确保可以协调到合适的人员，因为这是一个非常严重的风险。

　性能测试结果无法达到预期：即系统的性能无法达到生产预期上线要求或者存在性能问题无法解决。性能调优其实本身就是一个长期不断优化的过程，此时可以看是否通过服务器的横向或者纵向扩容来解决，如果还是无法解决，那么也需要提前上报风险。

1.4.3　编写性能测试方案

在有了性能测试计划后，我们就需要按照性能需求分析的结果来制定性能测试方案，即按照什么样的思路和策略去测试、需要设计哪些测试场景以及测试场景执行的先后顺序、每个测试场景需要重点关注的性能点等，一般包括如下：

·　测试场景的设计

　单场景设计：单一业务流程的处理模式设计。

　混合场景设计：多个业务流程同时混合处理模式的设计。

·　定义事务：测试方案中需要明确定义好压测事务，方便分析响应时间（特别是在混合场景中，事务的定义可以方便分析每一个场景响应时间的消耗）。比如我们对淘宝网购买商品这一场景进行压测，可以把下订单定义为一个事务，把支付也定义为一个事务，在压测结果中，如果响应时间较长时，就可以对每一个事务进行分析，看哪个事务耗时最长。

·　明确监控对象：针对每个场景，明确可能的性能瓶颈点（比如数据库查询、Web服务器服务转发、应用服务器等）、需要监控的对象，比如TPS、平均响应时间、点击率、并发连接数、CPU、内存、IO等。

·　定义测试策略：

　明确性能测试的类型：需要进行哪些类型的性能测试，比如负载测试、压力测试、稳定性测试等。

　明确性能测试场景的执行顺序，一般是先执行单场景，后执行混合场景测试。

　如果是进行压力测试，还需要明确加压的方式，比如按照开始前5分钟，20个用户，然后每隔5分钟，增加20个用户来进行加压。

·　性能测试工具的选取：

　性能测试工具有很多，常见的有LoadRunner、JMeter、nGrinder等，那么如何来选取合适的性能测试工具呢？

　一般性能测试工具都是基于网络协议开发的，所以我们需要明确待压测系统使用的协议，尽可能和被压测系统的协议保持一致，或者至少要支持被压测系统的协议。

　理解每种工具实现的原理，比如哪些工具适用于同步请求的压测，哪些工具适用于异步请求的压测。

　压测时明确连接的类型，比如属于长连接还是短连接、一般连接多久能释放。

　明确性能测试工具并发加压的方式，比如是多线程加压还是多进程加压，一般采用的都是多线程加压。

·　明确硬件配置和软件配置：

　硬件配置一般包括：服务器的CPU配置、内存配置、硬盘存储配置、集群环境下还要包括集群节点的数量配置等。

　软件配置一般包括：

　操作系统配置：操作系统的版本以及参数配置需要同线上保持一致。

　应用版本配置：应用版本要和线上保持一致，特别是中间件、数据库组件等的版本，因为不同版本，其性能可能不一样。

　参数配置：比如Web中间件服务器的负载均衡、反向代理参数配置、数据库服务器参数配置等。

·　网络配置：一般为了排除网络瓶颈，除非有特殊要求外，通常建议在局域网下进行性能测试，并且明确压测服务器的网卡类型以及网络交换机的类型，比如网卡属于千兆网卡，或者交换机属于百兆交换机还是千兆交换机等，这对我们以后分析性能瓶颈会有很大的帮助，在网络吞吐量较大的待压测系统中，网络有时候也很容易成为一个性能瓶颈。

1.4.4　编写性能测试案例

性能测试案例一般是对性能测试方案中性能压测场景的进一步细化，一般包括如下：

·　预置条件：一般指执行此案例需要满足何种条件，性能测试案例才可以执行。比如性能测试数据需要准备到位、性能测试环境需要启动成功等。

·　执行步骤：详细描述案例执行的步骤，一般需要描述包括测试脚本的录制和编写、脚本的调试、脚本的执行过程（比如如何加压、每个加压的过程持续多久等）、需要观察和记录的性能指标、需要明确性能曲线的走势、需要监控哪些性能指标等。

·　性能预期结果：描述性能测试预期需要达到的结果，比如TPS需要达到多少、平均响应时间需要控制到多少以内、服务器资源的消耗需要控制在多少以内等。