GB/T 39788-2021 系统与软件工程 性能测试方法

　　ICS 35 . 080 L 77

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 39788—2021

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

　　System andsoftwareengineering—performancetestingmethod

　　2021-03-09 发布 2021-10-01 实施

　　国家市场监督管理总局国家标准化管理委员会

　　发

　　布

　　GB/T 39788—202 1

　　GB/T 39788—202 1

　　前 言

　　本标准按照 GB/T 1 . 1—2009 给出的规则起草。

　　请注意本文件的某些内容可能涉及专利。 本文件的发布机构不承担识别这些专利的责任。

　　本标准由全国信息技术标准化技术委员会(SAC/TC 28)提出并归口 。

　　本标准起草单位：上海计算机软件技术开发中心、深圳赛西信息技术有限公司、国家应用软件产品质量监督检验中心、中国电子技术标准化研究院、中国电子科技集团公司第十研究所、厦门理工学院、中国电子科技集团公司第五十四研究所、内蒙古自治区电子信息产品质量检验院、山东道普测评技术有限公司、北京轩宇信息技术有限公司、中国航天系统科学与工程研究院、中电莱斯信息系统有限公司、广东省科技基础条件平台中心、北京京航计算通讯研究所、浙江省电子信息产品检验所、西宁市大数据服务管理局、上海第二工业大学、武汉大学。

　　本标准主要起草人：龚家瑜、李文鹏、蔡立志、张旸旸、简炜、卢俊文、孙凤丽、康京山、郭澍、王凤玲、张峻、李军、高猛、王建强、郝璟璐、陆澄澹、胡芸、杨隽、赵毅、易晶晶、孙肖、于泉、王威、沈颖、杨玲萍、滕俊元、许颖媚、白万芳、谢晓园、吴克寿、巩韶飞、贾素田、李丽萍、孟宪伟。

　　GB/T 39788—202 1

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

　　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

　　负载测试 loadtesting

　　用于评估系统与软件在预期变化负载下的性能表现，负载通常位于低谷、典型和高峰使用的预期条件之间。

　　注：性能效率测试的一种。

　　3.2

　　压力测试 stresstesting

　　用于评估系统与软件在高于预期或指定容量负载需求，或低于最少需求资源的条件下的性能表现。注：性能效率测试的一种。

　　3.3

　　峰值测试 spiketesting

　　用于评估系统与软件在短时间内负载大幅度超出通常负载时的性能表现。

　　注：性能效率测试的一种。

　　3.4

　　扩展性测试 scalabilitytesting

　　用于评估系统与软件适应外部性能需求变化(如用户负载支持、事务数量、数据量等)的性能表现。注：性能效率测试的一种。

　　3.5

　　容积测试 volumetesting

　　用于评估系统与软件在吞吐量、存储容量或两者兼考虑的情况下处理指定数据量(通常达到最大指

　　GB/T 39788—202 1

　　定容量或接近最大值)的能力。

　　注：性能效率测试的一种。

　　3.6

　　疲劳强度测试 endurancetesting

　　用于评估系统与软件在指定的时间段内，能够持续维持所需的负载的能力。

　　注：性能效率测试的一种。

　　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) 依据历史运行情况或实际运行环境设计测试数据生成和读取规则。 测试数据包括为待测系统与软件准备的基础数据，以及运行所需要的数据。 数据量应与测试环境的配置相适应或与未来扩展数据量一致，在实际环境中数据量应与实际规模相一致;在模拟环境中宜等比对数据规

　　GB/T 39788—202 1

　　模进行调整。

　　d) 确定负载生成方式，可采用工具或人工的方式加压。 应根据制定的测试方案布置各测试场景，包括并发用户数、执行时长以及需要监视的性能指标等。

　　e) 针对所需测试的业务逻辑设计测试用例。

　　f) 依据需求或实际运行环境确定测试用例顺序。

　　g) 开发测试脚本。 通过脚本对待测系统与软件的用户业务行为进行模拟，脚本的开发可采用录制、编写或定制开发等方式。 完成测试脚本开发后，应进行功能验证，确保测试脚本已完成用户业务行为。

　　h) 确定暂停和恢复准则：

　　1) 暂停准则可包括：

　　— 系统不可用;

　　— 由于不确定原因导致服务器宕机或必要服务停止运行;

　　— 应用程序在打开状态下具有阻塞程序/严重缺陷;

　　— 所需的依赖项不可用。

　　2) 恢复准则可包括：

　　— 系统和/或服务器可用，启动并运行;

　　— 解决阻塞和/或关键问题;

　　— 应用程序功能已恢复;

　　— 测试数据处理周期未完成时的恢复程度。

　　5 . 4 性能测试执行

　　性能测试执行过程包括下列活动：

　　a) 执行前就绪检查，对性能测试所需环境和资源进行评估。

　　b ) 由人工或利用测试工具执行测试脚本，并监控执行过程中的性能指标，记录测试结果。

　　c) 性能测试通常需考察待测系统与软件在一段时间范围内的综合表现，按需取平均值、最大值或最小值作为测试结果。

　　d) 若性能测试异常终止或不满足需求或预期，填写性能问题报告单。 问题报告单应包括问题来源、场景配置、问题描述、问题等级等内容。

　　e) 判断所执行的测试用例是否通过。 如果测试不通过，分析具体情况，确定是由软件本身性能瓶颈所引起的，还是由测试环境所引起的。

　　图 1 给出了性能测试执行框架，该执行框架由 5 个组件组成：输入、运行环境和待测系统与软件、输出、控制单元和监督单元。 其中，输入、运行环境和待测系统与软件以及输出是一般软件测试的组成部分，控制单元和监督单元是性能测试所特有的。 输入提供了性能测试的条件，可能包括测试数据及其相关的控制机制。 控制单元则为输入提供了相关信息，例如运行环境或测试执行顺序等所需的更改。 运行环境包括待测系统与软件、运行支撑环境和性能测试支撑环境。 控制单元用于决定和控制输入组件的输入。 监督单元监控输出组件的时间特性和资源利用性和容量，包括测试过程的即时信息。

　　注 1 ：控制单元可控制的信息包括并发请求、思考时间、集合点等。

　　注 2：资源利用性如处理器占用率、内存占用率等。

　　注 3：时间特性如响应时间、周转时间等。

　　注 4：容量如最大并发数、最大用户数等。

　　注 5：输入如系统登录用户名密码、查询关键词，输出如返回的查询结果等。

　　GB/T 39788—202 1

　　图 1 性能测试执行框架

　　5 . 5 性能测试总结

　　性能测试总结包括下列活动：

　　a) 整理性能测试结果。 性能测试的结果宜考虑多种环境因素下的综合结果，采用数学和统计方法进行数据综合分析考虑，如标准差、用户约定的统计模型。

　　注 1 ：分析数据时，宜删除异常数据，例如系统启动或关闭时捕获的数据。

　　注 2 ：响应时间、吞吐率和资源利用率考虑包括平均值、最小值、最大值或标准偏差。

　　注 3：并发请求数宜分析最大并发请求。

　　b ) 编写软件性能测试报告，内容宜包括：测试结果分析、对软件性能的评价和建议。

　　c) 根据测试记录和性能问题报告单编写性能问题报告。 性能测试事件报告宜包含问题来源、场景配置、问题描述和问题等级等内容。

　　6 性能测试需求模型

　　6 . 1 概述

　　性能测试需求模型应考虑环境、数据、业务流程、用户分布、请求时序分布和网络状态等因素。

　　6 . 2 环境需求

　　针对不同质量要求，应考虑测试环境对性能测试的影响，推荐使用系统或软件的实际生产环境作为性能测试环境。 在进行性能测试环境规划和设计时，应考虑以下因素：

　　a) 稳定性：在相同条件下的多轮次测试结果应保持一致，或在可接受误差范围内;

　　b ) 独立性：为避免测试结果失真，测试环境应与其他在用系统或软件保持相互隔离;

　　c) 可控制性：测试环境中的所有设备和资源应可被监控或控制。

　　性能测试环境考虑因素包括：

　　a) 硬件配置：包括需使用的计算机、服务器、磁盘阵列或其他专用设备，考虑上述硬件资源的型号、数量、部署逻辑、通信和连接状态等;

　　b ) 软件配置：包括需使用的操作系统、中间件、数据库、性能测试工具或其他专用软件，考虑前述

　　GB/T 39788—202 1

　　软件资源的版本、补丁等;

　　c) 网络配置：包括需使用的交换机、路由器、集线器或其他专用网络设备，考虑前述网络资源的组网方式、传输速率和延迟特性等。

　　当现有条件无法支撑测试环境构建时，应最大化利用现有资源进行测试环境构建，并分析测试环境和生产环境的差异性，如不同的软硬件或网络设备可能带来的性能增益或损耗。

　　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,并且该角色比其他角色的性能要求更高。

　　图 2 用户分布模型

　　对于不同的角色，其预期的用户数量和参与的业务是不同的。

　　测试执行时应考虑功能种类、数量、每种功能执行的人数等。

　　设计并发用户数时，若无特定约定，宜根据在线用户数进行估算。

　　示例：一般非高频交易的 Web 系统，按在线用户数的 10%~20%估算并发请求数。

　　6 . 6 请求时序分布模型

　　性能测试请求发送时序应符合业务需求。

　　GB/T 39788—202 1

　　性能测试通过一系列场景的执行来完成，分析用户的请求模型是获取性能测试需求的有效手段，即定义系统的典型使用方式，考虑用户使用系统的典型业务、时间段和用户数量。 图 3 给出了某个请求时序分布的示意图，描述了一天中某系统中负载随时间变化的情况。

　　图 3 请求时序分布示意图

　　示例 1 ：某 OA 系统的每天早上 8 ∶ 00 有 200 个用户在 10 min 内登录系统。

　　示例 2：每天查询交易的高峰是在 9 ∶ 00~11 ∶ 00 和下午的 14 ∶ 00~16 ∶ 00。

　　不同的网络请求会产生不同的负载，图 4 和图 5 给出了两种典型的请求负载模式。 图 4 描述了客户端同时发送请求，但在不同的时间到达服务器;图 5 描述了客户端在不同的时间发送请求，但在同 一时间到达服务器。

　　图 4 请求同时发出

　　图 5 请求同时到达

　　GB/T 39788—202 1

　　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) 确定负载测试的通过/不通过准则，例如响应时间或资源占用率大于某阈值时则视为不通过该次负载测试。

　　表 1 给出了某场景下负载测试的测试覆盖项和测试用例的示例。

　　GB/T 39788—202 1

　　表 1 负载测试的测试覆盖项和测试用例示例

　　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) 确定各项业务的预期输出;

　　GB/T 39788—202 1

　　2) 适用时，确定系统的监视指标(如响应时间、并发用户数、资源利用率等);

　　3) 确定系统与软件在极限状态下(超出预期峰值或者可用资源少于最低要求时)的性能。

　　表 2 给出了某业务场景下压力测试的示例。 负载是采用递增加载方式，当负载(用户数)达到 100时，系统响应时间增加过快，但在运行范围内;当负载(用户数)达到 150 时系统存在异常。 由表中数据可知，该系统的性能瓶颈是由数据库查询时间导致。

　　表 2 压力测试用例示例

　　7 . 3 峰值测试

　　7 . 3 . 1 建立模型

　　峰值测试模型由峰值负载业务、峰值负载量强度、峰值持续时间和监视指标来描述。 对于指定的负载业务，当负载业务瞬间峰值(超过系统所能正常承载的强度)来临时，系统将降级运行;当负载业务负载逐渐降低至正常水平，检查系统是否能恢复正常运行。

　　峰值测试模型的构建过程包括：

　　a) 确定所需测试负载的业务;

　　b ) 确定被测各业务的用户角色分布;

　　c) 确定对应的监视指标;

　　d) 确定被测各业务的峰值负载量强度、峰值持续时间、负载恢复至正常的下降步长/时间;

　　e) 确定被测各业务负载生成方法。

　　峰值测试模型中的负载量强度设计可与压力测试结合确定，由压力测试中所测量得出的软件崩溃的极限负载量，如系统的响应时间、并发用户数、吞吐量、资源利用率等，作为当前峰值测试的峰值负载量强度。

　　7 . 3 . 2 导出测试覆盖项

　　对于峰值测试，每项被测业务的峰值负载强度计划测试值为一个测试覆盖项。

　　7 . 3 . 3 导出测试用例

　　峰值测试用例按以下步骤导出：

　　a) 确定前提条件：

　　1) 根据业务场景实际情况，确定待测业务的前置业务条件;

　　2) 确定需要同时运行的测试用例组合。

　　b ) 设计输入数据：

　　1) 确定各操作所需的输入数据;

　　2) 确定输入数据的来源，例如历史数据或相似系统的数据。

　　c) 选择用户操作：

　　GB/T 39788—202 1

　　1) 依据用户使用场景确定用户操作;

　　2) 确定用户活动趋势，包括用户数起始量、峰值量、峰值持续时间和负载下降步长;

　　3) 确定思考时间。

　　d) 确定预期结果：

　　1) 适用时，确定系统的监视指标(如响应时间、并发用户数、资源利用率等);

　　2) 确定各项业务正常运行的预期输出;

　　3) 确定当前计划测试的峰值上各项业务的降级运行预期输出;

　　4) 确定当前计划测试的峰值过后各项业务的恢复运行预期输出。

　　表 3 给出了某场景下峰值测试的测试覆盖项和测试用例的示例。

　　表 3 峰值测试的测试覆盖项和测试用例示例

　　7 . 4 可扩展性测试

　　7 . 4 . 1 建立模型

　　可扩展性测试用于评估软件在外部性能需求或环境变化情况下的性能处理能力，通过在基准测试的性能需求、性能测试环境基础上进行扩展(如用户负载支持、事务数量、数据量等性能需求，处理器、内存、磁盘等硬件资源环境扩展)后的系统性能表现情况。 基准测试可以包括前述章节中的负载测试、疲劳强度测试等方式，或者采用单独的基准测试场景进行。

　　可扩展性测试模型的构建过程包括：

　　a) 确定所需可扩展性测试的业务;

　　b ) 确定被测各业务的用户角色分布;

　　c) 确定被测各业务的扩展量需求;

　　d) 确定可扩展性测试用例生成方法。

　　GB/T 39788—202 1

　　7 . 4 . 2 导出测试覆盖项

　　对于可扩展性测试，每项被测试业务的可扩展性测试需求为一个测试覆盖项。

　　7 . 4 . 3 导出测试用例

　　可扩展性测试用例按以下步骤导出：

　　a) 确定前提条件：

　　1) 根据业务场景实际情况，确定可扩展性测试业务的前置业务条件;

　　2) 根据可扩展性测试需求，确定基准测试、可扩展性测试环境条件，如被测试系统服务器数量的扩展，服务器内存的扩展等;

　　3) 确定需要进行性能扩展比较的测试用例组合。

　　b ) 设计输入数据：

　　1) 确定可扩展性测试各操作所需的输入数据，宜保证基准测试与可扩展性测试的输入数据一致;

　　2) 确定可扩展性测试输入数据的来源，例如历史数据或相似系统的数据，宜与基准测试所使用的数据来源相同，并在基准测试数据基础上进行扩展;

　　3) 可扩展性测试输入数据设计时需要考虑以下内容：

　　— 与基准测试相比较的业务数据扩展内容，如用户数据量、订单数据量等;

　　— 与基准测试相比较的业务数据扩展方式，如通过数据库语句进行数据批量生成等;

　　— 与基准测试相比较的业务数据扩展比例，如基准测试业务数据的整数倍。

　　c) 选择用户操作：

　　1) 依据基准测试用户使用场景确定可扩展性测试用户操作;

　　2) 确定业务、环境资源等扩展后的用户数;

　　3) 确定用户活动趋势;

　　4) 确定思考时间。

　　d) 确定性能指标及监控方式：

　　1) 依据基准测试场景中的性能指标，确定可扩展性测试对应性能指标，如响应时间、内存占用率等;

　　2) 确定测试需求、测试环境扩展后的性能指标的监控方式，如响应时间、硬件资源等性能指标的监控方式。

　　e) 确定具体扩展场景及执行顺序：

　　1) 依据基准测试场景中的性能场景，确定可扩展性测试对应场景;

　　注：单一场景主要是指针对某一项资源单独扩展情况下(如计算资源、存储资源、网络资源、数据资源

　　等)测试场景的设计;混合场景主要是指针对某几项资源共同扩展情况下测试场景的设计。

　　2) 依据可扩展性测试需求或扩展环境，确定每个测试场景对应的测试用例执行顺序或逻辑关系，以及测试场景启动或停止的条件。

　　f) 确定预期结果：

　　1) 确定各项业务的预期输出;

　　2) 适用时，确定系统的监视指标(如响应时间、并发用户数、资源利用率等);

　　3) 确定可扩展性测试的通过/不通过准则，例如在业务、环境资源等扩展后的响应时间或资源占用率大于某阈值时则视为不通过该次可扩展性测试。

　　表 4 给出了某场景下可扩展性测试的测试覆盖项和测试用例的示例。

　　GB/T 39788—202 1

　　表 4 可扩展性测试的测试覆盖项和测试用例示例

　　7 . 5 疲劳强度测试

　　7 . 5 . 1 建立模型

　　疲劳强度测试模型由用户规模、负载分布和执行时间来描述。 疲劳强度测试通常和被测软件的可靠性能力相关，在指定用户规模、负载分布和执行时间情况下，验证被测软件的持续稳定运行能力或软件失效后的恢复能力的饱和性试验。

　　疲劳强度测试模型的构建过程包括：

　　a) 确定满足性能指标(时间特性、资源特性等)要求的用户规模;

　　b ) 构建被测软件的混合业务模型;

　　c) 确定测试执行时间;

　　d) 确定场景中其他要素(思考时间、集合策略等)。

　　7 . 5 . 2 导出测试覆盖项

　　对于疲劳强度测试，被测软件混合业务模型的健壮性需求为一个测试覆盖项。

　　7 . 5 . 3 导出测试用例

　　疲劳强度测试用例按以下步骤导出：

　　a) 明确用户规模：

　　1) 选择满足软件性能指标要求的最大用户数作为疲劳强度测试的用户规模数;

　　2) 明确各业务相关用户的群体分布、行为趋势和交互模式。

　　b ) 构建业务模型：

　　1) 选择性能关键程度高的业务模块组成多组混合业务模型;

　　2) 根据业务场景实际情况，确定各组混合业务模型的业务处理比例;

　　3) 确定各组混合业务模型中业务的执行顺序和前置条件。

　　c) 确定执行时间：

　　宜根据软件生产环境运行情况或根据对软件的扩展性评估进行估算。

　　注：通常选择 24 h、3 × 24 h或 7 × 24 h执行。

　　GB/T 39788—202 1

　　d) 设计数据模型：

　　1) 明确数据使用要求，如数据文件大小限制或重用性限制等;

　　2) 确定各业务所需的数据类型和数据量;

　　3) 构建数据模型，涵盖输入参数数据和背景业务数据等;

　　4) 制定数据备份和恢复策略等。

　　e) 明确测试时机：

　　1) 软件已完成功能和性能测试，进入试运行阶段时;

　　2) 软件运行一定时间后，出现性能能力降级时;

　　3) 为提高软件性能水平，进行硬件升级或系统扩展时。

　　f) 确定预期结果：

　　1) 确定各项业务的预期输出;

　　2) 适用时，确定系统的监视指标(如响应时间、并发用户数、资源利用率等);

　　3) 确定疲劳强度测试的通过/不通过准则，例如响应时间或资源占用率超过预期或被测试软件无法继续提供正常服务等则视为不通过该次疲劳强度测试。

　　表 5 给出了某场景下疲劳强度测试的测试覆盖项和测试用例的示例。

　　表 5 疲劳强度测试的测试覆盖项和测试用例示例

　　7 . 6 容积测试

　　7 . 6 . 1 建立模型

　　容积测试模型由吞吐量和存储容量来描述。 在指定数据量(通常达到最大指定容积或接近最大值)的条件下，测量待测系统与软件的容积。 容积测试的 目 的是评估测试项在处理指定数量的数据时的性能，为系统扩容、性能优化提供参考。

　　容积测试模型宜按照以下步骤构建：

　　a) 确定所需测试指定的数据量;

　　GB/T 39788—202 1

　　b ) 确定待测系统与软件的用户操作;

　　c) 确定待测系统与软件的容积需求;

　　d) 确定容积检验方法。

　　7 . 6 . 2 导出测试覆盖项

　　对于容积测试，待测系统与软件的吞吐量指标、存储容量指标为一个测试覆盖项。 根据业务需求和系统架构不同，在选取容积指标时一般遵循如下原则：

　　a) 并发请求量较大时，重点关注响应时间和每秒事务处理数等指标;

　　b ) 需要存储读写的数据量较大时，重点关注吞吐量和磁盘 I/O 等指标。

　　7 . 6 . 3 导出测试用例

　　容积测试用例按以下步骤导出：

　　a) 确定前提条件：

　　根据业务场景实际情况，确定待测业务的前置业务条件。

　　b ) 设计输入数据：

　　确定输入数据的来源，例如历史数据或相似系统的数据。

　　c) 对系统进行监控：

　　1) 加载大容量的数据;

　　2) 依据用户使用场景确定用户操作;

　　3) 确定正常/峰值时间用户数;

　　4) 对 CPU/内存/磁盘/响应时间/事务成功率等指标进行监控。

　　d) 确定预期结果：

　　1) 确定各项业务的预期输出;

　　2) 适用时，确定系统的监视指标(如响应时间、并发用户数、资源利用率等);

　　3) 确定容积测试的通过/不通过准则，例如只要限定的某项资源达到最大使用状态或某项指标超出可接受阈值，则视为不通过该次容积测试。

　　表 6 给出了某场景下容积测试的测试覆盖项和测试用例的示例。

　　表 6 容积测试的测试覆盖项和测试用例示例

　　GB/T 39788—202 1

　　附 录 A

　　(资料性附录)

　　性能效率的质量测度

　　表 A. 1 给出了 GB/T 25000 . 23—2019 中定义的性能效率的质量测度。

　　表 A.1 GB/T 25000.23—2019 中定义的性能效率质量测度

　　GB/T 39788—202 1

　　附 录 B

　　(资料性附录)

　　移动应用性能测试案例

　　B.1 系统描述

　　待测系统与软件为移动应用软件，主要功能为在线发送消息，分为两部分：一为移动应用终端，运行环境为 Android平台，Android版本需大于 5 . 0;二为服务器端应用，负责消息的存取功能。

　　该系统包含如下两种角色：

　　a) 普通用户;

　　b ) 系统管理员。

　　主要功能如下：

　　a) 系统登录：所有用户均可进行此操作;

　　b ) 发布消息：普通用户可以创建消息并保存或者发布消息;

　　c) 审核消息：系统管理员可以审核用户发布的消息，可以通过审核或者取消发布。

　　B.2 性能需求

　　客户端性能需求如下：

　　a) 空闲状态下，软件运行时内存消耗最大不超过 200 MB,且在软件退出时应当 自行清理内存;

　　b ) 安装目标应用软件前后待机功耗无明显差异;

　　c) 应用后台连续运行 2 h 的流量值不超过 20 MB,如大于 20 MB应给出提示。

　　服务器端性能需求如下：

　　a) 审核功能应能具备 10 个并发用户操作;

　　b ) 发布消息功能应能具备 100 个并发用户操作;

　　c) 满足上述容量的前提下响应时间不超过 2 s。

　　B.3 测试用例

　　客户端测试用例设计如表 B. 1 所示。

　　表 B.1 客户端测试用例

　　GB/T 39788—202 1

　　表 B.1(续)

　　服务器端测试用例设计如表 B. 2 所示。

　　表 B.2 服务器端测试用例

　　GB/T 39788—202 1

　　表 B.2(续)

　　B.4 测试结果

　　B.4 . 1 概述

　　本测试结果案例仅考虑服务器测试中，100 个并发用户提交消息场景下的结果记录。

　　B.4 . 2 测试场景

　　100 个并发用户提交消息，采用静态加压方式，思考时间设置为 0 s,测试持续 5 min。

　　B.4 . 3 响应时间

　　图 B. 1 记录了服务器响应时间的变化趋势，表 B. 3 给出了各项统计结果。 实际测试过程中，服务器响应时间在满足相应负载的条件下未超过 2 s 的需求限制。

　　GB/T 39788—202 1

　　图 B.1 服务器响应时间

　　表 B.3 服务器响应时间统计结果

　　B.4 . 4 应用服务器资源消耗

　　应用服务器 CPU 占用率变化趋势如图 B. 2 所示，表 B. 4 给出了部分统计量。

　　图 B.2 应用服务器 CPU 占用率

　　表 B.4 应用服务器 CPU 占用率统计

　　GB/T 39788—202 1

　　应用服务器内存消耗变化趋势如图 B. 3 所示，表 B. 5 给出了部分统计量。

　　图 B.3 应用服务器内存消耗

　　表 B.5 应用服务器内存消耗统计

　　B.4 . 5 数据服务器资源消耗

　　数据服务器 CPU 占用率变化趋势如图 B. 4 所示，表 B. 6 给出了部分统计量。

　　图 B.4 数据服务器 CPU 占用率

　　GB/T 39788—202 1

　　表 B.6 数据服务器 CPU 占用率统计

　　数据服务器内存消耗变化趋势如图 B. 5 所示，表 B. 7 给出了部分统计量。

　　图 B.5 数据服务器内存消耗

　　表 B.7 数据服务器内存消耗统计

　　GB/T 39788—202 1

　　附 录 C

　　(资料性附录)

　　大型信息系统性能测试应用案例

　　C.1 系统描述

　　待测系统与软件为大型信息系统中的关联查询模块，主要功能为根据关键词检索信息，分为两部分：一为网页客户端，运行在 Windows 7 平台;二为服务器端，运行在 Windows Server 2008 平台，负责通过主题向数据库搜索并获取结果，返回给客户端。

　　该软件模块主要功能如下：

　　a) 根据关键词检索相关信息;

　　b ) 点击查询结果进入并加载详情页面。

　　C.2 性能需求

　　客户端性能需求如下：

　　a) 前台页面检索可以正常显示搜索结果;

　　b ) 打开一个目标的详情页，页面展示正常。

　　服务器端性能需求如下：

　　a) 搜索功能，能够支持 150 个用户并发操作，检索响应时间不超过 5 s ;

　　b ) 访问页面信息功能，能够支持 150 个用户并发操作，页面打开响应时间不超过 5 s。

　　C.3 测试用例

　　客户端测试用例设计如表 C. 1 所示。

　　表 C.1 客户端测试用例

　　GB/T 39788—202 1

　　服务器端测试用例设计如表 C. 2 所示。

　　表 C.2 服务器端测试用例

　　C.4 测试结果

　　C.4 . 1 概述

　　本测试结果案例仅考虑服务器测试中，150 个并发用户搜索关键词、查看详情的结果记录。

　　C.4 . 2 测试场景

　　初始 50 个线程，每 15 s增加 50 用户，共计 150 个用户;思考时间：0 s;持续时间：5 min。

　　GB/T 39788—202 1

　　C.4.3 响应时间

　　表 C. 3 给出了 150 个用户并发进行检索操作服务器响应时间的各项统计结果，可见平均响应时间为 2 . 293 s,低于规定的时间 5 s,故满足性能需求。

　　表 C.3 150 用户并发进行搜索操作服务器响应时间统计结果

　　表 C. 4 给出了 150 个并发用户查看人员详情页面服务器响应时间的各项统计结果，平均响应时间为 9 . 228 s,超过了 5 s,故不满足给定的性能需求。

　　表 C.4 150 个并发用户查看人员详情服务器响应时间统计结果

　　在 150 个并发用户压力测试同时，在客户端查看详情页面，浏览器记录的请求响应时间在 1 s 以内 。 由于查看详情页操作请求数较多，响应时间记录最后一个请求返回的时间，所以结果超出了 5 s,但是由于网页访问使用异步加载策略，虽然有个别请求返回较慢，但网页先展示了大部分请求返回的数据，所以对用户来说加载较快，不会有卡顿或者长时间等待展示数据的情况。

　　C.4.4 应用服务器资源消耗

　　在压力测试期间，应用服务器内存使用量最高为 120 M,内存消耗正常;而应用服务器的 CPU 占用率变化幅度较大，在压力峰值时 CPU 占用率达到 95%以上。

　　GB/T 39788—202 1

　　附 录 D

　　(资料性附录)

　　云应用性能测试案例

　　D.1 系统特点

　　待测系统与软件为基于云的购票应用，提供在线购票和在线支付等功能，主要功能如下：

　　a) 系统登录：所有用户均可进行此操作;

　　b ) 在线购票：所有用户均可以在线购票并提交订单;

　　c) 在线支付：所有用户均可以对已提交的订单进行支付操作。

　　待测系统与软件的用户群体主要为全国各地的购票人员，在购票时可能存在并发压力，因此待测系统与软件设计时重点考虑两点：一是个人信息保护，二是需要强大的计算资源支持子系统业务，待测系统与软件的特点如下：

　　a) 系统分布式部署于云平台上，系统架构分为四部分，即接入层、Web层、应用层和数据层;

　　b ) 采用虚拟化机制实现，包含 2 组运行数据库，每组均包括售票节点、支付节点;

　　c) 待测系统与软件只将部分流程的环节交由云服务供应商提供服务，系统全流程未采用按需扩容的托管模式;

　　d) 为了保证用户的数据安全，采用混合云架构，即融合公有云和私有云，系统将敏感数据存放于私有云的数据中心，同时获得公有云的计算资源，将业务子系统部署于公有云。

　　D.2 性能需求

　　待测系统与软件的用户群体分布于全国各地，测试时需模拟不同地域、不同网络环境和服务器环境发起请求，更真实的模拟系统上线后的使用需求，同时监控云服务集群中应用服务器集群、数据库服务器集群等网络资源、服务器资源的资源利用性。 性能测试需求如下：

　　a) 在线购票应满足 1 000 个并发用户操作;

　　b ) 在线支付应满足 1 000 个并发用户操作;

　　c) 满足上述容量的前提下平均响应时间不超过 3 s。

　　D.3 测试环境及准备

　　根据性能需求，测试环境准备的要求如下：

　　a) 模拟全国各地用户访问待测系统与软件不同节点的实际需求;

　　b ) 配置不同的网络环境和服务器环境;

　　c) 配置云测试环境，根据给定数据量，测试关键业务的响应时间。

　　本次测试所使用的云性能测试工具，提供脚本录制、场景设置、压力测试、资源监控和报表统计等功能，为真实的模拟实际应用环境，测试工具分别部署在华北、华东、华南、香港等多个区域的云服务平台上，通过分布在全国各地的云性能测试工具，可模拟全国各地用户访问待测系统与软件不同节点的实际需求，云性能测试基础技术架构见图 D. 1 。

　　GB/T 39788—202 1

　　图 D.1 基础技术架构图

　　性能测试控制中心：测试时的性能测试接口，提供环境管理、性能测试、性能监控、性能分析、性能报告等功能的云测试平台，可将性能测试任务传递至控制消息服务器。

　　控制消息服务器：接收测试控制中心任务消息传递给分布式压测集群运行，接收分布式引擎传递回来的数据，并传递给测试控制中心。

　　分布式压测集群：由 2 台控制器和 16 台代理组成，控制器接收到任务后，将任务传递给代理进行加压，目前分布式压测集群部署于多个区域。

　　D.4 测试用例

　　测试范围主要是在线购票和在线支付两个功能点，根据其操作流程设计测试用例，具体见表 D. 1 。

　　表 D.1 测试用例

　　GB/T 39788—202 1

　　表 D.1(续)

　　D.5 测试结果

　　D.5 . 1 概述

　　本次测试通过被测软件主要功能的测试结果，反映云应用系统的整体性能，包括云应用信息系统各节点性能情况、1 000 个并发用户在线购票并支付场景下的结果记录。

　　D.5 . 2 测试场景

　　1 000 个并发用户在线购票并支付，完成全流程业务操作，采用静态加压方式，思考时间忽略，测试

　　持续 5 min。

　　D.5 . 3 响应时间

　　图 D. 2 记录了云应用信息系统响应时间的变化趋势，表 D. 2 给出了各项统计结果。 实际测试过程中，被测软件响应时间在满足相应负载的条件下未超过 3 s 的需求限制。

　　GB/T 39788—202 1

　　图 D.2 云应用信息系统响应时间

　　表 D.2 云应用信息系统响应时间统计结果

　　D.5 . 4 资源监控

　　D.5 . 4 . 1 概述

　　被测软件的架构中主要有如下服务器：

　　a) 应用服务器：部署购票、支付等核心业务;

　　b ) 代理服务器：部署用于通信的非核心业务;

　　c) 消息管理服务器：部署信息推送等服务业务;

　　d) 数据库服务器：部署结构化数据库存储业务。 D.5 . 4 . 2 云应用服务器资源消耗

　　云应用服务器 CPU 占用率变化趋势见图 D. 3 。

　　图 D.3 云应用服务器 CPU 占用率

　　GB/T 39788—202 1

　　云应用服务器内存消耗变化趋势见 D. 4 。

　　图 D.4 云应用服务器内存消耗

　　D.5 . 4 . 3 云数据服务器资源消耗

　　云数据服务器 CPU 占用率变化趋势见图 D. 5 。

　　图 D.5 云数据服务器 CPU 占用率

　　云数据服务器内存消耗变化趋势见图 D. 6 。

　　图 D.6 云数据服务器内存消耗

　　GB/T 39788—202 1

　　附 录 E

　　(资料性附录)

　　嵌入式软件性能测试案例

　　E.1 系统描述

　　待测系统与软件为嵌入式机载软件，是分系统的核心软件，完成分系统内综合化管理和数据处理工作 。该软件固化于机载设备中，随机载设备一同上下电。

　　该软件主要功能包括：

　　a) 参数加载：接收航电系统指令，对分系统内各设备进行参数加载，并上报加载结果;

　　b ) 设备自检：接收航电系统指令，控制分系统内各设备进行自检测，并上报自检测结果;

　　c) 参数控制：接收航电系统指令，对分系统内各设备当前工作参数进行控制;

　　d) 周期数据上报：接收分系统内各设备周期上报的数据，经过处理后上报航电系统。

　　E.2 性能需求

　　被测软件性能需求如下：

　　a) 对机载设备上电后，该软件的初始化时间不超过 5 s ;

　　b ) 当航电系统启动设备自检测时，该软件需在 100 ms 内将自检测指令下发分系统内各设备;

　　c) 该软件以 3 s 为周期向分系统内各设备发送周期自检测指令;

　　d) 当航电系统对分系统内某设备进行参数设置时，若该设备不在线(未应答)，被测软件需在500 ms 内进行数据重传，重传 2 次仍未收到设备应答，判设备总线故障，并上报航电系统;

　　e) 被测软件需周期上报分系统内各设备主动上报的参数，其中 A设备的距离参数，处理精度为毫米级;当距离数据有效时，上报距离数值和有效状态;当距离数据无效时，上报无效状态。 该距离参数计算公式为：s=槡r2 -(h-d)2 , s为 A设备距离，r为 A设备主动上报的距离数据， h 为气压高度，d为 A设备台站高度;

　　f) 被测软件 FLASH 余量、内存余量和 CPU余量均大于 30% ;

　　g) I/O 总线传输不超过 100 kbit/s。

　　E.3 测试用例

　　E.3 . 1 平均启动时间

　　表 E. 1 给出了软件初始化时间测试用例设计。

　　表 E.1 软件初始化时间测试用例

　　GB/T 39788—202 1

　　表 E.1(续)

　　E.3 . 2 平均响应时间

　　表 E. 2 给出了启动自检转发时间测试用例设计。

　　表 E.2 启动自检转发时间测试用例

　　GB/T 39788—202 1

　　表 E. 3 给出了数据重传时间测试用例设计。

　　表 E.3 数据重传时间测试用例

　　E.3 . 3 响应时间的充分性

　　表 E. 4 给出了周期自检时间测试用例设计。

　　表 E.4 周期自检时间测试用例

　　GB/T 39788—202 1

　　表 E.4(续)

　　E.3 . 4 数据精度处理

　　表 E. 5 给出了数据精度处理测试用例设计。

　　表 E.5 数据精度处理测试用例

　　GB/T 39788—202 1

　　E.3 . 5 处理器平均占用率

　　表 E. 6 给出了 CPU余量测试用例设计。

　　表 E.6 CPU余量测试用例

　　E.3 . 6 内存平均占用率

　　表 E. 7 给出了内存余量测试用例设计。

　　表 E.7 内存余量测试用例

　　GB/T 39788—202 1

　　表 E.7(续)

　　表 E. 8 给出了 FLASH 余量测试用例设计。

　　表 E.8 FLASH余量测试用例

　　E.3 . 7 I/O总线传输平均占用率

　　表 E. 9 给出了 I/O 总线传输平均占用率测试用例设计。

　　表 E.9 I/O总线传输平均占用率测试用例

　　GB/T 39788—202 1

　　表 E.9(续)

　　E.4 测试结果

　　E.4 . 1 平均启动时间

　　表 E. 10 给出了软件初始化时间结果示例。

　　表 E.10 软件初始化时间结果示例

　　测试结论：被测软件初始化时间最大值为 4 . 997 s,平均值为 4 . 993 s,满足要求。

　　E.4 . 2 平均响应时间

　　表 E. 11 给出了启动自检转发时间结果示例，表 E. 12 给出了数据重传时间结果示例。

　　表 E.1 1 启动自检转发时间结果示例