接口性能测试方案
1. 性能测试术语解释
1. 响应时间
响应时间即从应用系统发出请求开始，到客户端接收到最后一个字节数据为止所消耗的时间。响应时间按软件特点可以再细分，如对一个C/S软件响应时间可以细分为
网络传输时间
、
应用服务器处理时间
、
数据库服务器处理时间
。另外客户端自身也存在着
解析时间
、
界面绘制呈现时间
等。
响应时间主要站在客户端角度来看的一个性能指标，他是用户
最关心
并且
容易感知到
的一个性能指标
2. 吞吐率
吞吐率是指单位时间内系统处理用户的请求数，从业务角度看，吞吐率可以用
每秒请求数
、
每秒事务数
、
每秒页面数
、
每秒查询数
等单位来衡量。从网络角度看，吞吐率也可以用
每秒字节数
来衡量。
吞吐率主要站在服务端的角度上来看的一个性能指标，他可以衡量整个系统的处理能力。对于集群或者云平台来说，吞吐率指标反映的是服务器集群对整体能够承受的压力，该指标比用户数更容易对比。
备注：吞吐量 = 吞吐率 * 单位时间
3. 用户数
对于服务器集群或者是云平台，几乎都是多用户系统，系统能提供给多少用户正常使用，也是一个非常重要的度量指标。我们把这些用户按照使用系统的实际不同，做如下区分：
系统用户数（System Users）：
指系统能够存储的用户量
在线用户数（Online Users）：
指用户通过身份确认后，处于能正常使用状态的用户个数
并发用户数（Concurrent Users）：
指在某个时间范围内，同时正在使用系统的用户的个数
严格并发用户数（Strictly the number of concurrent users）：
指同一时刻都操作某个业务的用户数
在性能测试的过程中，我们要去模拟实际用户来发请求，但是为了向服务器产生更大的压力，我们模拟的用户操作和实际的用户操作存在一定的差异（场景：模拟用户请求比实际用户请求更频繁），而且这种模拟用户数和实际用户数也难以互相换算。所以在度量服务器集群能力时，吞吐率指标比用户数指标更实用。
2. 性能测试方法及目标
1. 性能测试方法
1.1 基准测试（Benchmark Testing）
基准测试是基于一定规模的数据量上进行但业务或按照实际比例用户操作同比例组合业务测试。目的是在于；量化响应时间、吞吐率指标，便于后续比对。
方法是做多组不同场景的测试，观察结果，抽取几个关键数据做好记录，用于以后进行性能对比和评价。
1.2 性能测试（Performance Testing）
通过模拟生产运行的业务压力量和使用场景组合，测试系统性能是否满足生产性能需求。
（1）主要目的是验证系统是否具有系统宣称的能力；
（2）需要事先了解被测系统的典型业务场景；
（3）要求在已确定的环境下运行；
1.3 负载测试（Load Testing）
通过在北侧系统上不断增加压力，直到达到性能指标，列如“响应时间”超过预订指标或者某种资源使用已经达到饱和状态
特点：
（1）主要目的是找到系统处理能力的极限；
（2）需要在给定的测试环境下进行，通常也要考虑被测系统业务压力量和典型场景，使得结果具有业务上的意义；
（3）一般用来了解系统的性能容量，或者配合性能调优使用；
1.4 压力测试（Stress Testing）
测试系统在一定饱和的状态下，列如：CPU、内存在饱和使用的情况下，系统能够处理会话的能力，以及系统是否会出现错误
特点：
（1）主要目的是检查系统处于压力情况下的表现；
（2）一般通过模拟负载等方法，使得系统的资源使用达到较高水平；
（3）一般用于测试系统的稳定性；
1.5 配置测试（Configuration Testing）
通过对被测系统的软、硬件环境的调整，了解各个不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则
特点：
（1）了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作；
（2）一般在对系统性能情况有初步了解后进行；
（3）一般用于性能调优和规划能力；
1.6 并发测试（Concurrency Testing）
通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其他性能问题。
特点：
（1）发现系统中可能隐藏的并发访问时的问题；
（2）主要关注系统可能存在的并发问题，列如
内存泄漏
、
线程锁
和
资源竞争
等方面问题；
（3）可在开发的各阶段使用，需要相关的测试工具的配合和支持；
1.7 可靠性测试（Reliability Testing）
通过给系统加载一定的业务压力（列如资源在70%-90%的使用率）的情况下，让应用持续运行一段时间，测试系统在这种条件下能否正常运行。
特点：
（1）验证系统是否能够长期有效的运行；
（2）需要在压力下持续一段时间的运行；
（3）需要关注系统运行的情况；
1.8 失效恢复测试（Failover Testing）
针对有冗余备份和负载均衡系统设计的
，可以用来检验如果系统局部发生故障，用户是否能够即系使用系统；以及如果这种情况发生，用户将受到多大程度的影响
特点：
（1）验证在局部故障的情况下，系统是否能继续使用；
（2）需指出，当问题发生时
“能支持多少用户访问”
的结论和
“采取何种应急措施”
的方案
（3）一般来说，只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试；
2. 性能测试目标（4个方面）
2.1 能力验证
在系统测试或者是验收测试时，我们需要评估系统的能力，衡量系统的性能指标。系统能力可以是容纳的
并发用户数
、
系统吞吐率
；系统性能指标可以是
响应时间
也可以选择
CPU
、
内存
、
磁盘
、
网络使用情况
特点：
（1）要求在已确定的环境下运行；
（2）需要根据典型场景设计测试方案和用例；
一般方法是：性能测试、压力测试、可靠性测试、失效恢复测试。
2.2 能力规划
评估某系统能否支持未来一段时间内的用户增长或是应该如何调整系统配置，使得系统能够满足增长的用户数的需要
特点：
（1）属于一种探索性测试
（2）可被用来了解系统的性能以及获得拓展性能的方法，例如：系统扩容规划。
系统容量可以是
用户容量
，或者是
系统吞吐量
（系统处的处理能力）。对于集群服务我们更多的是用系统吞吐率作为容量
方法是 ①先对各系统、组件进行性能测试，找出他们之间的最优配比；②再通过各个环节的水平拓展，计算出整体的扩容机配比。
一般方法是：负载测试、压力测试、配置测试。
2.3 性能调优
为了更好的发挥系统潜能，定位到系统瓶颈，有针对性的进行系统优化。
方法：在系统进行性能调优时，我们需要准备好基准测试，用以对比性能数据的变化，并反复调整系统软硬件设置，以使系统发挥最优性能。当然在系统进行优化时，我们会选取关键指标进行优化，返时可能要牺牲其他性能指标。如目标是优化想用时间，我们可能选取的策略是以空间换时间，以牺牲内存的代价或扩大缓存为代价，还需要我们再各个性能指标中找到平衡点。
一般对系统的调整包括以下3个方面：
（1）硬件环境的调整；
（2）系统设置的调整；
（3）应用级别的调整；
一般采用的方法是：基准测试、负载测试、压力测试、配置测试以及失效恢复测试。
2.4 发现缺陷
和其他测试一样，性能测试也可以发现缺陷。特别是严格并发访问时是否存在资源争夺导致的响应时间过慢，或者大量用户访问时是否导致程序崩溃。
方法是设置集合点，实现严格并发用户的访问；或者超大规模用户突发访问等这样的性能测试用例进行测试，
一般采用的方法是：并发测试
3. 业务目标的转化
3. 性能需求分析
1. 性能需求获取
1.1 功能规划说明书
1.2 系统设计文档
1.3 运营计划
1.4 用户行为分析记录
2. 性能关键点获取（4个维度）
2.1 业务分析
确定被测接口是否属于业务关键接口或先分析出关键业务以间接获取该业务所访问的接口；
2.2 统计分析
若接口系统访问行为存在日志分析记录，则直接获取日访问量高的接口；否则根据接口发布类型，选择第三方日志分析工具间接获取
（1）IIS日志分析工具：Log Parser 2.2 + Log Parser Lizard GUI
下载地址：
http://www.lizard-labs.com/log_parser_lizard.aspx
（2）Tomcat日志分析工具：AWStarts v7.3
下载地址：
http://www.awstarts.org
（3）Nginx日志分析工具：GoAccess v0.9
若IIS或Tomcat等接口应用服务器使用Nginx进行负载，则日志访问量要以负载为准，因避免接口在Nginx设置缓存（即未进行透传）而导致统计不正确
下载地址：
http://www.goaccess.io
2.3 技术分析
（1）逻辑实现复杂度高的接口（如：判断分支过多或涉及CPU/IO密集型计算等）
（2）对系统（内存、CPU、磁盘IO）以及网络IO等硬件资源耗用高的接口
备注：若接口因逻辑修改而重构，则需要重新分析
2.4 运营分析
由于运营推广活动导致日访问量突然增高的接口
备注：若运营计划调整，则需要重新分析
3. 性能指标描述
3.1 响应时间
在一般情况下，弱交互类接口平均响应时间不超过
1秒
；强交互类接口平均响应时间不超过
200ms
，且
曲线平稳
；
3.2 成功率
在一般情况下，接口响应成功率需达到
99.99%
以上；
3.3 处理能力
立项申请书明确要求
：在xx压力下（并发数）TPS需要达到YY或接口可支撑YY万实时在线访问，且
曲线平稳
3.4 系统资源
若为最佳负载，则系统CPU以及内存使用率建议区间
[50%-80%]
，否则不建议超过
50%
，且
曲线平稳
；
3.5 稳定性
在实际系统运行压力情况下，可稳定运行
N * 24（一般N >= 7）
小时。在高于实际系统运行压力1倍的情况下，可稳定运行
12
小时。
3.6 特性指标
例：Java类应用FullGC次数
<= 1次/天
4. 性能测试范围
1. 业务范围
关键业务功能点描述
2. 设计范围
网络接入层、接口层、中间件、存储层等被测组件及拓补结构描述
5. 并发数计算方法
并发数可以从用户业务和服务器2个角度来看
1. 80/x原则
适用范围：无限制
例：母亲节当天接口服务器访问量分布如下所示，如何计算当天平均并发数和高峰并发数？
通过百度统计平台：
http://tongji.baidu.com/
查看母亲节当天UV曲线分布与请求量曲线呈线性关系，如下所示：
采用微积分的思想，将每个时间点视为一个矩形，可以通过求和的方式求出整个分布图的面积，如下所示：
其实每个矩形的长度均为 1（1 小时），故求面积时只需考虑宽度，即考虑每小时请求量即可。
根据 80/X 原则，找出占据总体面积 80%的时间，选择尽可能大的点计算出占据总体面
积 80%的时间，发现点的个数是 7，意味着此时间长度占总时间长度 30%，则 80/X 原
则转换成 80/30 原则，如下所示：
故，（平均）请求数/秒 = TPS 均值 = 80% * 日请求量 / 1 天 * 30%
进一步计算出：（高峰）请求数/时 与 （平均）请求数/时 的倍数 = 最高值（中午
12 时）/ （日请求量 / 24 小时） = 486096 / （24 小时访问量之和 / 24 小时）
= 2.25
故，（高峰）请求数/秒 = TPS 峰值 = 2.25 * （平均）请求数/秒 =
2.25 * 80% * 日请求量 / 1 天 * 30% = 6 * 日请求量 / 1 天
因 UV 与请求量曲线分布呈线性关系，日请求量 = 9.25 * 日 UV
故，高峰 TPS = 6 * 9.25 * 日 UV / 1 天 = 55.5 * 日 UV / 1 天
据统计，接口请求平均响应时间为 0.5 秒，故并发数 = TPS 峰值 * 0.5
2. 公式法
适用范围：Web 类访问（访问会话需符合泊松分布）
公式（1）计算平均并发用户数：C = n * L / T
C 是平均的并发用户数；n 是 login session 的数量；L 是 login session 的平均长度；T
指考察的时间段长度。
公式（2）计算并发用户数峰值： C’≈ C+3 根号 C
C’指并发用户数的峰值，C 就是公式（1）中得到的平均的并发用户数。该公式的得出是
假设用户的 login session 产生符合泊松分布而估算得到的。
例 1：
假设有一个 OA 系统，该系统有 3000 个用户，平均每天大约有 400 个用户要访问该系统，
对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为 4 小时，在一天的
时间内，用户只在 8 小时内使用该系统。
C = 400 * 4 / 8 = 200
C’≈ 200 + 3 * 根号 200 = 242
为了更好地理解上述公式，将其转换为如下公式：
公式（3）并发用户数 = 吞吐率 * 场景业务时间 / 单位时间段
例 2：
一个 OA 系统，1 小时内有 8000 用户登录系统。用户每次登录系统，需启动登录页面，然
后输入用户名和密码，进入首页。一般情况下，用户在上述操作过程中需耗时 5 秒，且要
求从点击登录按钮到首页完全展现，需控制在 5 秒内。
分析：
吞吐率 = 8000 * 2（整个业务操作需加载 2 次页面才能完成）
场景业务时间 = 5 + 5 = 10 秒
单位时间段 = 1 小时 = 3600 秒
并发用户数（登录场景） = （8000 * 2）* 10 / 3600 = 45
通过以上方法得到业务并发数后，我们可以进一步分析业务访问了哪些接口，我们只要模
拟这些接口调用方式和调用时序就行了。
有时我们需要计算某一个或某一类接口的并发数，我们可以按如下步骤进行分析计算：
（1） 梳理出被测接口被访问的业务场景和每个业务场景访问的次数
（2） 通过上述方法计算出业务场景的并发用户数
接口并发数 = 场景 1 并发用户数 * 业务场景接口调用次数 1 + 场景 2 并发用
户数 * 接口调用次数 2 + …
6. 性能测试用例与测试场景
1. 脚本模板
2. 场景模板
