GB/T 39788-2021
基本信息
标准号： GB/T 39788-2021
中文名称：系统与软件工程 性能测试方法
标准类别：国家标准(GB)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：17942173
标准分类号
关联标准
出版信息
相关单位信息
标准简介
GB/T 39788-2021.System and software engineering一Performance testing method.
1范围
GB/T 39788规定了系统与软件性能测试的测试过程、测试需求模型和测试类型。
GB/T 39788适用于系统与软件性能测试的分析、设计和执行。
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
负载测试 load testing
用于评估系统与软件在预期变化负载下的性能表现,负载通常位于低谷、典型和高峰使用的预期条件之间。
注:性能效率测试的一种。
3.2
压力测试 stress testing
用于评估系统与软件在高于预期或指定容量负载需求,或低于最少需求资源的条件下的性能表现。
注:性能效率测试的一种。
3.3
峰值测试 spike testing
用于评估系统与软件在短时间内负载大幅度超出通常负载时的性能表现。
注:性能效率测试的一种。
3.4
扩展性测试 scalability testing
用于评估系统与软件适应外部性能需求变化(如用户负载支持、事务数量、数据量等)的性能表现。
注:性能效率测试的一种。
1范围
GB/T 39788规定了系统与软件性能测试的测试过程、测试需求模型和测试类型。
GB/T 39788适用于系统与软件性能测试的分析、设计和执行。
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
负载测试 load testing
用于评估系统与软件在预期变化负载下的性能表现,负载通常位于低谷、典型和高峰使用的预期条件之间。
注:性能效率测试的一种。
3.2
压力测试 stress testing
用于评估系统与软件在高于预期或指定容量负载需求,或低于最少需求资源的条件下的性能表现。
注:性能效率测试的一种。
3.3
峰值测试 spike testing
用于评估系统与软件在短时间内负载大幅度超出通常负载时的性能表现。
注:性能效率测试的一种。
3.4
扩展性测试 scalability testing
用于评估系统与软件适应外部性能需求变化(如用户负载支持、事务数量、数据量等)的性能表现。
注:性能效率测试的一种。
标准图片预览
标准内容
ICs35.080
中华人民共和国国家标准
GB/T39788—2021
系统与软件工程
性能测试方法
System and software engineering-Performance testing method2021-03-09发布
国家市场监督管理总局
国家标准化管理委员会
2021-10-01实施
GB/T39788—2021
规范性引用义件
3术和定义
性能测试概述
5性能测试过程
6性能测试需求模型
7性能测试类型
附录A（资料性附录）性能效率的质量测度附录B（资料性附录）移动应用性能洲试案例次
附录（（资料性附录）大型信息系统性能测试应用案例附录D（资料性附录）
云应用性能测试案例
附录E（资料性附录）嵌人式软件性能测试案例-rKaeerKa-
本标准按照GB/T1.12009给出的规则起草。GB/T39788—2021
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准山全国信息技术标准化技术委员会（SAC/TC28）提出并归口本标准起草单位：上海计算机软件技术开发中心、深圳赛西信息技术有限公司、国家应用软件产品质量监督检验中心、中国电了技术标准化研究院、中国电了科技集团公司第十研究所、厦门理工学院、中国电了科技集团公司第五十四研究所、内蒙占白治区电了信总产品质量检验院、山东道普测评技术有限公司、北京轩宇信息技术有限公司、中国航大系统科学与工程研究院、中电莱斯信息系统有限公司、广东省科技基础条件平台中心、北京京航计算通讯研究所、浙江省电子信息产品检验所、西字市大数据服务管埋局、上海第二工业大学、武汉大学。本标准主要起草人：龚家瑜、李文鹏、蔡立志、张肠肠、简炜、卢俊文、孙风丽、康京山、郭澍、工风玲、张峻、李军、高猛、工建、郝璟璐、陆澄澹、胡芸、杨隽、赵毅、易晶晶、孙肖、于泉、工威、沈颖、杨玲萍、滕俊儿、许颖媚、白方芳、谢晓园、吴克寿、巩韶飞、贾素用、李丽萍、孟宪伟。-rrKaeerkca
-riKacerKAca-
1范围
系统与软件工程
性能测试方法
本标准规定了系统与软件性能测试的测试过程、测试需求模型和测试类型。本标准适用丁系统与软件性能测试的分析、设计和执行。2规范性引用文件
GB/T 39788—2021
下列文件对本文件的成用是必不可少的：凡是注期的引用文件：仅注期的版本适用干本文件。凡是不注日期的引用文件，其最新版本（包括所有的修收单)适用丁本文件。GB/T25000.102016系统与软件工程：系统与软件质量要求和评价（SQuaRE）第10部分：
系统与软件质量模型
GB/T25000.232019
系统与软件工程系统与软件质量要求和评价（SQuaRE）第23部分：系统与软件产品质量测量
G3/T3863412020系统与软件工程软件测试第「部分：概念和定义3术语和定义
GB/T38634.12020界定的以及下列术语和定义适用于本文件。3.1
负载测试loadlesting
用于评估系统与软件在预期变化负载下的性能表现，负载通常位于低谷、典型和高峰使用的预期条件之间。
注：性能效率测试的一种。
stress testing
压力测试
用于评估系统与软件在高于预期或指定容量负载需求，或低于最少需求资源的条件下的性能表现，注：性能效率测试的种。
峰值测试spikelesting
用于评估系统与软件在短时间内负载人幅度超出通觉负裁时的性能表现注：性能效率测试的一种。
扩展性测试scalabilitytesting用于评估系统与软件适应外部性能需求变化(如用广负载支持、事务数量、数据量等)的性能表现：注：性能效率测试的”-种。
voluinetesting
容积测试
用评估系统与软件在春吐量、存储容量或两者兼考息的情况下处理指定数据量（通常达到最大指-rKaeerkca-
GB/T 39788—2021
定容量或接近最大)的能力
注：性能效率测试的一种。
疲劳强度测试endurance lesting用于评估系统与软件在指定的时间段内，能够持续维持所需的负载的能力：注：性能效率测试的一种。
4性能测试概述
性能测试用丁评估待测系统与软件在给定的时问和其他资源限制下完成其指定功能的程度，也称作性能效率测试。
系统与软件性能效率质量特性和子特性见GB/T25000.10—2016中4.3.2.2.系统与软件性能效率质量测度参见附录A，质量测度的描述和测量函数见GB/T25000.232019中8.3，在使用时，应依系统和软件的实际需求对质量测度进行裁剪，移动应用性能测试案例参见附录B。大型信息系统性能测试案例参见附录C云应用性能测试案例参见附录D。嵌人式软件性能测试案例参见附录E，5性能测试过程
5.1概述
性能测试过程包括性能测试需求分析、性能测试设计和实现、性能测试执行和性能测试总结四个过程。
5.2性能测试需求分析
性能测试需求分析包括下列活动：a）确定性能测试的准人准则，在系统构架确定后或冒烟测试通过后执行，测试介入越越好，b）确定待测系统与软件的性能需求。性能需求可来自合同、需求规格说明等文档中所明示的需求，或者由业务，数据、预期的用户和系统行为约定的隐含需求，性能需求亢依据性能需求模型来确定.性能需求模型见第6章，c）识别待测系统与软件相关的其他外部应用。dl）确定性能测试完成或终止准则5.3性能测试设计和实现
性能测试设计和实现过程用于导出测试用例和测试规程，相关的活动包括：a）确定所需监测的指标、业务场景、被测业务的用角色分布。b）确定采用的性能测试类型，
依据历史运行情况或实际运行环境设计测试数据生成和读取舰则，测试数据包括为待测系统与软件准备的基谢数据，以及运行所需要的数据：数据量应与测试环境的配置相适应或与未来扩展数据量一致，在实际坏境中数据量应与实际舰模相一致：在模拟环境中亢等比对数据rKaeerkAca-
模进行调整
GB/T 39788—2021
l）确定负载生成方式，川采用工具或人上的方式加压：应根据制定的测试方案布置各测试场景，包括并发用户数、执行时长以及需要监视的性能指标等。针对所需测试的业务逻辑设计测试用例，e）
依据需求或实际运行环境确定测试用例顺序8）开发测试脚本，通过脚本对待测系统与软件的用户业务行为进行模拟，脚本的开发可采用录制、编写或定制开发等方式：完成测试脚本开发后，成进行功能验证，确保测试脚本已完成用户业务行为。
h）确定暂停和恢复准则：
1）暂停准则可包括：
系统不川用：
由于不确定原因导致服务器容机或必要服务停止运行；一届用程序在打开状态下其有阻塞程序/严重缺陷：一所需的依赖项不可用.
2）恢复准则可包括：
一系统和/或服务器可用.启动并运行；—一解决阻塞和/或关键问题；
应用程序功能已恢复：
一测试数据处理埋周期未完成时的恢复程度：5.4性能测试执行
性能测试执行过程包括下列活动：a）执行前就绪检查，对性能测试所需环境和资源迹行评估，b)［
由人工或利用测战工具执行测战脚本，并监控执行过程中的性能指标，记录测战结果性能测试通常需考繁待测系统与软件在·段时间范围内的综合表现，按需取平均估、最大估惑最小值作为测试结果：
l）若性能测试只常终止或不满足需求或预期，填写性能问题报告单，问题报告单应包括问题米源、场景配置、问题捕述、问题等级等内容。判断所执行的测试用例是否通过：如果测试不通过.分析具体情况，确定是山软件本身性能瓶e)
颈所引起的，还是由测试坏境所引起的图【给出了性能测试执行框架.该执行框架由5个组件组成：输入、运行坏境和待测系统与软件、输出、控制单元和监督单元：其中，输入、运行环境和待测系统与软件以及输出是·股软件测试的组成部分控制单元和监督单元是性能测试所特有的。输入提供了性能测试的条件，川能包括测试数据及其相美的控制机制，控制单元则为输人提供了相关信息，例如运行环境或测试执行顺序等所需的史改，运行环境包括待测系统与软件、运行支撑环境和性能测试支撑环境：控制单儿用丁决定和控制输人组件的输人。监督单元监控输出组件的时间特性和资源利用性和容量，包括测试过程的即时信息注1：择制单元可控制的信息包括并发请求，思考时问、集合点等。注2：资源利用性如处理器占用率，内存占用率等注3：时间特性如响应时间、周转时间等，注4：容量如最大并发数、最大用广数等。注5：输人如系统登录用户名密码查询关链间，输出如返回的查询结果等，3
-rKaeerkca-
GB/T39788—2021
控制单元
5.5性能测试总结
性能测试总结包括下列活动：
监督单元
时间特性
资源利用性
运行环境
待测系统
与软件
图1性能测试执行框架
控制信息
测试激据
性能指标
a）整理性能测试结果。性能测试的结果宜考虑多种环境因素下的综合结果.来用数学和统计方法进行数据综合分析考虑，如标准差、用广约定的统计模型。注1：分析数据时：直删除兄常数据，例如系统片动或关闭时捕获的数据，注2：响应时问、吞叶率和资源利用率考虑包括平均值、最小值、最大值或标准偏差注3：并发请求数宜分析最人并发请求，b）编写软件性能测试报告，内容宜包括：测试结果分析、对软件性能的评价和建议根据测试记录和性能问题报告单编写性能问题报告：性能测试事件报告宜包含问题来源、场景配置、问题描述和问题等级等内容，6性能测试需求模型
6.1概述
性能测试需求模型成考虑环境、数据业务流程，用分布，请求时序分布和网络状态等因靠，6.2环境需求
针对不同质量要求，应考虑测试坏境对性能测试的影响，推荐使用系统或软件的实际生产坏境作为性能测试环境，在进行性能测试坏境舰划和设时，魔考虑以下因素：a）稳定性：在相同条件下的多轮次测试结果应保持一致，或在可接受误差范围内；b）独立性：为避免测试结果失真.测试环境应与其他在用系统或软件保持相五.隔离；c）可控制性：测试环境中的所有设备和资源应可被监控或控制.性能测试环境考虑因索包括：
a）硬件配置：包括需使用的计算机、服务器、磁盘阵列或其他专用设备，考虑「述硬件资源的型号、数量、部署逻辑、通信和连接状态等：b）软件配置：包括需使用的操作系统、中问件、数据库、性能测试工具或其他专用软件，考虑前述rrKaeerKAca-
软件资源的版本、补丁等；
GB/T 39788—2021
网络配置：包括需使用的交换机、路由器、集线器或其他专用网络设备，考虑前述网络资源的组C
网方式、传输速率和延迟特性等当现有条件无法支撑测试环境构建时.应最大化利用现有资源进行测试环境构建，并分析测试环境和生产环境的差异性，如不同的软硬件或网络设备能带来的性能增益或损耗6.3数据需求
性能测试所需的数据包含如下需求：a）数据的奖型和业务需求相匹配。数据量和业务需求相匹配
数据分布模型和业务需求相匹配。应通过收集历史数据，确定数据需求，进行数据需求分析时，考虑数据的使用限制和重用性.制定数据读取策略和备份策略.当进行d
性能护展性测试时.成根抛实际情况加大数抛量，6.4
业务流程
性能测试应首先考虑测试主要或重要的业务流程，不同的业务流程对系统产牛的压力不同：在业务流程选择时应基丁风险评估考虑如下因素a）资源的占用情况；
b）业务使用频率；
c）业务的重要性，
6.5用户分布模型
性能测试的用户角色分布应服从真实坏境分布，可通过用户分布模型进行描述示例：图2描述了·个用户分布模型，该模型中有角色1、2.3三个角色.其中角色1（10元）.角色2（30关）、角色（60%）分别对应测试模型中负载的20，60、120的川广数量。从图2中可以看出系统的负载大部分来立角色3.并且该负色比其他角色的性能要求更高。20
真实负载分布
测试模型
角色1
角色2
角色3
图2用户分布模型
对于不同的角色，其预期的用户数量和参与的业务是不同的，测试执行时应考虑功能种类、数量、每种功能执行的人数等。设计并发用数时，若无特定约定，宜根批在线用户数进行估算。示例：一般非高频交易的Web系统·接在线用户数的10%-20%估算并发请求数6.6请求时序分布模型
性能测试请求发送时序应符合业务需求，5
-rKaeerkca-
GB/T39788—2021
性能测试过，系列场景的执行来完成，分析用的请求模型是获取性能测试需求的有效于段，即定义系统的典型使用方式，考虑用户使用系统的典型业务、时问段和用户数量。图3给出了某个请求时序分布的示意图，描述了一天中某系统中负载随时间变化的情况。系统负载
3请求时序分布示意图
示例1:某0A系统的每犬只上8：00有200)个用户在10min内登录系统。示例2：每天查询交易的高峰是在9：0011：00和下午的14：0016：00不同的网络请求会产生不同的负载.图4和图5给出了两种典型的请求负载模式。图4描述了客户端同时发送请求，但在不同的时问到达服务器：图5描述了客户端在不同的时问发送请求，但在同一时间到达服务器
客户端
客户端
图4请求同时发出
图5请求同时到达
-rKaeerkca-
服务器
服务器
6.7网络状态需求bzxZ.net
网络状态的需求应从以下方而进行考虑：a）保证网络传输速度：如果网络传输有较人延迟，可能影响性能测试结果，GB/T 39788—2021
b）网络背景流量应尽叫能少，如果背景流量没有限制在合理的范围内，能导致应用程序和/或网络故障。
7性能测试类型
负载测试
建立模型
负载测试模型由负载量、负载业务和运行时间米描述，在指定业务负载和运行时间的条件下，测量被测业务的负载量。
负载测试模型的构建过程包括：a）确定所需测试负载的业务：
确定被测各业务的用户角色分布；h）
确定被测各业务的负载量需求：l）确定负载生成方法。
7.1.2导出测试覆盖项
对于负载测试，每项被测业务的负载量需求为个测试覆盖项，7.1.3导出测试用例
负载测试用例按以下步骤导出：a）：确定前提条件：
根据业务场景实际情况，确定待测业务的前置业务条件：确定需要同时运行的测试用例组合。2）
b）设计输人数据：
确定各操作所需的输人数据；
2）确定输人数据的来源，例如历史数据或相似系统的数据。选择用户操作：
依据用使用场景确定用广操作；1）
确定正常/峰值时问用户数；
确定用广活动随势：
确定思考时间，
d）确定预期结果：
1）确定各项业务的预期输出；
2）适用时，确定系统的监视指标（如响应时间、并发用户数、资源利用率等）：3）
确定负载测试的适过/不通过准则，例如响应时间或资源占用率人于某阅值时则视为不适过该次负载测试。
表1给出了某场景下负载测试的测试覆盖项和测试用例的示例。7
-rKaeerkAca-
GB/T39788—2021
测试川例测试微盖项
TCOVER1
TCOVER2
TCOVER3
2压力测试
建立模型
表1负载测试的测试覆盖项和测试用例示例负载场景
已注册用户登录检索；
并发数：50；
思考时间：58~8 s
预期输出
川广名密码
搜索条件
结果选择条月综号
搜索结列表
结果详情
监视指标
响虚时问<5%；
CPU占川率<40%；
内存占川率≥60%
压力测试用丁评估软件在极重负载下是否健壮、可用，指通过增加系统负载，测量系统与软件极限负载下的状态：
注：状态通带包括响应时间、并发用户数、吞吐量和资源利用率等压力测试模型的构建过程包括：a）确定压力测试的指标需求：
b）确定压力测试的关键业务场景；c）确定被测业务的用广角色分布；d）确定压力测试用例的生成方法。导出测试覆盖项
对于压力测试，每项被测业务的压力测试需求为个测试覆盖项：7.2.3导出测试用例
压力测试用例按以下步骤导出：a）确定前提条件：
1）根据实际业务场景，确定关键业务预期的最人负载：2）确定需要同时运行的测试用例组合。b）设计输入数据：
1）确定各操作所需的输入数据：2）确定输人数据的米源，例如历史数据或相似系统的数据；3）
输人数据设计时通常要考急如下内容：提供要求处理的信息量，超过预期的最大负载：数据传输能力的饱和试验，要求比设计能力传输史多的数抛：内存的写人和读出，外部设备，其他分系统及内部界面的数据传输等：存储范围（如缓冲区、表格区和数据库)超过额定人小的能力c）选择用户操作：
1）依据用使用场景确定用操作：2）确定正常/峰值时间用户数-通常采用负载递增加载和峰谷加载（高低突变加载）；3）确定用户活动趋势；
4）确定思考时间。
d）确定预期结果：
1）确定各项业务的预期输出：
-rrKaeerkAca-
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国国家标准
GB/T39788—2021
系统与软件工程
性能测试方法
System and software engineering-Performance testing method2021-03-09发布
国家市场监督管理总局
国家标准化管理委员会
2021-10-01实施
GB/T39788—2021
规范性引用义件
3术和定义
性能测试概述
5性能测试过程
6性能测试需求模型
7性能测试类型
附录A（资料性附录）性能效率的质量测度附录B（资料性附录）移动应用性能洲试案例次
附录（（资料性附录）大型信息系统性能测试应用案例附录D（资料性附录）
云应用性能测试案例
附录E（资料性附录）嵌人式软件性能测试案例-rKaeerKa-
本标准按照GB/T1.12009给出的规则起草。GB/T39788—2021
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准山全国信息技术标准化技术委员会（SAC/TC28）提出并归口本标准起草单位：上海计算机软件技术开发中心、深圳赛西信息技术有限公司、国家应用软件产品质量监督检验中心、中国电了技术标准化研究院、中国电了科技集团公司第十研究所、厦门理工学院、中国电了科技集团公司第五十四研究所、内蒙占白治区电了信总产品质量检验院、山东道普测评技术有限公司、北京轩宇信息技术有限公司、中国航大系统科学与工程研究院、中电莱斯信息系统有限公司、广东省科技基础条件平台中心、北京京航计算通讯研究所、浙江省电子信息产品检验所、西字市大数据服务管埋局、上海第二工业大学、武汉大学。本标准主要起草人：龚家瑜、李文鹏、蔡立志、张肠肠、简炜、卢俊文、孙风丽、康京山、郭澍、工风玲、张峻、李军、高猛、工建、郝璟璐、陆澄澹、胡芸、杨隽、赵毅、易晶晶、孙肖、于泉、工威、沈颖、杨玲萍、滕俊儿、许颖媚、白方芳、谢晓园、吴克寿、巩韶飞、贾素用、李丽萍、孟宪伟。-rrKaeerkca
-riKacerKAca-
1范围
系统与软件工程
性能测试方法
本标准规定了系统与软件性能测试的测试过程、测试需求模型和测试类型。本标准适用丁系统与软件性能测试的分析、设计和执行。2规范性引用文件
GB/T 39788—2021
下列文件对本文件的成用是必不可少的：凡是注期的引用文件：仅注期的版本适用干本文件。凡是不注日期的引用文件，其最新版本（包括所有的修收单)适用丁本文件。GB/T25000.102016系统与软件工程：系统与软件质量要求和评价（SQuaRE）第10部分：
系统与软件质量模型
GB/T25000.232019
系统与软件工程系统与软件质量要求和评价（SQuaRE）第23部分：系统与软件产品质量测量
G3/T3863412020系统与软件工程软件测试第「部分：概念和定义3术语和定义
GB/T38634.12020界定的以及下列术语和定义适用于本文件。3.1
负载测试loadlesting
用于评估系统与软件在预期变化负载下的性能表现，负载通常位于低谷、典型和高峰使用的预期条件之间。
注：性能效率测试的一种。
stress testing
压力测试
用于评估系统与软件在高于预期或指定容量负载需求，或低于最少需求资源的条件下的性能表现，注：性能效率测试的种。
峰值测试spikelesting
用于评估系统与软件在短时间内负载人幅度超出通觉负裁时的性能表现注：性能效率测试的一种。
扩展性测试scalabilitytesting用于评估系统与软件适应外部性能需求变化(如用广负载支持、事务数量、数据量等)的性能表现：注：性能效率测试的”-种。
voluinetesting
容积测试
用评估系统与软件在春吐量、存储容量或两者兼考息的情况下处理指定数据量（通常达到最大指-rKaeerkca-
GB/T 39788—2021
定容量或接近最大)的能力
注：性能效率测试的一种。
疲劳强度测试endurance lesting用于评估系统与软件在指定的时间段内，能够持续维持所需的负载的能力：注：性能效率测试的一种。
4性能测试概述
性能测试用丁评估待测系统与软件在给定的时问和其他资源限制下完成其指定功能的程度，也称作性能效率测试。
系统与软件性能效率质量特性和子特性见GB/T25000.10—2016中4.3.2.2.系统与软件性能效率质量测度参见附录A，质量测度的描述和测量函数见GB/T25000.232019中8.3，在使用时，应依系统和软件的实际需求对质量测度进行裁剪，移动应用性能测试案例参见附录B。大型信息系统性能测试案例参见附录C云应用性能测试案例参见附录D。嵌人式软件性能测试案例参见附录E，5性能测试过程
5.1概述
性能测试过程包括性能测试需求分析、性能测试设计和实现、性能测试执行和性能测试总结四个过程。
5.2性能测试需求分析
性能测试需求分析包括下列活动：a）确定性能测试的准人准则，在系统构架确定后或冒烟测试通过后执行，测试介入越越好，b）确定待测系统与软件的性能需求。性能需求可来自合同、需求规格说明等文档中所明示的需求，或者由业务，数据、预期的用户和系统行为约定的隐含需求，性能需求亢依据性能需求模型来确定.性能需求模型见第6章，c）识别待测系统与软件相关的其他外部应用。dl）确定性能测试完成或终止准则5.3性能测试设计和实现
性能测试设计和实现过程用于导出测试用例和测试规程，相关的活动包括：a）确定所需监测的指标、业务场景、被测业务的用角色分布。b）确定采用的性能测试类型，
依据历史运行情况或实际运行环境设计测试数据生成和读取舰则，测试数据包括为待测系统与软件准备的基谢数据，以及运行所需要的数据：数据量应与测试环境的配置相适应或与未来扩展数据量一致，在实际坏境中数据量应与实际舰模相一致：在模拟环境中亢等比对数据rKaeerkAca-
模进行调整
GB/T 39788—2021
l）确定负载生成方式，川采用工具或人上的方式加压：应根据制定的测试方案布置各测试场景，包括并发用户数、执行时长以及需要监视的性能指标等。针对所需测试的业务逻辑设计测试用例，e）
依据需求或实际运行环境确定测试用例顺序8）开发测试脚本，通过脚本对待测系统与软件的用户业务行为进行模拟，脚本的开发可采用录制、编写或定制开发等方式：完成测试脚本开发后，成进行功能验证，确保测试脚本已完成用户业务行为。
h）确定暂停和恢复准则：
1）暂停准则可包括：
系统不川用：
由于不确定原因导致服务器容机或必要服务停止运行；一届用程序在打开状态下其有阻塞程序/严重缺陷：一所需的依赖项不可用.
2）恢复准则可包括：
一系统和/或服务器可用.启动并运行；—一解决阻塞和/或关键问题；
应用程序功能已恢复：
一测试数据处理埋周期未完成时的恢复程度：5.4性能测试执行
性能测试执行过程包括下列活动：a）执行前就绪检查，对性能测试所需环境和资源迹行评估，b)［
由人工或利用测战工具执行测战脚本，并监控执行过程中的性能指标，记录测战结果性能测试通常需考繁待测系统与软件在·段时间范围内的综合表现，按需取平均估、最大估惑最小值作为测试结果：
l）若性能测试只常终止或不满足需求或预期，填写性能问题报告单，问题报告单应包括问题米源、场景配置、问题捕述、问题等级等内容。判断所执行的测试用例是否通过：如果测试不通过.分析具体情况，确定是山软件本身性能瓶e)
颈所引起的，还是由测试坏境所引起的图【给出了性能测试执行框架.该执行框架由5个组件组成：输入、运行坏境和待测系统与软件、输出、控制单元和监督单元：其中，输入、运行环境和待测系统与软件以及输出是·股软件测试的组成部分控制单元和监督单元是性能测试所特有的。输入提供了性能测试的条件，川能包括测试数据及其相美的控制机制，控制单元则为输人提供了相关信息，例如运行环境或测试执行顺序等所需的史改，运行环境包括待测系统与软件、运行支撑环境和性能测试支撑环境：控制单儿用丁决定和控制输人组件的输人。监督单元监控输出组件的时间特性和资源利用性和容量，包括测试过程的即时信息注1：择制单元可控制的信息包括并发请求，思考时问、集合点等。注2：资源利用性如处理器占用率，内存占用率等注3：时间特性如响应时间、周转时间等，注4：容量如最大并发数、最大用广数等。注5：输人如系统登录用户名密码查询关链间，输出如返回的查询结果等，3
-rKaeerkca-
GB/T39788—2021
控制单元
5.5性能测试总结
性能测试总结包括下列活动：
监督单元
时间特性
资源利用性
运行环境
待测系统
与软件
图1性能测试执行框架
控制信息
测试激据
性能指标
a）整理性能测试结果。性能测试的结果宜考虑多种环境因素下的综合结果.来用数学和统计方法进行数据综合分析考虑，如标准差、用广约定的统计模型。注1：分析数据时：直删除兄常数据，例如系统片动或关闭时捕获的数据，注2：响应时问、吞叶率和资源利用率考虑包括平均值、最小值、最大值或标准偏差注3：并发请求数宜分析最人并发请求，b）编写软件性能测试报告，内容宜包括：测试结果分析、对软件性能的评价和建议根据测试记录和性能问题报告单编写性能问题报告：性能测试事件报告宜包含问题来源、场景配置、问题描述和问题等级等内容，6性能测试需求模型
6.1概述
性能测试需求模型成考虑环境、数据业务流程，用分布，请求时序分布和网络状态等因靠，6.2环境需求
针对不同质量要求，应考虑测试坏境对性能测试的影响，推荐使用系统或软件的实际生产坏境作为性能测试环境，在进行性能测试坏境舰划和设时，魔考虑以下因素：a）稳定性：在相同条件下的多轮次测试结果应保持一致，或在可接受误差范围内；b）独立性：为避免测试结果失真.测试环境应与其他在用系统或软件保持相五.隔离；c）可控制性：测试环境中的所有设备和资源应可被监控或控制.性能测试环境考虑因索包括：
a）硬件配置：包括需使用的计算机、服务器、磁盘阵列或其他专用设备，考虑「述硬件资源的型号、数量、部署逻辑、通信和连接状态等：b）软件配置：包括需使用的操作系统、中问件、数据库、性能测试工具或其他专用软件，考虑前述rrKaeerKAca-
软件资源的版本、补丁等；
GB/T 39788—2021
网络配置：包括需使用的交换机、路由器、集线器或其他专用网络设备，考虑前述网络资源的组C
网方式、传输速率和延迟特性等当现有条件无法支撑测试环境构建时.应最大化利用现有资源进行测试环境构建，并分析测试环境和生产环境的差异性，如不同的软硬件或网络设备能带来的性能增益或损耗6.3数据需求
性能测试所需的数据包含如下需求：a）数据的奖型和业务需求相匹配。数据量和业务需求相匹配
数据分布模型和业务需求相匹配。应通过收集历史数据，确定数据需求，进行数据需求分析时，考虑数据的使用限制和重用性.制定数据读取策略和备份策略.当进行d
性能护展性测试时.成根抛实际情况加大数抛量，6.4
业务流程
性能测试应首先考虑测试主要或重要的业务流程，不同的业务流程对系统产牛的压力不同：在业务流程选择时应基丁风险评估考虑如下因素a）资源的占用情况；
b）业务使用频率；
c）业务的重要性，
6.5用户分布模型
性能测试的用户角色分布应服从真实坏境分布，可通过用户分布模型进行描述示例：图2描述了·个用户分布模型，该模型中有角色1、2.3三个角色.其中角色1（10元）.角色2（30关）、角色（60%）分别对应测试模型中负载的20，60、120的川广数量。从图2中可以看出系统的负载大部分来立角色3.并且该负色比其他角色的性能要求更高。20
真实负载分布
测试模型
角色1
角色2
角色3
图2用户分布模型
对于不同的角色，其预期的用户数量和参与的业务是不同的，测试执行时应考虑功能种类、数量、每种功能执行的人数等。设计并发用数时，若无特定约定，宜根批在线用户数进行估算。示例：一般非高频交易的Web系统·接在线用户数的10%-20%估算并发请求数6.6请求时序分布模型
性能测试请求发送时序应符合业务需求，5
-rKaeerkca-
GB/T39788—2021
性能测试过，系列场景的执行来完成，分析用的请求模型是获取性能测试需求的有效于段，即定义系统的典型使用方式，考虑用户使用系统的典型业务、时问段和用户数量。图3给出了某个请求时序分布的示意图，描述了一天中某系统中负载随时间变化的情况。系统负载
3请求时序分布示意图
示例1:某0A系统的每犬只上8：00有200)个用户在10min内登录系统。示例2：每天查询交易的高峰是在9：0011：00和下午的14：0016：00不同的网络请求会产生不同的负载.图4和图5给出了两种典型的请求负载模式。图4描述了客户端同时发送请求，但在不同的时问到达服务器：图5描述了客户端在不同的时问发送请求，但在同一时间到达服务器
客户端
客户端
图4请求同时发出
图5请求同时到达
-rKaeerkca-
服务器
服务器
6.7网络状态需求bzxZ.net
网络状态的需求应从以下方而进行考虑：a）保证网络传输速度：如果网络传输有较人延迟，可能影响性能测试结果，GB/T 39788—2021
b）网络背景流量应尽叫能少，如果背景流量没有限制在合理的范围内，能导致应用程序和/或网络故障。
7性能测试类型
负载测试
建立模型
负载测试模型由负载量、负载业务和运行时间米描述，在指定业务负载和运行时间的条件下，测量被测业务的负载量。
负载测试模型的构建过程包括：a）确定所需测试负载的业务：
确定被测各业务的用户角色分布；h）
确定被测各业务的负载量需求：l）确定负载生成方法。
7.1.2导出测试覆盖项
对于负载测试，每项被测业务的负载量需求为个测试覆盖项，7.1.3导出测试用例
负载测试用例按以下步骤导出：a）：确定前提条件：
根据业务场景实际情况，确定待测业务的前置业务条件：确定需要同时运行的测试用例组合。2）
b）设计输人数据：
确定各操作所需的输人数据；
2）确定输人数据的来源，例如历史数据或相似系统的数据。选择用户操作：
依据用使用场景确定用广操作；1）
确定正常/峰值时问用户数；
确定用广活动随势：
确定思考时间，
d）确定预期结果：
1）确定各项业务的预期输出；
2）适用时，确定系统的监视指标（如响应时间、并发用户数、资源利用率等）：3）
确定负载测试的适过/不通过准则，例如响应时间或资源占用率人于某阅值时则视为不适过该次负载测试。
表1给出了某场景下负载测试的测试覆盖项和测试用例的示例。7
-rKaeerkAca-
GB/T39788—2021
测试川例测试微盖项
TCOVER1
TCOVER2
TCOVER3
2压力测试
建立模型
表1负载测试的测试覆盖项和测试用例示例负载场景
已注册用户登录检索；
并发数：50；
思考时间：58~8 s
预期输出
川广名密码
搜索条件
结果选择条月综号
搜索结列表
结果详情
监视指标
响虚时问<5%；
CPU占川率<40%；
内存占川率≥60%
压力测试用丁评估软件在极重负载下是否健壮、可用，指通过增加系统负载，测量系统与软件极限负载下的状态：
注：状态通带包括响应时间、并发用户数、吞吐量和资源利用率等压力测试模型的构建过程包括：a）确定压力测试的指标需求：
b）确定压力测试的关键业务场景；c）确定被测业务的用广角色分布；d）确定压力测试用例的生成方法。导出测试覆盖项
对于压力测试，每项被测业务的压力测试需求为个测试覆盖项：7.2.3导出测试用例
压力测试用例按以下步骤导出：a）确定前提条件：
1）根据实际业务场景，确定关键业务预期的最人负载：2）确定需要同时运行的测试用例组合。b）设计输入数据：
1）确定各操作所需的输入数据：2）确定输人数据的米源，例如历史数据或相似系统的数据；3）
输人数据设计时通常要考急如下内容：提供要求处理的信息量，超过预期的最大负载：数据传输能力的饱和试验，要求比设计能力传输史多的数抛：内存的写人和读出，外部设备，其他分系统及内部界面的数据传输等：存储范围（如缓冲区、表格区和数据库)超过额定人小的能力c）选择用户操作：
1）依据用使用场景确定用操作：2）确定正常/峰值时间用户数-通常采用负载递增加载和峰谷加载（高低突变加载）；3）确定用户活动趋势；
4）确定思考时间。
d）确定预期结果：
1）确定各项业务的预期输出：
-rrKaeerkAca-
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。