精华内容
下载资源
问答
  • 从而团队提出对平台进行稳定性分析,通过给系统施加一定业务压力大情况下,使系统持续运行一段时间,以此来检测系统是否稳定运行(下统称稳定性测试或测试)。 1.2 服务说明 平台运行的服务包括系统服务和业务服务,...

    注:
    1. 程序员做的测试
    2. 测试报告文档原稿在上传审核中,请等待
    审核好了:https://download.csdn.net/download/yiquan_yang/12694138

    1 概述

    1.1 背景

    系统的稳定性是系统长期稳定运行能力,需要时间累积才能度量。平台的某些问题需要达到一定时间、一定的使用量后才会暴露出来。如内存泄漏,系统运行过程中发现部分服务的部分接口会发生服务不可达的情况。
    从而团队提出对平台进行稳定性分析,通过给系统施加一定业务压力大情况下,使系统持续运行一段时间,以此来检测系统是否稳定运行(下统称稳定性测试或测试)。

    1.2 服务说明

    平台运行的服务包括系统服务和业务服务,系统服务包括Consul、Redis、Cap、RabbitMQ、Exceptionless套件等,业务服务包括用户服务、基础数据服务、网关服务,详细见《xxx发布标准》。本次测试针对三个业务服务,对系统外界只有网关可视(测试对象统称系统或平台),故测试对象为一个服务。

    1.2.1 服务器部署

    本次测试采用单机环境,所有服务全部配置在同一台服务上,数据库部署在另一台机器上。

    Manufacturer: Microsoft Corporation
    Product Name: Virtual Machine
    IP:192.168.4.57(业务服务)、192.168.4.253(数据库)
    CPU:Intel® Xeon® Gold 5117 CPU @ 2.00GHz (物理CPU个数 1,核数:16)
    Memory:16G

    OS:CentOS Linux release 7.6.1810 (Core)
    PostgreSQL:PostgreSQL 11.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit
    Docker:Docker version 19.03.5, build 633a0ea
    其他软件环境见1.3测试工具

    1.2.2 服务配置

    其中系统中存在大量配置,其中影响测试的配置包括:
    xx:单服务接口最大并发数 设置为 1万
    xxx:请求执行超时时间 设置为 30s
    xxx:是否启用性能追踪组件 设置为 不启用
    xxxxxx:是否启用服务接口缓存拦截 设置为 启用
    Xxxxxxxx:是否启用集中式日志 设置为 不启用

    1.3 测试工具

    Apache JMeter(5.2.1):测试客户端,作为虚拟用户脚本产生器(Virtual User Generator)、压力产生器(player)、用户代理(Agent)、压力调度和监控系统(Controller)、压力结果分析工具(Analysis)
    1)安装前需要安装Java,本次测试使用jre1.8.0_241
    2)客户端如需则自行汉化
    3)安装服务资源监控器插件,从官网下载安装Plugins Manager,并安装jpgc - Standard Set
    ServerAgent(2.2.1):服务器Agent,提供服务器资源使用数据
    1)服务器需要安装Java,本测试使用java version “1.8.0_241”
    2)进入ServerAgent存放目录,使用命令“./startAgent.sh”启动Agent
    3)需要确保端口4444能够访问,本测试关闭了服务器防火墙

    1.4 稳定标准

    在一定的配置情况下
    CPU:单颗,16核
    Memory:16G
    在以上硬件环境下满足
    1)系统指标
    满足100个/s的最大并发。请求100%请求成功,且平均响应时间小于5s;
    2)资源指标
    在单位时间内(5s),CPU最大使用率不能持续超过95%,内存最大占用率不能持续超过95%。
    1.5 关键字定义
    1.6 排除干扰项
    不考虑断电,硬件资源损坏情况

    2 测试方案

    本次测试采取负载测试并发测试可靠性测试。测试方案采取模拟真实用户使用场景,模拟指定人数在一定时间点击界面产生的请求数。
    在并发10(单位个/s)、20、40、80、160、500、1000、2000的基准下,调整用户数(虚拟用户用一个线程,下统称线程数)、点击准备时间(用户点击时间模拟时间,下称Ramp-up单位秒)和用户点击次数(下称循环),例如10个用户,每个用户每5秒点击1次,则线程数为10,Ramp-up为5,循环数为1。详细测试策略请看2.1。

    对登录、数据新增(用户)、编辑(用户)、获取(用户)和删除(用户)进行负载测试,获得其稳定负载值。
    对全站使用策略100-100-1-1进行并发测试,挑选用户服务所有接口。基础数据服务中挑选和用户服务关联的功能接口5个,组织结构接口4个,和用户服务无关的行政区3个接口。具体接口请查看附件1。
    对全站进行可靠性测试,根据以上测试接口,选择稳定的并发数后持续测试-模拟时长8+小时。
    稳定性测试是通过运行状态和资源指标的2个方面来分析及评估系统的稳定性,请求记录项响应的时间平均值、最小值、最大值、标准偏差、异常(百分比)、吞吐量、接收、发送、平均字节数,服务器资源指标CPU、Memory,在此额外添加记录数据库数据。通过调试测试策略、分析实验数据得出相关系统稳定性的结论,从而达到平台能力验证、规划能力、性能调优、缺陷发现等目的。

    评价定义
    稳定:无异常,平均值和变成偏差差距较少且不高;
    普通:无异常,平均值小于5秒,平均值和变成偏差差距较少;
    一般:无异常,平均值大于5秒,平均值和变成偏差差距较大;
    差:存在异常,异常率小于30%;
    极差:存在异常,异常率大于登录30%;

    2.1 测试策略

    测试策略

    编号并发数线程数Ramp-up循环场景备注
    10-1-1-101011101个用户,每个用户每秒提交10次请求
    10-10-1-110101110个用户,每个用户每秒提交1次请求
    10-20-2-110202120个用户,每个用户2秒内提交1次请求
    10-20-4-210204220个用户,每个用户4秒内提交2次请求
    10-40-4-110404140个用户,每个用户4秒内提交1次请求
    10-40-8-210408240个用户,每个用户8秒内提交2次请求
    10-80-8-110808180个用户,每个用户8秒内提交1次请求
    10-80-16-2108016280个用户,每个用户16秒内提交2次请求
    。。。。。。

    2.2 测试脚本

    测试脚本分为登录和服务接口两个线程组,模拟用户登录后进行系统。
    1)在测试前定义测试配置变量,查看图2.2-1,使用变量
    在这里插入图片描述

    图2.2-1 定义线程组中配置变量
    在这里插入图片描述
    图2.2-2 使用线程组中配置变量
    2)用户登录成功后将Token写入全局变量中,服务接口线程组统一使用该Token。
    3)创建数据类接口,相关使用值在BeanShell预处理程序中创建,创建完成后在JSON提取器中提取相关值,供请求组装报文,例如用户,产生用户姓名请查看图2.2-3,使用查看图2.2-4,提取值查看图2.2-5。
    在这里插入图片描述

    图2.2-3 定义线程组中创建用户姓名变量
    在这里插入图片描述

    图2.2-4 使用线程组中创建用户姓名变量
    在这里插入图片描述

    图2.2-5 使用线程组中创建用户姓名变量
    4)编辑、获取和删除接口需要的主键ID从创建请求成功后提取。
    5)脚本中还包括HTTP头信息管理器(HTTP Header Manager),相关运行结果项察看结果树(请求头,Body,Response结果)、用表格察看结果(请求开始时间、运行时间等)、汇总报告(样本、最小值、最大值、错误率等)、jp@pc-PerMon Metrics Collector(服务器资源监视器)、汇总图(请求时间管理:样本、中位数、平均值、90%百分比等)
    6)整体脚本编写完成后,请查看图2.2-6。
    在这里插入图片描述

    图2.2-5 脚本一览

    3 负载测试

    3.1 测试样本

    3.1.1 登录接口

    1)查看结果树

    登录接口(线程池100)

    策略编号样本平均值最小值最大值标准偏差异常%吞吐量接收发送平均字节数评价
    100-50-1-2100383401181294.89055.4330.9630.92572.00稳定
    100-100-1-110024441962192.77068.6338.3440.37572.00稳定
    100-200-2-1200768392969716.67055.8731.2133.03572.00稳定
    100-1000-10-1100050779387935829633.030.73912.173.977.35334.04极差
    100-1000-20-2很卡无法测试

    登录接口(线程池1000)

    策略编号样本平均值最小值最大值标准偏差异常%吞吐量接收发送平均字节数评价
    100-1000-10-1104018037433047311904.871570.153.451.772.07527.1

    登录接口(线程池1500)

    策略编号样本平均值最小值最大值标准偏差异常%吞吐量接收发送平均字节数评价
    100-1000-10-11000418932130702803.22054.3830.5933.06576稳定

    登录接口(使用多个策略连续测试-线程池1500)

    策略编号样本平均值最小值最大值标准偏差异常%吞吐量接收发送平均字节数评价
    1-10-10-1
    10-100-10-1
    100-1000-10-11000418932130702803.22054.3830.5933.06576一般
    100-1000-10-1
    100-1000-10-13110544334176753858.24021.6712.1913.17576一般
    100-1000-10-14120489530176753654.62013.777.758.37576一般
    1-10-10-1
    1-10-10-14130488330176753657.94011.796.637.16576

    2)使用多个策略连续测试
    在这里插入图片描述

    jp@pc-PerMon Metrics Collector 服务资源监控
    3)100-1000-10-无线循环(10次+)
    在这里插入图片描述

    CPU占用在30%左右
    内存在30%左右
    4)100-1000-10-2 汇总图
    在这里插入图片描述

    中位数(所有请求响应时间的中间值可认为50%的请求)低于平均值和最大值的一般,比较稳定。
    90%请求在15s内请求完成,在并发高的情况下响应时间会降低,一半以上的会大于6s。但是100%响应,无异常产生。

    3.1.2 创建接口

    创建用户(连续请求两次)
    策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价
    100-1000-10-1 2001 79 41 262 20.40 0.00 30.36 8.75 20.55 295 稳定

    各项测试策略表现的非常稳定

    在这里插入图片描述

    在这里插入图片描述

    3.1.3 获取接口

    此接口没有配置缓存拦截,数据直接读库

    获取用户(连续请求两次)

    策略编号样本平均值最小值最大值标准偏差异常%吞吐量接收发送平均字节数评价
    100-1000-10-1200021131447.950.0032.2319.7019.67626稳定

    各项测试策略表现的非常稳定

    3.1.4 编辑接口

    1)更新用户

    更新用户(连续请求两次)

    策略编号样本平均值最小值最大值标准偏差异常%吞吐量接收发送平均字节数评价
    100-1000-10-12000787726189324915.29016.354.1712.85261稳定

    2)修改用户密码

    修改用户密码

    策略编号样本平均值最小值最大值标准偏差异常%吞吐量接收发送平均字节数评价
    100-1000-10-12000398622127782689.050.0049.0912.8030.06267稳定

    3.1.5 删除接口

    删除用户(暂时无并场景)

    策略编号样本平均值最小值最大值标准偏差异常%吞吐量接收发送平均字节数评价

    3.1.6 分页接口

    此处没有选择分页查看用户,是因为查询数据无数据,经排查是没有权限,但是搜索角色却可以。并且页大小为10,查询第一页没有考虑数据量大的情况,搜索比较靠后的页。此接口没有配置缓存拦截,数据直接读库

    分页查询角色

    策略编号样本平均值最小值最大值标准偏差异常%吞吐量接收发送平均字节数评价
    100-1000-10-1200016101046.850.0012.6725.417.932054稳定

    3.1.7 其他接口

    用户服务

    编号模块接口是否满足评价备注
    1User获得当前登录用户信息满足稳定
    2User获得用户数据权限满足稳定获取同一个用户
    3User获得用户功能权限满足稳定获取同一个用户
    4User从数据库获取权限数据满足普通获取同一个用户
    5User获得用户列表满足稳定无权限
    6User分页获取用户数据满足稳定

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    比较突出的四个为评价“普通”,“一般”的。登录请求请看3.1.1

    3.2 结果分析

    3.2.1 稳定性分析

    经过修复上一轮测试暴露出来的问题,目前登录、新增、编辑、查看、删除、分页等不同类型接口都有较好负载能力,满足团队当前对并发值100的期望值,部分接口平均响应时间未能满足要求,请求查看3.1。

    3.2.2 解决方案

    1)修改PostgreSql最大连接数,视服务器配置设定
    在本次测试服务器环境下设定1000,能满足基本负载要求(基础数据平台)
    参考资料:
    https://stackoverflow.com/questions/30778015/how-to-increase-the-max-connections-in-postgres/32584211#32584211
    2)修改服务事务,禁止在事务中添加执行长时间的代码,例如:大量RPC、HTTP、大量循环等。
    事务使用方式请参考《xx平台文档库》
    3)修改服务最小线程池值
    在本次测试服务器环境下设定1500,能满足负载要求(基础数据平台)
    参考资料:https://stackexchange.github.io/StackExchange.Redis/Timeouts.html
    4)优化细节
    登录后权限设定改为异步;
    方法中添加返回值,返回类型为Task添加async关键字;
    取消接口事务,如果零个或单个DML取消事务,其他情况事务中只含DML语句;
    优化代码结构,防止重复代码或重复业务操作(如删除操作:Service判断是否存在、仓储层再次判断是否存在);
    获取类接口(执行时间久、修改频率低)添加服务端缓存拦截;
    修改xxxxxxxx.json中接口并发数,MaxConcurrentRequests=1000
    修改yyyyyyyy.json中管理Redis线程数值,本次测试为:minSize=100、maxSize=1000

    4 并发测试

    4.1 测试样本

    100-100-1-1策略下测试整个服务

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录133333333300.00%3.0031.670.91 568
    获得当前登录用户信息1001103522379757.520.00%3.1718823.721.567656.2
    。。。
    总体45011303523499865.010.00%48.365611987.830.8142085.8

    表3.2-1 负载测试汇总报告
    在这里插入图片描述

    图3.2-1 负载测试jp@pc-PerMon Metrics Collector

    在这里插入图片描述

    图3.2-2 负载测试汇总图
    在这里插入图片描述

    图3.2-3 负载测试报错日志
    在这里插入图片描述

    图3.2-4 吞吐量正序排序
    在这里插入图片描述

    图3.2-5 接收数据倒序排序

    4.2 结果分析

    测试一次用例总共耗时1分33秒,共4501一个请求,接口普遍正常,其中“根据角色和功能删除”、“根据角色Id删除对象功能”出现少量异常分别为1%、3%,错误信息请查看图“3.2-3”。接口的普遍中位数在500ms以上且标准偏差大在800ms左右,不考虑接口业务设计错误信息下,指标与当前版本要求差距不大。部分接口返回数据较大和吞吐量低的情况,更详细请查看可靠性测试。

    5 可靠性测试

    5.1 测试样本

    5.1.1 全站可靠性测试

    使用稳定的并发数持续运行-模拟时长8+小时
    先采取策略100-100-1-1执行一段时间报错,由于单个接口100并发,49个接口总共并发数较大,调整策略为10-10-1-1,单接口10并发整站490并发,循环持续执行。

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录72637137353871393.340.00%0.0003800568
    获得当前登录用户信息56005118329353493.230.00%0.24883102.870.12423337.8
    总体26738790347601051867.880.50%10.406722425.96.61238703.3

    表3.3.1-1 汇总报告
    修改后 相同测试样本,

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录212412312510.00%0.058110.030.02568
    。。。

    修改前和修改后服务器消耗资源对比
    在这里插入图片描述

    图3.3.1-1 PerMon Metrics Collector-修改前
    在这里插入图片描述

    图3.3.1-1 PerMon Metrics Collector-修改后

    修改前和修改后服务器内存消耗对比

    在这里插入图片描述

    图3.3.1-3 PerMon Metrics Collector-Memory-修改前

    在这里插入图片描述

    图3.3.1-3 PerMon Metrics Collector-Memory

    5.1.2 创建接口类型可靠性测试

    1)创建用户

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录10478642635101294.540.00%0.00200568
    创建用户1102634219153125481224.20.00%21.947856.3214.69295
    总体1102734219153125481224.160.00%21.931166.3214.67295

    表3.3.2-1 汇总报告
    修改后 平均响应时间缩短计算器60%,吞吐量增加300%

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录144744744700.00%2.237141.240.68568
    创建用户10000016091775784468.860.00%61.7266417.7841.3 295
    总体10000116091775784468.880.00%61.7095117.7841.29295

    在这里插入图片描述在这里插入图片描述

    图3.3.2-1 服务器资源消耗-修改前后对比
    修改后:内存消耗稳定,且能够回收内存,之前需要运行1h23min,现在仅需27min,缩短67%的时间。
    在这里插入图片描述
    在这里插入图片描述

    图3.3.2-2 服务器资源消耗-Memory-对比
    2)创建功能

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录24873451252343610.00%0.0028400568
    创建功能接口10870828291289021910.880.00%30.636978.8323.47295
    总体10871028291289021910.920.00%30.598518.8223.44295

    表3.3.2-2-1 汇总报告
    修改后 平均响应时间缩短计算器57%,吞吐量增加270%

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录240937544434.50.00%0.017320.010.01568
    创建功能接口10000012081153842432.260.00%81.569223.562.48295
    总体10000212081153842432.270.00%81.5402323.4962.45295

    修改后:各项指标均运行平稳,其中内存消耗比较明显,之前需要运行58min,现在仅需20min,缩短65%的时间。

    图3.3.2-2-1 服务器资源消耗
    内存消耗比较:由于是单机部署,存在多个服务,此处只比较内存变化稳定性,修改后较修改前稳定。

    图3.3.2-2-2 服务器资源消耗-Memory

    5.1.3 编辑接口类型可靠性测试

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录542804167441582.150.00%0.0007600568
    编辑用户130000476190305284445.930.15%17.246584.413.42261

    表3.3.3-1 汇总报告
    修改后 接口存在错误,并发下编辑同库同表同行数据,与本次测试的策略有关系。报错详情:This NpgsqlTransaction has completed;it is no longer usable. 限制因素:数据库行级锁限制或并发下事务处理方案需优化

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录49283522303805.260.00%0.0013800568
    编辑用户34264833884304557267.910.59%11.7566639.15261.7

    服务器资源消耗对比
    在这里插入图片描述
    在这里插入图片描述

    图3.3.3-1 服务器资源消耗
    内存消耗对比:修改后编辑用户前期内存消耗正常,在程序后期出现错误后内存消耗严重,和本次测试策略有关系。
    在这里插入图片描述
    在这里插入图片描述

    图3.3.3-2 服务器资源消耗-Memory

    5.1.4 获取接口类型可靠性测试

    。。。

    5.1.5 分页获接口类型可靠性测试

    5.2 结果分析

    5.2.1 概况

    本次测试计划测试时长为8h+,实际测试时长为7小时8分钟,总共发起请求267387个,吞吐量为10.4/s,平均响应时间900ms,错误率0.5%,平均发送速率6.61KB/s,接收速率2425KB/s。
    数据库数据无异常。

    假设系统常用在线用户10人,每人平均每分钟点击20次,每天平均在线时长10分钟,13天

    1)服务器资源CPU
    服务器资源中CPU表现稳定,在测试后半段出现满负荷情况;
    2)服务器Memory
    服务器内存单位时间内平缓但总体呈上逐步升趋势;
    3)服务器Disks I/O
    服务器磁盘I/O比较稳定,测试用例循环测试的启动初期会出现一定的波动;
    4)服务器Swap
    服务器Swap在服务启动初期会暂用比较高资源,在服务运行过程中逐步下降;
    5)服务器TCP
    服务器TCP连接数在运行过程中一直保持在4000个连接左右,可能是影响吞吐量的因素之一;
    6)Network I/O
    网络I/O比较稳定,总体上没有太多的异常。

    5.2.1.1 问题

    1)服务器资源占用会越来越多
    从图3.3-2 PerMon Metrics Collector-CPU、图3.3-3 PerMon Metrics Collector-Memory可以观察到CPU在测试后期出现异常,而内存逐步上升,在1h40min、3h、4h20min时出现一定下降,原因是测试循环和下一个循环的间隔,系统可能回收了资源。停止服务请求在相隔一定时间(8h+)后再次测试,资源占用情况并未好转(测试登录服务报错)。
    在这里插入图片描述

    2)服务吞吐量较低
    在负载测试和并发测试中,虽然请求在100并发下都能真确响应,但响应时间长,在可靠性测试中实际吞吐量为10.4个每秒,考虑到不同类型的接口场景不同受影响因素不同,该值有一定不准确性。
    3)服务出现的异常

    根据角色和功能删除权限 20.50%
    根据角色Id删除对象功能 2.98%
    从数据库获取权限数据 0.09%
    获得用户列表 0.09%
    刷新用户缓存数据 0.09%
    分页获取用户数据 0.04%
    删除用户 0.04%
    根据条件查询所有角色 0.04%
    获得用户数据权限 0.02%
    获取当用用户角色权限 0.02%

    4)部分接口响应时间长
    “从数据库获取权限数据”、“分页获取用户数据”等。
    在这里插入图片描述

    5.2.2 不同接口类型测试

    由于全栈可靠性测试发现问题“服务器资源占用会越来越多”,故而进一步测试,选取压力测试里面增加、编辑、获取、分页获取四种类型接口进行可靠性分析。总体服务器资源消耗严重在于内存会持续增加,最终导致服务器宕机。
    根据测试数据可得出以下结论
    1)服务器消耗瓶颈在于内存,CPU、TPC、I/O等比较稳定;
    2)创建类接口会导致内存泄露;
    3)编辑类接口总体上稳定,但长期观察内存有缓慢上升趋势,但TPC连接数也同步上升,需要深入Linux调优排查;
    4)获取类接口可以长时间稳定运行;
    5)接口吞吐量与接口响应时间正比,响应时间长的接口吞吐量低,比较突出的“分页获取用户数据”、“获得用户列表”、“登录”、“从数据库获得权限数据”、“获取组织机构List”。而相对于不同接口类型,获取类的接口比操作类的接口快。

    5.2.3 解决方案

    1)登录问题
    Token过期后大量请求导致系统卡顿
    原因,Token保活机制在其最后5分钟内触发,对比时间取得是请求Header中的时间,而保活操作取得是缓存时间,导致Token失效后所有请求都触发保活操作,消耗大量资源。
    解决方案:时间统一用缓存中时间
    2)DotNetty组件
    每次Rpc会长留一个byte[]的变量(客户端和客户端都会),记录已发送字节大小。
    修改方案修:不记录已发字节数且Rpc结束之后调用ReferenceCountUtil.Release(buffer);清除Rpc过程中产生的垃圾。
    修改DotNetty服务端和客户端,涉及模块Surging.Core.DotNetty、Surging.Core.DotNettyWSServer、Surging.Core.Protocol.Http、Surging.Core.Protocol.Mqtt、Surging.Core.Protocol.Udp、Surging.Core.DNS。
    3)禁用Surging性能追踪组件。
    原因:使用微软DiagnosticListener组件,记录记录锚点数据用于记录性能追踪数据,BUP目前未启用surging的Skywalking(不完善),所以数据一直长留在内存中,
    4)集中式日志
    当不使用集中式日志时需要在配置中不启动
    5)未使用Module影响
    xxxxxxxx.json中Packages->Using配置:ServiceProxyModule、SkywalkingModule

    6)Surging生命周期管理引起的内存泄漏
    总体上修改后提升了稳定性(详情数据查看3.3中修改后测试结果),首先CPU和Memory振幅变小,系统运行平稳,其次平均响应时间大大缩短,最好为200ms,再者吞吐量提升明显最大接近500个/s。

    5.3 稳定测试-可靠性测试

    5.3.1 平稳-高并发-平稳

    选择接口采用“平稳-高并发-平稳”的测试策略进行测试,设置并发数为1-5-10-15-10-5-30-60-5(接口35个,实际并发高于设定值)。
    在这里插入图片描述

    测试结果
    在这里插入图片描述

    结论:内存能够回收,证明在高并发后能够回收内存资源;

    5.3.2 长时间测试

    选择部分接口进行长时间运行测试,1千万左右请求
    在这里插入图片描述

    最终内存消耗情况
    在这里插入图片描述

    最终系统运行时间
    在这里插入图片描述

    结论:能够长时间运行,且请求结束能够能存占用情况能够回归到稳定水平。

    6 总结

    经过三种不同测试方法负载测试、并发测试、可靠性测试。
    负载测试证明能平台框架在不同类型接口下能满足预定的稳定指标;
    并发测试证明平台所有业务接口能够满足预定的稳定指标;
    可靠性测试证明平台能够长时间运行,满足预定的稳定指标

    7 附录

    附录1-测试接口列表

    编号 服务名 接口名 接口URL
    1 用户 登录 POST /api/user/login?servicekey=User
    2 获得当前登录用户信息 GET /api/user/getcurrentuserinfo?servicekey=User
    3 创建用户 POST /api/user/createuserinfo?servicekey=User

    详细请翻阅附件2-测试脚本

    附录2-测试脚本

    JMeter打开

    ··已删除jmx文件··

    PostMan打开
    ··已删除 postman_collection.json··

    附录3-数据库数据统计

    原始测试数据库是从253已存库备份而来
    1.数据库
    编号 数据库
    大小
    测试项 bup_xxx_stability bup_cap_stability bup_yyy_stability
    1 测试前数据 15 MB 8157 kB 15 MB
    2 负载测试 15 MB 8245 kB 20 MB
    3 并发测试 15 MB 8789 kB 23 MB
    4 可靠性测试 26 MB 31 MB 57 MB
    2.数据库表大小
    编号 数据库 表名 原始 负载测试 并发测试 可靠性测试
    1 bup_basedata_stability cap.published 16 kB 16 kB 16 kB 16 kB
    。。
    3.数据库表行数
    编号 数据库 表名 原始 负载测试 并发测试 可靠性测试
    1 bup_basedata_stability Xxx_t_xxxx 348 348 348 348

    展开全文
  • 作为测试工程师,相信大家对jmeter这个工具在熟悉不过了,小编的前几篇博客中也有写到jmeter用于接口自动化测试的实战文章,今天主要用来介绍使用jmeter来进行性能测试和稳定性测试的实战。 1、性能测试 性能测试...

    前言

        作为测试工程师,相信大家对jmeter这个工具在熟悉不过了,小编的前几篇博客中也有写到jmeter用于接口自动化测试的实战文章,今天主要用来介绍使用jmeter来进行性能测试和稳定性测试的实战。

    1、性能测试介绍

    性能测试和我们以往提到过的关于存储软件产品和分布式存储性能测试(fio,vdbench)不一样,fio,vdbench一般是真针对硬件性能测试,本次介绍的是软件性能测试。

    以web项目为例,性能测试用例包括但不限于以下几项:

    性能测试模块性能测试项性能测试用例
    模块A模块A专题1精确搜索在30万条数据量在测试环境下搜索3秒内返回结果
    模块A专题1模糊搜索在30万条数据量在测试环境下搜索3秒内返回结果
    模块B模块B专题1搜索1亿条数据在测试环境下精确查询2秒内返回结果,模糊查询5秒内返回结果
    关联关系总数小于50个,3秒内返回结果
    关联关系总数小于150个,5秒内返回结果
    模块C模块B专题1搜索50万条在测试环境下搜索3秒内返回结果
    模块B专题2搜索50万条在测试环境下搜索3秒内返回结果
    模块B专题3搜索50万条在测试环境下搜索3秒内返回结果
    模块B专题9搜索50万条在测试环境下搜索3秒内返回结果
    模块B专题10搜索50万条在测试环境下搜索3秒内返回结果
    并发用户数50个用户登陆并且操作支持并发用户数50个

    如上表所示,是一些性能测试用例的例子

    2、稳定性测试介绍

    对于web项目来说,稳定性一般来讲是指的在指定时间内可以无故障运行。包含但不限于以下几项:

    测试模块测试项测试用例预期结果
    系统整体负载持续运行产品在50%左右负载情况下,能够无故障持续运行3*24小时在3*24小时的运行中,系统运行正常,无故障出现。

    如上表软件项目整体在50%负载(CPU、内存)能够无故障进行3*24小时,或者7*24小时。

    3、jmeter脚本录制

    1、打开jmeter选择录制模板点击创建

    3、查看模板的目录

    由下图我们可以看出是英文的,我们可以自己进行改为中文名字,以便于我们自己查看。

    备注:因为真实环境中,你比如百度www.baidu.com,腾讯等这样的企业网站都有自己的安全保护措施,

    没办法实战给大家展示,所以就在网上随便找了一个网站进行测试 ,如下,我们就是对下面这个网站

    进行“计算字符串长度”的性能测试和稳定性测试。以此为例。

    3、开启win10的代理设置

     

    4、开启http的代理服务器

     

    当http的代理服务器开启时,我们去浏览器上开始操作,jmeter其实就已经为我们录制了。去网站中刷新一下

    jmeter就开始捕捉我们操作的行为了。

    此时我们要密切注意,录制控制器中产生的请求。如下图:

    为了我们更清晰的得到我们想要的,我们一般每执行一个操作(鼠标点击等操作)都会对新产生的请求去做注释。

    加完注释如下图:这样我们的每一步操作就清晰可见了。

    5、录制完之后停掉代理服务器,关闭win10自带代理

    截止到上述步骤,录制脚本就执行完毕了。

    4、性能测试跑脚本

    1、添加聚合报告组件

    2、设定循环时间或次数

    下图代表,1个线程,跑1次

    如果是100用户并发测试的话,就是100个线程

    3、点击执行,执行完毕后,并查看结果树结果。

    查看结果树:

    从下图中我们看到,结果树中我们录制的脚本,都一一对应执行了,且都是绿色代表执行成功。(实战中绿色不一定成功)

    我们还可进一步查看脚本执行的详情:包括请求、响应数据

    4、查看聚合报告

    聚合报告是本次执行脚本的一个综合报告,里面包含了我们执行本次甲苯的时间,正确率与错误率等。

    如下图所示,我们一般要看两个地方,

    Average:平均请求响应时间,单位为毫秒,图中数据显示我们619ms,代表我们执行的性能测试响应时间为619毫秒,

                   如果我们的测试要求在3秒内返回结果,619ms<3s,说明这个请求性能测试通过。

    Error:一般如果为0,说明没报错,也就是测试正常。

    5、稳定性测试跑脚本

    1、修改时间

    稳定性一般情况要跑的脚本和性能测试的脚本一样,就是把上述的步骤在执行一遍,但是不同的是测试时间要变。

    我们稳定性测试要求是3*24小时,无故障运行。所以时间要改。

    如下图,循环次数改为了  永远勾选调度器,持续时间(秒):3*24*3600秒=259200秒,如果是100用户并发,线程数还要改为100

    2、查看结果树、聚合报告

    这样脚本会循环执行三天三夜,时间到了之后,程序会停,我们还是去查看结果树,看有没有脚本出错。

    如果没有报错,并且,聚合报告中,Error也为0%,代表稳定性测试通过了。

    总结:

    本文到此是使用jmeter,对web项目的性能测试和稳定性测试进行了大体的介绍(比较详细),流程是很全面的,

    但是可能各位同学自己在使用时,会出现各种各样的问题。不要担心都是正常的,一点点解决。

    有问题请留言哦,看到必回复。

     

     

     

     

    展开全文
  • 今天面试遇到一个问题,如何进行网站的稳定性测试?因为之前从事的是电信行业,其稳定性测试是发送确定的traffic,运行72小时,观测系统的资源使用情况,traffic处理是否正常,有无内存泄漏,有无进程崩溃,其他资源...

    今天面试遇到一个问题,如何进行网站的稳定性测试?因为之前从事的是电信行业,其稳定性测试是发送确定的traffic,运行72小时,观测系统的资源使用情况,traffic处理是否正常,有无内存泄漏,有无进程崩溃,其他资源使用是否正常等等。所以也给了一个类似的稳定性测试思路:按照系统设计容量的性能指标,模拟最大并发访问需求,运行72小时,看系统响应时间,监控资源利用的方法。回来查询发现,网易对这个问题也有思考,并且已经做了探索,特摘录于此,借鉴使用。

    如何做好稳定性测试?我们的探索和实践
    作者:刘林霞

    展开全文
  • Web UI 优化自动化测试用例的稳定性

    千次阅读 2015-12-08 18:51:53
    Web UI自动化测试的一个很重要的问题就是整个测试稳定性,经常在运行测试的时候出现这样或那样的问题,而且大多都是稳定性问题,而非BUG,最近我针对同事的用例的稳定性问题做了些优化策略,今天跑了 500个用例 ...


         Web UI自动化测试的一个很重要的问题就是整个测试的稳定性,经常在运行测试的时候出现这样或那样的问题,而且大多都是稳定性问题,而非BUG,最近我针对同事的用例的稳定性问题做了些优化策略,今天跑了 500个用例 没有一个出现稳定性问题,当然 可能有运气成分吧 呵呵 总共运行时间 5小时,实际的测试用例有70-80个左右 是循环跑出了500次 特此声明一下 不然有人会质疑,UI自动化 以回归 和冒烟为主  我这不会出现那么多用例的,投入产出 会随着用例数增长而下降的,我们的自动化其实还是接口为重点。

    killed the useless process
    Tests run: 501, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 18,205.275 sec - in TestSuite
    
    Results :
    
    Tests run: 501, Failures: 0, Errors: 0, Skipped: 0
    
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 05:03 h
    [INFO] Finished at: 2015-12-08T18:41:54+08:00
    [INFO] Final Memory: 19M/222M
    [INFO] ------------------------------------------------------------------------
    Recording test results
    Sending e-mails to: qa.group@xxxxx.com
    Finished: SUCCESS

    添加页面跳转判断页面加载过程的代码:

    package ec.qa.autotest.ui.common.action;
    
    
    import java.util.concurrent.TimeUnit;
    
    
    import org.openqa.selenium.WebElement;
    import org.openqa.selenium.support.FindBy;
    import org.openqa.selenium.support.How;
    import org.openqa.selenium.support.PageFactory;
    import org.openqa.selenium.support.ui.SystemClock;
    import org.testng.Assert;
    
    
    import ec.qa.autotest.ui.custom.annotation.PageObject;
    import ec.qa.autotest.ui.testbase.TestBase;
    
    
    @PageObject
    public class SupplierProgressCommonAction {
    
    
    	@FindBy(how = How.ID, using = "ngProgress")
    	private WebElement spProgress;
    	
    	private final long TIMEOUTS = 5000;
    	
    	private final long WAIT_TIME = 500;
    
    
    	public SupplierProgressCommonAction() {
    		PageFactory.initElements(TestBase.getWebDriver(), this);
    	}
    
    
    	public void waitForProgressTOComplete(long timeOut) throws InterruptedException {
    		Assert.assertEquals(isProgressCompleted(timeOut), true);
    	}
    
    
    	public void waitForProgressTOComplete() throws InterruptedException {
    		Assert.assertEquals(isProgressCompleted(TIMEOUTS), true);
    	}
    
    
    	private boolean isProgressCompleted(long timeOut) throws InterruptedException {
    		SystemClock sc =new SystemClock();
    		long endTime = sc.laterBy(timeOut);
    		
    		while (sc.isNowBefore(endTime)) {
    			TimeUnit.MILLISECONDS.sleep(WAIT_TIME);
    			if (spProgress.getAttribute("style").contains("width: 0%")) {
    				WaitForUtil.pageIsPasered();
    				return true;
    			}
    		}
    		return false;
    	}
    }
    


    一些通用的保证测试稳定的代码:

    package ec.qa.autotest.ui.common.action;
    
    import java.util.concurrent.TimeUnit;
    
    import org.openqa.selenium.JavascriptExecutor;
    import org.openqa.selenium.WebDriver;
    import org.openqa.selenium.WebElement;
    import org.openqa.selenium.support.ui.ExpectedCondition;
    import org.openqa.selenium.support.ui.SystemClock;
    import org.openqa.selenium.support.ui.WebDriverWait;
    
    import ec.qa.autotest.ui.testbase.TestBase;
    
    /**
     * @author xin.wang 等待页面解析完成
     */
    public class WaitForUtil {
    
    	private static final long TIMEOUTS = 4000;
    
    	private static final long WAIT_TIME = 300;
    
    	public static void pageIsPasered() {
    		new WebDriverWait(TestBase.getWebDriver(), 10).until(new ExpectedCondition<Boolean>() {
    			public Boolean apply(WebDriver driver) {
    				return ((JavascriptExecutor) driver).executeScript("return document.readyState").equals("complete");
    			}
    		});
    	}
    
    	public static String getPageFieldText(WebElement el) throws InterruptedException {
    		long startTime = System.currentTimeMillis();
    		long curTime = startTime;
    		while ((curTime - startTime) <= TIMEOUTS) {
    			TimeUnit.MILLISECONDS.sleep(WAIT_TIME);
    			if (el.getText().trim() != "" && el.getText() != null) {
    				return el.getText();
    			}
    			curTime = System.currentTimeMillis();
    		}
    		return "";
    	}
    
    	/**
    	 * @author xin.wang 
    <span style="white-space:pre">	</span> *等待元素是否可见
    	 */
    	public static WebElement waitForElementToDisplay(WebElement el) throws Exception {
    		SystemClock sc = new SystemClock();
    		long endTime = sc.laterBy(TIMEOUTS);
    		boolean flag = false;
    
    		while (sc.isNowBefore(endTime)) {
    			TimeUnit.MILLISECONDS.sleep(WAIT_TIME);
    			if (el.isDisplayed()) {
    				flag = true;
    				break;
    			}
    		}
    		if (!flag) {
    			throw new Exception("the element is not visable");
    		}
    		return el;
    	}
    }










    展开全文
  • 自动化WEB系统稳定性测试框架研究.rar
  • 自动化WEB系统稳定性测试框架研究.pdf
  • 服务端稳定性测试

    千次阅读 2019-05-12 20:48:05
    二、稳定性测试方法 方法一:线下稳定性测试通常的做法 关注指标: 测试注意事项 方法二:线上监控/线上巡检 三、故障模拟测试在提升系统稳定性中的实际应用 四、客户端稳定性测试 一、什么是稳定性 稳定性...
  • 性能和稳定性测试报告模板

    千次阅读 2021-11-08 20:29:52
    验证系统稳定性 验证系统的架构是否存在瓶颈 测试环境: 提供网络拓扑图 可以使用visio来花图,描述清楚几个要点: 几台测试服务器,每台都有什么服务,前台web服务、memcache、数据库? 几台服务器的连接关系 ...
  • 软件稳定性测试

    万次阅读 2016-02-24 06:23:39
    稳定性测试就测试系统的长期稳定运行能力。在系统运行过程中,对系统施压,观察系统的各种性能指标,以及服务器的指标。 2 测试场景:模拟平常的压力,模拟实际中日常的用户数进行操作。数据库要存有一定的...
  • 【云真机平台】稳定性测试方案

    千次阅读 2021-04-28 08:38:55
    随着用户的增加和深度使用,需要确保平台的使用稳定性,故针对云真机平台设计稳定性测试方案测试并进行针对性优化 一、连接稳定性 1.1 重复连接设备稳定性 测试描述: 设备连续立即使用/断开连接操作 同时操作设备数...
  • Web UI自动化测试的不稳定性有两个层面: 技术层面–没有构造健壮的能稳定运行的脚本 非技术层面–项目原因或者用Web UI自动化企图达到不合适的目标,造成脚本频繁改动,维护成本高 今天先说第一点。首先,Web UI...
  • webWebWeb测试工具对比--自动化软件测试(1)软件测试针对xxx(java开发)软件进行测试,对winrunner7.0,RationalRobot,QuickTest进行评测,评测主要包括易用性,扩展性,稳定性等三方面.xxx登陆功能是使用最频繁的功能...
  • Web UI自动化测试的不稳定性有两个层面: 技术层面–没有构造健壮的能稳定运行的脚本 非技术层面–项目原因或者用Web UI自动化企图达到不合适的目标,造成脚本频繁改动,维护成本高 第一点在上一篇博文里从代码...
  • Web全面性能测试模型

    2021-03-23 13:56:56
    性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、……,这么多眼花缭乱的性能测试类型名称,估计很少有人能准确的区分并说出定义来。至于如何制定合理的性能  性能测试、压力测试、负载测试、强度...
  • Web应用架构演进 WEB应用架构演进过程,系统对于性能和稳定性方面需要解决的问题
  • Web安全性测试

    千次阅读 2018-12-04 17:28:05
    一、认证与授权 1、认证 即登录功能正常 2、权限 每个用户拥有正确的权限 3、避免未经授权的页面可以直接访问,通过认证和权限(Session),对每个页面有一...4、在手动进行安全测试时,对所有url地址在不登录...
  • 一般的网站的主要测试内容就分为以下几点: 目录 功能测试 性能测试 安全测试 稳定测试 兼容性测试 压力测试 功能测试: 功能测试常用到的有效方法: 等价划分法: ...
  • Web自动化测试实战(一)

    万次阅读 多人点赞 2019-08-23 15:41:39
    一丶认识web自动化测试 1. 什么是自动化测试? 2.为什么进行自动化测试? 3.自动化测试的分类 二丶元素定位 1.为什么要学习定位元素? 2.元素定位的工具或手段有哪些? 3.环境及工具 4.css选择器 一丶认识web...
  • 说明:在写这篇文章之前,本人也不曾了解LTP是干嘛的,直到参加一次技术沙龙才了解到它是用来对linux系统进行稳定性测试的一个开源工具,演讲人是世纪佳缘运维部门的技术老总!平时我们这些做运维朋友们都很少涉及到系统...
  • 软件测试-web端通用测试方法

    千次阅读 2018-12-14 14:53:28
    软件测试-web测试方法 一、输入框 1、非空校验(必填项校验): 必须按照需求说明书,编辑页面的输入框的必填校验,否则可能导致“业务相关的关键信息未输入/下个节点的获取不到数据报错”等异常情况; 2、...
  • Web自动化测试工具选择

    千次阅读 2019-09-23 10:13:29
    1. 了解Web自动化测试常用工具 2. 熟悉Selenium的特点 1. 主流的Web自动化测试工具 1. QTP QTP是一个商业化的功能测试工具,收费,支持web,桌面自动化测试。 2. Selenium(本阶段学习) Selenium是一个开源的...
  • https://testerhome.com/topics/15937
  • 十大开源Web应用安全测试工具

    千次阅读 2020-05-22 00:00:00
    点击蓝字关注我们Web应用安全测试可对Web应用程序执行功能测试,找到尽可能多的安全问题,大大降低黑客入侵几率。在研究并推荐一些最佳的开源Web应用安全测试工具之前,让我们首先了解一下安...
  • Web自动化测试

    千次阅读 2019-02-26 17:04:50
    1. 什么是自动化? 概念:由机器设备代替人为自动完成指定目标的...2. 什么是自动化测试 概念:让程序代替人为去验证程序功能的过程 2.1 为什么要进行自动化测试? 1. 解决-回归测试 2. 解决-压力测试 3. ...
  • Web测试和APP测试有什么区别?

    千次阅读 2018-11-03 19:43:59
    不管是传统行业的web测试,还是app测试,都离不开测试的基础知识,即是不管怎么变,测试的原理依然会融入在这两者当中。  1、Web测试和APP测试相同点   1)设计测试用例时,依然都是依据边界值分析法、等价类...
  • web页面测试方法与测试用例编写

    千次阅读 多人点赞 2020-06-12 17:18:51
    11、 上传文件容错性测试,如检查覆盖同文件操作 12、文件文件异常性测试,如硬盘空间不足 13、上传文件速率性能测试,检查系统资源占用 14、上传文件安全性测试,如上传常见木马 15、上传文件特性测试,如是否支持...
  • Web测试关注点

    千次阅读 2017-05-09 14:51:47
    Web测试关注点输入框1、字符型输入框: 字符型输入框:英文全角、英文半角、数字、空或者空格、特殊字符“~!@#¥%……&*?[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时,使用“粘贴、拷贝”功能尝试输入...
  • web测试知识详解

    千次阅读 多人点赞 2018-11-21 17:09:19
    web测试 web测试..............................................................................................................................1 1. 分类及测试要点...........................................
  • 一般来说,版本功能测试完成,对应的用例也实现了自动化,性能、兼容、稳定性测试也完成了以后,我们就需要考虑到系统的安全问题,特别是涉及到交易、支付、用户账户信息的模块,安全漏洞会带来极高的风险。...
  • web测试流程,确保后台接口已测试完毕 一、需求分析,了解具体需求 二、测试准备:原型图、效果图、需求文件、测试用用例、用例评审、各种测试数据准备 三、测试环节:接受版本开始执行 1)冒烟测试:对版本质量的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 272,358
精华内容 108,943
关键字:

web的稳定性如何测试