智能物联网性能检测流程_第1页
智能物联网性能检测流程_第2页
智能物联网性能检测流程_第3页
智能物联网性能检测流程_第4页
智能物联网性能检测流程_第5页
已阅读5页,还剩6页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1智能物联网性能检测流程本标准规定了基于智能物联网应用系统的性能检测相关术语和定义、检测方法和检测流程。本标准适用于基于智能物联网应用系统的通用性能检测。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅所注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。GB∕T25000.10-2016系统与软件工程系统与软件质量要求和评价(SQuaRE)第10部分:系统与软件质量模型GB∕T25000.51-2016系统与软件工程系统与软件质量要求和评价(SQuaRE)第51部分:就绪可用软件产品(RUSP)的质量要求和测试细则3术语和定义下列术语和定义适用于本文件。3.1智能物联网ArtificialIntelligence&InternetofThingsblockchain通过感知设备,按期约定协议连接物、人、系统和信息资源,在终端设备、边缘域或云中心通过机器学习对数据进行智能化分析,包括定位、比对、预测、调度等,实现对物理和虚拟世界的信息进行处理并作出反应的智能服务系统。3.2基准测试Benchmarks在一定的软件、硬件及网络环境下,模拟一定数量虚拟用户运行一种或多种业务,将测试结果作为基准数据,在系统调优或系统测评中,通过运行相同的业务场景并比较测试结果,确定调优是否达到效果或者为系统的选择提供决策数据。3.3压力测试Pressuretest在一定的软件、硬件及网络环境下,通过模拟大量的虚拟用户向服务器产生负载,使得服务器的资源处于极限状态下长时间连续运行,以测试服务器在高负载情况下是否能够稳定工作。3.4峰值测试Peaktest在一定的软件、硬件及网络环境下,通过运行一种或多种业务在不同虚拟用户数量情况下,测试服务器的性能指标是否在用户的要求范围内,用于确定系统所能承载的最大用户数、最大有效用户数以及不同用户数下的系统响应时间及服务器的资源利用率。3.52容量测试Capacitytest在一定的软件、硬件及网络环境下,向数据库中构造不同数量级别的时间记录,在一定的虚拟用户数量情况下运行一种或多种业务,获取不同数据级别的服务器性能指标,以确定数据库的最佳容量和最大容量。3.6稳定性测试Stabilitytest在一定的软件、硬件及网络环境下,通过给系统加载一定的压力,让系统持续运行一段时间,检测系统是否能够稳定运行。4检测方法4.1总则本标准规范的对象是智能物联网性能检测流程。主要针对感知层、网络传输层以及业务应用层三方面概述通用性能测试方法。其通用的性能测试方法包括:基准测试、负载测试、压力测试、容量测试以及稳定性测试。智能物联网架构图如图1所示:图1智能物联网架构图4.2基准测试基准测试是一种可再现性的测试(对于软件产品来来说,同样的数据量标准、硬件标准下性能指标相对确定;对于硬件产品来说,基准测试标准更是固定而明确的),一般首次测试,会把单用户(如果是双节点负载均衡就要双用户)单场景作为基准测试,而对于多轮测试来说,上一轮测试的稳定基准配置,定为新的基准测试标准,因为基准测试的关键是要获得一致的、可再现的结果,为多用户并发测试和综合场景测试等性能分析提供参考依据。故可认为基准测试是最基础的性能测试,如果基准测试的结果不能达到预期要求,后续性能场景就没必要测试。一般的性能测试往往只在版本计划中或遭遇系统性能问题时进行,而基准测试在日常中进行,当软件增加了新模块或有大的迭代更新,当硬件环境做了优化提升时,特别是在发生重大变更事件(例如:3系统配置、环境发生变更)之前与之后的测试,让测试结果数据与一般的性能测试结果数据更有实质上的参考意义。因为,当为系统创建性能基准后,基准数据作为性能指标的参照物,可用于判断任意一项变更为系统带来的具体影响。例如:某项配置优化后能够为系统带来的性能提升是多少、系统某项操作历史数据的增长与性能响应的关系、系统环境的变更对系统性能产生的影响。基准测试有两种主要的策略:一是针对整个系统的整体测试,另外是单独测试。这两种策略被称为集成式(full-stack)和单组件试(single-component)基准测试。测试方法可参考如下:a)避免一些常见错误,如:在多用户的场景中,只做单用户的测试;使用默认的服务器配置;反复执行同一个查询等;b)根据实际情况分析明确基准测试的目标,建立测试和结果文档化的规范;c)每次执行测试时,都创建单独的目录将测试结果、配置文件、测量指标、脚本等保存下来,确认测试结果是否可重复;d)每次测试前,确保系统状态一致;测试中,修改的参数尽量少;e)基准测试通常要运行多次,具体依据程序的重要程度而定,运行结果一般取最好值或平均值。获得结果后,对结果进行分析,得出诸如“升级4核CPU可以在保持响应时间不变的情况下,获得超过50%的吞吐量增加”的结论。4.3负载测试负载测试是在一定的工作负荷下,给系统造成的影响及系统响应时间,通常可描述为一种特定类型的压力测试(如逐步增加用户数量或用户请求来对系统进行加压)。其目标是测试在一定负载情况下的系统性能(不关注稳定性,目的只在于得到不同负载下系统的相关性能指标)。在基准测试通过后,应该先进行较小负荷下的负载测试。此负荷需要根据系统使用相关数据得出,如设备驱动接收实际设备上报数量、系统平均每天访问量、每日完成事务数等。通过此测试,发现一些较表面的性能问题并进行处理。较小负荷下的负载测试通过后,需要进行更大负荷的测试。可通过相关数据的支持,如历史日均压力、日最高压力等信息,估算出未来几年的日均以及日最高压力,再通过一些通用估算方法、如二八原则(80%的工作在20%时间内完成,相当于2小时完成一天8小时的工作量),将日压力转换成峰值压力,峰值压力即为可预期到的最大负载压力。4.4压力测试压力测试是在一定的负荷条件下,长时间连续运行系统所造成的性能影响。其目标是测试在一定的负载下系统长时间运行的稳定性,但这个负载不一定是应用系统本身造成的,比如利用脚本或工具测试会事先吃掉服务器的一部分CPU、内存或带宽等。压力测试尤其关注应用系统在大业务量情况下长时间运行时系统性能的变化(例如应用系统操作是否反应变慢、是否存在内存泄漏导致系统逐渐奔溃、是否能恢复等)。压力测试时测试应用系统的限制和故障恢复能力,包括以下两种情况:a)稳定性压力测试:通过给系统加载一定的业务压力下,长时间持续运行应用系统,观察各项性能指标是否在指定范围内,有无内存溢出、有无数据库连接不释放等情况;b)破坏性压力测试:在稳定性压力测试过程中往往会出现一些问题,如系统性能明显下降,但不容易暴露出其真实原因,通过破坏性不断加压的手段,往往能快速造成系统的崩溃或让问题明显的暴露出来。压力测试一般要求环境配置较高,最好与生产环境一致或者接近。其测试需考虑单用户运行压力测试场景,及多用户运行测试场景。44.5容量测试在压力测试的过程中,通过逐步增大系统的压力,直到性能指标不可接受或者出现了明显的拐点,即系统能够承受的最大压力,也就是容量,如图2所示。需要注意的是容量测试,通常和数据库有关,容量和负载的区别在于:容量关注的是大容量,而不需要关注使用中的实际表现。图2性能表现与压力关系图容量测试即测试确定系统可处理同时在线的最大用户数,使系统承受超额的数据容量来发现它是否能够正确处理。通过前面所说的性能测试,如果找到了系统的极限或苛刻条件下系统的性能表现,相当于在一定的程度上完成了负载测试和容量测试。容量可以看作系统性能指标中一个特定环境下的一个特定性能指标,即设定的界限或极限值。容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。知道了系统的实际容量,如果不能满足设计要求,就应该寻求新的技术解决方案,以提高系统的容量。有了对软件负载的准确预测,不仅能对软件系统在实际使用中的性能状况充满信心,同时也可以帮助用户经济地规划应用系统,优化系统的部署。4.6稳定性测试稳定性测试在于验证系统是否可稳定长期地运行,是否存在一些短时间内可能无法发现的缺陷(如内存泄漏等)。其本质与压力测试中的稳定性压力测试一样,区别在于稳定性测试要求应用系统的持续运行测试时间更长。实际应用中,为了缩短工期,可通过二八原则,将预期一天的工作量压力集中在2小时内完成,并持续加压10小时,相当于系统运行5天。期间注意监控各性能指标是否平稳,有无下降情况。5检测流程5性能检测流程一般包括制定测试计划和方案、测试前准备、测试执行、结果分析与调优、测试报告与总结几个阶段,如图3所示:图3性能检测流程图5.1测试计划和方案5.1.1确定测试目的:需明确性能测试目的,主要包括三类:性能符合性验证、性能能力验证、性能调优。性能符合性验证主要验证系统性能是否符合预定的设计目标,是否满足系统上线的需求等;性能能力验证主要是了解系统的整体性能状况;性能调优是为了通过性能测试查找系统的性能瓶颈,分析系统性能缺陷的原因,并进行针对性的性能优化。5.1.2确定测试范围:性能测试范围可以从系统任务书、系统需求规格说明、系统概要设计和用户手册等文件中获得。5.1.3确定性能指标:一般在系统任务书、系统需求规格说明、系统概要设计和用户手册等文件中可获取明确的性能指标;部分性能指标则需针对系统的业务特点、技术特点、应用情况、系统通用性能指标等进行综合分析来获得。5.1.4确定业务模型:业务模型一般包括系统的主要业务及其功能、关键业务信息及其处理流程、相应的业务量及比例。通过对生产系统的高峰时段进行采样,或者预估新功能投产后的情况来制定性能测试业务类型的选取和各类业务的比例。5.1.5确定测试策略:明确了测试目的、性能指标和业务模型后,应针对用户的需求确定测试策略,常用性能测试策略包含基准测试、关键业务的并发压力测试、混合业务的并发压力测试和混合业务的稳定性测试。5.1.6设计测试场景:测试场景是业务模型模拟系统的一些实际应用情况,包括业务分组及其对应的虚拟用户数,每种业务对应的运行参数、用户增长方式、测试迭代方式、用户退出方式、需要监视的性能指标等。5.1.7确定测试准则及测试风险:测试方和委托方必须要协商好测试准则,为测试的启动、暂停/再启动、结束工作提供参考标准。同时,还应对测试过程进行风险评估,对可能遇到的导致测试失败的情况进行分析,分析其发生可能性和可能造成的影响,并提出规避办法,为有效指导测试工作提供依据。5.2测试前准备工作6测试前准备工作包括测试环境准备、测试场景设计、测试工具准备和测试数据准备四部分:a)测试环境准备:即通常所说的应用系统测试环境,因做性能测试容易搞垮环境影响其他的功能测试,建议重新搭建一套专门用来做性能测试的环境;b)测试场景设计:根据性能需求分析设计符合用户使用习惯的场景;c)测试工具准备:负载工具(支持产生压力和负载,通过录制和生成脚本,设置和部署场景,产生并发用户和向系统施加持续的压力)、监控工具;d)测试数据准备:负载测试数据(如并发测试时需要多少数据)、DB数据量大小等。5.3测试执行a)编写测试脚本

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论