Web性能测试之发压篇

Posted 2021-04-30 360搜索测试

性能测试重要的是如何发压，在什么样的环境下进行，用什么样的流量进行压力测试。这里主要介绍一下Web端性能测试各阶段需要注意和考虑的问题：

1.对测试系统进行分析，明确需要对什么进行压力测试（接口？web页面？）

详细说明：

• 接口：接口中有哪些参数，各含义，是可选项还是必选项，取值范围，是计算密集型，还是IO密集型，期望性能

• Web页面，包含哪些接口，涉及哪些服务，期望性能

2.明确被测对象后，考虑测试环境

a）被测服务环境是否独立【一般情况下，被测服务的环境尽量与其他服务分开】

b）被测对象是否有缓存【要根据实际情况，确定压测过程中是否开启缓存】

详细说明：首先要了解缓存的有效期，真实的环境中命中缓存的比例大概是多少；不带缓存压测，可知晓系统的最差性能。带缓存压测，数据集的选取非常重要。

c）发压机与被测环境要在同机房【简单的ping命令，查看大概的访问延时】

d）服务是否有些安全机制【例如：同一ip的访问次数限定，同一用户的操作频率限定】，影响性能测试的因数，在测试前需要关闭。

3.详细分析被测对象，编写压测脚本

a）请求是http还是https

b）服务是否与登录有关【登录用户的操作，需要在请求的header中增加cookie字段，标识用户的状态等信息】

详细说明：

• 很多页面在登录与不登录的情况下处理方式是不同的；有些页面也只有登录用户才可以访问；页面的逻辑与用户的等级等状态有关。

• 如何获取cookie，fiddler抓包，拷贝整个消息头部的cookie字段。

• 涉及cookie字段的，要注意相关参数的有效期，压测前检查是否失效。

c）有些服务，会检查refer，hostname等参数，压测脚本中需要在header中增加这些字段

d）前端页面，有时不同的User-Agent也会影响实际的业务。此时也需要固定请求header中的UA字段

e）增加断言【检查业务错误率】

详细说明： jmeter错误率统计的是请求返回非200的情况，但是对于web端而言，在有异常情况的时候，都会有相关的处理方式（例如：302重定向到其他页面），最终不会返回非200。需要设置断言，判断返回页面是否符合预期。

设置断言，检测返回结果中，是否包含某些参数或值

f）设置日志【设置】

g）有时为了方便定位问题，会在请求的url中，增加一个唯一的随机参数，格式：randomtt=${__time(,)}_${__threadNum}，参数是由时间戳和进程号组合

4.准备测试数据集

a）压测数据集是性能测试的重中之重，压测数据直接影响测试的价值与可行度

b）多个参数的各种组合情况是否覆盖【tips：多个参数多个文件引入时，如果是倍数关系，很多组合情况覆盖不到，需要将各种组合情况列在一个文件中，以参数个数的形式引入】

c）Query类的压测，测试数据集的选用，需要考虑的问题

• query 是否需要去重【去重后的query，在一轮测试中，不会命中缓存】

• query 使用线上真实的流量，即从线上日志中获取，不进行去重，能够完整的模拟线上流量

• 特殊字符集【特殊字符可能会导致服务挂掉，影响稳定性，常见的一些特殊字符：空格，特殊字符，半角全角符号，其他语言文字等】

• 网络攻击字符集【主要是一些js注入，SQL注入，XSS攻击的语句】

d）涉及用户状态或等级等功能，准备的cookie数据要涉及不同情况，用户等级的比例也要通过cookie数据的个数进行控制。

5.进行尝试，确定压测脚本和数据集

a）1-4步完成后，开启日志设置中的responseData等参数，压测一轮。检查返回的数据是否符合预期。【可以检查参数是否正确，cookie是否生效等】

b）通过尝试，确定并发数

c）修改日志设置，关闭responseData，开始压力测试。

其他注意点：

a）涉及到特殊字符等压测数据，最好将测试数据urlencode之后使用。Jmeter本身的编码功能，对一些特殊字符的支持不是很好，测试会中断。

b）压测web页面，页面较大时，为了避免，打满带宽，导致压力上不去的情况，要设置header中的Accept-Encode字段，用压缩形式。