m0_70102063的博客

1、保险项目-性能测试印象深刻的bug【性能测试】履约域12并发压测理算提交接口，压力机每秒发送10笔数据，响应时间超过1100ms，指标要求小于800ms。【性能测试】运营支撑域SDK压测计算公式，频繁出现FGC。【性能测试】履约域10并发压测理算初始化接口，每秒发送9个请求，midagrmt-execution-management服务出现报错，且CPU占用满，需要优化。【性能测试】履约域10并发压测理算初始化接口，出现内存满导致系统重启。

1、银行对公渠道转账测试点转账测试点：1）点击转账按钮是否跳转到转账界面2）转账比如最低为0.01，最高为5万元，采用边界值测试0.01,100,50000,0.09,50000.01这种能不能转，或者输入为空，里面包含非法字符或者中文字符的能不能转3）转账是否需要填写对方的户名和银行名称，以及支行名称4）不存在的账户号和销户的账户号是否可以转账5）转账金额是否可以小于或等于可用余额6）转账输入框输入以0开头的金额，转账金额框自动去掉07）付款用途能否选择。

怎么计算得出tps指标？1）第一个通过运维那边给的生产数据，看一下生产进件有多少，计算得来的，如果没有生产数据，或者不过就看如下的方法2）第二个就是根据最近一个月的实际访问数据，比如每天调用了多少个接口，调用了哪些接口，把比例列出来==》这是通用的tps比如这100万次请求里面登录请求比例：40% 那么登录接口的标准退出请求比例：20% 那么退出接口的标准添加商品比例：20% 那么添加商品接口的标准查询商品比例：10% 那么查询商品接口的标准。

案例1：性能测试压测50怎么做的？在工作中我测试会对单个接口进行压测或一个性能场景进行压测；首先会分析需求，根据需求分析接口和场景做性能；设计性能场景；根据性能场景使用badboy（或反向代理录制脚本）录制脚本；将录制的脚本进行参数化、并且调通；在测试计划中设置压测用户数，设置压测时间，在添加查看结果树、聚合报告、tps插件、hps插件、混合图标、图像报告、表单报告等插件，在服务器中也可以使用nmon来采集硬件指标：cpu、内存、硬盘、网络I/等，或top命令去监控，在点击执行；

两种性能指标：① 业务指标：业务场景② 技术指标时间指标：接口响应时间、业务响应时间容量指标：接口容量、业务容量资源利用率指标：操作系统：CPU、IO、Disk、Mem1、并发狭义：指同一时间点执行相同的操作（如：秒杀）广义：同一时间点，向服务器发起的请求（可能是不同的请求）只要向服务器发起请求，那么服务器在这一时间点内都会收到请求（不管是不是同一个请求）2、并发用户数同一时间点，发出请求的用户数，一个用户可以发出多个请求场景不一定是同一个和 CPU、响应时间有关系。

1、常见的性能测试策略有哪些？参考答案:基准测试，并发(业务边界值)测试，综合场景测试，负载测试，疲劳测试，极限压力测试，大数据量测试2、完成一个性能测试项目，请阐述你的实施流程？参考答案：测试设计阶段：1）了解被测系统的性能需求，定义测试目标和范围；2）了解系统的技术信息，如系统架构等；3）确定测试方案、进度安排，并制定测试计划,场景设置方案,及需要收集的测试数据；4）同相关人员协商讨论测试方案；5）准备数据收集模板；不同项目的性能测试，需要收集的数据不同；

1、性能测试中常见且重要的一些指标在软件和系统的性能评估中，监控和分析特定的性能指标是至关重要的。以下是一些常见且重要的性能指标，可以参考：1）响应时间定义：从发送请求到接收到响应所需的时间。重要性：直接影响用户体验。较短的响应时间意味着更好的性能。2）吞吐量定义：系统单位时间内处理的请求数（通常以每秒请求数 QPS 或每秒事务数 TPS 表示）。重要性：反映系统的处理能力，吞吐量越高，越能处理大量请求。3）并发用户数定义：系统可以同时处理的用户数。

1、性能测试中如何确定TPS和并发数性能测试中，最难的就是需求不明，无法获取到有效的需求指标，造成测试工作无法推进。所以，我给大家一个预估TPS和并发数的公式。1）计算平均的并发用户数：C=nL/T公式1中：c是平均的并发用户数；n是loginsession的数量;L是loginsession的平均使用时长；T是考察的时间段长度。2）并发用户数峰值：C’≈C+3根号C公式2中：C’指并发用户数的峰值，C就是平均的并发用户数。

性能测试场景设计是指定义和创建用于评估系统性能的模拟场景的过程。这些场景通常包括模拟用户行为、负载模式和使用情况，以便在实际环境下测量系统的性能表现。性能测试场景设计的目标是模拟真实世界中的使用情况，以便评估系统在不同条件下的性能、稳定性和可靠性。1、性能测试的常用方法负载测试：负载测试通过模拟用户实际使用系统的场景，对系统的性能进行测试。这种方法可以模拟并发用户数、访问数量和请求频率等实际使用情况，以评估系统在不同负载下的性能表现。其中的关键是确保负载测试的设置与实际使用情况相匹配。

1、性能测试的前提必要性，是否有做性能测试的必要（关键项评估）1）主管部门、监管部门审查2）涉及生命财产安全3）大型新系统4）核心系统5）架构调整6）业务巨增7）重大缺陷修复可测性，可量化为性能指标值1）一般有需求文档，根据老板或者产品提出的需求，将需求内容量化为性能指标值，这是我们的性能指标预期结果。2）如果无法量化，我们就没有预期性能指标值，在性能测试中测出的性能指标值没有可对比的值，那就不知道是否满足需求。2、开展性能测试必备条件。

用JMeter执行压测，1000线程组，最后几个请求卡住了。网上的资料说可能是内存问题，因此将堆内存从2G改为了4G，重新尝试依然会卡住，有没有什么办法调整资源解决这个问题？我仔细看了他的聚合报告，Max-rt已经到了70000+ms级别，且响应时间分布图峰谷值差距很大，于是便问了他下面这几个问题：为什么要配置1000线程组？什么业务场景，被测服务什么类型？所谓的卡住，是请求没有返回响应报文吗？电脑硬件配置是什么？在什么环境执行的性能测试？

1、传统性能测试在传统的性能测试中，理论上都要求测试参与需求评审，评估是否存在可能的性能瓶颈场景。其次在技术方案设计阶段，和开发一起过方案，讨论方案的可测性和是否会导致性能问题。然后在研发阶段准备对应的测试环境，写压测方案，准备测试用例和数据，直到系统集成测试阶段，才开始介入真正的压测执行工作。但在实际的工作场景中，很多性能测试同学遇到的往往是一句话需求。比如：这几个接口压测一下，出一份报告；或者线上出了性能问题，才火急火燎的找测试同学，对系统进行压测，再排查定位问题。

1、介绍下最近做过的项目，背景、预期指标、系统架构、场景设计及遇到的性能问题，定位分析及优化？考察点：对项目的了解情况；需求分析和场景设计思路；问题分析思路及优化验证手段；参考答案：最近做了一个XXX项目，背景是老服务重构，预期指标是在原有系统基础上性能提升3倍，架构设计是XXX。针对这个项目我梳理了核心应用和接口有XXX个，对应的场景有XXX，我的压测策略是XXX。

1、理解全链路压测1）什么是全链路压测基于实际的生产业务场景和系统环境，模拟海量的用户请求和数据，对整个业务链路进行各种场景的测试验证，持续发现并进行瓶颈调优，保障系统稳定性的一个技术工程。2）全链路压测解决了什么问题业务场景越发复杂化、海量数据冲击下，发现并解决业务系统的可用性、扩展性以及容错性问题。3）全链路压测创造了什么价值业务角度：提升用户体验、增强业务竞争力、创造更多的业务价值；技术角度：完善技术体系、提高服务可用性、更好的服务业务而体现自我价值；

如何得到精确的性能瓶颈？性能测试和功能测试在本质上没有区别，大体的流程也没差，无非是分析需求，准备用例、执行用例、确认BUG、跟进修复验证，最终出具测试结果/报告。两者的不同点在于，侧重不一样：功能测试侧重需求的正确实现，性能测试更注重系统的处理能力是否能支撑真实的用户访问。在功能测试开展前，我们会分析需求，确认需求要实现的功能最终是什么表现形式，以便于设计测试用例和预期结果，性能测试同样如此。

性能测试的应用领域划分为下面五个不同领域：能力验证、规划能力、性能调优、瓶颈发现、性能基准比较1、能力验证能力验证是性能测试中最简单也是最常见的一个应用领域。一个典型的能力验证的问题会采取这样的描述方式：某系统能否在A条件下具有B能力？能力验证领域的特点与性能测试的特点非常接近：①要求在已确定的环境下运行只有在一个确定的环境下运行，软件性能的验证才是有意义的；因为无法或很难根据系统在一个环境中的表现去推断其在另一个不同环境中的表现，因此这种应用领域内的测试。

1、内存分析内存的使用情况是系统性能中重要的因素之一，频繁的页交换及内存泄露都会影响到系统的性能（这里主要以Windows系统为主）。内存分析用于判断系统有无遇到内存瓶颈，是否需要通过增加内存等手段提高系统性能表现。1）查看Memory\Available Mbytes指标在对系统进行操作系统级别的内存分析时，首先需要通过该指标（Available Mbytes：Windows系统自带计数器的一个计数值）建立一个初步的印象，了解性能测试过程中系统是否仍然有足够的内存可用。

1、传统性能测试的桎梏在传统的性能测试中，理论上都要求测试参与需求评审，评估是否存在可能的性能瓶颈场景。其次在技术方案设计阶段，和开发一起过方案，讨论方案的可测性和是否会导致性能问题。然后在研发阶段准备对应的测试环境，写压测方案，准备测试用例和数据，直到系统集成测试阶段，才开始介入真正的压测执行工作。但在实际的工作场景中，很多性能测试同学遇到的往往是一句话需求。比如：这几个接口压测一下，出一份报告；或者线上出了性能问题，才火急火燎的找测试同学，对系统进行压测，再排查定位问题。

1、性能测试实施流程正常的性能测试实施流程。一般情况下性能测试实施的流程是这样的：需求分析：什么业务/场景/问题，预期目标；构建模型：业务模型、流量模型、数据模型；压测准备：环境准备、脚本开发调试、监控检查；压测实施：按照case执行脚本，监控指标，定位分析；压测报告：场景覆盖度，结果是否达标，对线上的容量规划建议(结论)；当然，在实际的工作场景中，出于时间/资源/团队规模和技术建设等各方面的因素，会有会多或少的改变。

1、性能测试面临的痛点结合个人的实践经验来说，在性能测试实践中，最常见也是最大的痛点有如下四点：1）性能目标不合理：最典型的不合理的地方就是一句话需求。领导或者开发说系统要上线了，你把这个系统/接口压一下，明天给我报告，然后就没了。为什么要压测，要解决什么问题(请求慢还是客户要求)，预期的性能指标是多少，要啥没啥。这其实就是不同岗位对于同一件事的不同认知带来的差异。

搭建性能测试环境，有哪些需要注意的点？性能测试环境配置，必须和生产保持一致吗？什么情况下性能测试环境可以和生产保持一致？如何搭建性能测试环境，才能在成本和价值间保持平衡？1、独立性能环境的重要性有些同学担心，由于性能测试环境和线上环境配置不一致，会导致线下环境得到的性能结果无法发现足够多的性能问题，无法对线上环境的容量评估/稳定性保障带来足够的参考。其中担心的重点有如下几点：1）配置不一致，服务的容量无法很好的换算；2）配置不一致，导致压测时候无法模拟太高的并发；

性能测试，说简单也简单，因为实施性能测试的方法和流程和正常的功能测试没太多区别。说难也难，因为要想正确的开展性能测试并达到目标，对技术广度和深度都有一定的要求。误区1性能测试就是工具+高并发这是很多初学者最容易犯的一个错误，认为性能测试就是找个工具模拟高并发，不断加压然后看监控统计结果，其实不然。举一个在技术交流群看到的例子：单接口调用没问题，用JMeter调试系统返回code:500。遇到这个问题该如何处理呢？

性能测试和功能测试在本质上没有区别，大体的流程也没差，无非是分析需求，准备用例、执行用例、确认BUG、跟进修复验证，最终出具测试结果/报告。两者的不同点在于，侧重不一样：功能测试侧重需求的正确实现，性能测试更注重系统的处理能力是否能支撑真实的用户访问。在功能测试开展前，我们会分析需求，确认需求要实现的功能最终是什么表现形式，以便于设计测试用例和预期结果，性能测试同样如此。

1、产品需求1）业务场景：一个问卷调查的功能，然后产品和业务会不定时通过前端界面去根据筛选条件查询相关问卷问题的答案明细，但是觉得很慢，让测试这边给出一个指标。2）系统架构：MySQL数据库，所有问卷问题相关的数据都存储在同一张表，单台服务器，无缓存，通过一个查询接口去查询返回数据。3）数据量：每天大概新增3000张问卷调查，每张问卷30个问题，每个问题下面还有具体的答案，答案的数据类型、大小不清楚。2、具体问题具体分析1）场景建模。

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

引发性能瓶颈的原因是多种多样的。1、注意事项1）断言在压测时，为了判断发送的请求是否成功，一般会通过对请求添加断言来实现。使用断言时，建议遵循如下规范：①断言内容尽量以status/code、msg/message来判断（当然前提是接口设计遵循Restful规范）Jmeter示例：阿里云PTS：如果使用的是PTS压测，则断言设置中，以code/status、msg/message等于对应的值为准；

1、性能测试流程性能测试的步骤大概分四个阶段：需求分析阶段、准备阶段、执行阶段、报告整理和总结阶段需求分析阶段：1）熟悉项目相关的资源，如：架构设计，软硬件环境配置，线上业务运营数据（交易量，用户活跃度，请求分布等）2）根据运营数据或者指标，确定性能测试要达到的目标，如：支持xx并发，tps要达到多少，响应时间要达到多少，CPU，网络，IO的负载情况等等3）设计性能测试计划：与功能测试差不多–项目背景；–项目结构；–测试功能；–软硬件资源准备；–时间/人力安排；

并发用户数：是指现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)。并发用户数和注册用户数、在线用户数的概念不同。并发用户数一定会对服务器产生压力的；而在线用户数只是 ”挂” 在系统上，对服务器不产生压力；注册用户数一般指的是数据库中存在的用户数；TPS：Transaction Per Second, 每秒事务数, 是衡量系统性能的一个非常重要的指标。

1、测试工程师发展路径从两种不同的路径发展来看：管理路线：测试工程师？中级测试工程师？测试主管技术路线：软件测试工程师？中级测试工程师？高级测试工程师？测试专家？测试总监软件测试每个阶段有不同的要掌握的技术和经验，先按照薪资范围划分下（月薪）7-10K：零基础入门，学会功能测试能够找到工作15-25K：测试在职能搞定性能测试和自动化测试25K+：搞定测试开发，在一线大厂工作每一个阶段的侧重也不同，入门到找工作的阶段肯定是以能就业为主，性能和自动化测试是在技术基础上有行业经验。

性能测试实施流程性能测试流程分为五个阶段，分别是【需求调研阶段】→【测试准备阶段】→【测试执行阶段】→【测试报告阶段】→【测试总结阶段】。1、需求调研阶段1）阶段概述调研阶段的主要工作为：组建工作小组、项目创建、需求分析、模型构建、定制性能测试详细实施计划。重点关注：需求调研、需要分析、模型构建2）关键点描述需求调研分为两个步骤进行：需求调研、需求分析。该工作是性能测试必须的工作环节。工作产出文件为《XX 项目性能测试需求表》，如：《云智慧_XXX 系统_XXX 模块性能测试需求表》。

1、性能测试介绍为什么要做性能测试？有效的性能测试能给研发，运维团队提供有效的容量规划能力，系统风险识别，系统瓶颈识别，性能调优指导。2、性能测试流程与方法分析现状获取当前性能指标定义用户场景定义性能验收标准测试计划/脚本准备压力环境执行压测监控搜集分析测试报告改进建议持续测试3、性能测试方法性能测试方法：并发模式（虚拟用户模式）并发是指虚拟并发用户数，从业务角度，也可以理解为同时在线的用户数。

1、稳定性测试的要点1）长时间的以正常的业务负载进行运行（最低为用户实际使用时的负载量，如果用户实际负载量低于最优负载量，也可以使用最优负载量）2）稳定性的测试数据（用户实际使用负载量）来源于运营数据3）稳定性测试时，需要针对不同的业务操作，并且模拟不通的用户，进行长时间的稳定性测试（并行执行所有脚本，因为要模拟实际用户使用场景，不同的用户在线所做的动作肯定不一致）2、性能测试的监控的关键指标1）系统指标：与用户场景和需求相关的指标用户并发数：某一物理时刻同时向系统提交请求的用户数。

Jmeter分布式测试时需要的特别注意1）参数化文件的位置和内容如果使用csv文件进行参数化，即通过读取csv文件中的数据来为测试脚本提供不同的输入值，那么需要注意以下两点：需要把参数文件在每台slave上拷贝一份，最好都放置在bin目录下，因为Jmeter会直接从bin目录下查找；参数文件的内容要保持一致，即每台slave上的参数文件的行数、列数、数据类型等都要相同，否则可能会导致数据不匹配或缺失。2）slave机器的响应数据。

1、什么是负载测试？什么是性能测试?负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担，在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

1、什么是性能测试？指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。功能测试的时候关注的是1个人的操作，性能测试关注的是多个人。2、性能测试什么时候做？接口测试是最先做，性能测试是最后做。性能测试是基于所有功能都测试完毕并且修复完成，基本不改变，正常测试流程已经全部走完，在上线前的两三天做性能测试，性能测试通过则可以上线。3、不同群体眼中的性能1）用户的视角响应时间（还要让我等多久？需要加载老半天才出现页面？确定性（为什么总是失败？闪退？无响应？2）开发视角。

Jmeter分布式压测简介在工作中使用jmeter做大并发压力测试的场景下，单机受限内存、CPU、网络IO，会出现服务器压力还没有上去，但是压测服务器已经由于模拟的压力太大死机了。为了让jmeter工具提供更强大的负载能力，jmeter提供了多台机器同时产生负载的机制，下面是架构图。安装部署步骤1、在master和slaves机器上分别按照相同版本的jdk和jmeter2、在master机器上①修改配置文件，进入jmeter/bin目录下。

实现对登录密码进行MD5加密pom文件依赖MD5Util类} }} }} }} }} }} }package打包生成jar文件。方式一：把jar包加入到classpath添加jar包login请求beanshell脚本发送请求后，从查看结果树中可以看到请求的密码加密了方式二：把jar包放到lib/ext下。

架构：VM1：用作 Web 服务器，来模拟性能问题VM2：用作 Web 服务器的客户端，来给 Web 服务增加压力请求使用两台虚拟机（均是 Ubuntu 18.04）是为了相互隔离，避免交叉感染VM2 运行 ab 命令（初步观察 Nginx 性能）简单介绍 ab 命令ab（apache bench）是一个常用的 HTTP 服务性能测试工具可以向目标服务器并发发送请求运行 ab 命令并发 10 个请求测试 VM1 的 Nginx 性能，总共测试 100 个请求。

第一部分：主要从问题出发，引入接口测试的相关内容并与前端测试进行简单对比，总结两者之前的区别与联系。但该部分只交代了怎么做和如何做？并没有解释为什么要做？第二部分：主要介绍为什么要做接口测试，并简单总结接口持续集成和接口质量评估相关内容。第一部分后端接口都测试什么？怎么测的？后端接口测试一遍 ，前端也测试一遍，是不是重复测试了？后端接口都测试什么？怎么做接口测试？由于我们项目前后端调用主要是基于http协议的接口，所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。

并发/负载/压力理解负载测试：通过不断加压使系统达到瓶颈，为调优提供参考数据压力测试：稳定性压力测试：在不同的给定的条件下（比如内存的使用，一定时间段内有多少请求等），系统表现出来的处理，反应能力（这里会考虑系统的容错能力，恢复能力）破坏性压力测试：不断加压，直至系统崩溃，挂掉，来得出系统的最大承受能力在哪儿并发测试：简单理解就是业务场景短时间内有大量的请求需要处理，一般出现在登陆或者某些比较重要的模块，按钮。压力测试。