性能测试相关知识

一：性能测试的相关指标

1. 请求响应时间
2. 请求结果成功正确率
3. TPS 每秒处理的成功交易数（完整事务）
4. 并发数
5. cpu利用率
6. JVM内存利用率
7. fullGc频率

测试指标示例（具体由项目组评判确定） 

二：相关术语

1. VUser：Vistual User，虚拟用户
2. 性能测试：模拟系统在负载的情况下，系统的响应指标，吞吐量等指标是否满足性能要求
3. 负载： 模拟业务操作对服务器造成压力的过程
4. 负载测试：在一定的软硬件环境下，通过不断加大负载，来确定在满足各项性能指标的情况下，系统能承受的最大用户数
5. 压力测试：在一定的软硬件环境下，通过不断加大负载使服务器的某种硬件资源处于极限状态，测试系统在极限状态下能否长时间稳定运行。（只要保证服务能正常运行不出错，不考虑性能指标如响应时间）。
6. 配置测试： 测试不同软硬件配置的情况下系统的性能情况，从而为设备选择，设备配置，软件配置提供参考。
7. 稳定性测试： 在一定的软硬件环境下，长时间运行一定负载（一般为负载测试下用户数的1.5到2倍的负载量），测试系统在这种负载下能否长时间稳定运行。
8. 场景： 并发数，请求（交易）种类，占比，执行时长的不同组合；
9. 思考时间（think time）： 模拟用户在实际操作时的不同请求的间隔时间，在测试脚本中体现为两个请求语句之间的间隔时间。
10. 标准差： 包括响应时间标准差，Tps标准差，cpu利用率标准差等，标准差越小，表示系统越稳定。
11. TPS： 每秒成功的事务数。
12. PV：Page View，每秒用户访问页面的次数。
13. RT/ART：响应时间，平均响应时间。

三：性能测试有哪些类型？

按照测试的方式

负载测试

压力测试

配置测试

疲劳测试，稳定性测试

容量测试

失效恢复测试

外网测试（非内网，真实环境）

按照测试场景

单交易基准测试

单交易并发测试

混合场景测试

四：性能测试的大致流程

1. 业务学习，通过查看文档等方式来了解系统功能。（找产品经理）
2. 需求分析，圈定性能测试的范围，了解系统性能指标。（1.用户喜欢用哪些功能，哪个时间段用，用户大概是多少；2.需要有多少的数据量；3.系统架构是什么样的，模块之间的调用关系；4.运维日志有没有（已上线系统有），有的话进行用户行为分析；5.市场计划需求（是不是要搞活动）；6.项目管理计划，帮助我们明确测试执行的优先级）。
3. 设计模型（场景分析，事务考虑，挡板设计）。
4. 计划编写，在文档中写明测试范围，人力投入，预计时间，工作内容，风险评估，风险应对策略等。
5. 
6. 脚本开发或录制，如果不能录制需要自己开发。开发测试挡板程序。
7. 
8. 测试环境准备，主要包括系统服务器和负载机两部分，系统服务器是被测系统的运行平台，负载机是我们用来产生负载的机器，用来安装负载工具，执行测试脚本。
9. 
10. 测试数据准备，包括基础数据和业务数据的准备，基础数据如用户，菜单数据，业务数据值执行业务时设计的数据，如下单时订单，库存都是业务数据，准备数据时需要考虑数量与分布。
11. 测试执行，根据不同的测试场景进行执行，监控服务器资源使用情况。记录测试执行过程中的问题。
12. 性能分析，对执行过程中暴露出来的问题进行分析，找出原因。
13. 性能调优，性能测试工程师和开发组人员一起进行性能调优。
14. 生成性能测试报告，测试目标，测试情况，测试总结。

五：性能测试重要关注点

• 需求分析：一般需要进行测试的模块有：

                1.关键的业务流程

                2.业务逻辑复杂的模

                3.日pv量会比较高的模块

                参考同行业务，确定热门业务，测试指标

• 场景设计，用例设计，充足的系统调研和分析后，我们要在测试场景中尽可能真实地复原系统负载，按业务分布，业务量，业务时段，业务角色来分配用户数，执行时间，执行比例
•  测试执行，检测指标，分析定位问题，解决问题

六：测试工具之Jmeter

Jmeter与LoadRunner的异同

工具无所谓好坏，对应企业来说，快速，高效，低成本的解决性能问题

Jmeter的相关术语

组件：元件的上级菜单，元件的集合。

元件：最小的功能菜单，如具体的http取样器，if控制器

控制机：

• 在使用多台负载机的情况下，被选中作为管理机的那台机器即为控制机。
• 负责管理和执行远程负载机，同时收集远程负载机的执行结果。
• 控制机也可以进行负载。

负载机：

• 向被测系统服务器发起负载的机器。
• 受控制机管理，需要先启动Agent:jmeter-server.bat
• 接收控制机的运行脚本，但是不能接收参数文件和依赖的jar包，需要手动拷贝或自动化拷贝（自动化测试）

Jmeter测试计划基本要素

• 一个测试计划
• 一个线程组
• 一个取样器
• 一个监听器

Jmeter常用组件执行顺序

1. 逻辑控制器（如果存在）
2. 配置元件（如果存在）
3. 前置处理器（如果存在）
4. 定时器（如果存在）
5. 取样器（如果存在）
6. 后置处理器（如果存在且取样器的结果不为空）
7. 断言（如果存在且取样器的结果不为空）
8. 监听器（如果存在且取样器的结果不为空）

jmeter永久修改语言类型

Jmeter如何利用思考时间

压测环境配置

如何确定系统服务器数量  （每次压测环境也不太一样）

例如测试秒杀场景的时候，使用10台负载机，被测系统服务器各两台，数据库服务器两台，redis服务器6台

监控常用linux指令

监测cpu：vmstat    cat /proc/cpuinfo  top  ps   lscpu

监测内存：free命令  ，vmstat   , cat /proc/meminfo

监测网络：netStat

监测磁盘: Iostat    df -a    df -aT   du

遇到过的性能测试问题

稳定性测试，tps掉坑

性能测试定位流程

影响软件性能的因素：并发用户数，硬件因素，软件因素

参考资料：工具日志，应用服务器日志，数据库日志，性能监测到的指标

jmeter单压测机命令行模式启动

上传jmx文件至远程服务器（云服务器）

 

 将远端服务器执行的聚合jtl文件在GUI本地界面打开（summary report）

将远端生成的测试报告index.html在本地打开

 生成测试报告dashBoard的解释说明

 

jmeter分布式

1.控制机与压测机安装好jdk和jmeter环境，相同版本号，如果有csv文件导入相同目录（注意：路径相同且不能用中文和空格）

1.修改remote_hosts,设置ssl.disable= true;

 2.修改从节点的端口号为使用的端口号，设置ssl.disable= true;

3.关闭从节点防火墙和其他网卡，启动从节点jmeter-server

 5.在控制机导入jmx文件，使用命令行启动压测  -r 表示有远程压测机

 5.导出测试报告，查看

分布式压测常见问题汇总 

 

 Jmete性能优化建议（非GUI）

性能测试报告结果一般包括

 硬件需要明确的事项

应用服务器  数据库服务器  中间件服务器，每个服务器肯定不止装一个服务（应用，数据库，或者中间件），了解单个应用的使用硬件资源占比，这样可预测性部署应用个数。

需要记录的硬件指标：

csv是静态数据，以下方法可以取得动态数据

 

jdbc取样器动态获取数据库内容，提取为变量

增加测试覆盖率的方法：数据库随机取值，例如id，作为变量在接口请求中使用，判断接口请求时返回的数据库记录id与数据库发送时的id是否一致（json断言） 

 

性能定位：

是不是限流数应该调整

是不是慢查询了

是不是数据库连接少了

性能优化：

Tomcat：

1，最好使用内嵌式tomcat，自定义tomcat启动操作，使tomcat启动时占用较少的资源；

setting.xml：

2，选择protocal级别:bio nio nio2(Aio)  apr

3，压缩请求内容

4，是否需要调整允许接收的请求的数量，（每个应用服务器服务允许的请求数量，结合义务服务是计算密集型还是io密集型）

5，是否需要关闭tomcat的自动重载（应用发生变化自动更新，需要不停扫描）

 重启：

 3

 4

 5 

服务器为什么会挂掉，如何避免。。

1.需求分析没到位

2.短时间内并发大

3.系统架构缺少扩展性

性能测试专业的人

面试题：系统的并发用户数是多少？或者系统的响应时间是多少？

首先明确：衡量系统处理能力的核心指标是tps

核心回答思路：能处理的tps是多少，在这个tps下在几秒内的并发用户数最优是多少，在这种情况下rt是多少

需求分析，需求设计，场景设计模板（tps要么公司给，要么自己算）

tps = 并发用户数/响应时间