软件测试知识点和面试题--接口测试篇

软件测试知识点和面试题--app测试篇

软件测试知识点和面试题--手工测试篇（功能测试）

基础理论

概念

性能测试：使用自动化工具，模拟不同的场景，对软件各项性能指标进行测试和评估的过程

QPS：即Queries Per Second的缩写，每秒能处理查询数目。是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。每秒钟处理完请求的次数；注意这里是处理完，具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。QPS = 并发量 / 平均响应时间

TPS：即Transactions Per Second的缩写，每秒处理的事务数目。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息作出的评估分。

RPS：即Requests Per Second的缩写，每秒能处理的请求数目。等效于QPS。

PV：page view，页面浏览量，用户每一次对网站中的每个页面访问均被记录1次。用户对同一页面的多次刷新，访问量累计。

UV：Unique visitor，独立访客，通过客户端的cookies实现。即同一页面，客户端多次点击只计算一次，访问量不累计。

IP：Internet Protocol，本意本是指网络协议，在数据统计这块指通过ip的访问量。即同一页面，客户端使用同一个IP访问多次只计算一次，访问量不累计。

RT：响应时间，处理一次请求所需要的平均处理时间

目的

评估当前系统能力
寻找性能瓶颈，优化性能
评估软件是否能够满足未来的需要

测试流程

曲线拐点模型

性能测试场景（策略）

基准测试

概念
    侠义:测试环境确定后，对业务模型中的重要业务做单独的测试，获取单用户运行时的各项性能指标
    广义:建立基准线，当系统的软硬件环境发生变化之后，再进行一次基准测试以确定变化对性能的影响

用途:
    基准测试不会单独存在
    为多用户并发测试和综合场景测试等提供参考依据
    为系统/环境配置、系统优化前后的性能提升/下降提供参考指标

负载测试

概念:通过逐步增加系统负载，确定在满足系统的性能指标（如响应时间等）情况下，找出系统所能够承受的最大负载量的测试

作用:系统最大负载量达到用户要求时，系统才能正式上线使用

稳定性测试

概念:在服务器稳定运行（用户正常的业务负载下）的情况下进行长时间测试（1天-1周等），并最终保证服务器能满足线上业务需求

作用:系统在用户要求的业务负载下运行达到规定的时间时，系统才能正式上线使用

压力测试

概念:在强负载下的测试，查看系统在峰值情况下是否功能隐患、系统是否具有良好的容错能力和可恢复能力

测试场景:
高负载下的长时间的稳定性压力测试
极限负载情况下的破坏性压力测试

并发测试

概念:在极短的时间内，发送多个请求，来验证服务器对并发的处理能力 应用场景:特定活动场景，如：抢红包、秒杀、抢购等

强度测试

强度测试检查程序对异常情况的抵抗能力；是检查系统在极限状态下运行的时候性能下降的幅度是否在允许的范围内。

强度测试总是迫使系统在异常的资源配置下运行。

1.当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；

2.定量地增长数据输入率，检查输入子功能的反映能力；

3.运行需要最大存储空间（或其他资源）的测试用例； 4.运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。

容量测试

容量测试的目的是通过测试，预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下，没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。可以看作系统性能指标中，一个特定环境下的一个特定性能指标，即设定的界限或极限值。

性能指标

响应时间

从客户端发起请求开始，到接收到结果的总时间,网络传输时间+服务器处理时间,不包括前端页面处理和渲染时间 测试方式:HTTP接口请求响应时间

并发（用户）数

并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量，同一时刻向服务器发送请求的用户数，

吞吐量（Throughput）

单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力
业务角度
单位：“业务数/小时”、“业务数/天”、“访问人数/天”、“页面访问量/天”
网络角度
单位：“字节数/小时”、“字节数/天”
技术角度
每秒查询数（QPS）单个请求
每秒事务数（TPS）一个请求/多个请求
QPS和TPS关系一个事务对应一个请求时 TPS = QPS一个事务对应n个请求时 QPS = n * TPS

点击数

指客户端向服务端发送请求时，所有的页面资源元素（如：图片、链接、框架css、js等）的请求总数量 注意：只有web项目才有此指标,点击数不是页面上的一次点击

错误率

指系统在负载情况下，失败业务的概率，错误率＝(失败业务数/业务总数)*100% 注意点：错误率是一个性能指标，不是功能上的随机bug，大多系统都会要求错误率无限接近于0

资源使用率

系统各种资源的使用情况，资源的使用量/总的资源可用量×100%
资源指标CPU使用率：不高于75%-85%内存（大小）使用率：不高于80%磁盘IO（速率）：不高于90%网络（速率）：不高于80%

监控分级体系

性能瓶颈分析

服务器资源分析

CPU瓶颈：CPU已压满（接近100%），通常其他指标的拐点出现的时刻是否与CPU压满的时刻基本一致查看CPU：top内存瓶颈：内存不足时，操作系统会使用虚拟内存，从虚拟内存读取数据，影响处理速度查看内存：vmstat磁盘I/O瓶颈：磁盘I/O成为瓶颈时，会出现磁盘I/O繁忙，导致交易执行时在I/O处等待查看磁盘IO：iostat -x 1 1网络带宽：如果传递的数据包过大，超过了带宽的传输能力，就会造成网络资源竞争，导致TPS上不去查看网络接口信息：sar -n DEV 1 1

JVM瓶颈分析（Java项目）

Java 虚拟机在执行 Java 程序的过程中所管理的不同的内存数据区域。可简单分为：堆内存和非堆内存测试关注点1.堆内存使用量持续增长 —— 可能是内存泄漏2.Full GC比较慢，执行时会停止程序一些事务的处理。因此Full GC频率不能过高（低于10分钟）3.如果Full GC之后，堆中仍然无法存储对象，就会出现内存溢出 —— 程序出现crash（崩溃）内存问题引起原因：
内存泄漏：申请的内存空间没有完全被释放
内存溢出：由于内存泄漏导致没有内存空间JVM内存监控使用本地jvisualvm远程监控服务器

数据库瓶颈分析

慢查询

慢查询：设置慢查询时间范围，开启慢查询，执行SQL，找出慢查询的语句-- 查看慢查询SHOW VARIABLES LIKE 'slow_query%';--设置开启SET GLOBAL slow_query_log = 'ON';--查看阈值SHOW VARIABLES LIKE 'long_query_time';--设置阈值SET GLOBAL long_query_time = 1;--执行查询SELECT * FROM litemall_goods WHERE name LIKE '%母亲%'；-- 查看日志less /var/lib/mysql/localhost-slow.log

数据库连接池

数据库连接池作用：可以提高对数据库操作的性能方案：需要关注MYSQL的系统运行时数据库已建立连接数和最大连接数的比例，大于85%则需要增加最大连接数，小于10%则需要减小最大连接数

数据库死锁

数据库死锁：指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象➢表级锁：开销小，加锁快；不会出现死锁；锁定粒度最大，并发度最低。➢行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，并发度也最高。

压测机

原因：JMeter单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会导致TPS压不上去
解决方案：采用分布式执行的方法来提高负载量，达到系统性能测试要求的TPS

Jmeter使用

Jmeter原理

HTTP请求

GET请求
参数：在路径后添加参数在参数列表中添加参数
POST请求
参数在参数列表中添加参数（form）在消息体数据中添加请求体（form/json）
文件上传

参数化

用户定义的变量

位置：线程组>配置元件>用户定义的变量
引用方式：${变量名}
局限性：每次取值（无论是否相同的用户）都是固定值

用户参数

位置：线程组--> 前置处理器 --> 用户参数
引用方式：${变量名}
局限性：同一个用户在多次循环时，取到相同的值

CSV数据文件设置

位置：线程组--> 配置元件 --> CSV 数据文件设置
引用方式：${变量名}
局限性：需要手动进行测试数据的设置

__counter 函数

使用:${__counter(FALSE/TRUE,)}
局限性：输入数据有特定的业务要求时无法使用（如：登录时的用户名密码）

断言

响应断言

作用：对HTTP请求的任意格式的响应结果进行断言
位置:测试计划 --> 线程组--> HTTP请求 --> (右键添加) 断言 --> 响应断言

JSON断言

作用：对HTTP请求的JSON格式的响应结果进行断言
位置：测试计划 --> 线程组--> HTTP请求 --> (右键添加) 断言 --> JSON断言

持续时间断言

作用：检查HTTP请求的响应时间是否超出要求范围
位置：测试计划 --> 线程组--> HTTP请求 --> (右键添加) 断言 --> 断言持续时间

关联

正则表达式提取器

作用：针对任意格式的响应数据进行提取
位置：测试计划 --> 线程组--> HTTP请求 --> (右键添加) 后置处理器 --> 正则表达式提取器

XPath提取器

作用：针对HTML格式的响应结果数据进行提取
位置：测试计划 --> 线程组--> HTTP请求 --> (右键添加) 后置处理器 --> XPath提取器

JSON提取器

作用：针对JSON格式的响应结果数据进行提取
位置：测试计划 --> 线程组--> HTTP请求 --> (右键添加) 后置处理器 --> JSON提取器

JMeter属性(全局变量)

作用：需要实现跨线程组的数据传递时
设置
1.测试计划勾选【单独运行每个线程组】，先使用提取器获取局部属性值；
2.HTTP请求A添加BeanShell取样器>保存JMeter属性>${__setProperty(全局属性值,${局部属性值},)}
3.HTTP请求B读取JMeter属性>${__property(全局属性值,,)}

连接数据库

1.添加MySQL驱动jar包
2.配置数据库连接信息
添加：测试计划 --> 线程组--> (右键添加) 配置元件 --> JDBC Connection Configuration
参数：Variable Name--连接池名Database URL--协议 + 数据库IP + 数据库端口 + 连接的数据库名称JDBC DRIVER class--com.mysql.jdbc.DriverUsernamePassword
3.添加JDBC请求
添加：测试计划 --> 线程组--> 取样器 --> JDBC Request
参数：Variable Name--数据库连接池的名字Query Type---查询操作：选择“Select Statement” 增加、删除、修改操作：选择“Update Statement”任意正确且批量的SQL语句：选择“Callable Statement”Query--填写的SQL语句，未尾不要加“;”Variable names--保存SQL语句返回结果的变量名，使用${变量名}获取

负载测试

需求

TPS达到10的情况下，登录的时间不超过2s，找出最大负载量

方式

逐步增加用户并发数，在满足需求指标下和系统资源的指标下，找出最大负载量，如图最大负载量为150

用例

步骤

1.线程组的线程数为并发用户数，持续运行1分钟；

2.常数吞吐量定时器，目标吞吐量=TPS要求值*60/线程数

3.添加集合报告，和PerfMon 指标收集器插件（CPU、内存、磁盘I/O、网络）

4.服务器执行PerfMon 的服务代理程序，bash startAgent.sh

5.运行Jmeter脚本，收集聚合报告的数据，以及各PerfMon指标（导出本地计算出平均值）

稳定性测试

基于负载测试得出的最大负载量，进行长时间持续性地测试，并保证最终结果正常

并发测试

需求

模拟500个用户1秒内发送请求

方式

使用同步定时器，500个用户一组，控制并发操作

步骤

1.添加线程组

2.添加HTTP请求

3.添加同步定时器

4.添加监听器-聚合报告

5.添加用表格查看结果

分布式测试

原因

单台电脑瓶颈限制，无法满足测试目标，需要使用多台电脑协作完成测试
1、单台电脑支持线程数：1000~2000
2、windows默认TCP有限制，最多支持500左右，需要调试注册表进行开启多连接

原理

步骤

1.修改执行机的配置文件jmeter.properties，修改端口号和禁用SSL

2.启动执行机的服务 bin/jmeter-server.bat

3.修改控制机的配置文件jmeter.properties，修改端口号和禁用SSL

4.控制机通过界面启动执行

面试题

压力测试、负载测试、并发测试有什么区别？

负载测试：目标是测试在一定负载情况下系统性能（不关注稳定性，也就是说不关注长时间运行，只是得到不同负载下相关性能指标即可）；实际中我们常从比较小的负载开始，逐渐增加模拟用户的数量（增加负载）， 观察不同负载下应用程序响应时间、所耗资源，直到超时或关键资源耗尽，这就是所说的负载测试，它是测试系统的不同负载情况下的性能指标。压力测试：目标是测试在一定的负载下，系统长时间运行的稳定性，尤其关注大业务量情况下，长时间运行系统性能的变化（例如是否反应变慢、是否会内存泄漏导致系统逐渐崩溃、是否能恢复）。并发测试：主要指当测试多用户，并发访问同一个应用、模块、数据时，是否产生隐藏的并发问题，如内存泄漏、线程锁、资源争用问题，几乎所有的性能测试都会涉及并发测试。

TPS和QPS的区别是什么？

TPS：Transactions Per Second，意思是每秒事务数，具体事务的定义，都是人为的，可以一个接口、多个接口、一个业务流程等等。一个事务是指事务内第一个请求发送到接收到最后一个请求的响应的过程，以此来计算使用的时间和完成的事务个数。以单接口定义为事务为例，每个事务包括了如下3个过程：a.向服务器发请求b.服务器自己的内部处理（包含应用服务器、数据库服务器等）c.服务器返回结果给客户端如果每秒能够完成N次这三个过程，tps就是N；
如果多个接口定义为一个事务，那么，会重复执行abc，完成一次这几个请求，算做一个tps。QPS：Queries Per Second，意思是每秒查询率，是一台服务器每秒能够响应的查询次数（数据库中的每秒执行查询sql的次数），显然，这个不够全面，不能描述增删改，所以，不建议用qps来作为系统性能指标。区别：
如果是对一个查询接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么tps=qps，否则，tps≠qps
如果是容量场景，假设n个接口都是查询接口，且这个接口内部不会再去请求其它接口，qps=n*tpsjmeter聚合报告中，Throughput是用来衡量请求的吞吐量，也就是tps，tps=样本数/运行时间；我们定义的是tps，不是qps
如果没有定义事务，会把每个请求作为一个事务

TPS是怎么确定的？

稳定性测试场景根据真实的业务运营数据的统计计算普通计算方法：TPS = 总请求数 / 总时间二八原则计算方法：TPS = 总请求数 * 80% / (总时间*20%)压力测试场景根据用户峰值业务操作来计算作用：专门用于满足极端的用户业务场景下的性能需求计算方式：并发数TPS = 峰值请求数 / 峰值时间 * 系数

单机tps100，8台服务器，tps是多少？

如何设计性能测试场景？

我会从几个层面来考虑性能测试场景的设计：
第一个用户操作量大的功能场景所涵盖的接口，
第二个基于需求明确指出功能
第三个就是数据量较大接口
基于这些功能，所涉及到接口设定单接口并发场景，同时还会设计负载测试场景，最后会制定混合场景的压力测试。

有没有做过性能测试？简单的描述一下当时是怎么测试的？

(基于操作层面级别回答)
1、有的，在之前的项目测试中，按项目要求对核心功能模块实施过性能测试。如电商(商品搜索相关接口、购物车查询、提交订单等场景);
2、确认模块后，制定好性能测试场景，如单接口并发、压力测试场景;
3、然后部署性能测试环境，和生产环境等比资源搭建;
4、使用jmeter工具，配置对应接口场景，设定好对应场景所需的定时器，使用nmon监控硬件资源，jmeter聚合报告查看软件指标;
5、最后总结性能结果，产出性能测试报告;

有没有测试过百万级用户以上的性能测试场景？简单的描述下？

没有测试过，但是可以适当的表现出自己有思路（量力而行）。百万级用户对应信息有哪些，第一个用户量大，第二个数据量大。
如果让我去测试的话，首先需要想清楚如何解决模拟庞大用户量的问题，第二数据如何构造的问题。
那第一个问题，普通测试环境是无法满足性能测试的要求，可以适当等比降低服务器，那同样的并发用户数也会降低。
Jmeter的常规情况下，在我们普通的肉机上也就200并发了，可以通过分布式的方式提高一下并发数量。当然也可以使用其它的方式如：Ignareo、IOCP等解决方案。
大批量测试数据的准备，可以通过编写存储过程的方式，也可以直接导入生产环境数据来进行的方式。数据库层面的话，通常都会有缓存机制。这些问题解决了之后，其实后续测试执行过程个人觉得大同小异.

性能测试方案包含的主要内容

1.制定性能测试目的
2.性能测试场景梳理
3.确定被测业务的部署架构
4.对测试数据进行调研1）数据库基础数据量分析2）压测增量数据分析3）参数化的数据分析4）冷热数据的分析-数据会不会被缓存，缓存时间多久
5.业务规则的调研
6.测试监控的内容确认硬件监控：CPU、内存、磁盘、网络系统监控：实时连接数、连接状态、Redis缓存命中率、JVM监控、慢查询、MQ（生产速度、消费速度、堆积量）
7.性能测试排期涉及的人员

列举性能测试常见问题

性能测试结果中，我们关注的指标是tps和art，如果tps低，或者响应时间长，或者服务器资源紧张，那就需要我们去定位性能问题了，常见的性能问题主要包含：a.服务器问题cpu内存磁盘io磁盘容量b.网络带宽：看当前收发占用的带宽及有没有丢包c.load高：看线程信息；看是否fgcd.队列问题：磁盘io队列、线程队列e.各种连接池问题：不足或者没释放f.死锁问题：数据库死锁、线程死锁g.慢sql问题h.缓存设置问题

在性能测试过程中，有没有发现过什么问题？举例说明？如何解决的？

在之前实施测试实施的过程中，有遇到过内存泄露问题。内存泄露当时是这样的，在测试查询商品做并发的测试时候，几次短时间的并发测试，在服务器硬件资源数据搜集的层面，除了内存有一些增长外，其它指标数据都是满足条件。后续在做长时间持续负载测试的时候，发现当用户并发数稳定后内存持续性增加，处理完查询事务后，没有任何的释放内存迹象，直到内存占满，最终导致服务器请求全部500，重启服务器后内存又恢复正常。后面该问题提交给开发进行定位确认，查询商品接口在处理完查询事务后，线程并为释放，一直占用着资源所导致，具体的代码修复过程不说明。

测试了什么场景？吞吐量多少，其它的指标结果如何？

在之前的项目测试过程中，主要测试了登录、商品搜索相关接口、购物车查询、提交订单等单个场景，以及混合操作场景。登录场景的话，当时在测试环境所测试TPS大概在50左右，搜索商品大概是20左右，平均响应时间都在1s以下（两三百毫秒）；

需求文档没有给出性能指标，该如何计算性能指标？

1、当时我在执行测试的时候，需求层面没有特别全的指标要求，只提出了一个点：网站在客户网络情况OK的前提下，响应速度不能超过1s。拿到这个要求后我是这样做的。2、基于系统运营数据，获取到用户操作量最大的功能模块，选择登录、商品搜索、查看商品详情页、打开首页、购物车等，
第二获取到了最大在线用户数，当时最大在线用户为5000，每个用户平均使用系统时间1小时，一天里面用户集中使用时间段为12个小时左右。基于该数据估算出最大并发用户数≈478 （5000*1/12≈417 417+3*根号417），基于计算最终定下来一个预期指标：500并发。实际测试环境会和生产环境的资源有偏差，最终等比取值100并发。3、已经计算出来了对应的单接口的指标数据了：VUSER 100 PER SERCODN<1 QPS:按照标准工时计算出来很低，所以取了一个基准值 20

除了使用jmeter收集性能测试结果数据，还用过其它的方法吗？简单说下？

有的，之前的测试过程中，还有用过nmon来搜集系统资源使用情况的数据，直接在服务器上面安装nmon的包，在启动测试的时候，直接通过nmon命令来收集数据即可，会生成nmon监控数据文件，并获取到本地，通过nmon的宏工具来进行解析。当然除了这个搜集方法以外其实还有很多其它的数据监控方法：如jprofiler、dynatrace。1.top - 经典的Linux任务管理工具，CPU和内存的使用状况；
2.tcpdump - 洞察网络封包；
3.Nmon，监控系统的 CPU、内存、网络、硬盘、文件系统、NFS、高耗进程、资源和 IBM Power 系统的微分区的信息；
4.sar，监控系统的文件读写情况、系统调用的使用情况、磁盘I/O、CPU效率、内存使用状况、进程活动及IPC有关的活动等；
5.dstat，可以取代vmstat，iostat，netstat和ifstat这些命令的多功能产品，在性能测试、基准测试和排除故障过程中可以很方便监控系统运行状况；
6.atop，是一个功能非常强大的linux服务器监控工具，它的数据采集主要包括：CPU、内存、磁盘、网络、进程等；

有没有搭建过性能测试环境？性能测试环境需要注意一些什么？

有搭建过的。例如之前的项目中就有搭建过一次，总共3台机器，2台应用服务器tomcat，1台数据库服务器mysql，负载均衡nginx的服务放在其中的一台应用服务器上。
性能测试环境的话，首先必须保障其专用性，不能被其它因数干扰，第二尽量在局域网内，忽略的网络的影响，第三尽量和生产环境服务器架构一致（方便性能指标等比计算）。

稳定性场景，跑多久？

稳定性测试（亦可称可靠性测试）通过给系统加载一定的业务压力，让系统持续运行一段时间（一般为7x24小时），检测系统是否能够稳定运行。

在性能测试过程中，如何准备足够量级的测试数据？

在之前测试的过程中我用过两种方式，例如在测试查询商品时，我们需要保障有足够量的商品数据。
第一种方式是通过批量插入数据库的方式；
第二种就是直接通过jmeter调用新增商品的接口，通过参数化的方式，批量生成测试数据（这种方式生成的数据更加完整）；

jmeter中，Ramp-Up Period 该如何设置？

ramp-up = 线程数/吞吐率

你使用jmeter执行性能测试，常用的定时器有哪些？有什么区别？

用的最多是：固定定时器和同步定时器。
固定定时器，设定每个线程请求之前的等待时间，模拟多用户在实际操作的时候的等待时间。
同步定时器，可以模拟并发设置一个阀值（请求数量），让多个用户能在同个时间点同时发出，模拟并发。

除了jmeter做性能测试以外，还有没有其它的方式来实现？简单说下？

性能测试的方式有很多种，个人还有了解过LoadRunner、Locust等实现方式。
LoadRunner的话相对jmeter而言支持更多形式的协议，例如socket、数据库协议ODBC、邮件SMTP协议等，同时还支持脚本录制。
Locust是一个python库，需要一定的编码功底。
JVM本身也自带性能测试的功能。

jmeter的线程数、并发用户数、TPS、RPS 关系

1.jmeter的线程数就相当于并发用户数，并发用户数就是虚拟用户数。
2.并发用户数：简称VU，指的是现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数（Virtual User），注意并发用户数跟注册用户数、在线用户数有很大差别的，并发用户数一定会对服务器产生压力的，而在线用户数只是 ”挂” 在系统上，对服务器不产生压力，注册用户数一般指的是数据库中存在的用户数。
3.处理能力：简称TPS，每秒事务数，是衡量系统性能的一个非常重要的指标。
4.响应时间：简称RT，指的是业务从客户端发起到客户端接受的时间。1.系统的性能由TPS决定，跟并发用户数没有多大关系。
2.系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。
3.建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压。
4.一般情况下，大型系统（业务量大、机器多）做压力测试，10000~50000个用户并发，中小型系统做压力测试，5000个用户并发比较常见。

什么情况下要做关联，关联是怎么做的？

当脚本的上下文有联系，就用关联，比如登录的token关联，增删改查主键id关联
正则表达式提取器、Json提取器、Jmeter全局变量设置

如何获取VU和TPS

VU获取方式：
已有系统：可选取高峰时刻，在一定时间内使用系统的人数，这些人数可认为是在线用户数，并发用户数可以取10%，例如在半个小时内，使用系统的用户数为10万，那么取10%（即1万）作为并发用户数基本就够了。
新系统：没有历史数据作参考，建议通过业务部门进行评估。TPS获取方式：
已有系统：可选取高峰时刻，在一定时间内（如3分钟~10分钟），获取系统总业务量，计算单位时间（秒）内完成的笔数，乘以2-5倍作为峰值的TPS，例如峰值3分钟内处理订单18万笔，平均TPS是1000，峰值TPS可以是2000~5000。
新系统：没有历史数据作参考，建议通过业务部门进行评估。

如何评价系统的性能

针对服务器端的性能，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能，如果必须要用并发用户数来衡量的话，需要一个前提，那就是交易在多长时间内完成，因为在系统负载不高的情况下，将思考时间（思考时间的值等于交易响应时间）加到串联链路中，并发用户数基本可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义。同样的，如果系统间的吞吐能力差别很大，那么同样的并发下TPS差距也会很大。

性能测试策略

做性能测试需要一套标准化流程及测试策略。在做负载测试的时候，传统方式一般都是按照梯度施压的方式去加用户数，避免在没有预估的情况下，一次加几万个用户，导致交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内；较为适合互联网分布式架构的方式。

如何理解性能测试业务模型？

1.分析系统有很多业务，每种业务逻辑和业务量是不一样的，消耗系统的资源也不一样，因此业务种类、业务占比决定了系统的处理能力，业务模型在性能测试中起着关键性的作用。以电商场景为例，不同的促销形式和主推的类目决定了不同的容量整体配比，那么精准地将流量落地在PTS上进行压测拿到系统的木桶最短板可以更好的利用机器资源达到业务目的。
2.风险业务模型中业务和占比选取不对，跟生产差异非常大，直接导致测试结果没有任何参考价值，并且容易误导对系统处理能力的判断。 有些业务的业务量虽然占比很低，但一旦突变，对系统也是致命的，这些业务在性能测试中也需要关注。
3.规范系统中的典型业务如何选取一般情况下遵循的规则是选取业务量高的、经常使用的、有风险的、未来有增长趋势的业务作为系统的典型业务。已经上线的系统可以通过高峰时段历史业务量和生产问题性能来评估，对于即将上线的系统可以通过调研和单交易资源消耗的结果来评估。3.1已上线系统搜集生产上不同高峰时间段的业务种类和业务量，每个时间段的业务种类和业务量是否有很大的差异，如有的话，必须有多个业务模型，  差异不大的，可以只用一个业务模型。搜集生产上高峰时间段资源消耗和资源异常的时间点，从中捕获资源消耗高和异常的原因，可能是由于某种”不起眼”的业务导致。搜集生产问题，进行分析，如果是由于某种业务导致而且以前性能测试的时候忽略此笔业务，那么这笔业务的风险是非常大的，需要后续    性能测试将此业务加入到业务模型中。3.2未上线系统通过调研，确定业务种类和业务占比。通过调研，确定是否在业务促销等活动中，某些业务有突变的可能。通过测试结果，确定每笔业务的资源消耗，如果某些业务虽然占比低，但资源消耗非常大，那么需要适当的调整此业务占比。

相对并发与绝对并发

相对并发：指在一个时间段内发生的事情
绝对并发：指在同一时刻发生的事情，一般采用同步定时器（Synchronizing Timer）实现绝对并发

如何找到并发数、平均响应时间、tps的最佳平衡点？

注册用户数、在线用户数、并发用户数

由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。

你们公司用户体量多大？最大在线有用户数有多少？

可以说，日活2W左右，最大并发也就5000

如何确定系统最大负载？

通过负载测试，不断增加用户数，随着用户数的增加，各项性能指标也会相应产生变化，当出现了性能拐点，比如，当用户数达到某个数量级时，响应时间突然增长，那么这个拐点处对应的用户数，就是系统能承载的最大用户数。例如搜索商品在资源不变的情况下，不断提高并发用户数，10-30-50-100-150，直到测试到TPS、平均响应时间拐点。在资源满足的情况下出现拐点的话，既系统技术层面最大支持负载情况了。

系统哪些地方(哪些功能)，做了性能测试？

选用了用户使用最频繁的功能来做测试，比如：登陆，搜索，提交订单

性能测试在什么环境执行？

与真实生产环境保持高度一致性，硬件、软件一致，以及使用场景一致

性能测试什么时间执行？

基准测试：功能测试之后，系统比较稳定的时候再做。负载测试：夜深人静，系统没人用的时候

如何识别系统瓶颈？

从TPS指标分析，TPS即系统单位时间内处理事务的数量。观察当前随着用户数的增长期，系统每秒可处理的事务数是否也会增长

如何判断系统的性能是变好了还是变坏了

通过基准测试对比性能指标

性能测试需求哪里来？

1：客户提供需求
2：运维提供需求
3：开发提供需求

有验证码的功能，怎么做性能测试？

1、将验证码暂时屏蔽，完成性能测试后，再恢复
2、使用万能的验证码

系统出现500或白屏，你会如何分析问题？

1、查看系统服务器资源是否占满：磁盘、内存
2、通过查看磁盘占用状态：df -h；通过写入缓存信息，导致硬盘空间不足；
3、查看内存的使用情况：top- 内存泄漏：由于开发编写代码过程对于已经分配内存资源使用完毕之后，并不释放内存的资源，导致后面同样业务处
理所占用内存足部累加，最终导致内存不足。
- 内存溢出：现有空闲内存不足以提供服务器处理客户请求。作为测试需要定位信息：
基于内存泄漏，找到占用了资源而不释放的功能模块，然后基于功能找到请求地址

提高软件处理事务数，最简单快捷的方式是什么？

首先就是增加服务器资源，其次利用缓存机制来提高处理速度。

有没有提出过性能优化方案？

优化方案方向：服务器资源分析JVM瓶颈数据库慢查询、数据库连接池、数据库死锁

如果tps上不去，如何分析定位？

1.网络带宽在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。
2.连接池可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。
3.垃圾回收机制从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。
4.数据库配置高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到TPS。
5.通信连接机制串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。
6.硬件资源包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。
7.压力机比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。
8.压测脚本还是以jemter举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。
9.业务逻辑业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。
10.系统架构比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。
解决办法：
由公式：QPS（TPS）= 并发数/平均响应时间 可以看出，要提高qps,我们必须做2个方面努力一、增加并发数
1.比如增加tomcat并发的线程数，开喝服务器性能匹配的线程数，可以更多满足服务请求。
2.增加数据库的连接数，预建立合适数量的TCP连接数
3.后端服务尽量无状态话，可以更好支持横向扩容，满足更大流量要求
4.调用链路上的各个系统和服务尽量不要单点，要从头到尾都是能力对等的，不能让其中某一点成为瓶颈。
5.RPC调用的尽量使用线程池，预先建立合适的连接数。二，减少平均响应时间
1.请求尽量越前结束，越好，这样压力就不要穿透到后面的系统上，可以在各个层上加上缓存
2.流量消峰。放行适当的流量，处理不了的请求直接返回错误或者其他提示。和水坝道理很类似
3.减少调用链
4.优化程序
5.减少网络开销，适当使用长连接
6.优化数据库，建立索引

软件测试知识点和面试题--性能测试篇相关推荐

软件测试知识点和面试题--手工测试篇（功能测试）
软件测试知识点和面试题--接口测试篇软件测试知识点和面试题--app测试篇软件测试知识点和面试题--性能测试篇如何熟悉项目 1.根据项目的UI界面和需求文档,使用思维导图整理项目的组织结构架构图 ...
软件测试知识点和面试题--接口测试篇
软件测试知识点和面试题--性能测试篇软件测试知识点和面试题--手工测试篇(功能测试) 软件测试知识点和面试题--app测试篇接口规范接口测试流程测试用例的思路和方法 pymysql操作数据库 ...
软件测试知识点和面试题--app测试篇
软件测试知识点和面试题--接口测试篇软件测试知识点和面试题--性能测试篇软件测试知识点和面试题--手工测试篇(功能测试) APP发布流程内部发布平台蒲公英.Testlink等发布步骤1.开发打包 ...
软件测试知识点和面试题--UI自动化篇
主流自动化测试框架介绍软件测试的自动化一般可以分为3层 * 代码层的单元测试 * 接口层的集成测试 * UI 层的测试 1)代码层自动化代码层的自动化一般指针对代码进行的单元测试,比较常用的单元测 ...
Redis 知识点和面试题(持续更新ing)
推荐书籍 <Redis实战>,<Redis设计与实现>,<Redis使用手册> 视频 [[趣话Redis第二弹]Redis数据持久化AOF和RDB原理一次搞懂!- ...
软件测试项目实战之性能测试篇,软件测试项目实战之性能测试篇
第 1章性能测试基础 1 1.1 性能测试概念 2 1.2 性能测试作用 3 1.3 性能测试指标 4 1.4 性能测试流程 5 1.5 性能测试的分类 7 1.6 性能测试工程师技能模型 8 1. ...
2023年软件测试经典面试题（全三篇）【包含答案】做完面试进入大厂不是梦
文章目录前言软件测试经典面试题(一)共25题软件测试经典面试题(二)共16题软件测试经典面试题(三)共16题一.软件测试基础二.Linux 三.Python 四.MySQL 五.Web 六 ...
测试面试题集锦（五）| 自动化测试与性能测试篇（附答案）
简介:本系列文章总结归纳了一些软件测试工程师常见的面试题,主要来源于个人面试遇到的.网络搜集(完善).工作日常讨论等,分为以下十个部分,供大家参考.如有错误的地方,欢迎指正.有更多的面试题或面试中遇到 ...
35道最新【软件测试】面试题，常见面试题及答案汇总
前言除了掌握扎实的专业技能之外,你还需要一份<软件测试面试宝典2022版>才能在万千面试者中杀出重围,成功拿下offer. 小编特意整理了35道测试必问必过面试题,送给大家,希望大家都能 ...
2021【软件测试】面试题合集大放送
又到了金九银十跳槽求职旺季.准备好一场面试不仅需要在简历上多下功夫,还需要为面试问答做好充足的准备,简历书写请参考:https://blog.csdn.net/leboxy/article/detai ...

软件测试知识点和面试题--性能测试篇

基础理论

概念

目的

测试流程

曲线拐点模型

性能测试场景（策略）

性能指标

监控分级体系

性能瓶颈分析

服务器资源分析

JVM瓶颈分析（Java项目）

数据库瓶颈分析

压测机

Jmeter使用

Jmeter原理

HTTP请求

参数化

断言

关联

连接数据库

负载测试

稳定性测试

并发测试

分布式测试

面试题

压力测试、负载测试、并发测试有什么区别？

TPS和QPS的区别是什么？

TPS是怎么确定的？

单机tps100，8台服务器，tps是多少？

如何设计性能测试场景？

有没有做过性能测试？简单的描述一下当时是怎么测试的？

有没有测试过百万级用户以上的性能测试场景？简单的描述下？

性能测试方案包含的主要内容

列举性能测试常见问题

在性能测试过程中，有没有发现过什么问题？举例说明？如何解决的？

测试了什么场景？吞吐量多少，其它的指标结果如何？

需求文档没有给出性能指标，该如何计算性能指标？

除了使用jmeter收集性能测试结果数据，还用过其它的方法吗？简单说下？

有没有搭建过性能测试环境？性能测试环境需要注意一些什么？

稳定性场景，跑多久？

在性能测试过程中，如何准备足够量级的测试数据？

jmeter中，Ramp-Up Period 该如何设置？

你使用jmeter执行性能测试，常用的定时器有哪些？有什么区别？

除了jmeter做性能测试以外，还有没有其它的方式来实现？简单说下？

jmeter的线程数、并发用户数、TPS、RPS 关系

什么情况下要做关联，关联是怎么做的？

如何获取VU和TPS

如何评价系统的性能

性能测试策略

如何理解性能测试业务模型？

相对并发与绝对并发

如何找到并发数、平均响应时间、tps的最佳平衡点？

注册用户数、在线用户数、并发用户数

你们公司用户体量多大？最大在线有用户数有多少？

如何确定系统最大负载？

系统哪些地方(哪些功能)，做了性能测试？

性能测试在什么环境执行？

性能测试什么时间执行？

如何识别系统瓶颈？

如何判断系统的性能是变好了还是变坏了

性能测试需求哪里来？

有验证码的功能，怎么做性能测试？

系统出现500或白屏，你会如何分析问题？

提高软件处理事务数，最简单快捷的方式是什么？

有没有提出过性能优化方案？

如果tps上不去，如何分析定位？

软件测试知识点和面试题--性能测试篇相关推荐

最新文章

热门文章