(转)干货|一次完整的性能测试,测试人员需要做什么?

一、规范性能测试实施流程的意义

规范的性能测试实施流程能够加强测试工作流程控制,明确性能测试各阶段应完成的工作,指导测试人员正确、有序的开展性能测试工作,提高各角色在性能能测试中的工作效率。本次分享的性能测试实施流程是性能测试开展的”指导方针”,结合《性能测试入门——LoadRunner使用初探》内容,您就可以早日成为性能测试”达人”。

二、性能测试实施流程

性能测试流程分为五个阶段,分别是【需求调研阶段】→【测试准备阶段】→【测试执行阶段】→【测试报告阶段】→【测试总结阶段】。


每个阶段做什么事情?重点关注什么?

1.需求调研阶段

1.1.阶段概述

调研阶段的主要工作为:组建工作小组、项目创建、需求分析、模型构建、定制性能测试详细实施计划。
重点关注:需求调研、需要分析、模型构建

1.2.关键点描述

需求调研分为两个步骤进行:需求调研、需求分析。
该工作是性能测试必须的工作环节。工作产出文件为《XX项目性能测试需求表》,如:《云智慧_XXX系统_XXX模块性能测试需求表》。
此阶段模型构建主要是业务模型构建。

1.2.1需求调研

需求调研工作由性能测试实施人员牵头负责,产品经理、开发工程师、运维工程师配合完成;
需求调研的主要内容为:
系统线上环境的性能需求,例如性能需求、可靠性需求、可维护性需求等;
与系统性能需求相关的其它信息,包括系统信息(如线上环境硬件、参数配置、系统架构与部署方式、关联系统部署等)、业务信息(关键业务逻辑与处理流程、交易列表、交易量信息、业务分布规律等)、生产问题、文档资料等方面,并对收集到的信息进行汇总整理,实现对待测系统业务与技术的整体了解;
开发项目组、需求部门、运维部门等测试任务提出方应填写《云智慧_XXX系统_XXX模块性能测试需求表》中的“任务信息”和“测试背景”等信息,提出的测试需求,简单文字不能说明的,可附加文件;
性能测试小组的实施人员将调研获取的其它内容填入《云智慧_XXX系统_XXX模块性能测试需求表》;
对于新立项系统或系统新开发版本,《云智慧_XXX系统_XXX模块性能测试需求表》应与《需求规格说明书》中的性能需求相一致。

1.2.2需求分析

需求分析的基本流程是:
首先,由性能测试工程师根据需求调研所获取的信息进行分析,将《云智慧_XXX系统_XXX模块性能测试需求表》中的性能需求转换为具体的性能需求指标值;
其次,根据测试环境与线上环境的差异分析,由性能测试工程师将线上环境条件下的性能需求指标值转换为本次测试环境条件下的性能需求指标值;

例如:TPS(Transaction per Second):系统每秒处理交易数,推导过程如下,
当前线上APP1.0试用系统主要为查询类交易,交易占比40%,系统生产交易量统计为1个月约20W笔,假设APP2.0系统上线后业务量激增到每日查询类20W,则每日总交易量T达到:
T = 20W/40%=500000笔/日
系统处理能力TPS推导:APP2.0上线后交易量最大500000笔/日,系统晚间几乎无交易量,按2:8原则推算,则(50000080%)/(820%3600)=69.4笔/秒,取整为70笔/秒,每年按业务量增长50%计算,则一年后系统处理能力指标约等于70+7050%=105笔/秒。
稳定性交易量推导: 取系统处理能力的60%时长=105笔/秒60%83600=1814400笔。

经过分析后汇总成测试指标值

需求分析其主要内容和规范性要求如下:
性能测试需求:应准确描述性能测试指标项及需求指标值。
系统范围:应准确描述性能测试需求指标值所依托的测试范围信息,如应描述测试范围的关联系统逻辑示意图,及各关联系统的信息;在对系统局部环节进行测试时,也需阐明具体测试范围,详细描述被测系统的相关子系统。
环境差异分析:应准确描述性能测试需求指标值所依托的测试环境信息,如须描述测试环境的总体网络拓扑结构图、测试环境机器配置表(数量、型号、资源、操作系统)、以及相应的软件配置、重要参数配置等。同时应准确描述线上环境的上述信息,并进行详细的环境差异性分析。
以上分析内容将作为性能测试方案的重要组成部分。

1.2.3模型构建例如:业务模型

根据200X年XX月XX日~200X年XX月XX日期间的业务高峰日200X年XX月XX日的业务量统计,经过略微调整得出以下业务模型,要求业务模型交易至少占线上交易量的90%以上:

2.测试准备阶段

2.1阶段概述

测试准备阶段是性能测试工作中重要阶段。在准备阶段,需要完成业务模型到测试模型的构建、性能测试实施方案编写、测试环境的准备、性能测试案例设计、性能测试监控方案设计、性能测试脚本,及相关测试数据的准备,并在上述相关准备活动结束后按照测试计划进行准入检查。
重点关注:测试模型构建、方案设计、案例设计、数据准备等

2.2关键点描述
2.2.1测试模型构建

测试模型构建工作由性能测试实施人员完成;
在需求分析的基础上,对调研收集到的相关资料与信息进行分析梳理,重点分析跨系统的交易路径、交易关联关系、数据的处理与流转、业务量、交易比例、典型交易,以及系统的处理能力等性能测试点,针对性地确定多个业务场景,并为每个场景选择一套具体的业务交易集,按照业务量比例构建相应的测试模型。
本阶段的产出物为,各个测试场景,以及场景中典型交易及所占比率。
例如:从业务模型到测试模型推导
依据业务模型,通过与项目组及产品经理沟通,确定本次测试模型还需着重考虑以下内容:
(1)考虑到后期证券系统数据库升级,历史查询可能会影响,所以本次测试单独增加一个场景:历史委托和历史成交查询各50%(即0456和0457)。同时,考虑到线上环境绝大部分该交易是由总中心前置发起,所以本次测试“历史委托和历史成交查询”交易均采用从总中心发起;
(2)增加国债发行交易场景,国债发行认购日一般在柜台营业前进行,此场景只选择国债发行认购一支交易;
(3)同时,证券系统交易高峰时段柜员签到、柜员签退交易占比较小。
通过以上分析得出本次测试模型有3个:一般交易日日间模型、国债发行日模型、以及历史查询交易模型。
一般交易日日间模型:

储蓄国债交易模型:

历史查询交易模型:

2.2.2方案设计

性能测试实施方案编制是性能测试工作中必须的工作环节,其产出为《性能测试方案》,如:《云智慧XXX项目_XXX功能模块性能能测试方案V1.0.xlsb》。
在方案中需要描述:测试需求、启停准则、测试模型设计、测试策略、测试内容、测试环境与工具需求,以及各个阶段的输出文档。在方案中还需说明性能测试工作的时间计划安排、预期的风险与风险规避方法等。测试模型设计内容来自本阶段测试模型设计中形成的测试场景,以及场景中典型交易及所占比率。

2.2.3案例设计

在案例设计中,包括案例的描述、测试环境描述(硬件、软件、应用版本、测试数据)、延迟设置、压力场景、执行描述、预期结果、监控要点。
案例设计是性能测试工作的必须工作环节,案例设计的产出文件是《性能测试案例》。

2.2.4数据准备

环境准备工作中涉及到基础数据的准备。测试数据的数量、逻辑关系要求十分严格,测试基础数据的准备一般采用自造模拟数据或者使用脱敏后的线上数据。

2.2.5测试脚本开发

测试脚本开发工作就是发挥LR的时候。
测试脚本是对业务操作的程序化体现,一个脚本一般为一项业务的过程描述。本活动主要为脚本的录制(编写)、修改和调试工作,从而保证在测试实施之前每个测试用例的脚本都能够在单笔和少量迭代次数的条件下能够正确执行。测试脚本开发的一般步骤如下:
通过录制,或者编写,完成脚本代码生成。代码生成时,主要根据需求插入事务,作为测试过程中统计交易响应时间的单位;
根据测试需求,进行参数化设置;
设定检查点,根据报文内容字段判断交易是否正确执行,即检查点的设置在应用层面;
根据测试要求确定是否设置集合点;

3.测试执行阶段

3.1阶段概述

测试执行阶段是执行测试案例,获得系统处理能力指标数据,发现性能测试缺陷的阶段。测试执行期间,借助测试工具执行测试场景或测试脚本,同时配合各类监控工具。执行结束后统一收集各种结果数据进行分析。根据需要,执行阶段可进行系统的调优和回归测试。
重点关注:结果记录、测试监控、结果分析

3.2关键点描述
3.2.1测试执行与结果记录

测试执行过程有相应的优先级策略,依据测试案例的优先级别,优先执行级别较高的测试案例。测试过程中,通过对每个测试结果的分析来决定是重复执行当前案例还是执行新的测试案例;通常发现瓶颈问题会立即进行调整并重新执行测试用例,直到当前的案例通过。
在执行阶段,测试的执行、分析调优、回归测试工作较为反复,须认真记录全部执行过程和执行结果,执行结果数据是分析瓶颈的主要依据。

3.2.2测试监控

测试的监控工作与执行工作同步进行,场景或脚本开始执行时,同时启动监控程序(可以用nmon或者系统命令top/vmstat/iostat 等),当然也可以用云智慧的监控宝和透视宝协同工作,监控宝可以监控网站/网页性能/Ping/DNS/FTP/UDP/TCP/SMTP等IT基础设施的性能指标,透视宝可以发现主机资源、Web应用、浏览器、APP等应用的性能瓶颈,如下图所示:

监控宝监控页面

透视宝主机资源监控页面

在执行结束后,停止测试监控,并提取监控结果数据。

3.2.3测试结果分析

测试过程中根据前端性能测试工具显示结果、监控结果综合分析出现的测试问题。
例如:
测试组在执行“一般日日间交易模型”负载测试570TPS压力时,数据库监控发现有死锁想象,具体如下:

问题分析:经与开发一同分析,原因如下:流控信息收集程序(pltflowGthDaemon)在同一柜员、在毫秒级并发做交易时plt_flowgather表出现死锁。测试环境联机交易使用同一个柜员号发起,因此出现概率较高。

4.测试报告阶段

4.1阶段概述

测试执行工作结束后开始撰写性能测试报告。性能测试报告在发布前需要进行评审。

4.2关键点描述
4.2.1报告撰写

性能测试报告要内容包括:测试目的、范围及方法、环境描述、测试结果描述、结果分析、结论和建议等。

4.2.2测试结果描述

测试结果的描述,应体现性能测试的执行过程,如:混合场景的容量测试结果展示中,需要描述各个并发梯度下测试结果及监控结果;在数字形式的结果记录中,要求小数点后精确3位有效数字。

4.2.3测试缺陷与问题

在性能测试分析报告中须描述测试过程发现的缺陷与问题,对于确认是测试缺陷的项进行风险评估,并给出风险提示。

4.2.4最终结果分析

测试最终结果的分析,该部分内容应该全面、透彻、易理解且通过图表方式表达更直观。
例如:

4.2.5测试结论

测试结论是性能测试分析报告必须包括的内容。测试的结论须清晰、准确回答性能测试需求中描述的各项指标,需全面覆盖测试需求。

5.测试总结阶段

5.1阶段概述

性能测试的总结工作,主要对该任务的测试过程和测试技术进行总结。性能测试工作进入总结阶段,也意味着性能测试工作临近结束。在这个阶段,时间允许的情况下应将所有的重要测试资产进行归档保存。

出处:https://golangtc.com/t/585cd776b09ecc2e18000081

转载于:https://www.cnblogs.com/dayiran1222/p/8724695.html

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
某网站性能测试用例 某网站提供会员模板下载、上传、购买、支付等功能,目前进入性能测试阶段,通过性能需求可以了解到主要有以下几个性能指标需要进行测试:   ● 产品页面刷新性能   ● 产品上传性能   ● 产品下载性能   目前给出的指标为:   延迟:   测试项 响应时间 抖动 备注   产品页面刷新 <5秒 <2秒   产品下载相应时间 <4秒 <2秒   吞吐量:   编号 项 吞吐量   Perf.T.1 所有登录用户在线状态更改频率 每10分钟1次   Perf.T.2 每日页面平均访问量 60000次   Perf.T.3 每日下载量 50000   Perf.T.4 平均每日新增会员数量 500   Perf.T.5 高峰同一模板下载量 100用户并发下载   Perf.T.6 高峰不同模板下载量 150用户并发下载   容量:   编号 项 容量   Perf.C.1 用户数 <=100万   Perf.C.2 活动用户数 10000   Perf.C.3 模板中心总用户数 <=25万   根据如上性能需求及数据我们该如何设计性能测试用例及场景呢?(可以说给出的性能需求很垃圾,没有丝毫价值,但没办法还是点啊)   首先,我不去在乎它要求的性能是什么,我只需要在一定的测试环境下对系统进行压力测试,找到各个性能指标的临界点就好了,至于是否达到性能指标,在和性能需求对照编写测试报告即可。   所以,针对这几个需要进行性能测试的页面,我们一下分析,如何设计场景才能尽可能准确地体现出系统的性能:   先说一下搜索页面   搜索页面根据对项目的了解,搜索后,将所有符合条件的结果遍历出来,显示在前台,每页的显示数量是一定的,超出的部分分页显示。根据上面的描述我们可以看出搜索结果是在将符合条件的所有结果集均发送到前台页面,对于页面显示对性能的消耗我们可以忽略不计,主要的压力来自数据的传输、sql的执行及应用服务器的处理过程,所以我可以从两个方面设计场景:   a、虚拟用户一定,不同数据库数量级的情况下,搜索的性能   如何确定虚拟用户的数量成为一个关键,我们可以让客户提供一个常规情况下每天访问用户数(如果没有实际数据可参考,可以根据产品方案中期望的用户数来代替),我们就用这个用户数来进行测试;再来分析一下不同的数据库数量级,如果系统运营1年的产品数据量是5万条,那么我们就根据这个值分别取1W条、3W 条、5W条、10W条、20W条数据量来进行测试(具体的分法可以根据实际情况而定),所以对于这个测试目标,我们可以设计5个场景进行:   虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间   100 10000 搜索页面 随机产生 30分钟 加入思考时间   100 30000 搜索页面 随机产生 30分钟 加入思考时间   100 50000 搜索页面 随机产生 30分钟 加入思考时间   100 100000 搜索页面 随机产生 30分钟 加入思考时间   100 200000 搜索页面 随机产生 30分钟 加入思考时间   b、一定数据库数量级,不同量虚拟用户的情况下,搜索的性能   我们定下来一个常规的数据库数据量,在数据量不变的情况下逐步增加虚拟用户数,测试一下不同虚拟用户压力下系统的性能   虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间   50 50000 搜索页面 随机产生 30分钟 加入思考时间   80 50000 搜索页面 随机产生 30分钟 加入思考时间   100 50000 搜索页面 随机产生 30分钟 加入思考时间   120 50000 搜索页面 随机产生 30分钟 加入思考时间   150 50000 搜索页面 随机产生 30分钟 加入思考时间   产品上传   影响上传性能的主要因素有上传文件的大小和上传的请求数,所以我们就从这两个方面设计用例。   a、虚拟用户数一定,上传不同大小的文件   虚拟用户数 上传文件大小 录制页面 并发用户数 执行时间 思考时间   50 100k 上传页面 随机产生 30分钟 取消思考时间   50 300k 上传页面 随机产生 30分钟 取消思考时间   50 500k 上传页面 随机产生 30分钟 取消思考时间   50 800k 上传页面 随机产生 30分钟 取消思考时间   50 1M 上传页面 随机产生 30分钟 取消思考时间   b、上传文件大小一定,不同量的虚拟用户   虚拟用户数 上传文件大小 录制页面 并发用户数执行时间思考时间   20 300k 上传页面 随机产生 30分钟 取消思考时间   50 300k 上传页面 随机产生 30分钟 取消思考时间   80 300k 上传页面 随机产生 30分钟 取消思考时间   100 300k 上传页面 随机产生 30分钟 取消思考时间   产品下载   影响下载性能的主要因素有下载文件的大小和下载的请求数,所以我们就从这两个方面设计用例   a、虚拟用户数一定,下载不同大小的文件   虚拟用户数 下载文件大小 录制页面 并发用户数执行时间思考时间   50 100k 下载页面 随机产生 30分钟 取消思考时间   50 300k 下载页面 随机产生 30分钟 取消思考时间   50 500k 下载页面 随机产生 30分钟 取消思考时间   50 800k 下载页面 随机产生 30分钟 取消思考时间   50 1M 下载页面 随机产生 30分钟 取消思考时间   b、下载文件大小一定,不同量的虚拟用户   虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间   20 300k 下载页面 随机产生 30分钟 取消思考时间   50 300k 下载页面 随机产生 30分钟 取消思考时间   80 300k 下载页面 随机产生 30分钟 取消思考时间   100 300k 下载页面 随机产生 30分钟 取消思考时间

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值