系统与软件工程性能测试方法

系统与软件工程性能测试方法

国家标准 GB/T39788一2021 系统与软件工程性能测试方法 Systemandsoftwareengineering一Performaneetestingmethod 2021-03-09发布 2021-10-01实施 国家市场监督管理总局 发布 国家标涯花警理委员会国家标准
GB/T39788一2021 次 目 前言 范围 2 规范性引用文件 术语和定义 性能测试概述 性能测试过程 性能测试需求模型 性能测试类型 附录A(资料性附录 性能效率的质量测度 16 附录B资料性附录移动应用性能测试案例 附录c(资料性附录》大型信息系统性能测试应用案例 22 25 附录D资料性附录)云应用性能测试案例 附录E(资料性附录)嵌人式软件性能测试案例 30
GB/39788一2021 前 言 本标准按照GB/T1.1一2009给出的规则起草 请注意本文件的某些内容可能涉及专利 本文件的发布机构不承担识别这些专利的责任 本标准由全国信息技术标准化技术委员会(SAC/TC28)提出并归口 本标准起草单位:上海计算机软件技术开发中心,深圳赛西信息技术有限公司、国家应用软件产品 质量监督检验中心,电子技术标准化研究院、电子科技集团公司第十研究所厦门理工学院、中 国电子科技集团公司第五十四研究所、内蒙古自治区电子信息产品质量检验院、山东道普测评技术有限 公司、北京轩宇信息技术有限公司航天系统科学与工程研究院、中电莱斯信息系统有限公司、广东 省科技基础条件平台中心,北京京航计算通讯研究所,浙江省电子信息产品检验所、西宁市大数据服务 管理局、上海第二工业大学、武汉大学 本标准主要起草人;龚家瑜、李文鹏,蔡立志,张肠肠,简炜、卢俊文、孙风丽、康京山、郭谢、王风玲 张峻、李军,高猛,王建强、郝躁璐陆澄漪、胡芸、杨舅、赵毅、易晶晶孙肖、于泉、王威、沈颖、杨玲萍 膝俊元、许颗媚、白万芳,谢晓园,吴克寿,巩韶飞、贾素田、李丽伴,孟宪伟
GB/39788一2021 系统与软件工程性能测试方法 范围 本标准规定了系统与软件性能测试的测试过醒.测试需求模型和测试类. 本标准适用于系统与软件性能测试的分析、设计和执行 规范性引用文件 下列文件对于本文件的应用是必不可少的 凡是注日期的引用文件,仅注日期的版本适用于本文 件 凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件 GB/T25000.10-2016系统与软件工程系统与软件质量要求和评价(SQuaRE)第10部分 系统与软件质量模型 GB/T25000.23一2019 系统与软件工程系统与软件质量要求和评价(sQuaRE)第23部分 系统与软件产品质量测量 GB/T38634.l12020 系统与软件工程软件测试第1部分:概念和定义 术语和定义 GB/T38634.1一2020界定的以及下列术语和定义适用于本文件 3.1 负载测试loadtesting 用于评估系统与软件在预期变化负载下的性能表现,负载通常位于低谷、典型和高峰使用的预期条 件之间 注性能效率测试的一种 3.2 压力测试stresstesting 用于评估系统与软件在高于预期或指定容量负载需求,或低于最少需求资源的条件下的性能表现 注性能效率测试的一种 3.3 峰值测试spiketesting 用于评估系统与软件在短时间内负载大幅度超出通常负载时的性能表现 注性能效率测试的一种 3,4 扩展性测试scalabilitytesting 用于评估系统与软件适应外部性能需求变化(如用户负载支持、事务数量、数据量等)的性能表现 注:性能效率测试的一种 3.5 容积测试olumetesting 用于评估系统与软件在吞吐量、存储容量或两者兼考虑的情况下处理指定数据量(通常达到最大指
GB/T39788一202 定容量或接近最大值)的能力 注，性能效率测试的一 种 3.6 疲劳强度测试endurancetesting 用于评估系统与软件在指定的时间段内,能够持续维持所需的负载的能力 注:性能效率测试的一种 性能测试概述 性能测试用于评估待测系统与软件在给定的时间和其他资源限制下完成其指定功能的程度,也称 作性能效率测试 系统与软件性能效率质量特性和子特性见GB/T25000.10-2016中4.3.2.2 系统与软件性能效 率质量测度参见附录A,质量测度的描述和测量函数见GB/T25000.23一2019中8.3,在使用时,应依 据系统和软件的实际需求对质量测度进行裁剪 移动应用性能测试案例参见附录B. 大型信息系统性能测试案例参见附录C 云应用性能测试案例参见附录D. 嵌人式软件性能测试案例参见附录E 5 性能测试过程 5.1概述 性能测试过程包括性能测试需求分析、性能测试设计和实现、性能测试执行和性能测试总结四个 过程 5.2性能测试需求分析 性能测试需求分析包括下列活动 确定性能测试的准人准则,在系统构攀确定后或冒烟测试通过后执行,测试介人越早越好 a b 确定待测系统与软件的性能需求 性能需求可来自合同、需求规格说明等文档中所明示的需 求,或者由业务、,数据、预期的用户和系统行为约定的隐含需求 性能需求宜依据性能需求模 型来确定,性能需求模型见第6章 识别待测系统与软件相关的其他外部应用 d 确定性能测试完成或终止准则 5.3性能测试设计和实现 性能测试设计和实现过程用于导出测试用例和测试规程,相关的活动包括 a 确定所需监测的指标,业务场景、被测业务的用户角色分布 b 确定采用的性能测试类型 依据历史运行情况或实际运行环境设计测试数据生成和读取规则 测试数据包括为待测系统 与软件准备的基础数据,以及运行所需要的数据 数据量应与测试环境的配置相适应或与未 来扩展数据量一致,在实际环境中数据量应与实际规模相一致;在模拟环境中宜等比对数据规
GB/39788一2021 模进行调整 确定负载生成方式,可采用工具或人工的方式加压 应根据制定的测试方案布置各测试场景 包括并发用户数、执行时长以及需要监视的性能指标等 针对所需测试的业务逻辑设计测试用例 e 依据需求或实际运行环境确定测试用例顺序 开发测试脚本 通过脚本对待测系统与软件的用户业务行为进行模拟,脚本的开发可采用录 g 制、编写或定制开发等方式 完成测试脚本开发后,应进行功能验证,确保测试脚本已完成用 户业务行为 h)确定暂停和恢复准则 暂停准则可包括 系统不可用 由于不确定原因导致服务器宕机或必要服务停止运行 应用程序在打开状态下具有阻塞程序/严重缺陷; 所需的依赖项不可用 恢复准则可包括 系统和/或服务器可用,启动并运行; 解决阻塞和/或关键问题; 应用程序功能已恢复 测试数据处理周期未完成时的恢复程度 5.4性能测试执行 性能测试执行过程包括下列活动 执行前就绪检查,对性能测试所需环境和资源进行评估 a b 由人工或利用测试工具执行测试脚本,并监控执行过程中的性能指标,记录测试结果 性能测试通常需考察待测系统与软件在一段时间范围内的综合表现,按需取平均值,最大值或 c 最小值作为测试结果 d 若性能测试异常终止或不满足需求或预期,填写性能问题报告单 问题报告单应包括问题来 源,场景配置、,问题描述、,问题等级等内容 判断所执行的测试用例是否通过 如果测试不通过,分析具体情况,确定是由软件本身性能瓶 颈所引起的,还是由测试环境所引起的 图1给出了性能测试执行框架,该执行框架由5个组件组成;输人、运行环境和待测系统与软件、输 出、控制单元和监督单元 其中,输人、,运行环境和待测系统与软件以及输出是一般软件测试的组成部 分,控制单元和监督单元是性能测试所特有的 输人提供了性能测试的条件,可能包括测试数据及其相 关的控制机制 控制单元则为输人提供了相关信息,例如运行环境或测试执行顺序等所需的更改 运 行环境包括待测系统与软件、运行支撑环境和性能测试支撑环境 控制单元用于决定和控制输人组件 的输人 监督单元监控输出组件的时间特性和资源利用性和容量,包括测试过程的即时信息 注1:控制单元可控制的信息包括并发请求、思考时间、集合点等 注2资源利用性如处理器占用率、内存占用率等 注3，时间特性如响应时间周转时间等 注4容量如最大并发数最大用户数等 注5输人如系统登录用户名密码,查询关键词,输出如返回的查询结果等
GB/T39788一2021 图例 控制信息 监督单元 控制单元 测试数据 时间特性 性能指标 资源利用性 容量 运行环境 输入 输出 特测系统 与软件 性能测试执行框架 5.5性能测试总结 性能测试总结包括下列活动 整理性能测试结果 性能测试的结果宜考虑多种环境因素下的综合结果,采用数学和统计方 a 法进行数据综合分析考虑,如标准差、用户约定的统计模型 注1分析数据时,宜酬除异常数据,例如系统启动或关闭时捕获的数据 注2:响应时间、吞吐率和资源利用率考虑包括平均值、最小值、最大值或标准偏差 注3并发请求数宜分析最大并发请求 编写软件性能测试报告,内容宜包括;测试结果分析、对软件性能的评价和建议 b 根据测试记录和性能问题报告单编写性能问题报告 性能测试事件报告宜包含问题来源、场 c 景配置、问题描述和问题等级等内容 性能测试需求模型 6 6.1概述 性能测试需求模型应考虑环境、数据、业务流程、用户分布、请求时序分布和网络状态等因素 6.2环境需求 针对不同质量要求,应考虑测试环境对性能测试的影响.推荐使用系统或软件的实际生产环境作为 性能测试环境 在进行性能测试环境规划和设计时,应考虑以下因素 稳定性;在相同条件下的多轮次测试结果应保持一致,或在可接受误差范围内; a b) 独立性:为避免测试结果失真,测试环境应与其他在用系统或软件保持相互隔离 可控制性;测试环境中的所有设备和资源应可被监控或控制 c 性能测试环境考虑因素包括 硬件配置;包括需使用的计算机、服务器、磁盘阵列或其他专用设备,考虑上述硬件资源的型 a 号、数量、部署逻辑、通信和连接状态等 D)软件配置:包括需使用的操作系统、中间件、数据库性能测试工具或其他专用软件,考虑前述
GB/39788一2021 软件资源的版本、补丁等; 网络配置;包括需使用的交换机路由器、集线器或其他专用网络设备,考虑前述网络资源的组 网方式、传输速率和延迟特性等 当现有条件无法支撑测试环境构建时,应最大化利用现有资源进行测试环境构建,并分析测试环境 和生产环境的差异性,如不同的软硬件或网络设备可能带来的性能增益或损耗 6.3数据需求 性能测试所需的数据包含如下需求 数据的类型和业务需求相匹配 a 数据量和业务需求相匹配 b 数据分布模型和业务需求相匹配 应通过收集历史数据,确定数据需求 c d)进行数据需求分析时,考虑数据的使用限制和重用性,制定数据读取策略和备份策略,当进行 性能扩展性测试时,应根据实际情况加大数据量 6.4业务流程 性能测试应首先考虑测试主要或重要的业务流程,不同的业务流程对系统产生的压力不同 在业 务流程选择时应基于风险评估考虑如下因素 资源的占用情况 a b) 业务使用频率; 业务的重要性 c 6.5用户分布模型 性能测试的用户角色分布应服从真实环境分布,可通过用户分布模型进行描述 示例图2描述了一个用户分布模型,该模型中有角色1,2,3三个角色,其中角色1(10%),角色2(30%),角色3 60%)分别对应测试模型中负载的20,60,120的用户数量 从图2中可以看出系统的负载大部分来自角色3,并且该角 色比其他角色的性能要求更高 20 0% 角色1 60 30% 角色2 60% 120 角色3 真实负载分布 测试模型 图2用户分布模型 对于不同的角色,其预期的用户数量和参与的业务是不同的 测试执行时应考虑功能种类、数量、每种功能执行的人数等 设计并发用户数时,若无特定约定,宜根据在线用户数进行估算 示例;一般非高频交易的Web系统,按在线用户数的10%20%估算并发请求数 6.6请求时序分布模型 性能测试请求发送时序应符合业务需求
GB/T39788一202 性能测试通过一系列场景的执行来完成,分析用户的请求模型是获取性能测试需求的有效手段,即 定义系统的典型使用方式,考虑用户使用系统的典型业务时间段和用户数量 图3给出了某个请求时 序分布的示意图,描述了一天中某系统中负载随时间变化的情况 系统负载 时间 图3请求时序分布示意图 示例1:某OA系统的每天早上8:00有200个用户在10min内登录系统 ;00~16;00 示例2;每天查询交易的高峰是在9 ~11:00和下午的14 ;00 不同的网络请求会产生不同的负载,图4和图5给出了两种典型的请求负载模式 图4描述了客 户端同时发送请求,但在不同的时间到达服务器;图5描述了客户端在不同的时间发送请求,但在同一 时间到达服务器 请求 tl R1 R2 R3 服务器 RR4 R5 R6 客户端 R8 图 请求同时发出 4 请求 2 R1 R2 R3 服务器 R4 R5 客户端 R6 R R8 图5请求同时到达
GB/39788一2021 6.7网络状态需求 网络状态的需求应从以下方面进行考虑 保证网络传输速度 如果网络传输有较大延迟,可能影响性能测试结果 a b)网络背景流量应尽可能少 如果背景流量没有限制在合理的范围内,可能导致应用程序和/或 网络故障 性能测试类型 7.1负载测试 7.1.1建立模型 负载测试模型由负载量,负载业务和运行时间来描述 在指定业务负载和运行时间的条件下,测量 被测业务的负载量 负载测试模型的构建过程包括: 确定所需测试负载的业务; a 确定被测各业务的用户角色分布; b 确定被测各业务的负载量需求; c 确定负载生成方法 d 导出测试覆盖项 7.1.2 对于负载测试,每项被测业务的负载量需求为一个测试覆盖项 7.1.3导出测试用例 负载测试用例按以下步骤导出: 确定前提条件: 根据业务场景实际情况,确定待测业务的前置业务条件 2)确定需要同时运行的测试用例组合 b 设计输人数据: 1 确定各操作所需的输人数据; 22 确定输人数据的来源,例如历史数据或相似系统的数据 选择用户操作 1依据用户使用场景确定用户操作; 确定正常/峰值时间用户数; 22 33 确定用户活动趋势 ！ 确定思考时间 d)确定预期结果: 1确定各项业务的预期输出 2) 适用时,确定系统的监视指标(如响应时间,并发用户数,资源利用率等); 确定负载测试的通过/不通过准则,例如响应时间或资源占用率大于某阔值时则视为不通 33 过该次负载测试 表1给出了某场景下负载测试的测试覆盖项和测试用例的示例
GB/T39788一2021 1 表 负载测试的测试覆盖项和测试用例示例 测试用例测试覆盖项 负载场景 活动 输人 预期输出 监视指标 TC1 TCOVER1 登录 用户名密码 无 已注册用户登录检索; 响应时间<5s T2 TcoVER2并发数;50.; 检索 搜索条件 搜索结果列表CPU占用率<40% 思考时间:5s8s 内存占用率<60% TC3 TC(OVER3 结果选择条目编号 结果详情 7.2压力测试 7.2.1建立模型 压力测试用于评估软件在极重负载下是否健壮,可用 指通过增加系统负载,测量系统与软件在极 限负载下的状态 注:状态通常包括响应时间、并发用户数、吞吐量和资源利用率等 压力测试模型的构建过程包括 确定压力测试的指标需求 aa b) 确定压力测试的关键业务场景; 确定被测业务的用户角色分布; c 确定压力测试用例的生成方法 d 7.2.2导出测试覆盖项 对于压力测试,每项被测业务的压力测试需求为一个测试覆盖项 7.2.3导出测试用例 压力测试用例按以下步骤导出 确定前提条件 a 1) 根据实际业务场景,确定关键业务预期的最大负载; 确定需要同时运行的测试用例组合 22) 设计输人数据 b 确定各操作所需的输人数据; 1 确定输人数据的来源,例如历史数据或相似系统的数据; 2 33 输人数据设计时通常要考虑如下内容 提供要求处理的信息量,超过预期的最大负载 -数据传输能力的饱和试验,要求比设计能力传输更多的数据:内存的写人和读出,外 部设备,其他分系统及内部界面的数据传输等 存储范围(如缓冲区,表格区和数据库)超过额定大小的能力 选择用户操作 依据用户使用场景确定用户操作; 1 22) 确定正常/峰值时间用户数,通常采用负载递增加载和峰谷加载(高低突变加载); 33 确定用户活动趋势; 4)确定思考时间 d 确定预期结果 1 确定各项业务的预期输出;
GB/39788一2021 适用时,确定系统的监视指标(如响应时间,并发用户数,资源利用率等); 33 确定系统与软件在极限状态下(超出预期峰值或者可用资源少于最低要求时)的性能 表2给出了某业务场景下压力测试的示例 负载是采用递增加载方式,当负载(用户数)达到100 时,系统响应时间增加过快,但在运行范围内;当负载(用户数)达到150时系统存在异常 由表中数据 可知,该系统的性能瓶颈是由数据库查询时间导致 表2压力测试用例示例 响应时间CPU占用率 等待数据库连接的 数据库查询时间数据库执行时间 负载(用户数) 状态 % 线程数量 ms ms ms 3000 10 28 40 580 430 正常 50 4710 35 60 150 970 正常 l00 8920 40 130 4890 480 正常 150 0670 失效 50 l60 6120 5890 7.3峰值测试 7.3.1建立模型 峰值测试模型由峰值负载业务、峰值负载量强度、峰值持续时间和监视指标来描述 对于指定的负 载业务,当负载业务瞬间峰值(超过系统所能正常承载的强度)来临时,系统将降级运行;当负载业务负 载逐渐降低至正常水平,检查系统是否能恢复正常运行 峰值测试模型的构建过程包括 确定所需测试负载的业务; a 确定被测各业务的用户角色分布 b 确定对应的监视指标; c 确定被测各业务的峰值负载量强度、峰值持续时间、负载恢复至正常的下降步长/时间 d 确定被测各业务负载生成方法 e 峰值测试模型中的负载量强度设计可与压力测试结合确定,由压力测试中所测量得出的软件崩溃 的极限负载量,如系统的响应时间、并发用户数、吞吐量、资源利用率等,作为当前峰值测试的峰值负载 量强度 7.3.2导出测试覆盖项 对于峰值测试,每项被测业务的峰值负载强度计划测试值为一个测试覆盖项 7.3.3导出测试用例 峰值测试用例按以下步骤导出 确定前提条件 a 根据业务场景实际情况,确定待测业务的前置业务条件 22) 确定需要同时运行的测试用例组合 b)设计输人数据: 确定各操作所需的输人数据 22 确定输人数据的来源,例如历史数据或相似系统的数据 选择用户操作:
GB/T39788一202 1) 依据用户使用场景确定用户操作; 22 确定用户活动趋势,包括用户数起始量,峰值量,峰值持续时间和负载下降步长 3)确定思考时间 d 确定预期结果 适用时,确定系统的监视指标(如响应时间、并发用户数、资源利用率等); 1) 22 确定各项业务正常运行的预期输出 33 确定当前计划测试的峰值上各项业务的降级运行预期输出 ！ 确定当前计划测试的峰值过后各项业务的恢复运行预期输出 表3给出了某场景下峰值测试的测试覆盖项和测试用例的示例 表3峰值测试的测试覆盖项和测试用例示例 测试用例渊试覆盖项 负载场景 活动业务比例 输人 预期输出 监视指标 无 TcOVERI 20% 登录 用户名密码 思考时间:5s一8s; 闲时并发数 40 搜索结果 检索 0% 搜索条件 TCOVR2 峰值并发数:3000; 列表 峰值持续时间:3min; 闲时指标; TC 3min后负载开始下降 响应时间<5s 负载下降步长，每分钟结果 TC(OVER3 30% 条目编号 结果详情CPU占用率<40%; 并发数降低100,直至选择 内存占用率<60%; 低于闲时并发数为止 峰值时段仅记录指标 数据,不做判断 无 TC(OVER4 20% 登录 用户名密码 思考时间:5s8s 负载下降到低于闲时 闲时并发数;40 搜索结果 50% 检索 搜索条件 并发数后,重新判断 TCOVER5 峰值并发数:4000; 列表 指标是否依旧符合 峰值持续时间;5min; TC2 要求 5nmin后负载开始下降 负载下降步长，每分钟结果 TC(OVER6 30% 条目编号 结果详情 并发数降低80,直至低选择 于闲时并发数为止 7.4可扩展性测试 7.4.1建立模型 可扩展性测试用于评估软件在外部性能需求或环境变化情况下的性能处理能力,通过在基准测试 的性能需求、性能测试环境基础上进行扩展(如用户负载支持、事务数量、数据量等性能需求,处理器、内 存、磁盘等硬件资源环境扩展)后的系统性能表现情况 基准测试可以包括前述章节中的负载测试、疲 劳强度测试等方式,或者采用单独的基准测试场景进行 可扩展性测试模型的构建过程包括: 确定所需可扩展性测试的业务; aa b 确定被测各业务的用户角色分布; c 确定被测各业务的扩展量需求; d 确定可扩展性测试用例生成方法 10
GB/39788一2021 7.4.2导出测试覆盖项 对于可扩展性测试,每项被测试业务的可扩展性测试需求为一个测试覆盖项 7.4.3导出测试用例 可扩展性测试用例按以下步骤导出 确定前提条件 a I)根据业务场景实际情况,确定可扩展性测试业务的前置业务条件 22 根据可扩展性测试需求,确定基准测试、可扩展性测试环境条件,如被测试系统服务器数 量的扩展,服务器内存的扩展等; 确定需要进行性能扩展比较的测试用例组合 3 b)设计输人数据: 确定可扩展性测试各操作所需的输人数据,宜保证基准测试与可扩展性测试的输人数据 -致; 确定可扩展性测试输人数据的来源,例如历史数据或相似系统的数据,宜与基准测试所使 用的数据来源相同,并在基准测试数据基础上进行扩展; 可扩展性测试输人数据设计时需要考虑以下内容 与基准测试相比较的业务数据扩展内容,如用户数据量、订单数据量等; 与基准测试相比较的业务数据扩展方式,如通过数据库语句进行数据批量生成等; -与基准测试相比较的业务数据扩展比例,如基准测试业务数据的整数倍 选择用户操作: 依据基准测试用户使用场景确定可扩展性测试用户操作 2)确定业务、,环境资源等扩展后的用户数:; 确定用户活动趋势 3 确定思考时间 ！ d 确定性能指标及监控方式 依据基准测试场景中的性能指标,确定可扩展性测试对应性能指标,如响应时间、内存占 用率等; 确定测试需求、测试环境扩展后的性能指标的监控方式,如响应时间、硬件资源等性能指 标的监控方式 确定具体扩展场景及执行顺序 依据基准测试场景中的性能场景,确定可扩展性测试对应场景 注;单一场景主要是指针对某一项资源单独扩展情况下如计算资源、存储资源、网络资源、数据资源 等)测试场景的设计;混合场景主要是指针对某几项资源共同扩展情况下测试场景的设计 依据可扩展性测试需求或扩展环境,确定每个测试场景对应的测试用例执行顺序或逻辑 关系,以及测试场景启动或停止的条件 确定预期结果: fD 1确定各项业务的预期输出 适用时,确定系统的监视指标(如响应时间,并发用户数,资源利用率等); 33 确定可扩展性测试的通过/不通过谁则,例如在业务.环境资鄙等扩展后的响应时间或欢 源占用率大于某闵值时则视为不通过该次可扩展性测试 表4给出了某场景下可扩展性测试的测试覆盖项和测试用例的示例. 11
GB/T39788一2021 表4可扩展性测试的测试覆盖项和测试用例示例 测试用例测试覆盖项 扩展场景 活动业务比例 输人 预期输出 监视指标 0 TcCOVER1 登录 用户名密码 无 已注册用户数据量扩 搜索结果 展:由10万用户量扩展 响应时间<5s; TCOVER2 检索 60% 搜索条件 列表 Tc1 到100万用户量; CPU占用率<40% 并发数:5000; 内存占用率<60% 结果 TCOVER3 30 条目编号 结果详情 思考时间5s一8s 选择 无 TCOVER1 登录 10% 用户名密码 硬件资源扩展:由5台 搜索结果响应时间<3s 相同配置服务器扩展到 TC(OVER2 检索 60% 搜索条件 Tc2 列表 CPU占用率<40% 10台相同配置服务器; 并发数:10000; 内存占用率<60% 结果 TCOVER3思考时间5s 30% 条目编号 结果详情 s8s 选择 7.5疲劳强度测试 7.5.1建立模型 疲劳强度测试模型由用户规模负载分布和执行时间来描述 疲劳强度测试通常和被测软件的可 靠性能力相关,在指定用户规模、负载分布和执行时间情况下,验证被测软件的持续稳定运行能力或软 件失效后的恢复能力的饱和性试验 疲劳强度测试模型的构建过程包括: a 确定满足性能指标(时间特性、资源特性等)要求的用户规模; b 构建被测软件的混合业务模型; c 确定测试执行时间; d 确定场景中其他要素(思考时间、集合策略等) 7.5.2导出测试覆盖项 对于疲劳强度测试,被测软件混合业务模型的健壮性需求为一个测试覆盖项 7.5.3导出测试用例 疲劳强度测试用例按以下步骤导出 明确用户规模 a 选择满足软件性能指标要求的最大用户数作为疲劳强度测试的用户规模数 1！ 明确各业务相关用户的群体分布、行为趋势和交互模式 22 构建业务模型: b 选择性能关键程度高的业务模块组成多组混合业务模型 1 根据业务场景实际情况,确定各组混合业务模型的业务处理比例; 2 确定各组混合业务模型中业务的执行顺序和前置条件 33 确定执行时间: 宜根据软件生产环境运行情况或根据对软件的扩展性评估进行估算 注，通常选择24h,3×24h或7×24h执行 12
GB/39788一2021 d)设计数据模型: 1) 明确数据使用要求,如数据文件大小限制或重用性限制等 确定各业务所需的数据类型和数据量; 2 3 构建数据模型,涵盖输人参数数据和背景业务数据等 制定数据备份和恢复策略等 4 明确测试时机 1软件已完成功能和性能测试,进人试运行阶段时; 软件运行一定时间后,出现性能能力降级时 22 为提高软件性能水平,进行硬件升级或系统扩展时 33 f 确定预期结果 l)确定各项业务的预期输出 22 适用时,确定系统的监视指标(如响应时间、并发用户数、资源利用率等) 33 确定疲劳强度测试的通过/不通过准则,例如响应时间或资源占用率超过预期或被测试软 件无法继续提供正常服务等则视为不通过该次疲劳强度测试 表5给出了某场景下疲劳强度测试的测试覆盖项和测试用例的示例 表5疲劳强度测试的测试覆盖项和测试用例示例 测试用例测试覆盖项 疲劳强度场最 活动业务比例 输人 预期输出 监视指标 身份证号和开户成功并 TcCOVER1 开户 10% 登录密码 进人首页 响应时间 已构建背景数据 开户<3s; 套餐 显示套餐 60% TcOVER2 搜索条件 并发数:100; 套餐查询<5s 查询 信息 TC1 思考时间;3s一5s 缴费<3s; 缴费成功并CPU占用率<60%; 测试时长;24h TcOVER3 内存占用率<50% 缴费 30% 条目编号 显 示电 发票 业务 显示更新后 30% 业务编号 TCOVER4 响应时间: 变更 的业务状态 业务变更<5s; 已构建背景数据 详单 显示详单详单查询<8s 并发数:l00; TC2 TcOVER5 40% 搜索条件 思考时间:3s~5s; 查询 信息 积分兑换<5s 测试时长;24 PU占用率 80% 积分 显 示兑换 TCO)VER6 30% 商品编号 内存占用率<70% 结果 兑换 7.6容积测试 7.6.1建立模型 容积测试模型由吞吐量和存储容量来描述 在指定数据量(通常达到最大指定容积或接近最大值 的条件下,测量待测系统与软件的容积 容积测试的目的是评估测试项在处理指定数量的数据时的性 能,为系统扩容、性能优化提供参考 容积测试模型宜按照以下步骤构建 确定所需测试指定的数据量; 13
GB/T39788一202 b 确定待测系统与软件的用户操作; c 确定待测系统与软件的容积需求 d)确定容积检验方法 7.6.2导出测试覆盖项 对于容积测试,待测系统与软件的吞吐量指标,存储容量指标为一个测试覆盖项 根据业务需求和 系统架构不同,在选取容积指标时一般遵循如下原则 并发请求量较大时,重点关注响应时间和每秒事务处理数等指标 b)需要存储读写的数据量较大时,重点关注吞吐量和磁盘I/0等指标 7.6.3导出测试用例 容积测试用例按以下步骤导出 确定前提条件 a 根据业务场景实际情况,确定待测业务的前置业务条件 设计输人数据 b 确定输人数据的来源,例如历史数据或相似系统的数据 对系统进行监控 C 加载大容量的数据 1) 依据用户使用场景确定用户操作; 2 确定正常/峰值时间用户数 3 对CPU/内存/磁盘/响应时间/事务成功率等指标进行监控 确定预期结果: d 确定各项业务的预期输出 1 适用时,确定系统的监视指标(如响应时间,并发用户数、资源利用率等); 2 确定容积测试的通过/不通过准则,例如只要限定的某项资源达到最大使用状态或某项指 3 标超出可接受值,则视为不通过该次容积测试 表6给出了某场景下容积测试的测试覆盖项和测试用例的示例 表6容积测试的测试覆盖项和测试用例示例 测试用例测试覆盖项 容积测试场景 输人 预期输出 监视指标 活动 TCOVERI 登录用户名密码 无 并发数:5000; TCOVER2 检索搜索条件 搜索结果列表响应时间<5 s; TC1 思考时间:5s8s 最小每秒事务数>120次/s 结果 CPU占用率>80% TCOVER3 条目编号 结果详情 选择 无 TC(OVER1 登录用户名密码 并发数:5000; TC(OVER2 检索搜索条件 搜索结果列表 响应时间3s TC2 思考时间;5一8s 最小每秒事务数>100次/s 结果 内存占用率>80% TcoVER3 条目编号 结果详情 选择 14
GB/39788一2021 录 附 A 资料性附录 性能效率的质量测度 表A.1给出了GB/25000.23-2019中定义的性能效率的质量测度 表A.1GB/25000.23一2019中定义的性能效率质量测度 子特性 测度名称 平均响应时间 响应时间的充分性 时间特性 平均周转时间 周转时间充分性 平均吞吐量 处理器平均占用率 内存平均占用率 资源利用性 I/0设备平均占用率 带宽占用率 事务处理容量 容量 用户访问量 用户访问增长的充分性 性能效率的依从性 性能效率的依从性 15
GB/T39788一2021 附 录 B 资料性附录) 移动应用性能测试案例 B.1系统描述 待测系统与软件为移动应用软件,主要功能为在线发送消息,分为两部分;一为移动应用终端,运行 环境为Android平台,Android版本需大于5.0;二为服务器端应用,负责消息的存取功能 该系统包含如下两种角色: 普通用户 a b) 系统管理员 主要功能如下 系统登录;所有用户均可进行此操作 a b 发布消息:普通用户可以创建消息并保存或者发布消息; 审核消息:系统管理员可以审核用户发布的消息,可以通过审核或者取消发布 c B.2 性能需求 客户端性能需求如下: 空闲状态下,软件运行时内存消耗最大不超过200MB,且在软件退出时应当自行清理内存 a b 安装目标应用软件前后待机功耗无明显差异; 应用后台连续运行2h的流量值不超过20MB,如大于20MB应给出提示 服务器端性能需求如下: 审核功能应能具备10个并发用户操作; a b 发布消息功能应能具备100个并发用户操作; 满足上述容量的前提下响应时间不超过2s B.3测试用例 客户端测试用例设计如表B.1所示 表B.1 客户端测试用例 消息发送客户端性能测试 版本号 名称 0.1 测试目的 测试移动应用性能 设计人员 测试时间 前置条件 待测应用已完成功能测试 测试环境 Android7.0系统 测试场景 单用户 16
GB/39788一2021 表B.1续 步骤编号 操作 测试数据 性能监控 CPU占用率; 内存占用率 应用安装 安装前待机电量消耗 安装后待机电量消耗 CPU占用率; 内存占用率 应用启动 首次启动时间; 非首次启动系统时间: 切换至后台后启动时间 响应时间 客户端操作: 用户名/密码: CPU占用率; 登录相应账户; Userl/J8Qn0H5 内存占用率 保存消息并发布消息 随机生成500字节内容 运行2h电量总消耗" 运行2h数据流量消耗 CPU占用率; 应用关闭 内存占用率; 待机电量消耗 服务器端测试用例设计如表B.2所示 表B.2服务器端测试用例 名称 消息发送审核性能测试 版本号 0.l 测试目的 测试消息发送审核业务的性能 设计人员 测试时间 前置条件 待测系统与软件已完成功能测试 测试环境 保存消息;并发用户数;100;静态加压;思考时间;1s~10s随机;持续时间:5min 测试场景 发布消息;并发用户数:100;静态加压;思考时间;0s;持续时间;5tmin 审核消息;并发用户数:l0;静态加压;思考时间:0s;持续时间;5min 测试用例 用例描述 100个用户并发保存消息 步骤编号 操作 测试数握 服务器监控 响应时间 设置用户名密码 username/password;Userl/J8QnoH5 通过事务数 URL;http;//192.16.20,204;9001/login 发送登录请求 失败事务数 应用服务器 编辑主题 随机生成50字节内容 CPU占用率 编辑消息内容 随机生成500字节内容 内存占用率 数据服务器 1/192.16.20.204:9001/savedraft URL 发出保存消息请求 ;http;/ CPU占用率 发出登出请求 内存占用率 17
GB/T39788一2021 表B.2(续 用例名称 100个用户并发提交消息 前置条件 100个用户成功保存消息,且并发过程中服务器资源消耗未见异常 步骤编号 操作 测试数据 服务器监控 word:User1/J8Qn0HI5 响应时间 设置用户名密码 username/pass 通过事务数 发送登录请求 URL:http://192.16.20.204:9001/login 失败事务数 应用服务器 读取已保存消息 CPU占用率 编辑消息内容 随机生成500字节内容 内存占用率 数据服务器 发出提交消息请求 URLhttp://192.16.20.204;9001/postmassage CPU占用率 发出登出请求 内存占用率 100个用户并发审核消息 用例名称 前置条件100个用户成功并发提交消息,且并发过程中服务器资源消耗未见异常 步骤编号 操作 测试数据 服务器监控 响应时间 设置用户名密码 username/passwordadmim/marFU5PaL 通过事务数 发送登录请求 URL:;http://192.16.20.204;9001/login 失败事务数 应用服务器 查看消息 CPU占用率 依据消息编号设置消息参数 内存占用率 数据服务器 发出通过/不通过审核请求 CPU占用率 发出登出请求 内存占用率 B.4测试结果 B.4.1 概述 本测试结果案例仅考虑服务器测试中,100个并发用户提交消息场景下的结果记录 B.4.2测试场景 100个并发用户提交消息,采用静态加压方式,思考时间设置为0s,测试持续5min B.4.3响应时间 图B.1记录了服务器响应时间的变化趋势,表B.3给出了各项统计结果 实际测试过程中,服务器 响应时间在满足相应负载的条件下未超过2s的需求限制 18
GB/39788一2021 1.8 .6 .4 1.2 0.8 0.6 0,4 0.2 时间 图B.1服务器响应时间 表B.3服务器响应时间统计结果 平均值 第90百分位 最小值 最大值 标准偏差 0.120 0.065 0.206 0.300 0.280 B.4.4应用服务器资源消耗 应用服务器CPU占用率变化趋势如图B.2所示,表B.4给出了部分统计量 50 45 40 3 30 25 20 15 10 时间 图B.2应用服务器CPU占用率 表B,4应用服务器CPU占用率统计 最小值 平均值 最大值 9% 11% 13% 19
GB/T39788一202 应用服务器内存消耗变化趋势如图B.3所示,表B.5给出了部分统计量 16 14 12 10 时间 图B.3应用服务器内存消耗 表B.5应用服务器内存消耗统计 平均值 最大值 最小值 GB GB GB 0.5 0.7 B4.5数据服务器资源消耗 数据服务器CPU占用率变化趋势如图B.4所示,表B.6给出了部分统计量 100 90 8o 60 50 40 30 20 10 时间 图B4数据服务器CPU占用率 20
GB/39788一2021 表B.6数据服务器CPU占用率统计 平均值 最小值 最大值 15% 8% 12% 数据服务器内存消耗变化趋势如图B.5所示,表B.7给出了部分统计量 16 14 12 10 时间 图B.5数据服务器内存消耗 表B.7数据服务器内存消耗统计 最小值 平均值 最大值 GB GB GB 0,4 0,8 1.6 21
GB/T39788一2021 附 录 C 资料性附录) 大型信息系统性能测试应用案例 C.1 系统描述 待测系统与软件为大型信息系统中的关联查询模块,主要功能为根据关键词检索信息,分为两部 分;一为网页客户端,运行在windows7平台;二为服务器端,运行在windowsServer r2008平台,负责 通过主题向数据库搜索并获取结果,返回给客户端 该软件模块主要功能如下 根据关键词检索相关信息 a b) 点击查询结果进人并加载详情页面 c.2性能需求 客户端性能需求如下 前台页面检索可以正常显示搜索结果; a 打开一个目标的详情页,页面展示正常 b) 服务器端性能需求如下 搜索功能,能够支持150个用户并发操作,检索响应时间不超过5s; a 访问页面信息功能,能够支持150个用户并发操作,页面打开响应时间不超过5s b C.3 测试用例 客户端测试用例设计如表c.1所示 表C.1客户端测试用例 版本号 名称 关联查询客户端搜索关键词性能测试 测试目的 测试检索功能客户端响应时间 设计人员 测试时间 前置条件待测应用已完成功能测试 测试环境 windows764位 测试场景 单用户 测试数据 步骤编号 性能监控 操作 打开关联查询web网页 模拟150个用户在关联查询页面同时 关键词“××指挥所"“××机场” 页面搜索响应时间 进行搜索操作随机输人关键词 打开××系统客户端,打开关联查询界 页面是否加载流畅 面,手动进行搜索操作 在搜索出的结果中随机点击一条查不 详情页能正常展示 详情 22
GB/39788一2021 服务器端测试用例设计如表C.2所示 表c.2服务器端测试用例 名称 关联查询检索及查看详情性能测试 版本号 1.0 测试关联查询检索及查看详情的性能 测试目的 测试时间 设计人员 前置条件 待测系统与软件已完成功能测试 测试环境 WindowsServer2008R2Enterprise64位 搜索关键词;初始50个线程,每15=增加50个用户,共计150个用户;思考时间:0s;持续时间5minm 测试场最 查看详情页面:初始50个线程,每15s增加50个用户,共计150个用户;思考时间:0s;持续时间5minm 测试用例 150用户并发搜索关键词操作 用例描述 步骤编号 操作 测试数据 服务器监控 打开关联查询主页 用户角色:LHQB 响应时间 通过事务数 150个用户并发进行搜索随机关键词关键词;“××指挥所”“××机 失败事务数 操作 场”“莫×森”等随机取 应用服务器 打开QB系统客户端,打开关联查询页 CPU占用率 面,输人关键词进行搜索操作,查看页 内存消耗 面是否加载流畅,正常显示搜索结果 堆内存消耗 用例描述 50个用户并发查看详情操作 前置条件 150 个用户成功搜索关键词,且并发过程中服务器资源消耗未见异常 步骤编号 操作 测试数握 服务器监控 打开关联查询搜索结果页 用户角色:lHQB 响应时间 通过事务数 150个用户并发进行查看目标详情页面 关键词“××人员"等随机取 失败事务数 操作 应用服务器 打开QB系统客户端,打开搜索结果页 CPU占用率 面点击某条进人详情页面,查看页面 内存消耗 是否加载流畅,正常显示详情信息 堆内存消耗 C.4测试结果 C.4.1概述 本测试结果案例仅考虑服务器测试中,150个并发用户搜索关键词、查看详情的结果记录 C.4.2测试场景 初始50个线程,每15s增加50用户,共计150个用户;思考时间:0s;持续时间:5min 23
GB/T39788一2021 C.4.3响应时间 表C.3给出了150个用户并发进行检索操作服务器响应时间的各项统计结果,可见平均响应时间 为2.293s,低于规定的时间5s,故满足性能需求 表c.3150用户并发进行搜索操作服务器响应时间统计结果 最小值 平均值 最大值 0.011 2.293 18.491 表C.4给出了150个并发用户查看人员详情页面服务器响应时间的各项统计结果,平均响应时间 为9.228s,超过了5s,故不满足给定的性能需求 表C.4150个并发用户查看人员详情服务器响应时间统计结果 最小值 平均值 最大值 1.071 9.228 16.282 在150个并发用户压力测试同时,在客户端查看详情页面,浏览器记录的请求响应时间在1s以 内 由于查看详情页操作请求数较多,响应时间记录最后一个请求返回的时间,所以结果超出了5s,但 是由于网页访问使用异步加载策略,虽然有个别请求返回较慢,但网页先展示了大部分请求返回的数 .不会有卡顿或者长时间等待展示数据的情况 据,所以对用户来说加载较快， C,4.4应用服务器资源消耗 在压力测试期间,应用服务器内存使用量最高为120M.内存消耗正常;而应用服务器的CPU占用 率变化幅度较大,在压力峰值时CPU占用率达到95%以上 24
GB/39788一2021 附 录 D 资料性附录 云应用性能测试案例 D.1系统特点 待测系统与软件为基于云的购票应用,提供在线购票和在线支付等功能,主要功能如下 系统登录;所有用户均可进行此操作; a 5 在线购票;所有用户均可以在线购票并提交订单; 在线支付;所有用户均可以对已提交的订单进行支付操作 c 待测系统与软件的用户群体主要为全国各地的购票人员,在购票时可能存在并发压力,因此待测系 统与软件设计时重点考虑两点;一是个人信息保护,二是需要强大的计算资源支持子系统业务,待测系 统与软件的特点如下 系统分布式部署于云平台上,系统架构分为四部分,即接人层、web层、应用层和数据层 aa b 采用虚拟化机制实现,包含2组运行数据库,每组均包括售票节点、支付节点; 待测系统与软件只将部分流程的环节交由云服务供应商提供服务,系统全流程未采用按需扩 c 容的托管模式; d 为了保证用户的数据安全,采用混合云架构,即融合公有云和私有云,系统将敏感数据存放于 私有云的数据中心,同时获得公有云的计算资源,将业务子系统部署于公有云 D.2性能需求 待测系统与软件的用户群体分布于全国各地，测试时需模拟不同地域、不同网络环境和服务器环境 发起请求,更真实的模拟系统上线后的使用需求,同时监控云服务集群中应用服务器集群、数据库服务 器集群等网络资源、服务器资源的资源利用性 性能测试需求如下 在线购票应满足1000个并发用户操作; b在线支付应满足1000个并发用户操作; 满足上述容量的前提下平均响应时间不超过3s D.3测试环境及准备 根据性能需求,测试环境准备的要求如下 模拟全国各地用户访问待测系统与软件不同节点的实际需求; a b配置不同的网络环境和服务器环境; 配置云测试环境,根据给定数据量,测试关键业务的响应时间 c 本次测试所使用的云性能测试工具,提供脚本录制、场景设置、,压力测试、资源监控和报表统计等功 能,为真实的模拟实际应用环境,测试工具分别部署在华北、华东,华南、香港等多个区域的云服务平台 上,通过分布在全国各地的云性能测试工具,可模拟全国各地用户访问待测系统与软件不同节点的实际 需求,云性能测试基础技术架构见图D.1 25
GB/T39788一2021 互联网 控制消息服务器 性能测试控制中心 路 分布式乐测集群c 分布式压# 集群A 分布式压测集群N 分布式压测集群B 云应用服务器 云数据库服务器 云环境 图D.1基础技术架构图 性能测试控制中心:测试时的性能测试接口,提供环境管理、性能测试、性能监控、性能分析、性能报 告等功能的云测试平台,可将性能测试任务传递至控制消息服务器 控制消息服务器;接收测试控制中心任务消息传递给分布式压测集群运行,接收分布式引擎传递回 来的数据,并传递给测试控制中心 分布式压测集群由2台控制器和16台代理组成,控制器接收到任务后,将任务传递给代理进行加 压,目前分布式压测集群部署于多个区域 D.4测试用例 测试范围主要是在线购票和在线支付两个功能点,根据其操作流程设计测试用例,具体见表D.1 表D.1测试用例 版本号 名称 在线购票支付性能测试 测试目的 测试在线购票支付业务的性能 设计人员 测试时间 前置条件 待测系统与软件已完成功能测试 测试环境 云平台环境 在线购票;并发用户数l000;静态加压;思考时间;忽略;持续时间;5minm 测试场景 在线支付;并发用户数;l000;静态加压;思考时间.忽略;持续时间5minm 26
GB/39788一2021 表D.1续 测试用例 用例措述 个用户并发“在线购票” 1000 步骤编号 操作 测试数据 服务器监控 输人用户名密码 username/password:User02/test1234 响应时间 通过事务数 发送登录请求 URL:http://102.11.34.34:7001/login 失败事务数 应用服务器集群 选择场次 选择任意票务信息 CPU占用率 设置数量 设置购票数量 内存占用率 数据服务器集群 102.11.34.34:7001/addtie 发出在线购票请求 URL,htp:/ CPU占用率 发出登出请求 内存占用率 1000个用户并发“在线支付” 用例名称 个用户成功提交购票订单,且并发过程中服务器资源消耗未见异常 1000 前置条件 步骤编号 操作 测试数据 服务器监控 输人用户名密码 username/password:User02/test1234 响应时间 通过事务数 发送登录请求 URL:http:/102.ll.34.34:7001/login 失败事务数 应用服务器集群 查看待支付订单 CPU占用率 选择任意支付订单 随机选择支付订单 内存占用率 数据服务器集群 发出在线支付请求 URLhttp;/102.l1.34.34;70o1/pay CPU占用率 发出登出请求 内存占用率 D.5测试结果 D.5.1概述 本次测试通过被测软件主要功能的测试结果,反映云应用系统的整体性能,包括云应用信息系统各 节点性能情况、1000个并发用户在线购票并支付场景下的结果记录 D.5.2测试场景 000个并发用户在线购票并支付,完成全流程业务操作,采用静态加压方式,思考时间忽略,测试 l 持续5min D.5.3响应时间 图D,2记录了云应用信息系统响应时间的变化趋势,表D.2给出了各项统计结果 实际测试过程 中,被测软件响应时间在满足相应负载的条件下未超过3s的需求限制 27

深入解读系统与软件工程性能测试方法GB/T39788-2021

系统与软件工程性能测试是指在特定条件下对系统或软件进行评估和验证，以确定其在满足给定需求的同时，所能提供的性能水平。性能测试的结果可以帮助企业和组织决策者做出更好的决策，确保系统和软件在不同情况下都能够稳定、可靠地运行。

GB/T39788-2021《系统与软件工程性能测试方法》是我国性能测试领域的标准规范，该标准针对传统性能测试中存在的问题，提出了一套完整的性能测试流程，包括性能测试计划、性能测试环境、性能测试用例设计、性能测试实施、性能测试分析和性能测试报告等环节。

在GB/T39788-2021标准中，性能测试被定义为“在给定的测试环境中，模拟用户负载条件下，对系统或软件的性能及其相关指标进行评价和验证的过程”。其中，性能测试的主要指标包括响应时间、吞吐量、并发用户数等。

在性能测试实施过程中，需要根据系统或软件的特点，选择合适的性能测试方法，并将测试结果与预期目标进行对比分析。同时，在性能测试过程中还需要注意控制测试环境、设计合理的测试用例以及收集和分析测试数据等。

总之，GB/T39788-2021标准为系统与软件工程性能测试提供了规范和标准，帮助企业和组织更好地评估和验证系统和软件的性能水平，从而确保其在各种情况下都能够稳定、可靠地运行。

系统与软件工程性能测试方法的相关资料

和系统与软件工程性能测试方法类似的标准

GB/T32423-2015

系统与软件工程验证与确认

2022/10/17 14:32:57 现行

GB/T38639-2020

系统与软件工程软件组合测试方法

2022/7/24 5:16:39 现行

GB/T39788-2021

系统与软件工程性能测试方法

2022/7/17 1:59:23 现行