接口性能测试方案_接口1，2024年最新软件测试一年经验面试

本文链接：https://blog.csdn.net/2401_84247617/article/details/137984733

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

备注：若运营计划调整，则需重新分析。
3. 性能指标描述
3.1 响应时间
在一般情况下，弱交互类接口平均响应时间不超过1秒，强交互类接口平均响应时间不超过200毫秒。
3.2 成功率
在一般情况下，接口响应成功率需达到99.99%以上。
3.3 系统资源
若为最佳负载，则系统CPU及内存使用率建议区间[50%，80%]，否则建议不超过50%。
3.4 处理能力
立项申请书明确要求：在XX压力下（并发数）TPS需达到XX或接口系统可支撑XX万实时在线访问。
3.5 稳定性
在实际系统运行压力情况下，可稳定运行N*24(一般 N >= 7 )小时。在高于实际系统运行压力1倍的情况下，可稳定运行12小时。
3.6 特性指标
例：Java类应用 FullGC 次数 <= 1次/天

04 性能测试范围

1. 业务范围
关键业务功能点描述。
2. 设计范围
网络接入层、接口层、中间件、存储层等被测组件及拓扑结构描述。
五、并发数计算方法
做过一些性能测试的童鞋刚开始比较纠结某个或某一类接口的并发数如何计算，其实并发数可以从用户业务和服务器的2个角度来看。

80/X原则
适用范围：无限制
以一项目为案例，母亲节当天接口服务器访问量分布如下所示，如何计算当天平均并发数和高峰并发数？

查看母亲节当天UV曲线分布与请求量呈线性关系，如下所示：

采用微积分的思想，将每个时间点视为一个矩形，可以通过求和的方式求出整个分布图的面积，如下所示：

其实每个矩形的长度均为1（1小时），故求面积时只需考虑宽度，即考虑

每小时请求量即可。
根据80/X原则，找出占据总体面积80%的时间，选择尽可能大的点计算出占据总体面积80%的时间，发现点的个数是7，意味着此时间长度占总时间长度30%，则80/X原则转换成80/30原则，如下所示：

故，平均并发数（每秒平均请求数）= 80% * 日请求量 / 1天 * 30%
进而计算出最高峰值与平均并发数的倍数 = 2.25
故，高峰并发数（每秒高峰请求数）= 2.25 * 平均并发数 =
2.25 * 80% * 日请求量 / 1天 * 30% = 6 * 日请求量 / 1天
因UV与请求量曲线分布呈线性关系，日请求量 = 9.25 * 日UV
故，高峰并发数 = 6 * 9.25 * 日UV / 1天 = 55.5 * 日UV / 1天
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 + …
假如一个系统需支撑10万在线用户数访问，如何通过性能需求分析来计算并发用户数？大家可以通过以上内容学习，独立思考下？

05 性能测试用例与场景

脚本模板

场景模板

06 性能测试工具选择

1. 数据建模工具
DataFactory是一种强大的数据产生器，它允许开发人员和QA很容易产生百万行有意义的正确的测试数据库，该工具支持DB2、Oracle、 Sybase、SQL Server数据库，支持ODBC连接方式，无法直接使用MySQL数据库，可间接支持。
2. 脚本开发工具
（1）若考虑脚本运行效率，则可考虑底层开发语言C或支持异步通信的语言JS，我们可以分别选择：Loadrunner 或 Node.js 的IDE环境进行开发。
（2）若考虑脚本开发效率，则可考虑代码复用性，可以选择面向对象语言C#或Java，为此我们可以分别选择：VS2008及以上版本 + 对应LR.NET控件或者 Eclipse4.0及以上版本 + JDK1.7及以上版本。
HTTP、Socket等协议接口性能测试脚本开发过程，请详见附件：
HTTP接口性能测试之脚本开发与性能问题分析.pdf
利用LR.Net控件完成性能测试脚本编写方法.pdf
Node.js学习入门手册.pdf
3. 压力模拟工具
（1）若为Java类接口且单机并发数控制在500内，则可选择Jmeter或者 Loadrunner。
（2）若为WebService类接口且单机并发数控制在500内，则可选择SoapUI或者Loadrunner。
（3）若单机并发数超过500且控制在5000内，则可选择Loadrunner。
（4）若单机并发数超过5000，则建议采用负载集群，即采用“中控（Control Center）+ 多机部署（Load Generator）”方案。
4. 性能监控工具
4.1 监控工具
无论Windows或Linux平台，一般存在的是一个或一组进程实例，我们可以选择Loadrunner 或 Nmon 来监控。有时为了获取被测应用的一些特性指标，可以选择被测组件自带的性能工具集或监控系统。常见应用服务器监控工具推荐如下：

4.2 监控平台
监控机器主要对被测集群服务器的服务或资源使用情况进行监控，比如各种开源的监控工具，MRTG：流量监控；CACTI：流量预警，性能报告Smokeping:IDC 质量监控；综合监控：Nagios、Zenoss、Ganglia 、Zabbix、Sitescope、Hyperic HQ 等，如下所示：

4.3 第三方监控云服务（APM）
APM提供端到端应用性能管理软件及应用性能监控软件解决方案，包含移动，浏览器，应用，基础设施，网络，数据库性能管理等，支持Java、.NET、PHP、Ruby、Python、Node.js、iOS、Android、HTML5等应用性能监控管理，主流云服务包括听云、OneAPM等，如下所示：

07 性能测试结果分析

1. 指标分析
性能测试的指标可分为产品指标和资源指标两类。对测试人员而言，性能测试的需求来自于用户、开发、运维的三方面。用户和开发关注的是与业务需求相关的产品指标，运维人员关注的是与硬件消耗相关的资源指标。

（1）从用户角度关注的指标
用户关注的是单次业务相关的体验效果，譬如一次操作的响应快慢、一次请求是否成功、一次连接是否失败等，反映单次业务相关的指标包括：
a.成功率b.失败率c.响应时间
（2）从开发角度关注的指标
开发人员更关注的是系统层面的指标。
a.容量：系统能够承载的最大用户访问量是多少?系统最大的业务处理量是多少?
b.稳定性:系统是否支持7*24小时(一周)的业务访问。
（3）从运维角度关注的指标
运维人员更关注的是硬件资源的消耗情况。

以上说明了测试人员在选择指标时需站在用户角度去思考，另外为了后续能够更好地分析问题，更需掌握与被测组件特性或运行原理相关的性能指标。
举例来说，通常接口系统均会直接或间接地访问数据库层介质（如Mysql、Oracle、SQLServer等），此时我们需考虑由接口系统产生压力下存储介质的性能情况，通常我们会选择分析指标如下：
（1）连接数（Connections）
（2）每秒查询数/每秒事务数（QPS/TPS）
（3）每秒磁盘IO数（IOPS）
（4）缓存命中率（Buffer Hits）
（5）每秒发生的死锁数（Dead Locks/sec）
（6）每秒读/写字节数（Read/Write Bytes/sec）
对于Windows或Linux平台具体指标监控及分析方法，请详见附件：
《Windows操作系统性能监控工具和指标分析V1.0》.pdf
《Linux操作系统性能监控分析手册V1.0》.docx
2. 建模分析
2.1 理发店模型

图中展示的是1个标准的软件性能模型。在图中有三条曲线，分别表示资源的利用情况（Utilization，包括硬件资源和软件资源）、吞吐量（Throughput，这里是指每秒事务数）以及响应时间（Response Time）。图中坐标轴的横轴从左到右表现了并发用户数（Number of Concurrent Users）的不断增长。
在这张图中我们可以看到，最开始，随着并发用户数的增长，资源占用率和吞吐量会相应的增长，但是响应时间的变化不大；不过当并发用户数增长到一定程度后，资源占用达到饱和，吞吐量增长明显放缓甚至停止增长，而响应时间却进一步延长。如果并发用户数继续增长，你会发现软硬件资源占用继续维持在饱和状态，但是吞吐量开始下降，响应时间明显的超出了用户可接受的范围，并且最终导致用户放弃了这次请求甚至离开。
根据这种性能表现，图中划分了三个区域，分别是Light Load（较轻的压力）、Heavy Load（较重的压力）和Buckle Zone（用户无法忍受并放弃请求）。在Light Load和Heavy Load 两个区域交界处的并发用户数，我们称为“最佳并发用户数（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone两个区域交界处的并发用户数则称为“最大并发用户数（The Maximum Number of Concurrent Users）”。
当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的响应时间而放弃。所以我们应该保证最佳并发用户数要大于系统的平均负载。
2.2 压力变化模型

随着单位时间流量的不断增长，被测系统的压力不断增大，服务器资源会不断被消耗，TPS 值会因为这些因素而发生变化，而且符合一定的规律。
图中：
a 点：性能期望值
b 点：高于期望，系统资源处于临界点
c 点：高于期望，拐点
d 点：超过负载，系统崩溃
2.3 容量计算模型

以一网站性能测试为案例：

通过分析运营数据，可以知道当前系统每小时处理的PV数
通过负载测试，可以知道系统每小时最大处理的PV数
即整理得
系统每小时PV处理剩余量 = 系统每小时最大处理的PV数 — 系统每小时处理的PV数
假设该网站用户负载基本呈线性增长，现有系统用户数为70万，根据运营推广计划，1年内该网站发展用户将达到1000万，即增长了14倍。即整理得：
系统每小时PV处理增加量 = 当前系统每小时处理的PV数 * 14 — 当前系统每小时处理的PV数
每天系统负载增加率 = 100% / 365 = 2.74 % （备注：此处将未来系统用户数达到1000万的负载定义为 100% ）
系统每天PV处理增加量 = 系统每小时PV处理增加量 * 每天系统负载增加率 * 24
所以，我们可以知道在正常负载条件下：
系统可支持正常运行天数 = 系统每小时PV处理剩余量 * 24 / 系统每天PV处理增加量
假设该网站后续部署升级天数已知，这样我们可以知道提前升级的天数：
系统可支持正常运行天数 — 部署升级天数。

08 性能测试通过标准