精华内容
下载资源
问答
  • 软件测试服务器稳定性测试方法

    千次阅读 2017-08-29 20:40:44
    正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能,如:数据冗余、网卡荣誉、电源冗余、风扇冗余等。   一些测试方法主要分以下几种: 压力测试:已知系统高峰期使用...

    服务器稳定性是最重要的,如果在稳定性方面不能够保证业务运行的需要,在高的性能也是无用的。

     

    正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能,如:数据冗余、网卡荣誉、电源冗余、风扇冗余等。

     

    一些测试方法主要分以下几种:

    压力测试:已知系统高峰期使用人数,验证各事务在最大并发数(通过高峰期人数换算)下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应(如:宕机、应用异常中止等)。

     

    Ramp Up 增量设计:如并发用户为75人,系统注册用户为1500人,以5%-7%作为并发用户参考值。一般以每15s加载5人的方式进行增压设计,该数值主要参考测试加压机性能,建议Run几次。以事务通过率与错误率衡量实际加载方式。

     

    Ramp Up增量设计目标:

    寻找已增量方式加压系统性能瓶颈位置,抓住出现的性能拐点时机,一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数,如早晨的登录,下班后的退出,工资发送时的消息系统等。

     

    另一种极限模拟方式,可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变,在各脚本事务点中设置同集合点名称(如:lr_rendzvous("same");)在场景设计中,使用事务点集合策略。以同时达到集合点百分率为标准,同时释放所有正在RunVuser

     

    稳定性测试:已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景,测试时将每个场景按照一定人数比率一起运行,模拟用户使用数年的情况。并监控在测试中,系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。

    根据上述测试中,各事务条件下出现性能拐点的位置,已确定稳定性测试并发用户人数。仍然根据实际测试服务器(加压机、应用服务器、数据服务器三方性能),估算最终并发用户人数。

     

    场景设计思想:从稳定性测试场景的设计意义,应分多种情况考虑:

     

    针对同一个场景为例,以下以公文附件上传为例简要分析场景设计思想:

     

    1)场景一:已压力测试环境下性能拐点的并发用户为设计测试场景,目的验证极限压力情况下测试服务器各性能指标。

     

    2)场景二:根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。

     

    测试方法:采用1)Ramp Up-Load all Vusers simultaneously

    2)Duration-Run Indefinitely

    3)Sechedule-勾选Initalize all Vusers before Run

     

    容错性测试:通过模拟一些非正常情况(如:服务器突然断电、网络时断时续、服务器硬盘空间不足等),验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA(自动容灾系统),还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。

     

    问题排除性测试:通过原有案例或经验判断,针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如:上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。

     

    测评测试是用于获取系统的关键性能指标点,而进行的相关测试。主要是针对预先没有明确的预期测试结果,而是要通过测试获取在特定压力场景下的性能指标(如:事务响应时间、最大并发用户数等)。

     

    评测事务交易时间:为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值,获取事务在这种压力下的响应时间。

     

    评测事务最大并发用户数:为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境,评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义(如响应时间,CPU占用率,内存占用率,已出现点击率峰值,已出现吞吐量峰值等)。

     

    评测系统最大并发用户数:为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率,定义各事务在综合场景中所占的比率,以比率方式分配各事务并发用户数。

     

    模拟真实环境或直接采用真实环境,评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义(如响应时间,CPU占用率,内存占用率,已出现点击率峰值,已出现吞吐量峰值等)。取值标准以木桶法则为准(并发数最小的事务为整个系统的并发数)。

     

    评测不同数据库数据量对性能的影响:针对不同数据库数据量的测试,将测试结果进行对比,分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后,或某些模块客户要求数据量较大时可能存在的隐患。

     

    问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能,可以直接找出引起性能问题所在的代码或模块。

     

    该类测试主要还是通过测试出问题的脚本场景,并可以增加发现和检测的工具,如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。

     

    (本文转载自网络,感谢原文作者,如有版权问题请及时留言,我会第一时间处理)

     

     


    展开全文
  • 压力测试服务器稳定性测试
  • dns服务器稳定性
  • 服务器稳定性测试方法

    千次阅读 2019-07-04 16:02:12
     正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能,如:数据冗余、网卡荣誉、电源冗余、风扇冗余等。 一些测试方法主要分以下几种:  压力测试:已知系统高峰期使用...

            服务器稳定性是最重要的,如果在稳定性方面不能够保证业务运行的需要,在高的性能也是无用的。

      正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能,如:数据冗余、网卡荣誉、电源冗余、风扇冗余等。

    一些测试方法主要分以下几种:

      压力测试:已知系统高峰期使用人数,验证各事务在最大并发数(通过高峰期人数换算)下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应(如:宕机、应用异常中止等)。
    Ramp Up 增量设计:如并发用户为75人,系统注册用户为1500人,以5%-7%作为并发用户参考值。一般以每15s加载5人的方式进行增压设计,该数值主要参考测试加压机性能,建议Run几次。以事务通过率与错误率衡量实际加载方式。
    Ramp Up增量设计目标: 寻找已增量方式加压系统性能瓶颈位置,抓住出现的性能拐点时机,一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数,如早晨的登录,下班后的退出,工资发送时的消息系统等。
      另一种极限模拟方式,可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变,在各脚本事务点中设置同集合点名称(如:lr_rendzvous("same");)在场景设计中,使用事务点集合策略。以同时达到集合点百分率为标准,同时释放所有正在Run的Vuser。
      稳定性测试:已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景,测试时将每个场景按照一定人数比率一起运行,模拟用户使用数年的情况。并监控在测试中,系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。
      根据上述测试中,各事务条件下出现性能拐点的位置,已确定稳定性测试并发用户人数。仍然根据实际测试服务器(加压机、应用服务器、数据服务器三方性能),估算最终并发用户人数。

    场景设计思想:
         从稳定性测试场景的设计意义,应分多种情况考虑:

      针对同一个场景为例,以下以公文附件上传为例简要分析场景设计思想:

    1)场景一:已压力测试环境下性能拐点的并发用户为设计测试场景,目的验证极限压力情况下测试服务器各性能指标。

    2)场景二:根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。

      测试方法:采用1)Ramp Up-Load all Vusers simultaneously

    2)Duration-Run Indefinitely

    3)在Sechedule-勾选Initalize all Vusers before Run

      容错性测试:通过模拟一些非正常情况(如:服务器突然断电、网络时断时续、服务器硬盘空间不足等),验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA(自动容灾系统),还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。

      问题排除性测试:通过原有案例或经验判断,针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如:上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。

      测评测试是用于获取系统的关键性能指标点,而进行的相关测试。主要是针对预先没有明确的预期测试结果,而是要通过测试获取在特定压力场景下的性能指标(如:事务响应时间、最大并发用户数等)。

      评测事务交易时间:为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值,获取事务在这种压力下的响应时间。

    评测事务最大并发用户数:为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境,评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义(如响应时间,CPU占用率,内存占用率,已出现点击率峰值,已出现吞吐量峰值等)。

      评测系统最大并发用户数:为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率,定义各事务在综合场景中所占的比率,以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境,评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义(如响应时间,CPU占用率,内存占用率,已出现点击率峰值,已出现吞吐量峰值等)。取值标准以木桶法则为准(并发数最小的事务为整个系统的并发数)。

      评测不同数据库数据量对性能的影响:针对不同数据库数据量的测试,将测试结果进行对比,分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后,或某些模块客户要求数据量较大时可能存在的隐患。

      问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能,可以直接找出引起性能问题所在的代码或模块。

      该类测试主要还是通过测试出问题的脚本场景,并可以增加发现和检测的工具,如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试

     

    展开全文
  • 软件测试服务器稳定性测试方法文.pdf
  • 从而团队提出对平台进行稳定性分析,通过给系统施加一定业务压力大情况下,使系统持续运行一段时间,以此来检测系统是否稳定运行(下统称稳定性测试测试)。 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

    展开全文
  • 文章目录系统测试概述功能测试性能测试负载测试压力测试性能测试、压力测试、负载测试的关系兼容性测试安全测试健壮性测试配置测试可用性测试文档测试 系统测试概述 系统测试的定义 将已经集成好的软件系统,作为...

    系统测试概述

    • 系统测试的定义
      • 将已经集成好的软件系统,作为整个计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行(使用)环境下, - 对计算机系统进行一系列测试活动。
    • 根本任务
      • 证明被测系统的功能和结构的稳定性;还要有一些非功能测试:性能测试、压力测试、可靠性测试等等。
    • 目的
      • 确保软件产品能够被用户或操作者接受。
    • 系统测试属于黑盒测试范畴,不再对软件的源代码进行分析和测试。
    • 系统测试的组织
      • 系统测试主要是由质量部门的测试工程师来主导工作。
        • 测试组组长:组织测试;
        • 测试分析员:负责设计和实现测试脚本和测试用例;
        • 测试者:负责执行测试脚本中记录的测试用例。
      • 系统测试员和用户
        • 相似的地方
          • 都是使用软件,一般不接触软件的代码
          • 都是假设软件应该正确实现说明书的功能
        • 不同的地方
          • 使用软件的目的
          • 对待错误
    • 系统测试的内容
      • 功能特性的测试:功能测试、用户界面测试、安装/卸载测试、可使用性测试。
      • 非功能特性的测试:性能测试、负载测试、压力测试、疲劳测试、安全测试、恢复测试、兼容性测试、可靠性测试、强度测试、容量测试、配置测试。

    功能测试

    功能测试(Functional Test)是在规定的一段时间内运行软件系统的所有功能,以验证这个软件系统有无严重错误。

    • 目标
      • 检验产品功能是否正确实现
    • 内容
      • 正常功能、异常功能、边界测试、界面测试、接口测试、安全测试、错误处理测试等。
    • 依据
      • 需求规格说明书
    • 方法
      • 黑盒测试
        在这里插入图片描述

    性能测试

    性能测试(Performance Testing)通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

    • 目标
      • 对产品的性能进行测试,检验是否达标、是否能够保持。
    • 工具
      • 在需要大访问量时候尤其需要使用工具。
      • 并发性能测试工具 (load—负载)
        • LoadRunner、 QALoad、 SilkPerformer、 WebLoad
    • 用户视角的软件性能
      • 从用户角度来说,软件性能就是软件对用户操作的响应时间。
    • 系统管理员视角的软件性能
      • 系统的响应时间;
      • 系统运行时服务器的状态,如CPU利用情况、内存使用情况等;
      • 系统是否能够实现扩展;
      • 系统支持多少用户访问;
      • 系统性能可能的瓶颈在哪里;
      • 系统是否支持7*24小时的业务访问。
    • 软件性能指标
      • 并发用户
        • 一给定时间内,某个时刻与服务器同时进行会话操作的用户数。
      • 响应时间
        • 客户端发出请求到得到服务器返回结果的整个过程所经历的时间。
      • 吞吐量
        • 单位时间内系统处理的客户请求的数量
        • 一般来说,吞吐量用请求数/秒或页面数/秒来衡量。
        • 从业务的角度,吞吐量也可以用访问人数/天或处理的业务数/小时等单位来衡量。
        • 从网络的角度来说,也可以用字节数/天等单位来考察网络流量。
      • 资源利用率
        • 指系统资源的使用程度,比如服务器的CPU利用率、内存利用率、磁盘利用率、网络带宽利用率等。
    • 软件性能要素
      • 环境要素
        • 软件、硬件、网络
      • 业务要素
        • 用户数、执行功能、数据量
      • 在使用性能指标描述软件的性能特征时,应该给出明确的软件性能要素,否则,所给出的性能指标无法参考。
    • 性能测试用例的设计:主要是通过改变模拟的业务因素来测试软件的性能。
      • 并发用户数
        • 精算法
          在这里插入图片描述
        • 估算法
          在这里插入图片描述
        • 经验值
          • 对于一些系统,可以通过同类软件系统的用户数据来估算,这种估算可以通过类似系统的日志分析和问卷调查来进行。
      • 吞吐量
      • 基于业务的设计

    负载测试

    • 定义
      • 数据在超负荷环境下运行,测试软件系统是否能够承担。这种超负荷主要指多并发用户。
    • 方法
      • 人为生成大数据量,并利用工具模拟频繁并发访问
    • 工具
      • 一般需要使用自动化工具
    • 考察指标
      • 响应时间、交易容量、资源使用率等

    压力测试

    • 定义
      • 指系统不断施加越来越大的负载(并发,循环操作,多用户,网络流量)的测试。
    • 目标
      • 通过确定一个系统的瓶颈或者不能接收的性能点,来确定系统能提供的最大服务级别的测试。

    性能测试、压力测试、负载测试的关系

    • 性能测试是正常情况下的性能指标;
    • 压力测试是测试系统的瓶颈所在;
    • 负载测试是指系统重负荷性能指标;
    • 性能测试、压力测试、负载测试在广义上讲都是性能测试的内容,建议将三种测试结合起来并行进行。

    兼容性测试

    • 定义
      • 测试软件在一个特定的硬件、软件、操作系统、网络等环境下系统能否正常运行。
    • 目的
      • 检验被测软件对其他应用软件或者其他系统的兼容性。

    安全测试

    • 定义
      • 安全测试检测系统对非法入侵的防范能力。
    • 应用程序级别的安全性测试
    • 数据库安全性测试
    • 系统级别的安全性测试

    健壮性测试

    • 定义
      • 又称为容错测试。主要检查系统容错能力。当系统出错时,能否在指定的时间间隔内修正错误并重启系统。
    • 方法
      • 容错测试首先要通过各种手段让软件系统强制发生故障,然后验证系统能否快速恢复。

    配置测试

    • 定义
      • 配置测试将验证软件与其所依赖硬件环境的依赖程度。
    • 测试中的硬件环境指进行测试所必需的服务器、客户端、网络连接设备,以及打印机、扫描仪等辅助硬件设备所构成的环境。
    • 所有软件都需向用户说明其运行的硬件环境,对于多层结构的软件系统来说,需要分别说明其服务器、客户端以及网络所需的环境。

    可用性测试

    可用性测试是面向用户的系统测试。让一群有代表性的用户尝试对产品进行典型操作,- - 同时观察员和开发人员在一旁观察,聆听,做记录。

    • 系统中是否存在繁琐的功能以及指令;
    • 安装过程是否复杂;
    • 错误信息提示内容是否详细;
    • GUI接口是否标准;
    • 登录是否方便;
    • 需要用户记住内容的多少;
    • 帮助文本是否详细;

    文档测试

    • 定义
      • 文档测试是对系统提交给文档进行验证,它要求检查系统的文档是否齐全。
    • 文档的种类
      • 包括联机帮助文档或用户手册,指南和向导,
      • 安装、设置指南,示例及模板,错误提示信息,
      • 用于演示的图像和声音,
      • 授权/注册登记表及用户许可协议,
      • 软件的包装、广告宣传材料等。
    展开全文
  • FTP服务器稳定性测试

    千次阅读 2012-09-12 18:21:05
    FTP服务器稳定性探讨,如何部署FTP服务在server2003上,可能广大网友们有其他的选择,我选择的是Filezilla server。毕竟他是开源又免费 在架构师的悉心指导下,对FTP有了个更深入的认识,主要有以下几点,先分享...
  • 如何进行稳定性测试????

    千次阅读 2019-12-09 18:25:56
    在微信公众号上偶然看到一篇关于如何进行稳定性测试的文章,文章标题为 “面试官说:请你说一下软件稳定性怎么测试”, 在此转载分享:https://mp.weixin.qq.com/s/u3VEmGX7GbbkFEVeMTRkpw 1.对软件多次测试,长...
  • 性能和稳定性测试报告模板

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

    千次阅读 2018-08-28 17:04:00
    如何测试软件的稳定性其实是很难的,按照常规思路,只有长期的用户场景测试才能一定程度上保证软件的稳定性是可靠的,但并不能百分之百确定软件就是稳定的。软件测试本身就是由局限和尽头的,无穷的测试只能带来高...
  • 服务端稳定性测试

    千次阅读 2019-05-12 20:48:05
    二、稳定性测试方法 方法一:线下稳定性测试通常的做法 关注指标: 测试注意事项 方法二:线上监控/线上巡检 三、故障模拟测试在提升系统稳定性中的实际应用 四、客户端稳定性测试 一、什么是稳定性 稳定性...
  • 1、LTP--linux稳定性测试: LTP套件是由 Linux Test Project 所开发的一套系统测试套件。它基于系统资源的利用率统计开发了一个测试的组合,为系统提供足够的压力。通过压力测试来判断系统的稳定性和可靠性。 2、...
  • 软件稳定性测试

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

    千次阅读 2016-01-31 13:04:23
    正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能,如:数据冗余、网卡荣誉、电源冗余、风扇冗余等。 一些测试方法主要分以下几种: 压力测试:已知系统高峰期使
  • 软件测试工程师经典面试题

    万次阅读 多人点赞 2018-10-27 23:55:52
    涉及的知识主要有MySQL数据库的使用、Linux操作系统的使用、软件测试框架的问题,测试环境搭建问题、当然还有一些自动化测试和性能测试的问题。测试工程师的面试题,基本上都是大同小异的,面试的核心主要在于框架...
  • jmeter-稳定性测试

    千次阅读 2019-09-18 09:53:40
    1、需要记录借助SSH Secure Shell 应用服务器测试),数据库服务器测试)cup以及内存占用情况,网络占用情况。 连接上服务器后输入命令:top 可以查看服务器CPU内存使用情况,nload ens160 可以查看网络使用情况...
  • 性能测试压力变化模型随着单位时间流量的不断增长,被测系统的压力不断增大,服务器资源会不断被消耗,TPS 值会因为这些因素而发生变化,而且符合一定的规律。淘宝网性能测试压力变化模型如图中:a 点:性能期望值b ...
  • 1、负载测试主要关心的是用户规则和需求,压力测试关心的是软件系统本身 2、并发测试单独提出来,是因为并发测试往往涉及服务器的并发容量,...4、稳定性测试测试系统在一定负载下运行长时间后是否会发生问题。 ...
  • 软件稳定性测试测试

    千次阅读 2019-02-01 13:20:35
    1.对软件多次测试,长时间运行,是否正常运行 2.长时间对软件开启关闭软件和系统是否正常 3.软件长时间执行某个业务后切换到别的不同的业务操作是否受影响 4.软件长时间开启但是不执行任何操作,然后检查能否正常...
  • 作为测试工程师,相信大家对jmeter这个工具在熟悉不过了,小编的前几篇博客中也有写到jmeter用于接口自动化测试的实战文章,今天主要用来介绍使用jmeter来进行性能测试稳定性测试的实战。 1、性能测试 性能测试...
  • 软件测试面试题(面试前准备篇)

    万次阅读 多人点赞 2019-09-27 10:42:37
    目录 一、问题预测 让简单介绍下自己(每次面试开场) ...为什么做测试,觉得自己做测试有哪些优势?(有问到) 知道哪些Bug系统 9.测试用例的基本要素是? 二、介绍一下公司项目 三、技能...
  • 服务器的认识

    千次阅读 多人点赞 2019-07-31 17:51:43
    我们要根据服务器的用途,来决定服务器的性能、容量和可靠需求。 这里我们按照最典型的基础架构:Web服务器、数据服务器、应用程序服务器来展开讨论。 1.Web服务器 Web服务器对硬件要求不高,甚至一般的硬件...
  • 压力测试工具

    万次阅读 多人点赞 2018-12-20 16:06:28
    目录 1 性能测试... 2 2 压力测试(Stress Test)... 2 2.1 网站测试... 2 2.2 系统测试要求... 3 3 测试工具... 3 3.1 Webbench. 4 3.1.1 Ubuntu 下载安装... 5 3.1.2 ...
  • 超级Ping是一个可以实现对多个主机网络状态的实时监测,并有自动记录分析结果、断网自动告警等功能的网络监测软件。监测的结果可以记录在以IP地址为文件名的文本文件中,也可以记录在Acess数据库中,用户可自由选择...
  • 测试开发需要学习的知识结构

    万次阅读 多人点赞 2018-04-12 10:40:58
    努力成为一个优秀的测试开发从业者,加油!... - 假装在测试的回答 - 知乎白盒与黑盒测试什么区分1、黑盒测试 黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 202,791
精华内容 81,116
关键字:

服务器测试稳定性