大佬云集技术答疑交流群：743262921(进群暗号:222)

压测过程中TPS上不去？请求响应时间过长？硬件资源不足：服务器的CPU、内存、磁盘等硬件资源不足，无法支撑高并发的请求处理。可以通过增加硬件资源或者优化服务器配置来提升TPS。网络带宽限制：网络带宽不足，导致服务器无法及时响应请求。可以通过增加网络带宽或者优化网络传输方式来提升TPS。数据库性能问题：数据库的读写性能不足，无法满足高并发的请求。可以通过优化数据库结构、索引、查询语句等方式来提升数据库性能。代码逻辑问题：应用程序中存在性能瓶颈或者死循环等问题，导致请求处理速度变慢。

性能测试，模拟这些真实存在的业务场景，比如，各种秒杀活动、开门红活动等等电子商务促销活动。考验系统的负载能力，定位相应的问题并给出对应的解决方案，最终让系统满足实际的业务场景。性能测试流程1、性能测试接口文档准入1）系统架构设计文档（系统基础架构图、业务架构图、数据流图）。2）非功能性需求文档（性能测试指标如：PV、用户数、TPS、并发、响应时间、系统峰值CPU、内存消耗…等等）。3）资源动作分解表（申请压测环境，包含硬件配置及数量信息）。4）测试场景（核心业务）。2、准备系统环境。

1、内存溢出1）堆内存溢出现象：压测执行一段时间后，系统处理能力下降。这时用JConsole、JVisualVM等工具连上服务器查看GC情况，每次GC回收都不彻底并且可用堆内存越来越少。压测持续下去，最终在日志中有报错信息：java.lang.OutOfMemoryError.Java heap space。

1、并发测试的定义1）并发测试的定义中，最主要的有两点①点层面上的：例如：周一早上7:30半，小学生要统一到操场升国旗。即：同一时间做某件事②线层面上的：例如：中午11:30-13:00，小学生有的跳皮筋，有的踢足球，但同时对服务器产生压力。即：一个时间段做不同的事2）并发测试不等于性能测试这个问题，我面试的时候，问过多个求职者，大部分求职者的第一反应都是说并发测试就是性能测试！性能测试中把并发又分为负载和压力测试。

1、性能测试关注点性能是评估一个软件最为关键的维度，性能测试关注点：how much 与 how fast1）性能测试的分类极限测试：在各种边界压力情况下，如电池、存储、网速，验证APP是否能正确响应，内存满时安装APP—运行APP时手机断电—运行APP时断网响应能力测试：APP中各类操作是否满足用户响应时间要求，APP安装—APP卸载—APP各类功能性操作的响应时间压力测试：反复/长期操作下、系统资源的占用情况2）性能的评估。

1、什么是性能测试先看下百度百科对它的定义性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。我们可以认为性能测试是：通过在测试环境下对系统或构件的性能进行探测，用以验证在生产环境下系统性能是否达到预估的性能需求，发现系统可能存在的性能瓶颈，进而改善优化并系统的性能，提高系统的可扩展性、稳定性。2、系统性能指标1）响应时间响应时间(Response Time)，简称RT，是指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的结果。

1、了解业务活动的必要性一般情况下压测人员不会与业务人员打交道，对业务也不会有太强的敏感性，所以通常拿到的测试指标都是开发人员提供的。这很容易会陷入一个误区，如果开发人员对整体业务活动和压测不熟悉，提供的指标可能会与业务活动的压力有较大的差异甚至无法提供。这时就需要专业的性能测试工程师介入熟悉业务活动，评估压力指标。

1、性能测试-TPS上不去哪些原因导致的？1）网络带宽在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，就会造成网络资源竞争，导致服务端接收到的请求数达不到服务端的处理能力上限。2）连接池可用连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行），没有保持长连接，TCP 连接频繁中断3）GC如果堆内存分配的不合理，就会导致频繁的gc，gc会导致线程暂停。

性能测试指标1、QPS，每秒查询QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。互联网中，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。（每秒钟处理完的请求次数，注意这里是处理完）2、TPS，每秒事务TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。

从个人的实践经验来说，我认为性能测试技术体系的构建，大致要分为四个阶段，分别是：日常化、自动化、工具化和平台化。1、日常化很多做性能测试的同学，在工作中面临的最大问题是性能测试无法成为日常测试工作的一部分，即性能测试作为质量保障的一种手段，却无法融入正常的需求版本迭代流程中。最常见的例子就是一句话需求，比如：这几个接口压测一下，出一份报告；或者线上出了性能问题，才火急火燎的找测试同学，对系统进行压测，再排查定位问题。

1、概述性能测试按照不同视角，可以分为以下几类：1） 用户视角的性能用户角度感受到的网站响应速度的快和慢。从用户在浏览器输入网址/打开应用，到整个页面呈现给用户的耗时。包含了用户端发送请求，服务端收到并执行请求，返回请求，客户端收到之后渲染的总时间。2）开发人员视角的性能包括系统吞吐量，并发处理能力，系统稳定性，响应延迟等。如果发现有不满足要求的地方，需要定位出问题所在，并给出解决方案。3）运维。

1、阶梯式场景（负载测试）该场景主要应用在负载测试里面，通过设定一定的并发线程数，给定加压规则，遵循“缓起步，快结束”的原则，不断地增加并发用户来找到系统的性能瓶颈，进而有针对性的进行各方面的系统优化。

性能测试这种测试方式在发生过程中，其中一个过渡性的工作，就是对执行过程中的问题，进行定位，对功能的定位，对负载的定位，最重要的，当然就是问题中说的“瓶颈”。

1、开始准备工作1）系统基础功能验证性能测试在什么阶段适合实施？切入点很重要！一般而言，只有在系统基础功能测试验证完成、系统趋于稳定的情况下，才会进行性能测试，否则性能测试是无意义的。2）测试团队组建根据该项目的具体情况，组建一个几人的性能测试team，其中DBA是必不可少的，然后需要一至几名系统开发人员（对应前端、后台等），还有性能测试设计和分析人员、脚本开发和执行人员；在正式开始工作之前，应该对脚本开发和执行人员进行一些培训，或者应该由具有相关经验的人员担任。3）工具的选择。

1、性能测试常用8个步骤1）获取最常用场景已有面向广大用户的系统，只要使用就能提取到性能测试点。最直接的方式：自己可以去操作下。如：视频网站，首页（访问量占总访问量的50-70），内容详情页，各子导航等。已有面向少数客户的系统，最快速的方式看下数据库表量，找出数据量大的表去问项目经理 数据是怎么产生的，也能获取到性能测试点。如果不能访问数据库，则可以找使用系统的客户聊聊（找聊的人数不少于角色人数），听听他们是如何使用的 也能知道最常用的功能是什么。

开始性能测试前需要了解1）项目具体需求。2）指标：响应时间在多少以内，并发数多少，tps多少，总tps多少，稳定性交易总量多少，事务成功率，交易波动范围，稳定运行时长，资源利用率，测哪些交易，哪些接口,测试哪些场景。3）环境：生产环境服务器数量，测试环境服务器数量，按照资源配比得出测试指标。4）协议：系统用什么协议进行通讯。5）压力机数量：如果并发用户数太多，需要把压力发到不同的压力机，不然可能会存在压力机瓶颈问题，导致tps和响应时间抖动。6）交易占比：分析线上日志得出tps占比。

1、性能测试之重要指标1）并发用户并发一般分两种情况。一种是严格意义的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。另外一种并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发生了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。2）并发用户数量在同一时刻与服务器进行交互的在线用户数量。3）请求响应时间指的是客户端发出请求到得到响应的整个过程的时间。4）吞吐量指的是在一次性能测试过程中网络上传输的数据量的总和。

1、性能测试需求分析性能测试需求分析，与传统的功能测试需求分析有所不同，功能测试需求分析重点在于从用户层面分析被测对象的功能性、易用性等质量特性。性能测试则需要从终端用户应用，系统架构设计，硬件配置等多个维度分析可能存在的性能瓶颈的业务。2、性能测试必要性评估任何项目在开始性能测试之前，都需要进行必要性评估，通过必要性评估活动，确认被测对象是否有必要实施性能测试活动，千万不可为了性能而性能。通常情况下，必要性评估可以设定不同条件，不同权重进行分析，将评估项分为关键评估项和一般评估项。

1、性能分析方法1）自底向上：通过监控硬件及操作系统性能指标（CPU、内存、磁盘、网络等硬件资源的性能）来分析性能问题（配置、程序的问题）。因为用户请求最终是由计算机硬件设备完成的。2）自顶向下：通过生成负载来观察被测试的系统性能，比如响应时间、吞吐量，由外及里一层一层分析，从而找到性能问题所在。备注：两种方法建议结合使用，先用自顶向下的方式解决掉明显性能问题，再结合 自底向上的方式分析更深层次的问题。

1、性能测试场景设计性能测试场景设计，是性能测试中的重要概念，性能测试场景设计，目的是要描述如何执行性能测试。通常来讲，性能测试场景设计主要会涉及以下部分：并发用户数是多少？测试刚开始时，以什么样的速率来添加并发用户？比如，每秒增加 5 个并发用户。为什么要逐步增加负载？如果我们一下子将负载升到峰值，系统如果支持不了，会一瞬间挂掉。达到最大并发用户数后持续多长时间？测试结束时，以什么样的速率来减少并发用户？比如，每秒减少 5 个并发用户。需要包含哪些业务操作，各个业务用户占比是多少？

1、性能压测–常用指标1）并发用户数指同一时间点对系统进行操作的用户数。准确说为"同时向服务器发送服务请求,给服务器产生压力的用户数量"并发用户数和注册用户数、在线用户数的概念不同：注册用户数一般指的是数据库中存在的用户数，在线用户数只是 ”挂” 在系统上，不一定对服务器不产生压力，而并发用户数一定会对服务器产生压力的。2）每秒事务数(TPS)/每秒查询率(QPS)

交易系统性能是体现互联网证券业务能力的重要指标，如何确保新构建的交易系统能够满足针对互联网大数据量的业务需求成为重中之重。因此必须对交易系统的性能容量指标进行合理的评测，以满足经营机构中长期业务发展的需要。下面将从建模策略和数据采集、软硬件环境配置及性能监控指标定义等方面提出相关测试思路。抛砖引玉，以求更进一步的理解。1、建模策略和数据采集性能测试往往面临如下问题：1）业务模型单一，且与线上实际业务偏差比较大；2）数据脱离实际。

1、什么是全链路压测基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。2、全链路压测解决什么问题针对业务场景越发复杂化、海量数据冲击下整个业务系统链的可用性、服务能力的瓶颈，让技术更好的服务业务，创造更多的价值。3、面对的问题点以及解决方案1）业务模型梳理首先应该明确的是：全链路压测针对的是现代越来越复杂的业务场景和全链路的系统依赖。

1、前期准备性能测试虽然是核心功能稳定后才开始压测，但是在需求阶段就应该参与，这样可以深入了解系统业务、重要功能的业务逻辑，为后续做准备。2、性能需求分析（评审）评审时，要明确性能测试范围、目标；由于非专业性能测试人员不知道怎么定目标，如果你让他们定，可能定的目标会很离谱，比如，要求单机tps10万、支持1万的并发等等，显然是不合理的，你压测也达不到这个目标；

1、测试环境的鉴定我们需要确定软件应用程序的物理测试和生产环境。还需要确定测试团队用到的工具和资源。这里的环境、工具和资源指的是硬件、软件和网络的配置和设置。全面了解测试环境，可以更好的规划和设计本次测试。同时，在测试过程中也需要定期审核环境是否发生改变。以下就是关于测试环境的重要因素：①硬件和机器配置②网络架构和用户位置③域名系统配置④软件安装⑤软件许可证⑥存储容量和数据量⑦日志级别⑧负载均衡⑨负载生成和监测工具⑩网络流量的量和类型⑪预定流程，更新和备份。

1、性能测试TPS上不去的几种原因先来解释下什么叫TPS：TPS：每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量，一般以request/second为单位。下面就说说压测中为什么TPS上不去的原因：1）网络带宽在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。2）连接池可用的连接数太少，造成请求等待。

1、测试策略1）先进行混合业务功能场景的测试，在考虑进行测试单业务功能场景的测试2）负载测试->压力测试->稳定性测试->强度测试注意：如果测试稳定性，时间建议至少8小时；3）逐步加压比如开始前5分钟，20个用户，然后每隔5分钟，增加20个用户。好处：不仅比较真实的模拟现实环境，而且在性能指标比较模糊，且不知道服务器处理能力的情况下，可以帮我们确定一个大致基准，因为通常情况下，随着用户数的不断增加，服务器压力也会随着增加。

1、需求分析测试目的：为什么测？目的在于测试系统相关性能能否满足业务需求。通常分以下两种情况：1）新项目上线2）老项目优化如果是老项目优化，可考虑是否存有历史测试方案，如果有可以参考，或许可以省事很多。测试对象：要测啥？测试对象可以归结为“业务功能”。测试前，需要了解我们需要测试的业务功能（不深入细节）有哪些，比如“购买商品”、“寄送快递”。有没有必要测？需求来源哪里？，有没有数据支撑测试这个需求的必要性？通常，可以从以下几个方面考虑：1）是否核心功能，是否要求严格的质量。

1、必要性分析分析是否有必要进行性能测试；2、被测对象分析确认被测对象，并根据被测对象性质确认测试方案；3、测试技术准备根据被测对象准备测试技术不同协议测试工具、测试重点及方案是有区别的，例如http接口、rpc、websocket、udp测试技术不同，应根据不同的测试对象准备不同的测试方案4、目标评估评估被测服务性能指标预期结果5、峰值QPS已上线的需求可以按目前线上状态评估，这样最准未上线的需求一种方式可以找类似其它功能。

1、Android客户端性能测试常见指标内存、CPU、流量、电量、启动速度、滑动速度、界面切换速度、与服务器交互的网络速度2、预期标准指定原则分析竞争对手的产品，所有指标要强于竞品；产品经理给出的预期性能指标数据；符合业内行业标准；3、测试方法及工具内存：使用adbshell脚本进行测试，查看Log数据。CPU：使用adbshell脚本进行测试，查看Log数据。注意：程序持续运行及操作过程中，内存不能一直增加，不然系统会自动kill掉该进程。流量监控：可以借用网易的开源工具：Emmagee。

4、性能测试用例设计1）单场景场景描述：模拟用户进行登录操作并发量：分别模拟并发用户数为1、10、50三种情况进行测试压测时间：每次15分钟数据量：MySQL的user表中有70万账户集合点：不使用集合点重点关注指标：响应时间、事物成功率、应用服务器资源使用情况(CPU、内存、IO)、MySQL数据库资源使用情况(CPU、内存、IO)、应用日志是否有死锁等错误、数据库日志是否有死锁等错误、JVM内存使用情况和GC情况。

性能测试什么时候开始？一般在系统功能稳定没有大的缺陷之后开始执行。但前期准备工作可以从系统需求分析时就开始：性能目标制定、场景获取、环境申请等。1、制定性能测试目标在特定的并发用户数下测试特定场景的响应时间在一定的响应时间的要求下来测试特定场景的最大并发用户数测试特定场景的TPS1）线上系统对线上系统的日志进行分析以获取到这个系统每个功能的访问情况、最大的并发用户量、平均/最大/最小响应时间。然后通过每日的增长趋势来确定最大的并发用户数、响应时间参考日志分析的结果，即与平均响应时间相当。

1、软件性能的关注点对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果以用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间，当响应时间较小时，用户体验是很好的。当然用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索，这时用户并不知道我们后台在做什么。

1、Web应用压力测试在众多软件测试类别中，Web应用压力测试是其中基础的测试工作，常见的软件压力测试要关注怎么给应用进行施压，正确评估系统存在的瓶颈问题，以及预估系统能够承载的测试压力等方面因素。web应用压力测试也不例外，举个简单的例子，线上演唱会门票抢购页面在面对大量的用户涌入时系统常常崩溃，让网友体验感很差。如何确保系统不崩溃就与做好web应用压力测试有关了，那么怎么做Web应用压力测试？常规的步骤有哪些呢？1）什么是Web应用压力测试？

1、何时介入性能测试1）压测的时机我们选择什么样的时机去介入压测，时机的选择是很重要的，如果时间选择不对呢，那么可能压测都是无用功。或者是高投入，低产出的。我大概总结了几个时机。项目上线稳定后，对系统的评估；系统研发后期，对系统的检验；活动前，摸高压测，预估流量；线上出现性能问题；合作活动、系统，对方要求上线前压测；大概是5个方面，当然了，也不只是这些，这里只是做了几种情况的列举。我们接下来可以详细的看看。

1、需要登录的接口性能测试在实际业务场景中，很多业务都需要先登录才能正常使用。在做接口性能测试的时候，需要测试登录后才能访问的接口肯定是无法避免的。那么，我们怎么才能完成先登录后发出请求的性能脚本呢？思路：1）发出登录请求2）提取响应的认证内容3）后面的请求引用认证内容提出问题：做性能测试，是模拟多个虚拟用户实现并发的，那我们的登录接口也需要重复发起吗？

负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试；压力测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试。例子：登录接口，我们先10个用户访问，然后100个用户访问，然后1000个用户访问，关注程序的响应时间，所耗资源，直到超时或关键资源耗尽。压力测试：是指程序长时间运行的稳定性。

1、性能测试如何选择并发用户数并发用户：指的是现实系统中同时操作业务的用户，在性能测试工具中一般称为虚拟用户(VirutalUser)。并发用户跟注册用户、在线用户有很大差别，并发用户一定会对服务器产生压力，在线用户数只是”挂”在系统上对服务器不产生压力，注册用户一般指的是数据库中存在的用户。TPS：TransactionPerSecond,每秒事务数,是衡量系统性能的一个重要指标。

1、究竟什么是压力测试压力测试指的是在高并发大流量下进行的测试，测试人员可以通过观察系统在峰值负载下的表现，从而找到系统中存在的性能隐患。与监控一样，压力测试是一种常见的发现系统中存在问题的方式，也是保障系统可用性和稳定性的重要手段。而在压力测试的过程中，我们不能只针对某一个核心模块来做压测，而需要将接入层、所有后端服务、数据库、缓存、消息队列、中间件以及依赖的第三方服务系统及其资源，都纳入压力测试的目标之中。因为，一旦用户的访问行为增加，包含上述组件服务的整个链路都会受到不确定的大流量的冲击。

1、性能测试是什么？性能测试是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。性能测试概括为三个方面：应用在客户端性能的测试；应用在网络上性能的测试；应用在服务器端性能的测试；通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。目前绝大多数应用都是基于网络的分布式应用，我们无法知道用户数量，用户场景的不确定性，导致系统测试时，不仅仅是功能，业务逻辑，接口测试，还要测试系统性能。