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

  • GB/T 39788-2021  系统与软件工程 性能测试方法.pdf为pdf格式
  • 文件大小:24.9 M
  • 下载速度:极速
  • 文件评级
  • 更新时间:2021-04-18
  • 发 布 人: 13648167612
  • 文档部分内容预览:
  • 负载测试模型由负载量、负载业务和运行时间 来描述。在指定业务负载和运行时间的条件下,测量 被测业务的负载量。 负载测试模型的构建过程包括: a 确定所需测试负载的业务; b) 确定被测各业务的用户角色分布; 确定被测各业务的负载量需求; d)确定负载生成方法

    7.1.2导出测试覆盖项

    7.1.3导出测试用例

    负载测试用例按以下步骤导出: a)确定前提条件: 1) 根据业务场景实际情况,确定待测业务的前置业务条件; 2)确定需要同时运行的测试用例组合。 b) 设计输人数据: 1)石 确定各操作所需的输入数据; 2)确定输人数据的来源,例如历史数据或相似系统的数据。 选择用户操作: 1) 依据用户使用场景确定用户操作; 2) 确定正常/峰值时间用户数: 3) 确定用户活动趋势; 确定思考时间。 d) 确定预期结果: 1) 确定各项业务的预期输出; 2)适用时,确定系统的监视指标(如响应时间、并发用户数、资源利用率等); 确定负载测试的通过/不通过准则服务质量标准,例如响应时间或资源占用率天于某國值时则视为不通 过该次负载测试。 表1给出了某场景下负载测试的测试覆盖项和测试用例的示例

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

    压力测试用于评估软件在极重负载下是否健壮、可用 限负载下的状态, 注:状态通常包括响应时间、并发用户数、吞吐量和资源利用率等。 压力测试模型的构建过程包括: a)确定压力测试的指标需求; b) 确定压力测试的关键业务场景; 确定被测业务的用户角色分布; d)确定压力测试用例的生成方法

    7.2.2导出测试覆盖项

    力测试,每项被测业务的压力测试需求为一个测

    7.2.3导出测试用例

    压力测试用例按以下步骤导出: a)确定前提条件: 1)根据实际业务场景,确定关键业务预期的最大负载; 2)确定需要同时运行的测试用例组合。 b)设计输人数据: 1)确定各操作所需的输入数据; 2)确定输人数据的来源,例如历史数据或相似系统的数据; 3转 输入数据设计时通常要考虑如下内容: 提供要求处理的信息量,超过预期的最大负载; 数据传输能力的饱和试验,要求比设计能力传输更多的数据:内存的写入和读出,外 部设备,其他分系统及内部界面的数据传输等; 存储范围(如缓冲区、表格区和数据库)超过额定大小的能力, c)选择用户操作: 1) 依据用户使用场景确定用户操作; 2)确定正常/峰值时间用户数,通常采用负载递增加载和峰谷加载(高低突变加载); 3) 确定用户活动趋势; 4)确定思考时间。 d) 确定预期结果: 1)确定各项业务的预期输出;

    GB/T397882021

    2)适用时,确定系统的监视指标(如响应时间、并发用户数、资源利用率等); 3)确定系统与软件在极限状态下(超出预期峰值或者可用资源少于最低要求时)的性能。 表2给出了某业务场景下压力测试的示例。负载是采用递增加载方式,当负载(用户数)达到100 时,系统响应时间增加过快,但在运行范围内;当负载(用户数)达到150时系统存在异常。由表中数据 可知,该系统的性能瓶颈是由数据库查询时间导致

    表2压力测试用例示例

    峰值测试模型由峰值负载业务、峰值负载量强度、峰值持续时间和监视指标来描述。对于指定的负 载业务,当负载业务瞬间峰值(超过系统所能正常承载的强度)来临时,系统将降级运行;当负载业务负 载逐渐降低至正常水平,检查系统是否能恢复正常运行。 峰值测试模型的构建过程包括: a)确定所需测试负载的业务; b 确定被测各业务的用户角色分布; 确定对应的监视指标; d) 确定被测各业务的峰值负载量强度、峰值持续时间、负载恢复至正常的下降步长/时间; e)确定被测各业务负载生成方法。 峰值测试模型中的负载量强度设计可与压力测试结合确定,由压力测试中所测量得出的软件崩溃 的极限负载量,如系统的响应时间、并发用户数、吞吐量、资源利用率等,作为当前峰值测试的峰值负载 量强度

    7.3.2导出测试覆盖项

    ,每项被测业务的峰值负载强度计划测试值为一

    7.3.3导出测试用例

    峰值测试用例按以下步骤导出: a) 确定前提条件: 1)根据业务场景实际情况,确定待测业务的前置业务条件; 2)确定需要同时运行的测试用例组合。 b) 设计输入数据: 1)确定各操作所需的输入数据; 2)确定输人数据的来源,例如历史数据或相似系统的数据。 选择用户操作:

    7.4.2导出测试覆盖项

    7.4.3导出测试用例

    GB/T397882021

    测试,每项被测试业务的可扩展性测试需求为一

    可扩展性测试用例按以下步骤导出: a)确定前提条件: 1) 根据业务场景实际情况,确定可扩展性测试业务的前置业务条件; 2) 根据可扩展性测试需求,确定基准测试、可扩展性测试环境条件,如被测试系统服务器数 量的扩展,服务器内存的扩展等; 3)确定需要进行性能扩展比较的测试用例组合。 b)设计输人数据: 1)确定可扩展性测试各操作所需的输人数据,宜保证基准测试与可扩展性测试的输人数抗 一致; 2 确定可扩展性测试输入数据的来源,例如历史数据或相似系统的数据,宜与基准测试所但 用的数据来源相同,并在基准测试数据基础上进行扩展; 3) 可扩展性测试输人数据设计时需要考虑以下内容: 一与基准测试相比较的业务数据扩展内容,如用户数据量、订单数据量等; 与基准测试相比较的业务数据扩展方式,如通过数据库语句进行数据批量生成等; 与基准测试相比较的业务数据扩展比例,如基准测试业务数据的整数倍。 选择用户操作: 1) 依据基准测试用户使用场景确定可扩展性测试用户操作; 2)确定业务、环境资源等扩展后的用户数; 3)确定用户活动趋势; 4)确定思考时间。 确定性能指标及监控方式: 1 依据基准测试场景中的性能指标,确定可扩展性测试对应性能指标,如响应时间、内存中 用率等; 2) 确定测试需求、测试环境扩展后的性能指标的监控方式,如响应时间、硬件资源等性能打 标的监控方式。 e 确定具体扩展场景及执行顺序: 1 依据基准测试场景中的性能场景,确定可扩展性测试对应场景; 注:单一场景主要是指针对某一项资源单独扩展情况下(如计算资源、存储资源、网络资源、数据资 等)测试场景的设计;混合场景主要是指针对某几项资源共同扩展情况下测试场景的设计。 2 依据可扩展性测试需求或扩展环境,确定每个测试场景对应的测试用例执行顺序或逻辑 关系,以及测试场景启动或停止的条件。 f)确定预期结果: 1)确定各项业务的预期输出; 2)适用时,确定系统的监视指标(如响应时间、并发用户数、资源利用率等); 3) 确定可扩展性测试的通过/不通过准则,例如在业务、环境资源等扩展后的响应时间或费 源占用率大于某阅值时则视为不通过该次可扩展性测试。

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

    疲劳强度测试模型由用户规模、负载分布和执行时间来描述。疲劳强度测试通常和被测软件的可 靠性能力相关,在指定用户规模、负载分布和执行时间情况下,验证被测软件的持续稳定运行能力或软 件失效后的恢复能力的饱和性试验。 疲劳强度测试模型的构建过程包括: a)确定满足性能指标(时间特性、资源特性等)要求的用户规模; b) 构建被测软件的混合业务模型; 确定测试执行时间; d) 确定场景中其他要素(思考时间、集合策略等)

    7.5.2导出测试覆盖项

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

    7.5.3导出测试用例

    疲劳强度测试用例按以下步骤导出: 明确用户规模: 1)选择满足软件性能指标要求的最大用户数作为疲劳强度测试的用户规模数; 2)明确各业务相关用户的群体分布、行为趋势和交互模式。 b) 构建业务模型: 1)选择性能关键程度高的业务模块组成多组混合业务模型; 2)根据业务场景实际情况,确定各组混合业务模型的业务处理比例; 3)确定各组混合业务模型中业务的执行顺序和前置条件。 C 确定执行时间: 宜根据软件生产环境运行情况或根据对软件的扩展性评估进行估算。 注:通常选择24h、3×24h或7×24h执行

    GB/T397882021

    d)设计数据模型: 1)明确数据使用要求,如数据文件大小限制或重用性限制等; 2)确定各业务所需的数据类型和数据量; 3)构建数据模型,涵盖输人参数数据和背景业务数据等; 4) 制定数据备份和恢复策略等。 明确测试时机: 1) 软件已完成功能和性能测试,进入试运行阶段时; 2 软件运行一定时间后,出现性能能力降级时; 3) 为提高软件性能水平,进行硬件升级或系统扩展时。 f 确定预期结果: 1) 确定各项业务的预期输出; 2)适用时,确定系统的监视指标(如响应时间、并发用户数、资源利用率等); 3 确定疲劳强度测试的通过/不通过准则,例如响应时间或资源占用率超过预期或被测试软 件无法继续提供正常服务等则视为不通过该次疲劳强度测试。 表5给出了某场景下疲劳强度测试的测试覆盖项和测试用例的示例

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

    容积测试模型由吞吐量和存储容量来描述。在指定数据量(通常达到最大指定容积或接近最值 的条件下,测量待测系统与软件的容积。容积测试的目的是评估测试项在处理指定数量的数据时的性 能,为系统扩容、性能优化提供参考。 容积测试模型宜按照以下步骤构建: a)确定所需测试指定的数据量;

    b)确定待测系统与软件的用户操作; c)确定待测系统与软件的容积需求; d)确定容积检验方法。

    7.6.2导出测试覆盖项

    7.6.3导出测试用例

    容积测试用例按以下步骤导出: a 确定前提条件: 根据业务场景实际情况,确定待测业务的前置业务条件。 b) 设计输人数据: 确定输人数据的来源,例如历史数据或相似系统的数据。 对系统进行监控: 1)加载大容量的数据; 2) 依据用户使用场景确定用户操作; 3)确定正常/峰值时间用户数; 4)对CPU/内存/磁盘/响应时间/事务成功率等指标进行监控。 d)确定预期结果: 1)确定各项业务的预期输出; 2)适用时,确定系统的监视指标(如响应时间、并发用户数、资源利用率等); 3) 确定容积测试的通过/不通过准则,例如只要限定的某项资源达到最大使用状态或某项指 标超出可接受值,则视为不通过该次容积测试。 表6给出了某场景下容积测试的测试覆盖项和测试用例的示例

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

    GB/T397882021

    附录A (资料性附录) 性能效率的质量测度

    待测系统与软件为移动应用软件,主要功能为在线发送消息,分为两部分:一为移动应用终端,运 境为Android平台:Android版本需大于5.O:二为服务器端应用,负责消息的存取功能 该系统包含如下两种角色: a)普通用户; b)系统管理员。 主要功能如下: a)系统登录:所有用户均可进行此操作; b 发布消息:普通用户可以创建消息并保存或者发布消息; C 审核消息:系统管理员可以审核用户发布的消息,可以通过审核或者取消发布

    客户端性能需求如下: a)空闲状态下,软件运行时内存消耗最大不超过200MB,且在软件退出时应当自行清理内存 安装目标应用软件前后待机功耗无明显差异: 应用后台连续运行2h的流量值不超过20MB,如大于20MB应给出提示。 服务器端性能需求如下: a)审核功能应能具备10个并发用户操作; b) 发布消息功能应能具备100个并发用户操作; 满足上述容量的前提下响应时间不超过2S。

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

    表B.1客户端测试用件

    附录C (资料性附录) 大型信息系统性能测试应用案例

    待测系统与软件为大型信息系统中的关联查询模块,主要功能为根据关键词检索信息,分为两部 分:一为网页客户端,运行在Windows7平台;二为服务器端,运行在WindowsServer2008平台,负责 通过主题向数据库搜索并获取结果,返回给客户端。 该软件模块主要功能如下: a)根据关键词检索相关信息; b)点击查询结果进入并加载详情页面。

    客户端性能需求如下: a)前台页面检索可以正常显示搜索结果; b)打开一个目标的详情页,页面展示正常。 服务器端性能需求如下: a)搜索功能,能够支持150个用户并发操作,检索响应时间不超过5s; b)访问页面信息功能,能够支持150个用户并发操作,页面打开响应时间不超过5s

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

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

    个并发用户查看人员详情服务器响应时间统计结

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

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

    在压力测试期间, 20M,内存消耗正常:而应用服务器的CP0

    GB/T397882021

    待测系统与软件为基于云的购票应用,提供在线购票和在线支付等功能,主要功能如下: a) 系统登录:所有用户均可进行此操作; b)在线购票:所有用户均可以在线购票并提交订单; c)在线支付:所有用户均可以对已提交的订单进行支付操作。 待测系统与软件的用户群体主要为全国各地的购票人员,在购票时可能存在并发压力,因此待测系 统与软件设计时重点考虑两点:一是个人信息保护,二是需要强大的计算资源支持子系统业务,待测系 统与软件的特点如下: a 系统分布式部署于云平台上,系统架构分为四部分,即接人层、Web层、应用层和数据层; b 采用虚拟化机制实现,包含2组运行数据库,每组均包括售票节点、支付节点; 待测系统与软件只将部分流程的环节交由云服务供应商提供服务,系统全流程未采用按需扩 容的托管模式; d 为了保证用户的数据安全,采用混合云架构,即融合公有云和私有云,系统将敏感数据存放于 私有云的数据中心,同时获得公有云的计算资源.将业务子系统部署于公有云

    待测系统与软件的用户群体分布于全国各地,汉 创试时需模拟不同地域、不同网络环境和服务器环境 发起请求,更真实的模拟系统上线后的使用需求,同时监控云服务集群中应用服务器集群、数据库服务 器集群等网络资源、服务器资源的资源利用性。性能测试需求如下: a)在线购票应满足1000个并发用户操作: b)在线支付应满足1000个并发用户操作;

    根据性能需求,测试环境准备的要求如下: 模拟全国各地用户访问待测系统与软件不同节点的实际需求; b) 配置不同的网络环境和服务器环境; 配置云测试环境,根据给定数据量,测试关键业务的响应时间。 本次测试所使用的云性能测试工具,提供脚本录制、场景设置、压力测试、资源监控和报表统计等功 能,为真实的模拟实际应用环境,测试工具分别部署在华北、华东、华南、香港等多个区域的云服务平台 上,通过分布在全国各地的云性能测试工具,可模拟全国各地用户访问待测系统与软件不同节点的实际 需求,云性能测试基础技术架构见图D.1。

    GB/T397882021

    表E.8FLASH余量测试用例

    E.3.7I/0总线传输平均占用率

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

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

    E.4.1平均启动时间

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

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

    E.4.2平均响应时间

    了启动自检转发时间结果示例,表E.12给出了数

    11启动自检转发时间络

    GB/T397882021

    测试结论:被测软件启动自检转发时间最大值为99ms,平均值为97ms,满足要求。

    表E.12数据重传时间结果示例

    测试结论:被测软件重传时间约为495ms~503ms.满足要求。

    测试结论:被测软件重传时间约为495ms~503ms.满足要求。

    E.4.3响应时间的充分性

    表E.13给出了周期自检发送时间结果示例

    石化标准表E.13周期自检发送时间结果示例

    论:被测软件周期自检测指令发送时间约为2.99

    E.4.4数据精度处理

    表E.14给出了数据精度处理结果示例

    表E14数据精度处理结果示例

    E.4.5处理器平均占用率

    表E.15给出了处理器平均占用率结果示例

    园林造价表E.15处理器平均占用率结果示例

    ....
  • 相关专题: 系统  

相关下载

常用软件