概述一下性能测试流程？

• 1.分析性能需求。挑选用户使用最频繁的场景来测试。确定性能指标，比如：事务通过率为100%，TOP99%是5秒，最大并发用户为1000人，CPU和内存的使用率在70%以下
• 2.制定性能测试计划，明确测试时间(通常在功能稳定后，如第一轮测试后进行)和测试环境和测试工具
• 3.编写测试用例
• 4.搭建测试环境，准备好测试数据
• 5.编写性能测试脚本
• 6.性能测试脚本调优(脚本增强)。设置检查点、参数化、关联、集合点、事务，调整思考时间，删除冗余脚本
• 7.设计测试场景，运行测试脚本，监控服务器
• 8.分析测试结果，收集相关的日志提单给开发
• 9.回归性能测试
• 10.编写测试报告

如何确定系统最大负载？

通过负载测试，不断增加用户数，随着用户数的增加，各项性能指标也会相应产生变化，当出现了性能拐点，比如，当用户数达到某个数量级时，响应时间突然增长，那么这个拐点处对应的用户数就是系统能承载的最大用户数

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

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

你们的并发用户数是怎么确定的？

1）会先上线一段时间，根据收集到的用户访问数据进行预估

2）根据需求来确定（使用高峰时间段，注册用户数，单次响应时间等

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

参考答案：我们会搭建一套独立的性能测试环境进行测试

你们性能测试什么时间执行？

基准测试：功能测试之后，系统比较稳定的时候再做。

负载测试：夜深人静，系统没人用的时候

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036【暗号：csdn999】

怎么分析性能测试结果？

首先查看事物通过率(错误率)，然后分析其他性能指标，比如，确认响应时间，事务通过率，CPU等指标是否满足需求；如果测试结果不可信，要分析异常的原因，修改后重新测试(复测)。

在确定性能测试结果可信后，如果发现以下问题，按下面的思路来定位问题

问题一：响应时间不达标

查看事务所消耗的时间主要在网络传输还是服务器，如果是网络，就结合Throughput(网络吞吐量)图，计算带宽是否存在瓶颈，如果存在瓶颈，就要考虑增加带宽，或对数据的传输进行压缩处理；如果不存在瓶颈，那么，可能是网路不稳定导致。如果主要时间是消耗在服务器上，就要分别查看web服务器和数据库服务器的CPU，内存的使用率是否过高，因为过高的CPU，内存必定会造成响应时间过长，如果是web服务器的问题，就把web服务器对应上对应的用户操作日志取下来，发给开发定位；如果是数据库的问题，就把数据库服务器对应上对应的日志取下来，发给开发定位。

问题二：服务器CPU指标异常

分析思路：就把web服务器对应上对应的用户操作日志取下来，发给开发定位。

问题三：数据库CPU指标异常

分析思路：把数据库服务器对应上对应的日志取下来，发给开发定位。

问题四：内存泄漏

分析思路：把内存的heap数据取出来，分析是哪个对象消耗内存最多，然后发给开发定位。

问题五：程序在单用户场景下运行成功，多用户运行则失败，提示连不上服务器。

原因：程序可能是单线程处理机制

如何识别系统瓶颈？

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

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

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

你们的性能测试需求哪里来？

1：客户提供需求

2：运维提供需求(负责服务器的稳定性)

3：开发提供需求

如何实现200用户的并发？

在脚本对应的请求后添加集合点(绝对并发)

相对并发：线程组设置200线程数

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

当脚本的上下文有联系，就用关联。

比如登录的token关联，增删改查主键id关联

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

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

2、使用万能的验证码

你们性能测试做的是前台还是后台？

BS项目：测试的是后台服务器的性能和浏览器端性能；

APP项目：手机端和服务器端的性能都做

性能测试指标有哪些

响应时间

吞吐量

cpu

内存

io

disk

如何脚本增强？

1、做参数化

2、做关联

3、添加事务

4、添加断言

5、添加集合点(jmeter的同步定时器)

6、添加思考时间(jmeter的统一随机定时器和固定定时器)

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

先回顾下基础，性能测试常用的指标有三个：并发、响应时间、tps

　　并发：跑道里参加赛跑的人数（这里的并发是广义的并发，即同一个时间段内对系统发起的请求数量）

　　响应时间：也就是平均每个事务的处理时间

tps：每秒处理的事务数

需求指标：分为单指标和多指标

　　单指标：一般是单测试tps，或者根据并发测试响应时间，或者根据响应时间测试并发，只考虑单指标的很少

　　多指标：要同时考虑多个指标，比如tps + 响应时间(<1s)

这个题，意思就是要找到这三个指标同时最佳值的点，即：不能只追求并发数大，而忽略tps，所以，这是一个多指标性能需求，假设是这样的：要求响应时间1秒以内，并发数要尽可能的多，tps要尽可能的大。

是不是依旧有点懵逼？先画一个简单的示意图，方便大家理解：随着并发数增加，响应时间肯定是越来越高，所以，上面红线是响应时间；

随着并发数增加，tps是先升高到峰值，然后下降（也可能是一直平稳，或者平稳一段时间再下降），所以，上面蓝线是tps；

紫色表示并发用户数；

该怎么去找这个最佳平衡点呢？

1.尽可能多的做不同并发数下的压测，记录下响应时间（1s以内）和最大tps，当然，服务器端，各个服务器的资源利用率在可接受范围内（每个公司不一样，我们是90%以内）；

2.然后根据获取到的不同并发下的指标数据（并发数、tps、响应时间），画出上图，关注右侧的交点，即tps下降的地方和响应时间的交点，这个点的tps最大，如果响应时间在1s以内，此时并发数也是比较大的，这个点就可以认为是三个指标都不错的平衡点（当然，我这里把tps放在第一位优先考虑了，这个就看大家最在乎哪个指标了，排个优先级）；如果响应时间大于1s，最佳平衡点就往左找，找到响应时间为1秒的点，此时对应的tps和并发值，就是最佳平衡点。总之，测试采样越多，获取的平衡点就越准确。

另外，如果是用loadrunner作为并发工具，并发过程中是可以增加或者减少并发用户数的，就不用必须压完一次，再调整并发数继续压，但是，loadrunner并发过程中调整了并发数，还是要尽可能跑久一点，比如10-15min。

END今天的分享就到此结束了，点赞关注不迷路~