零、压测指标问题

压测指标，一定要需求方定 啊，谁提压测需求，谁来定压测指标。

如果需求方，对压测指标没有概念，研发和测试，可以把历史压测指标、生产数据导出来给需求方看，引导他们来定指标，千万别自己定啊。不然将来大锅要自己背的。

一、环境问题

1、保证本地环境（jmeter版本、jdk版本）与Linux负载机环境一致，不然可能会报错。

jmeter脚本，要禁用掉多余的插件（查看结果树、曲线图之类的）。

2、jmeter内存设置

要保证jmeter有足够的内存，不然启动或者写日志的时候，会内存不足的错误。

3、确认一下linux负载机，网络与被测系统的ulr是否时通的。可能会遇到ping不通的情况，可能是运维做了某些限制，及时与运维沟通

4、负载机与被测系统，要在同一个局域网内，为了避免网络带宽的限制，以至于负载机给不了足够的压力。

5、提前与开发/运维人员，确认被压测系统有没有过载保护之类的，比如有的有ip限制，同一个ip只能并发3个请求。

二、数据问题

2.1 系统体量

背景：为了测试在一定用户体量下的性能表现，需要提前向数据库中注入100万的用户数据。

1、向数据库注入数据之前，要确保造数据的脚本是正确的。需要先在其他备份数据库里尝试一下，不要造成脏数据

2、向数据库注入数据之前，要提前将现有数据备份一下，避免造数据，将现有数据弄乱。

2.2 压测使用的数据问题

1、要压测登录功能，需要提前准备十万条登录数据。将数据从数据库导出来后，要提前校验一下这十万条数据是否都可以用。

三、脚本问题

1、有的脚本，在低并发的时候不会报错，但是在高并发的时候会报错。

比如登录问题，当高并发的时候，会出现几个线程使用同一个账号进行登录，导致登录失败。

解决办法：

a、增大登录用户的数据量

b、使用循环控制器，依次读取数据

2、 缓存因素影响

查询类接口，是否有缓存，我们压测的策略也是不一样的。

在写压测脚本时，及时与开发沟通，哪些接口是否涉及到缓存影响。

或者我们直接使用参数化，这样即使有缓存，也会避免缓存的影响。（当然最好提前与开发确认一下哪些是否有缓存）

3、加密、验签等需要脚本处理

在压测接口的时候，有时候需要提前处理数据，加密啊、验签等。一定要使用java来处理这些，不要用js等这些歪门邪道的语言。

同样一个验签处理，用js处理，2分钟，打出了8000个样本请求。

用java处理，2分钟打出了300000个请求。 js脚本严重制约了性能。

四、流程问题

1、提前与运维、业务方、开发测试等项目相关人员确定是否对他们有影响

2、第三方依赖。有的系统需要依赖第三方，需要做挡板处理。

五、压测数据收集

记录压测开始与结束的时间很重要，方便开发查询定位问题。

使用命令：

jmeter -n -t /home/test.jmx -l /home/xx.jtl -e -o /home/xx_report/

生成的report index.html 会记录压测开始与结束时间。手动记录一下也可以。