性能测试:性能测试计划
简介
性能测试计划是在进行软件或系统的性能测试之前制定的详细计划和指导文件。它描述了所需性能测试的目标、范围、测试环境、资源需求、测试策略、测试用例、时间表等重要信息。
为什么要制定性能测试计划
制定性能测试计划的主要目的是确保性能测试的有效性和可靠性。以下是制定性能测试计划的重要原因:
明确测试目标:性能测试计划可以明确定义所需测试的性能目标,例如响应时间、吞吐量、并发用户数等。这有助于确保测试的准确性和一致性,并提供可评估的性能指标。
确定测试范围:通过性能测试计划,可以明确确定需要测试的系统或软件的范围,包括功能模块、关键业务流程等。这有助于确保测试覆盖的全面性,避免遗漏关键的性能热点。
提供测试环境和配置:性能测试计划可以指定测试所需的硬件、软件、操作系统和网络配置等。这有助于创建一个与实际生产环境相似的测试环境,并确保测试的真实性和准确性。
设定测试策略:性能测试计划定义了测试的方法、策略和技术。它确定了要使用的负载模型、测试用例设计方法、测试数据和性能统计指标,以确保测试具有可重现性和可测量性。
资源管理和规划:性能测试计划列出了执行测试所需的人员、工具、时间和预算等资源。这有助于合理规划和管理测试过程,确保资源的有效利用并避免测试中断或延误。
风险评估和应对措施:性能测试计划识别可能的风险和挑战,并提供相应的风险评估和应对措施。这有助于规避潜在的性能问题和系统崩溃,并确保测试的可靠性和稳定性。
结果分析和报告:通过性能测试计划,可以规定测试结果的分析方法和报告格式。这有助于准确分析和解释测试结果,向相关方提供清晰、可理解的性能测试报告。
总之,性能测试计划提供了一个全面的框架和指导,确保性能测试的有效性、可靠性和可重复性。它帮助测试团队、项目经理和相关方明确测试目标、范围和策略,最大程度地发现性能问题并提供优化建议。
性能测试计划的流程
需求分析与测试设计阶段
环境设计与搭建阶段
测试数据准备阶段
性能指标预期设定阶段
测试执行 &监控阶段
测试报告输出阶段
需求分析与测试设计阶段
场景 1:对于已经在线上运行的业务或相似业务:
收集行为日志:获取业务运行时的行为日志,包括用户的访问请求、操作行为、响应时间等信息。这些日志可以帮助了解用户行为模式和业务负载情况。
分析当前业务数据:通过分析当前业务数据,例如每日活跃用户数(DAU)、每日页面浏览量(PV)、每天的订单量等,可以获得业务的基本性能指标,如每秒钟的请求量(QPS)或每秒钟的事务处理量(TPS)等。
建立业务模型:基于当前业务数据和行为日志的分析结果,建立业务模型,包括各个关键业务场景、用户行为流程、系统组件之间的交互等。
预估接口 TPS/QPS:根据业务模型和当前业务数据,预估出每个关键接口或服务的每秒钟的事务处理量(TPS)或每秒钟的请求量(QPS)。这可以帮助确定性能测试的目标和负载程度。
场景 2:对于新业务或新活动:
参考友商经验:如果有类似的业务已经在线上运行,可以参考其性能测试经验和结果,了解其业务模型、性能指标和测试场景,从而为新业务制定性能测试计划提供参考依据。
产品和运营共同梳理评估:产品和运营团队可以针对新业务梳理出核心场景路径、入口及对应的转化率、问题收敛页面等。然后,将这些信息转化为业务模型,进而确定相应的测试场景、数据量级和接口比例。
环境设计与搭建阶段
设计:根据需求,结合线上机器部署情况,搭建线下测试环境,要求具有⼀定的参考价值,⼀般同比 1/2,1/4。
注意:测试环境无论怎么仿真和模拟,基本都不太可能达到 1 比 1 的效果。
环境搭建
起压环境:压测⼯具的安装与调试、机器参数记录;
被压环境:基础服务的搭建、web 机代码部署及代码改造、机器参数记录。
环境调试:查看接口是否正常。
测试数据准备阶段
接口请求参数:自己构造/日志获取/上下关联。
数据表的数据填充:部分业务数据信息可以直接从数据库或缓存数据库获取。
如果是多接口,则需结合业务场景设计请求⽐例。
性能指标预期设定阶段
每秒请求数(QPS):基于业务进行拆分,比如业务会提出需要再双十一的时候支持每分钟两万的订单。根据这个需求,再去拆分具体有哪一些接口的请求。
请求响应时间(最小、最大、平均):需要考虑到用户体验,即使后面能够正常响应,但是请求响应时间不能太长。(通常 C 端不超过 1s,尽量在 200 毫秒内)
错误率:基于在性能测试过程中,每个请求不可能百分百成功,但是也要有一个上限的阈值,那么这个阈值是多少。
机器性能:cpu memory 无剧烈抖动或者飙升。
压测过程接口功能是否正常:不要只关注响应状态码 200,还需要从业务角度来看响应信息是否符合业务需求。
注意:不同性能测试方式下指标预期会有差异。
发压工具配置及脚本编写阶段
选择发压工具:根据需求和系统特点选择适合的发压工具。常用的性能测试工具包括 JMeter、LoadRunner、Gatling 等。考虑到测试目标、可支持的协议和工具的易用性。
安装和配置发压工具:根据工具的官方文档,下载和安装所选发压工具。然后,根据具体情况进行配置。配置项可能包括服务器地址、并发用户数、请求协议和频率等。确保工具和测试环境的通信设置正确。
编写性能测试脚本:根据需要和测试场景,编写性能测试脚本。性能测试脚本用于定义测试场景,包括模拟并发用户行为、设定请求参数和验证响应等。脚本可以使用工具提供的图形界面或编程语言来编写。
测试执行 &监控阶段
测试前环境检查:记录机器参数。
起压:根据被压情况,调节并发量到适合的情况。
查看记录各项性能指标。
nginx 日志查看每秒请求数。
查看 nginx 错误请求。
查看机器参数:cpu idle、mem 等。
查看 db、cache 等数据是否写⼊正常。
访问接口,查看功能是否正常。
性能测试中的常用命令
查看 nginx 每秒请求数
命令:tail -f access.log | awk '{print $4}' | uniq -c
tail -f access.log:用于实时监视 access.log 日志文件的内容。
awk '{print $4}':使用 awk 命令提取出每行的第 4 列内容。
uniq -c:对提取出的内容进行去重计数,即统计每个不重复的值出现的次数。
查看某个接口每秒请求数
命令:tail -f access.log | grep p_getorderstatus |awk '{print $4}' | uniq -c
tail -f access.log:用于实时监视 access.log 日志文件的内容变化。
grep p_getorderstatus:使用 grep 命令过滤出包含"p_getorderstatus"的行。
awk '{print $4}':使用 awk 命令提取出过滤结果中的第四列内容。
uniq -c:对提取出的第四列内容进行去重统计,并显示出现次数。
查看 cpu idle
命令:vmstat 1
查看内存
命令:free -m
查看 nginx 日志是否有错误请求
命令:tail -f access.log |cut -d ' ' -f 10 |grep -v 200
tail -f access.log:用于实时监视 access.log 日志文件的内容变化。
cut -d ' ' -f 10:使用 cut 命令以空格作为分隔符,提取出日志行中的第十列内容。
grep -v 200:使用 grep 命令过滤出不包含 200 的行,即排除掉一切含有状态码为 200 的行。
查看进程
命令:- top - ps aux|grep xxx
查看 nginx 日志某接口访问数量
命令:cat access.log.xxxx|grep p_getorderstatus |wc -l
cat access.log.xxxx:用于查看 access.log.xxxx 文件的内容。xxxx 是日志文件的后缀,可以是日期或其他标识符。
grep p_getorderstatus:通过 grep 命令过滤出包含关键字"p_getorderstatus"的行。
wc -l:统计行数,即统计包含关键字"p_getorderstatus"的行数。
杀进程
指定进程号:kill xxx
指定部分进程名:pkill xxx
⾃定义特征:
或者 kill pgrep -f xxxx
ps aux:显示当前系统中所有的进程信息。
grep xxxx:通过 grep 命令过滤出包含特定关键字(xxxx)的进程行。
awk '{print $2}':使用 awk 命令提取出进程 ID(PID)这一列。
for i in...; do kill $i; done:通过循环遍历进程 ID(PID),逐个使用 kill 命令杀死进程。
pgrep -f xxxx:通过-f 参数搜索包含特定关键字(xxxx)的进程名,并显示对应的进程 ID(PID)。
kill ...:使用 kill 命令杀死搜索到的进程 ID(PID)。
查看 TIME_WAIT 数量
ss -s
netstat -tnlp |grep TIME_WAIT|wc -l
测试报告输出阶段
根据测试过程中记录的各项参数,结合压测⼯具产生的⽇志,对测试结果进行分析,并产出测试报告。
测试完成后,及时与相关人员沟通,确认是否满⾜需求。
发送测试报告邮件。
总结
为什么要制定性能测试计划。
性能测试计划的流程。
性能测试中的常用命令。
评论