标准搜索结果: 'GB/T 39788-2021'
| 标准编号 | GB/T 39788-2021 (GB/T39788-2021) | | 中文名称 | | | 英文名称 | System and software engineering - Performance testing method | | 行业 | 国家标准 (推荐) | | 中标分类 | L77 | | 字数估计 | 42,451 | | 发布机构 | 国家市场监督管理总局、中国国家标准化管理委员会 | GB/T 39788-2021: 系统与软件工程 性能测试方法
GB/T 39788-2021 英文名称: System and software engineering -- Performance testing method
1 范围
本标准规定了系统与软件性能测试的测试过程、测试需求模型和测试类型。
本标准适用于系统与软件性能测试的分析、设计和执行。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文
件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T 25000.10-2016 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第10部分:
系统与软件质量模型
GB/T 25000.23-2019 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第23部分:
系统与软件产品质量测量
GB/T 38634.1-2020 系统与软件工程 软件测试 第1部分:概念和定义
3 术语和定义
GB/T 38634.1-2020界定的以及下列术语和定义适用于本文件。
3.1
负载测试
用于评估系统与软件在预期变化负载下的性能表现,负载通常位于低谷、典型和高峰使用的预期条件之间。
注:性能效率测试的一种。
3.2
压力测试
用于评估系统与软件在高于预期或指定容量负载需求,或低于最少需求资源的条件下的性能表现。
注:性能效率测试的一种。
3.3
峰值测试
用于评估系统与软件在短时间内负载大幅度超出通常负载时的性能表现。
注:性能效率测试的一种。
3.4
扩展性测试
用于评估系统与软件适应外部性能需求变化(如用户负载支持、事务数量、数据量等)的性能表现。
注:性能效率测试的一种。
3.5
容积测试
用于评估系统与软件在吞吐量、存储容量或两者兼考虑的情况下处理指定数据量(通常达到最大指定容量或接近最大值)的能力。
注:性能效率测试的一种。
3.6
疲劳强度测试
用于评估系统与软件在指定的时间段内,能够持续维持所需的负载的能力。
注:性能效率测试的一种。
4 性能测试概述
性能测试用于评估待测系统与软件在给定的时间和其他资源限制下完成其指定功能的程度,也称
作性能效率测试。
系统与软件性能效率质量特性和子特性见GB/T 25000.10-2016中4.3.2.2。系统与软件性能效
率质量测度参见附录A,质量测度的描述和测量函数见GB/T 25000.23-2019中8.3,在使用时,应依
据系统和软件的实际需求对质量测度进行裁剪。
移动应用性能测试案例参见附录B。
大型信息系统性能测试案例参见附录C。
云应用性能测试案例参见附录D。
嵌入式软件性能测试案例参见附录E。
5 性能测试过程
5.1 概述
性能测试过程包括性能测试需求分析、性能测试设计和实现、性能测试执行和性能测试总结四个过程。
5.2 性能测试需求分析
性能测试需求分析包括下列活动:
a) 确定性能测试的准入准则,在系统构架确定后或冒烟测试通过后执行,测试介入越早越好。
b) 确定待测系统与软件的性能需求。性能需求可来自合同、需求规格说明等文档中所明示的需
求,或者由业务、数据、预期的用户和系统行为约定的隐含需求。性能需求宜依据性能需求模
型来确定,性能需求模型见第6章。
c) 识别待测系统与软件相关的其他外部应用。
d) 确定性能测试完成或终止准则。
5.3 性能测试设计和实现
性能测试设计和实现过程用于导出测试用例和测试规程,相关的活动包括:
a) 确定所需监测的指标、业务场景、被测业务的用户角色分布。
b) 确定采用的性能测试类型。
c) 依据历史运行情况或实际运行环境设计测试数据生成和读取规则。测试数据包括为待测系统
与软件准备的基础数据,以及运行所需要的数据。数据量应与测试环境的配置相适应或与未
来扩展数据量一致,在实际环境中数据量应与实际规模相一致;在模拟环境中宜等比对数据规
模进行调整。
d) 确定负载生成方式,可采用工具或人工的方式加压。应根据制定的测试方案布置各测试场景,
包括并发用户数、执行时长以及需要监视的性能指标等。
e) 针对所需测试的业务逻辑设计测试用例。
f) 依据需求或实际运行环境确定测试用例顺序。
g) 开发测试脚本。通过脚本对待测系统与软件的用户业务行为进行模拟,脚本的开发可采用录
制、编写或定制开发等方式。完成测试脚本开发后,应进行功能验证,确保测试脚本已完成用
户业务行为。
h) 确定暂停和恢复准则:
1) 暂停准则可包括:
---系统不可用;
---由于不确定原因导致服务器宕机或必要服务停止运行;
---应用程序在打开状态下具有阻塞程序/严重缺陷;
---所需的依赖项不可用。
2) 恢复准则可包括:
---系统和/或服务器可用,启动并运行;
---解决阻塞和/或关键问题;
---应用程序功能已恢复;
---测试数据处理周期未完成时的恢复程度。
5.4 性能测试执行
性能测试执行过程包括下列活动:
a) 执行前就绪检查,对性能测试所需环境和资源进行评估。
b) 由人工或利用测试工具执行测试脚本,并监控执行过程中的性能指标,记录测试结果。
c) 性能测试通常需考察待测系统与软件在一段时间范围内的综合表现,按需取平均值、最大值或
最小值作为测试结果。
d) 若性能测试异常终止或不满足需求或预期,填写性能问题报告单。问题报告单应包括问题来
源、场景配置、问题描述、问题等级等内容。
e) 判断所执行的测试用例是否通过。如果测试不通过,分析具体情况,确定是由软件本身性能瓶
颈所引起的,还是由测试环境所引起的。
图1给出了性能测试执行框架,该执行框架由5个组件组成:输入、运行环境和待测系统与软件、输
出、控制单元和监督单元。其中,输入、运行环境和待测系统与软件以及输出是一般软件测试的组成部分,控制单元和监督单元是性能测试所特有的。输入提供了性能测试的条件,可能包括测试数据及其相关的控制机制。控制单元则为输入提供了相关信息,例如运行环境或测试执行顺序等所需的更改。运行环境包括待测系统与软件、运行支撑环境和性能测试支撑环境。控制单元用于决定和控制输入组件的输入。监督单元监控输出组件的时间特性和资源利用性和容量,包括测试过程的即时信息。
注1:控制单元可控制的信息包括并发请求、思考时间、集合点等。
注2:资源利用性如处理器占用率、内存占用率等。
注3:时间特性如响应时间、周转时间等。
注4:容量如最大并发数、最大用户数等。
注5:输入如系统登录用户名密码、查询关键词,输出如返回的查询结果等。
5.5 性能测试总结
性能测试总结包括下列活动:
a) 整理性能测试结果。性能测试的结果宜考虑多种环境因素下的综合结果,采用数学和统计方
法进行数据综合分析考虑,如标准差、用户约定的统计模型。
注1:分析数据时,宜删除异常数据,例如系统启动或关闭时捕获的数据。
注2:响应时间、吞吐率和资源利用率考虑包括平均值、最小值、最大值或标准偏差。
注3:并发请求数宜分析最大并发请求。
b) 编写软件性能测试报告,内容宜包括:测试结果分析、对软件性能的评价和建议。
c) 根据测试记录和性能问题报告单编写性能问题报告。性能测试事件报告宜包含问题来源、场
景配置、问题描述和问题等级等内容。
6 性能测试需求模型
6.1 概述
性能测试需求模型应考虑环境、数据、业务流程、用户分布、请求时序分布和网络状态等因素。
6.2 环境需求
针对不同质量要求,应考虑测试环境对性能测试的影响,推荐使用系统或软件的实际生产环境作为
性能测试环境。在进行性能测试环境规划和设计时,应考虑以下因素:
a) 稳定性:在相同条件下的多轮次测试结果应保持一致,或在可接受误差范围内;
b) 独立性:为避免测试结果失真,测试环境应与其他在用系统或软件保持相互隔离;
c) 可控制性:测试环境中的所有设备和资源应可被监控或控制。
性能测试环境考虑因素包括:
a) 硬件配置:包括需使用的计算机、服务器、磁盘阵列或其他专用设备,考虑上述硬件资源的型
号、数量、部署逻辑、通信和连接状态等;
b) 软件配置:包括需使用的操作系统、中间件、数据库、性能测试工具或其他专用软件,考虑前述
软件资源的版本、补丁等;
c) 网络配置:包括需使用的交换机、路由器、集线器或其他专用网络设备,考虑前述网络资源的组
网方式、传输速率和延迟特性等。
当现有条件无法支撑测试环境构建时,应最大化利用现有资源进行测试环境构建,并分析测试环境
和生产环境的差异性,如不同的软硬件或网络设备可能带来的性能增益或损耗。
6.3 数据需求
性能测试所需的数据包含如下需求:
a) 数据的类型和业务需求相匹配。
b) 数据量和业务需求相匹配。
c) 数据分布模型和业务需求相匹配。应通过收集历史数据,确定数据需求。
6.4 业务流程
性能测试应首先考虑测试主要或重要的业务流程,不同的业务流程对系统产生的压力不同。在业
务流程选择时应基于风险评估考虑如下因素:
a) 资源的占用情况;
b) 业务使用频率;
c) 业务的重要性。
6.5 用户分布模型
性能测试的用户角色分布应服从真实环境分布,可通过用户分布模型进行描述。
示例:图2描述了一个用户分布模型,该模型中有角色1、2、3三个角色,其中角色1(10%)、角色2(30%)、角色3(60%)分别对应测试模型中负载的20、60、120的用户数量。从图2中可以看出系统的负载大部分来自角色3,并且该角色比其他角色的性能要求更高。
6.6 请求时序分布模型
性能测试请求发送时序应符合业务需求。
性能测试通过一系列场景的执行来完成,分析用户的请求模型是获取性能测试需求的有效手段,即
定义系统的典型使用方式,考虑用户使用系统的典型业务、时间段和用户数量。图3给出了某个请求时序分布的示意图,描述了一天中某系统中负载随时间变化的情况。
6.7 网络状态需求
网络状态的需求应从以下方面进行考虑:
a) 保证网络传输速度。如果网络传输有较大延迟,可能影响性能测试结果。
b) 网络背景流量应尽可能少。如果背景流量没有限制在合理的范围内,可能导致应用程序和/或
网络故障。
7 性能测试类型
7.1 负载测试
7.1.1 建立模型
负载测试模型由负载量、负载业务和运行时间来描述。在指定业务负载和运行时间的条件下,测量被测业务的负载量。
负载测试模型的构建过程包括:
a) 确定所需测试负载的业务;
b) 确定被测各业务的用户角色分布;
c) 确定被测各业务的负载量需求;
d) 确定负载生成方法。
7.1.2 导出测试覆盖项
对于负载测试,每项被测业务的负载量需求为一个测试覆盖项。
7.1.3 导出测试用例
负载测试用例按以下步骤导出:
a) 确定前提条件:
1) 根据业务场景实际情况,确定待测业务的前置业务条件;
2) 确定需要同时运行的测试用例组合。
b) 设计输入数据:
1) 确定各操作所需的输入数据;
2) 确定输入数据的来源,例如历史数据或相似系统的数据。
c) 选择用户操作:
1) 依据用户使用场景确定用户操作;
2) 确定正常/峰值时间用户数;
3) 确定用户活动趋势;
4) 确定思考时间。
d) 确定预期结果:
1) 确定各项业务的预期输出;
2) 适用时,确定系统的监视指标(如响应时间、并发用户数、资源利用率等);
3) 确定负载测试的通过/不通过准则,例如响应时间或资源占用率大于某阈值时则视为不通
过该次负载测试。
7.2 压力测试
7.2.1 建立模型
压力测试用于评估软件在极重负载下是否健壮、可用。指通过增加系统负载,测量系统与软件在极限负载下的状态。
a) 确定压力测试的指标需求;
b) 确定压力测试的关键业务场景;
c) 确定被测业务的用户角色分布;
d) 确定压力测试用例的生成方法。
7.2.2 导出测试覆盖项
对于压力测试,每项被测业务的压力测试需求为一个测试覆盖项。
7.2.3 导出测试用例
压力测试用例按以下步骤导出:
a) 确定前提条件:
1) 根据实际业务场景,确定关键业务预期的最大负载;
2) 确定需要同时运行的测试用例组合。
b) 设计输入数据:
1) 确定各操作所需的输入数据;
2) 确定输入数据的来源,例如历史数据或相似系统的数据;
3) 输入数据设计时通常要考虑如下内容:
---提供要求处理的信息量,超过预期的最大负载;
---数据传输能力的饱和试验,要求比设计能力传输更多的数据:内存的写入和读出,外
部设备,其他分系统及内部界面的数据传输等;
---存储范围(如缓冲区、表格区和数据库)超过额定大小的能力。
c) 选择用户操作:
1) 依据用户使用场景确定用户操作;
2) 确定正常/峰值时间用户数,通常采用负载递增加载和峰谷加载(高低突变加载);
3) 确定用户活动趋势;
4) 确定思考时间。
d) 确定预期结果:
1) 确定各项业务的预期输出;
2) 适用时,确定系统的监视指标(如响应时间、并发用户数、资源利用率等);
3) 确定系统与软件在极限状态下(超出预期峰值或者可用资源少于最低要求时)的性能。
表2给出了某业务场景下压力测试的示例。负载是采用递增加载方式,当负载(用户数)达到100
时,系统响应时间增加过快,但在运行范围内;当负载(用户数)达到150时系统存在异常。由表中数据可知,该系统的性能瓶颈是由数据库查询时间导致。
7.3 峰值测试
7.3.1 建立模型
峰值测试模型由峰值负载业务、峰值负载量强度、峰值持续时间和监视指标来描述。对于指定的负载业务,当负载业务瞬间峰值(超过系统所能正常承载的强度)来临时,系统将降级运行;当负载业务负载逐渐降低至正常水平,检查系统是否能恢复正常运行。
峰值测试模型的构建过程包括:
a) 确定所需测试负载的业务;
b) 确定被测各业务的用户角色分布;
c) 确定对应的监视指标;
d) 确定被测各业务的峰值负载量强度、峰值持续时间、负载......
|