压力测试的测试方法
2024-05-17 02:30
1. 压力测试的测试方法
进行压力测试的方法，大致可归纳为两大类： （1）敏感度分析（sensitiveanalysis）此方法是利用某一特定风险因子或一组风险因子，将因子在执行者所认定的极端变动的范围内变动，分析其对于资产组合的影响效果。这一分析方法的优点在于容易了解风险因子在可能的极端变动中，每一变动对于资产组合的总影响效果及边际效果，缺点则是执行者对于每一逐渐变动所取的幅度及范围必须十分恰当，否则将会影响分析的结果与判断，特别是对于非线性报酬率的资产组合，这种情况将更为显著。（2）情景分析（scenarioanalysis）即一组风险因子定义为某种情景，分析在个别情景下的压力损失，因此此类方法称为情景分析。情景分析的事件设计方法有两种：历史情景分析和假设性情景分析。① 历史情景分析（Historicalscenario）：利用某一种过去市场曾经发生的剧烈变动，评估其对现在的资产组合会产生什么影响。例如考虑1987年美国股市崩盘，计算当时的历史变动幅度，并依此基础分析评估对资产组合的影响。BCGFS（2001）的研究显示，1998年俄罗斯政府违约事件，是金融机构用来在信用风险压力测试上使用的压力事件，其他如中南美洲比索风暴、东南亚金融风暴亦是很重要的压力事件。这种方法的优点是具有客观性，利用历史事件及其实际风险因子波动情形，在建立结构化的风险值计算上较有说服力，且风险因子间的相关变化情形也可以依历史数据作为依据，使模型假设性的情形降低许多。此外，这种模型较直觉，重大历史事件的深刻印象将使风险值与历史事件紧密结合，管理者在设定风险限额时，便可依历史事件的意义来进行评估，使决策更具说服力。 但这种方法的缺点在于现今金融市场变动非常迅速，许多金融商品不断创新，因此历史事件无法涵盖此类商品，且某些商品的历史价格未出现极端情况，亦无法利用此方法进行衡量。虽然过去发生过的情景未来不一定会再发生，但使用历史情景分析方法来对资产进行风险管理，至少可保证过去的压力事件，在事前预防下，未来不会重演。② 假设性情景分析：仅以历史情景分析进行压力测试有其限制，参考历史事件并另建立对于每个风险因子可能产生的极端事件，将使得压力测试更具完整性，这就是假设性情景分析。这种分析方法银行可自行设计可能的各种价格、波动及相关系数等的情景，这些汁算的设定主要来自经验及主观。
2. 如何测试压力呢？
3. 软件如何进行压力测试?
在最近的一次测试中定义了测试的目的是：需要了解AUT（被测应用程序）一般能够承受的压力，同时能够承受的用户访问量（容量），最多支持有多少用户同时访问某个功能。在AUT中选择了用户最常用的五个功能作为本次测试的内容，包括登录。大概的需求就是这样。
接下来我AUT的登录说一说怎么用LoadRunner和Jmeter来实现场景的设置达到测试的目的。（注：对服务器的检测不是本次测试的重点，本次测试主要收集并发访问用户数和发生错误用户数）
首先是对脚本的要求：
1、录制脚本（注意所有的脚本都应录制到Action中），自定义事务，事务从提交用户名和口令的脚本之前开始；
2、在定义事务开始的脚本前加入集合点；
3、在脚本中加入检查点，以登录成功的页面出现登录用户的ID即可；
4、参数化登录用户的身份；
其次是对场景设置的要求：
1、因为事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变用户数来确定；
2、建议修改运行时设置，优化对服务器的访问；
3、计划的设置，每x时间后加载10用户（根据总用户数设置），完全加载后持续运行不超过5分钟（根据需要设置）；
4、集合策略，当运行中的用户数100%达到集合点时释放；
5、注意事项，需要注意几个时间：1）服务器响应超时时间；2）登录事务迭代一次所使用的时间；3）集合点等待超时时间；4）计划中设置的间隔时间。在我的测试中事务运行一次的时间不超过30秒，通过修改脚本使它的运行时间达到一分钟左右， 服务器响应超时时间、结合点等待超时时间、计划中设置的间隔时间都设置为了2分钟。
这样场景开始运行后运行用户数呈阶梯增长，另外在每个上升点新增的用户都会随原来已经运行的用户并发访问服务器。
通过多次的运行和对测试结果中正在运行用户数与错误用户的对比，然后根据定义可接受错误率就可得到该功能的最大并发访问的用户数。
以上测试中排除了对网络、客户端等的要求。在实际测试中首先要保证这些资源是足够的。
使用Jmeter也能够达到上述描述的场景的测试，并且更加的便捷。
抄来的
随便看看吧
4. 压力测试的压力测试
情境压力测试即主体向被观察者布置一定任务和作业，借以观察个体完成任务的行为。工作样本测验、无领导小组讨论都可算作情境压力测验。在软件工程中，压力测试是对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败。网络游戏中也常用到这个词汇。 网络定义：2009年9月7日下午，移动公司开商务车装载200多部电信手机，在温州某大学边上不停拨打，导致电信网络瘫痪。电信发现后连车带人押送到公安局，在公安局，移动自称没有违法，只是帮电信做压力测试。“压力测试”与俯卧撑、打酱油等词汇一样，成为网络流行词汇。压力测试、终端机性能功率、各项性能趋势指标等。
5. 如何执行压力测试
Jmeter是一个性能测试工具，同loadrunner类似，他功能较多，我们常用的功能是用jmeter模拟多浏览器对网站做压力测试。 我们一般的网站，在进入业务功能前先需登录，然后才能访问业务功能。下面介绍如何用jmeter登录系统再对主业务做压力测试。 1. 运行jmeter 2. 左边树将出现测试计划、工作台两根节点。 3. 选择测试计划，按右键－》添加－》threads（users）线程组 线程组能设置以多少个线程并发做压力测试。 在”循环次数”设置不选择永远，循环次数设置1。 4. 现在先介绍如何设置登录http请求，选择线程组，右键――添加――》sampler－―》http 请求。 http请求即模仿浏览器的访问。 在“服务器名称或ip”设置127.0.0.1，端口号设置:8080，“方法”设置post，路径设置网站登录的地址，如“/exam/operatorAction”。 登录需传入用户、密码。在“同请求一起发送参数”列表中添加参数。参数值根据web应用设置。如login_user=0001;login_password=1;actFlag=login 5. 登录成功后，网站一般将跳入主页面。在jmap中可做判断，判断是否登录后按预想进入主页面（此步骤也可不设）。选择4中的“http请求“，右键――》添加――》断言――》响应断言。“Apply to”设置Main smaple only；“要测试的响应字段”设置“url样本”；“模式匹配规则”设置“包括”，“要测试的模式”增加页面跳转到的主页面，如：“studentMain.jsp” 6. 一般网站登录后，在tomcat中生成了session，之后访问其他页面将无需再次登录，前提是浏览器需支持cookie。在jmap中也同样，如要继续访问其他页面，还需做下面关键的设置。 选择“线程组”――》右键――》添加――》配置元件――》Http cookie管理器。加了此步骤后，http请求将具备cookie功能，即登录成功后访问其他页面将不会跳转到登录页面重新登录。 7. 对目标页面反复压力测试。 7.1 如何使被测页面反复访问达到测压效果。选“线程组”―》右键――》逻辑控制器――》循环控制器。循环次数中选择“永远”。 7.2 选择刚加的“循环控制器”，右键――》添加――》sampler－―》http 请求，按4步骤设置ip、端口，http请求方法为“get”，路径为被压力测试的url，如：“exam/business/studentExam.action.StudentExamAction?action=goIntoMockExam”。 按上面的设置后，已完成配置，可做压力测试。只需点菜单“运行”――》启动，即运行压力测试。 8. jmeter提供了许多压力结果查看工具。是压力测试时非常好的分析工具。下面几种查看工具可有选择的添加。 8.1 察看结果树。他记录每次请求发送数据、响应返回数据。选择“线程组”――》右键――》添加――》察看结果树。 8.2 用表格查看结果。可查看每次请求的响应时间等。选择“线程组”――》右键――》添加――》用表格查看结果。 8.3 Summary Report。可查看平均响应时间、最长响应时间等。
6. 什么是压力测试
压力测试 是给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷，是通过搭建与实际环境相似的测试环境，通过测试程序在同一时间内或某一段时间内，向系统发送预期数量的交易请求、测试系统在不同压力情况下的效率状况，以及系统可以承受的压力情况。 然后做针对性的测试与分析，找到影响系统性能的瓶颈，评估系统在实际使用环境下的效率情况，评价系统性能以及判断是否需要对应用系统进行优化处理或结构调整，并对系统资源进行优化。
7. 什么叫压力测试
传统上所谓压力测试（stress testing）是指将整个金融机构或资产组合置于某一特定的（主观想象的）极端市场情况下，如假设利率骤升100个基本点，某一货币突然贬值30%，股价暴跌20%等异常的市场变化，然后测试该金融机构或资产组合在这些关键市场变量突变的压力下的表现状况，看是否能经受得起这种市场的突变。 在软件测试中：压力测试（Stress Test），也称为强度测试、负载测试。压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。
8. 压力测试流程
一、压测流程
可参照上篇压测对抗流程
二、压测需求
需要明确需要压测的环境
需要压测的接口，其中包含接口的入参
需要明确接口的预计qps
需要明确线上机器配置
三、压测准备
3.1、服务端开发准备：
1.根据需要测试的接口，决定需要部署哪些相关依赖服务
2.测试接口对应的服务、接口
3.相关配置
4.相关数据库
5.需要的机器整理，其中包含机器的配置，需要几台机器
3.2、前端开发准备：
1.测试的接口和服务应用
2.域名
3.需要准备的机器
4.根据需要测试的接口，决定要部署哪些相关依赖
3.3、测试准备：
1.准备压测的测试方案和测试计划
2.通过接口确认压测的场景，其中包含每一个接口需要测试的场景，预计接口需要的压测线程。通过测试场景确认测试方案。
3.根据测试计划准备测试脚本
4.根据每一个接口的情况准备对应的测试场景。
5.根据测试场景准备需要的测试数据。其中会包含登录账号相关，接口返回有数据相关等。建议可以将线上的数据库直接copy一份到压测环境中
6.测试申请施压机器的权限
7.施压机上准备压测需要跑的工具
四、压测方案和计划
4.1、编写压测方案和计划
1.压测方案和计划的模板查看
2.在测试方案中将信息进行整合和处理，其中包含需要测试的接口，每一个流程对应的时间节点。
3.测试方案和测试计划确定后需要跟对应的人员（包含服务端开发、前端开发、测试人员、前端运维、服务端运维等）进行评审，确认最终的流程的时间节点。
4.根据测试计划中的时间输出对应的结果。其中包含服务券和前端代码部署、机器申请和部署、测试的测试脚本输出
4.2、测试编写测试脚本
1.确认测试接口是否依赖于登录，是否需要登录信息
2.确认需要测试的接口属于atop接口还是http接口。
3.确认需要编写哪些脚本
4.调试测试脚本5.
自动化脚本或者jmeter脚本编写，可查看jmeter使用
4.3、测试验证测试脚本
1.在日常环境对测试脚本进行验证，确定脚本能够正常跑
2.对测试接口需要的准备数据进行整理
3.对测试接口需要的断言进行准备
4.4、施压机上对压测环境的验证
1.将测试脚本中对应的域名和数据等换成压测环境的数据
2.在压测环境中对环境和脚本进行验证
3.与开发调试压测环境中的问题，并调试脚本问题
4.5、在压测环境中进行模拟压测
1.使用一个接口进行模拟压测，确认需要收集的图标信息、结果是否满足预期
2.确认施压机和压测机器是否正常，是否需要更换
3.确认需要采集数据的采集
4.确认断言方式是否ok
五、压测开始
5.1、正式压测：
1.开始正式压测，将各路人马（开发、运维、DBA等人进行封闭压测）
2.针对压测的接口进行决定接口压测的顺序
3.压测中需要逐渐增加线程数量
4.在压测过程中观察实时的qps和报错相关，并通知开发进行查询对应的接口响应时间。
5.根据接口的链路分别通知对应的人员进行查看压测过程中其接收时间、响应时间等。
5.2、当次压测结果分析：
1.当次接口压测结束后，对结果进行分析，确认压测后的qps、报错率、10%、50%、90%用户的响应时间
2.开发寻找对应浪费的时间，当场进行优化后，可以针对此接口在进行压测，以便找到性能瓶颈问题。
3.压测结果最终是需要找到最大的qps和开始出现报错的并发数
4.当前线程数对应的线程数，如没有达到对应的qps要求，可根据qps进行决定增加多少线程数。若线程数增加后，qps没有提高，大致已经找到qps的极限。
5.3、稳定性测试：
1.找到比较稳定的qps对应的线程数，进行稳定性测试
2.稳定性测试与压测的区别在于持续的时间。
3.可通过稳定性测试进行观察持续性调用接口时系统的表现。
4.后续可根据稳定性测试和压测的qps进行计算出对应的每日能够承受的日活量。
六、压测后测试报告整理
1.测试报告整理
a.对此次压测进行整理测试报告
b.测试报告中需要记录压测对应的时间节点、此次压测对应的qps、此次压测中的错误率
c.此次压测10%、50%、90%用户的响应时间
d.压测过程中出现的毛刺时间节点
e.压测过程中曲线不正常对应的原因。
f.此报告需要开发、测试同步进行整理
g.测试记录压测数据和图标
h.开发记录对应系统的cpu使用率、负载、数据库负载等信息。
i.测试报告模板
最新文章
热门文章
推荐阅读