性能测试——压力测试指标

最新推荐文章于 2023-12-21 14:46:58 发布
最新推荐文章于 2023-12-21 14:46:58 发布
阅读量2.2k 收藏 10
点赞数 2
分类专栏： 性能测试 Jmeter 文章标签： 压力测试 软件测试 程序人生 软件测试工程师 性能测试 jmeter压力测试 经验分享
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_70618214/article/details/131601556
版权

目录

背景

什么是TPS

性能测试的指标是怎么来的呢？

怎么通过业务量来计算TPS多少合适呢？

相关总结

​🎁更多干货

完整版文档下载方式：

先说结论
一般推荐，如果你：

没啥人用的服务 tps 20，返回有300ms就行了
十万到百万级的服务，响应能达到tps50 /200ms就可以了
后台服务，能达到tps 20 / 200ms即可（通常后台同时使用也没多少人）
秒杀类的短时间高并发……TPS100或200 在 100ms内响应 应该也能撑一段时间（具体情况还是要看业务量）

背景

做项目开发的时候，不止一次被性能测试问“这个服务性能要求是多少？”他期望能得到一个这次接口TPS压到50还是100，返回时间是100ms还是200ms的回答。然后压力测试的脚本就跑起来，挨个接口就去压了。
但作为产品我怎么知道报多少合适呢？（是的，在某些团队这是研发负责人应该考虑的）。通常我们是只知道业务量，怎么转换成tps、返回时间的要求呢？（有时候业务量都估算不出来，那这种场景下你就按最顶部的推荐的来测吧。）
现在，只要10分钟，让你了解怎么计算这些内容。
首先，需要知道不同的产品有不同的应对要求

手机发货的抢购秒杀场景和美团的场景需求不一致，导致产品性能要求就不一致
千万级用户的app和十万级app，同样的性能要求，转换为技术指标上也不一致

继续计算，我们需要了解

什么是TPS

Transactions Per Second（每秒传输的事物处理个数，或者说每秒系统接收的任务数量），系统接收到任务后会有一个处理时间。
在压力测试时，测试人员会主动按一定tps的量来主动发起接口请求，比如tps=50，就是每秒请求50次，获取一个平均的响应时间（单位一般都是毫秒ms）。压力测试人员口中的TPS50 200ms返回，就是指每秒测试人员主动发起50次请求，这些请求会在平均200ms返回。
由于其他技术指标如QPS（数据的每秒查询个数）等性能都会在tps这个维度上展示出来，因此可通过tps对系统性能进行简单判断，以满足日常性能测试需求。

性能测试的指标是怎么来的呢？

1、产品和运营要给出业务匡算：
这个服务，在多长时间段，多少人会访问
2、性能要求上，通常情况下的APP应该如何？
页面访问的2、5、8原理（用户进入服务2s内要展示完所有内容，超过5秒用户就无法忍受了，超过8秒就没有人再等了，直接关闭服务）
因此页面的渲染时间+资源文件的载入时间+接口的获取时间需要保证1s~2s内完成
3、这个条件下接口获取时间多长合适？
无脑建议200ms以内（考虑到你页面也要2s打开，还要给其他工作留时间）

怎么通过业务量来计算TPS多少合适呢？

直接上公式不太好理解，我们先看案例
案例1，秒杀型算法
案例的业务量要求
某业务，类似秒杀型，用户估算有2W左右，每个用户平均请求2次接口（查询用户信息接口、查询业务接口）， 这些用户大概率会在2分钟内会访问我们的系统，业务要保证用户2s能打开页面
TPS的分析
TPS是系统每秒钟处理的任务数量，给定二业务场景，我们就需要先计算出来每秒需要系统处理多少任务，从而反推在压力测试的时候，需要给多大的TPS了。

首先，整个系统的总请求数=用户（2W）* 每个用户请求数（2次）= 40000次
其次，每秒要求处理的请求数=总请求数/时间（切换到秒） 即约350（333向上取个整吧）。
最后，TPS并发数量与每个请求所消耗的时间，可实际计算出每秒实际能够处理的请求数。
即每秒实际处理请求数量=tps数量 * 1000【1秒，需要切换为毫秒】/单组tps处理时间【这里是按200ms返回】
因此，我们只要保证 每秒实际处理请求数>每秒要求处理的请求数 就可以了。

最终结果就是
TPS数量 > 每秒要求处理的请求数 * tps返回时间【按200ms计算】/1000ms

带入数据计算

tps>(350 * 200)/1000，具体tps>70。
因此可让压力测试人员按照tps100来压接口，返回在200ms以内就满足性能要求。
当然如果实际tps50的返回时间为100ms，则按照这个粗略的公式来推算，也是能够支撑的（350 * 100/1000=35，也就是说tps高于35，返回100ms以内也是可以的）
案例2，我们来看一个日常服务的算法
如：一个100w访问的服务，每天访问集中白天8小时，每个用户大约会请求3个接口，每天早上9点是峰值。
首先计算日均请求数（每秒）
按8小时 100w访问量、平均3个接口请求计算
每秒日均请求数=100w（访问量）* 3（每个访问量平均请求接口数）/8（小时）/3600（切换成秒），结果就是每秒请求100次。
按接口200ms返回，tps需要> 100 * 200/1000，即>20就行了。
如考虑日常服务的峰值，则按4 * 日均，即每秒请求400次，则tps>80即可，因此可推荐按tps=100来做接口的压力测试。

相关总结

时间段越短，数据也越接近于瞬间并发
如果用整日的数据来计算总请求数，需要按照日流量分布来估算一个峰值数据，日常APP可考虑使用 峰值=4 * 日均【当然还是要看你具体的访问量】

如果觉得以上繁杂，反正你也可以参考这个结论

没啥人用的服务 tps 20，返回有300ms就行了
十万到百万级的服务，响应能达到tps50 /200ms就可以了
后台服务，能达到tps 20 / 200ms即可（通常后台同时使用也没多少人）
秒杀类的短时间高并发……TPS100或200 在 100ms内响应 应该也能撑一段时间（具体情况还是要看业务量）

​🎁更多干货

完整版文档下载方式：

这些资料，对于从事【软件测试】等相关工作的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享。

在评论区和我互动交流或者私❤我【软件测试学习】领取即可，拿走不谢。

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “👍点赞” “✍️评论” “💙收藏” 一键三连哦！

 

软件测试凡哥
关注
  • 2
    点赞
  • 踩
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
【项目实战】性能测试之压力测试的系统性能指标基本介绍（每秒事务数TPS和峰值TPS）
本本本添哥
04-06 106
峰值TPS是指系统在特定高峰时段内能够处理的最大TPS。这个指标有助于了解系统在流量高峰期的表现。通常平均TPS是压力测试的重要指标之一，应与预期目标TPS值做对比。同时，取所采集到的请求的最小TPS和最大TPS作为测试结果。
性能测试中TPS和并发用户数
weixin_33937778的博客
07-31 1805
并发用户数：是指现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)。并发用户数和注册用户数、在线用户数的概念不同，1、并发用户数一定会对服务器产生压力的，2、而在线用户数只是 ”挂” 在系统上，对服务器不产生压力，3、注册用户数一般指的是数据库中存在的用户数。TPS：Transaction Per Second, 每秒事务数, 是衡量系...
接口压测总结
Shadowed_Heart
10-25 4088
首先明确压测的目的：为了在业务高峰期到来之前，确保服务器经得起高峰期的压力。 但是每个系统的用户数量以及业务量都不一样。那么，在压测之前就需要根据系统的规模，定个小目标。 一般情况，没啥人用的服务 tps 20，RT300ms就行了 十万到百万级的服务，响应能达到tps50 RT200ms就可以了 后台服务，能达到tps 20 RT200ms即可（通常后台同时使用也没多少人） 秒杀类的短时间高并发……TPS100或200 在 100ms内响应 应该也能撑一段时间（具体情况还是要看业务量） 例如，
压测参数说明
qq_36010886的博客
10-24 390
​ **QPS 其实是衡量吞吐量（Throughput）的一个常用指标。**一个有着简单业务逻辑（包括数据库访问）的程序在单核心运行时可以提供 50 – 100 左右的 QPS，即每秒可以处理 50 – 100 个请求。​ 大部分请求的响应时间在 15 – 30 毫秒左右，如果每个请求花费 15 毫秒的话，那么每秒可以处理 66 个请求，也就是我们前面提到的 66 QPS；而如果都是复杂的请求，每个需要 30 毫秒的话，那么服务器就只有 33 QPS 了。
性能压测
武汉小喽啰
02-15 415
1. 性能指标 1）响应时间（Response Time：RT）：响应时间指用户从客户端发起一个请求开始到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间 2）HPS（hits per second）:每秒点击次数，单位是次/秒 3）TPS（Transaction per second）；系统每秒处理交易数，单位是笔/秒 4）QPS（Query per second）：系统每秒处理查询次数，单位是次/秒。 对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=Q...
性能测试（记一次论坛网站性能测试）
weixin_55282974的博客
03-20 3187
近期做了一次论坛网站性能测试，记录下来以便总结提高，欢迎大家交流分享，若有不妥之处还请指教；
性能测试TPS指标到底多算才算合适呢？二八定律
weixin_43865008的博客
08-12 1万+
前言 通常我们在压测的时候，都会有一个指标去衡量，比如搜索商品接口，我们预期TPS需要达到多少。 最理想的情况就是开发/产品/项目经理提前确定好了性能指标，但是通常大多数公司对于性能不是很理解，可能你问产品经理，产品经理说TPS是什么。那么这种情况下，我们就需要根据实际情况进行分析，确认性能指标。 明确压测项目类型 一般我们压测的项目会分为两类，一种是老项目，一个是新项目。像我们公司的项目已经上线运行了很长一段时间了，那么在生产环境中，会生成一些历史数据，并且线上也业务监控系统，定期监控各个业务模块核心接口
性能测试问产品 压力测试指标给多少？TPS、响应时间、并发量的要求是多少？这样计算
空城雀的博客
08-28 3万+
先说结论 一般推荐，如果你： 没啥人用的服务 tps 20，返回有300ms就行了 十万到百万级的服务，响应能达到tps50 /200ms就可以了 后台服务，能达到tps 20 / 200ms即可（通常后台同时使用也没多少人） 秒杀类的短时间高并发……TPS100或200 在 100ms内响应 应该也能撑一段时间（具体情况还是要看业务量） 背景 做项目开发的时候，不止一次被性能测试问“这个服务性能...
QPS/TPS/并发量/系统吞吐量
weixin_44458365的博客
02-23 1734
 QPS: 每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。 吞吐量: 这个问题从业务上来讲，可以理解为应用系统每秒钟最大能接受的用户访问量。或者每秒钟最大能处理的请求数；   TPS：每秒钟处理完的事务次数，一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个...
用LoadRunner分析资源占用率
weixin_30435261的博客
05-13 357
1. 平均事务响应时间 　　Average Transation Response Time 优秀：<2s 　　良好：2－5s 　　及格：6－10s 　　不及格：>10s 　　2. 每秒点击率 　　Hits per Second 　　当增大系统的压力（或增加并发用户数）时，吞吐率和TPS的变化曲线呈大体一致，则系统基本稳定若压力增大时，吞吐率的曲线增加到一定程度...
性能测试进阶指南——LoadRunner11实战 part2
06-14
《测试实践丛书：性能测试进阶指南·LoadRunner 11实战》结合了很多工作中的实际案例，图文并茂，既适合渴望了解性能测试的新人，也适合对性能测试有一定认识和经验的中、高级测试工程师。同时，《测试实践丛书：性能测试进阶指南·LoadRunner 11实战》也可以作为高校开展性能测试课程的参考教材，让在校学生能对性能测试的本质和价值有一定的认识。 《测试实践丛书：性能测试进阶指南·LoadRunner 11实战》是一本基于HP LoadRunner 11工具的指导用书，从性能测试原理到工具使用再到项目实施，全面介绍了性能测试的各个方面，其内容基本主线说明如下。 第一步（了解理论）：磨刀不误砍柴工，打下基础；第二步（掌握工具）：深入介绍LoadRunner 11工具三大部分（Virtual User Generator、Controller、Analysis）如何实现用户行为的模拟、性能指标的监控、负载的生成及后期的数据分析；第三步（项目实施）：理论联系实际，介绍性能测试项目实施的流程和性能测试部门的组织管理；第四步（进阶提升）：对一些当下流行的或比较特殊的协议和开发技巧通过真实案例进行介绍。 基础篇 第1章 性能测试基础 1.1 性能测试工程师的标准及挑战 1.1.1 性能测试工程师的考评指标 1.1.2 性能测试工程师的挑战 1.2 性能测试基础 1.2.1 性能定义 1.2.2 性能指标 1.2.3 单机与网络性能测试 1.2.4 性能测试的流程 1.2.5 性能测试招聘要求 1.2.6 性能测试学习阶段 1.3 性能分析与调优 1.3.1 性能分析及调优原理 1.3.2 常见系统性能瓶颈 1.3.3 性能测试的注意要点 1.4 小结 工具篇 第2章 LoadRunner综述 2.1 LoadRunner简介 2.2 LoadRunner工具组成 2.3 性能测试原理 2.4 自动化测试工具和性能测试工具的区别 2.5 协议分析 2.5.1 HTTP详细介绍 2.5.2 HTTP报文结构 2.5.3 HTTP请求 2.5.4 HTTP应答 2.5.5 HTTP捕获 2.5.6 HTTP回放 2.6 安装 2.6.1 在Windows下安装LoadRunner 2.6.2 安装Load Generator 2.6.3 附加组件 2.6.4 LoadRunner License 2.7 LoadRunner性能测试操作流程预览 2.8 小结 第3章 用户行为模拟 3.1 VuGen界面介绍 3.1.1 Tree图形化模式 3.1.2 脚本模式 3.1.3 Output Window 3.2 录制用户行为 3.2.1 录制流程 3.2.2 协议选择 3.2.3 录制选项 3.2.4 开始录制 3.2.5 插入命令 3.2.6 结束录制 3.2.7 回放验证 3.2.8 录制回放常见问题 3.3 脚本开发 3.3.1 Action简介 3.3.2 脚本如何注释 3.3.3 语言规则 3.3.4 如何使用模板 3.3.5 脚本的导入导出 3.3.6 脚本调试 3.4 通用选项（General Options） 3.4.1 Parameterization标签 3.4.2 Replay标签 3.4.3 Environment标签 3.4.4 Display标签 3.4.5 Correlation标签 3.5 运行设置（Run-Time Setting） 3.5.1 Run Logic 3.5.2 Pacing 3.5.3 Log 3.5.4 Think Time 3.5.5 Additional attributes 3.5.6 Miscellaneous 3.5.7 Speed Simulation 3.5.8 Browser Emulation 3.5.9 Preferences 3.5.10 Download Filters 3.5.11 Data Format Extensions 3.6 参数化 3.6.1 参数化的操作 3.6.2 Parameter List界面介绍 3.6.3 VuGen中的参数 3.6.4 Controller中的参数 3.6.5 同行取值（Same line as） 3.6.6 参数类型 3.6.7 数据向导（Data Wizard） 3.6.8 参数和变量 3.7 关联 3.7.1 关联原理 3.7.2 自动关联 3.7.3 手动关联 3.7.4 一边录制一边关联 3.7.5 关联函数web_reg_save_param_ex详解 3.7.6 关联函数web_reg_save_param_regexp详解 3.7.7 关联函数web_reg_save_param_xpath详解 3.
性能测试进阶指南——LoadRunner11实战 part3
06-14
《测试实践丛书：性能测试进阶指南·LoadRunner 11实战》结合了很多工作中的实际案例，图文并茂，既适合渴望了解性能测试的新人，也适合对性能测试有一定认识和经验的中、高级测试工程师。同时，《测试实践丛书：性能测试进阶指南·LoadRunner 11实战》也可以作为高校开展性能测试课程的参考教材，让在校学生能对性能测试的本质和价值有一定的认识。 《测试实践丛书：性能测试进阶指南·LoadRunner 11实战》是一本基于HP LoadRunner 11工具的指导用书，从性能测试原理到工具使用再到项目实施，全面介绍了性能测试的各个方面，其内容基本主线说明如下。 第一步（了解理论）：磨刀不误砍柴工，打下基础；第二步（掌握工具）：深入介绍LoadRunner 11工具三大部分（Virtual User Generator、Controller、Analysis）如何实现用户行为的模拟、性能指标的监控、负载的生成及后期的数据分析；第三步（项目实施）：理论联系实际，介绍性能测试项目实施的流程和性能测试部门的组织管理；第四步（进阶提升）：对一些当下流行的或比较特殊的协议和开发技巧通过真实案例进行介绍。 基础篇 第1章 性能测试基础 1.1 性能测试工程师的标准及挑战 1.1.1 性能测试工程师的考评指标 1.1.2 性能测试工程师的挑战 1.2 性能测试基础 1.2.1 性能定义 1.2.2 性能指标 1.2.3 单机与网络性能测试 1.2.4 性能测试的流程 1.2.5 性能测试招聘要求 1.2.6 性能测试学习阶段 1.3 性能分析与调优 1.3.1 性能分析及调优原理 1.3.2 常见系统性能瓶颈 1.3.3 性能测试的注意要点 1.4 小结 工具篇 第2章 LoadRunner综述 2.1 LoadRunner简介 2.2 LoadRunner工具组成 2.3 性能测试原理 2.4 自动化测试工具和性能测试工具的区别 2.5 协议分析 2.5.1 HTTP详细介绍 2.5.2 HTTP报文结构 2.5.3 HTTP请求 2.5.4 HTTP应答 2.5.5 HTTP捕获 2.5.6 HTTP回放 2.6 安装 2.6.1 在Windows下安装LoadRunner 2.6.2 安装Load Generator 2.6.3 附加组件 2.6.4 LoadRunner License 2.7 LoadRunner性能测试操作流程预览 2.8 小结 第3章 用户行为模拟 3.1 VuGen界面介绍 3.1.1 Tree图形化模式 3.1.2 脚本模式 3.1.3 Output Window 3.2 录制用户行为 3.2.1 录制流程 3.2.2 协议选择 3.2.3 录制选项 3.2.4 开始录制 3.2.5 插入命令 3.2.6 结束录制 3.2.7 回放验证 3.2.8 录制回放常见问题 3.3 脚本开发 3.3.1 Action简介 3.3.2 脚本如何注释 3.3.3 语言规则 3.3.4 如何使用模板 3.3.5 脚本的导入导出 3.3.6 脚本调试 3.4 通用选项（General Options） 3.4.1 Parameterization标签 3.4.2 Replay标签 3.4.3 Environment标签 3.4.4 Display标签 3.4.5 Correlation标签 3.5 运行设置（Run-Time Setting） 3.5.1 Run Logic 3.5.2 Pacing 3.5.3 Log 3.5.4 Think Time 3.5.5 Additional attributes 3.5.6 Miscellaneous 3.5.7 Speed Simulation 3.5.8 Browser Emulation 3.5.9 Preferences 3.5.10 Download Filters 3.5.11 Data Format Extensions 3.6 参数化 3.6.1 参数化的操作 3.6.2 Parameter List界面介绍 3.6.3 VuGen中的参数 3.6.4 Controller中的参数 3.6.5 同行取值（Same line as） 3.6.6 参数类型 3.6.7 数据向导（Data Wizard） 3.6.8 参数和变量 3.7 关联 3.7.1 关联原理 3.7.2 自动关联 3.7.3 手动关联 3.7.4 一边录制一边关联 3.7.5 关联函数web_reg_save_param_ex详解 3.7.6 关联函数web_reg_save_param_regexp详解 3.7.7 关联函数web_reg_save_param_xpath详解 3.
性能测试进阶指南——LoadRunner11实战 part1
06-14
《测试实践丛书：性能测试进阶指南·LoadRunner 11实战》结合了很多工作中的实际案例，图文并茂，既适合渴望了解性能测试的新人，也适合对性能测试有一定认识和经验的中、高级测试工程师。同时，《测试实践丛书：性能测试进阶指南·LoadRunner 11实战》也可以作为高校开展性能测试课程的参考教材，让在校学生能对性能测试的本质和价值有一定的认识。 《测试实践丛书：性能测试进阶指南·LoadRunner 11实战》是一本基于HP LoadRunner 11工具的指导用书，从性能测试原理到工具使用再到项目实施，全面介绍了性能测试的各个方面，其内容基本主线说明如下。 第一步（了解理论）：磨刀不误砍柴工，打下基础；第二步（掌握工具）：深入介绍LoadRunner 11工具三大部分（Virtual User Generator、Controller、Analysis）如何实现用户行为的模拟、性能指标的监控、负载的生成及后期的数据分析；第三步（项目实施）：理论联系实际，介绍性能测试项目实施的流程和性能测试部门的组织管理；第四步（进阶提升）：对一些当下流行的或比较特殊的协议和开发技巧通过真实案例进行介绍。 基础篇 第1章 性能测试基础 1.1 性能测试工程师的标准及挑战 1.1.1 性能测试工程师的考评指标 1.1.2 性能测试工程师的挑战 1.2 性能测试基础 1.2.1 性能定义 1.2.2 性能指标 1.2.3 单机与网络性能测试 1.2.4 性能测试的流程 1.2.5 性能测试招聘要求 1.2.6 性能测试学习阶段 1.3 性能分析与调优 1.3.1 性能分析及调优原理 1.3.2 常见系统性能瓶颈 1.3.3 性能测试的注意要点 1.4 小结 工具篇 第2章 LoadRunner综述 2.1 LoadRunner简介 2.2 LoadRunner工具组成 2.3 性能测试原理 2.4 自动化测试工具和性能测试工具的区别 2.5 协议分析 2.5.1 HTTP详细介绍 2.5.2 HTTP报文结构 2.5.3 HTTP请求 2.5.4 HTTP应答 2.5.5 HTTP捕获 2.5.6 HTTP回放 2.6 安装 2.6.1 在Windows下安装LoadRunner 2.6.2 安装Load Generator 2.6.3 附加组件 2.6.4 LoadRunner License 2.7 LoadRunner性能测试操作流程预览 2.8 小结 第3章 用户行为模拟 3.1 VuGen界面介绍 3.1.1 Tree图形化模式 3.1.2 脚本模式 3.1.3 Output Window 3.2 录制用户行为 3.2.1 录制流程 3.2.2 协议选择 3.2.3 录制选项 3.2.4 开始录制 3.2.5 插入命令 3.2.6 结束录制 3.2.7 回放验证 3.2.8 录制回放常见问题 3.3 脚本开发 3.3.1 Action简介 3.3.2 脚本如何注释 3.3.3 语言规则 3.3.4 如何使用模板 3.3.5 脚本的导入导出 3.3.6 脚本调试 3.4 通用选项（General Options） 3.4.1 Parameterization标签 3.4.2 Replay标签 3.4.3 Environment标签 3.4.4 Display标签 3.4.5 Correlation标签 3.5 运行设置（Run-Time Setting） 3.5.1 Run Logic 3.5.2 Pacing 3.5.3 Log 3.5.4 Think Time 3.5.5 Additional attributes 3.5.6 Miscellaneous 3.5.7 Speed Simulation 3.5.8 Browser Emulation 3.5.9 Preferences 3.5.10 Download Filters 3.5.11 Data Format Extensions 3.6 参数化 3.6.1 参数化的操作 3.6.2 Parameter List界面介绍 3.6.3 VuGen中的参数 3.6.4 Controller中的参数 3.6.5 同行取值（Same line as） 3.6.6 参数类型 3.6.7 数据向导（Data Wizard） 3.6.8 参数和变量 3.7 关联 3.7.1 关联原理 3.7.2 自动关联 3.7.3 手动关联 3.7.4 一边录制一边关联 3.7.5 关联函数web_reg_save_param_ex详解 3.7.6 关联函数web_reg_save_param_regexp详解 3.7.7 关联函数web_reg_save_param_xpath详解 3.7.8 关联函数的高级使用 3.8 检查点 3.8.1 文本检查点 3.8.2 自动检查点 3.8.3 图片检查点 3.9 事务 3.9.1 响应时间 3.9.2 添加事务 3.9.3 事务时间 3.9.4 手工事务 3.10 集合点 3.11 小结 第4章 负载生成及监控Controller 4.1 设计场景 4.1.1 新建场景 4.1.2 负载生成器管理 4.1.3 用户管理 4.1.4 运行设置 4.1.5 IP虚拟 4.1.6 场景运行原理 4.1.7 Service Level Agreement（服务品质保障） 4.2 系统监控 4.2.1 Scenario Groups（场景用户状态） 4.2.2 Scenario Status（场景运行状态） 4.2.3 计数器原理 4.2.4 计数器管理 4.2.5 SiteScope 4.3 场景运行 4.4 QTP脚本在场景中的运行 4.5 场景数据 4.6 小结 第5章 数据收集分析Analysis 5.1 新建Analysis分析 5.2 Analysis Summary 5.2.1 Analysis Summary（场景的摘要） 5.2.2 Statistics Summary（场景状态的统计说明） 5.2.3 5 Worst Transaction（SLA失败事务） 5.2.4 Scenario Behavior Over Time（场景行为综述） 5.2.5 Transaction Summary（事务摘要） 5.2.6 HTTP Responses Summary（HTTP响应摘要） 5.3 Graphs（数据图） 5.3.1 Vusers（虚拟用户状态） 5.3.2 Errors（错误统计） 5.3.3 Transactions（事务） 5.3.4 Web Resources（网页资源信息） 5.3.5 Web Page Diagnostics（网页分析） 5.3.6 Network Monitor（网络监控） 5.3.7 Resources（资源监控） 5.4 图设置与操作 5.4.1 Merge Graphs（合并图） 5.4.2 Auto Correlate（自动定位瓶颈） 5.5 Transaction Report（事务报告） 5.6 SLA Report（系统阈值监控报告） 5.7 External Monitor（外部监控数据导入） 5.8 Cross with result（跨脚本横向比较） 5.9 生成测试报告 5.9.1 New Report（新建报告） 5.9.2 Reprt Templates（报告模板） 5.9.3 HTML报告 5.10 小结 实战篇 第6章 性能测试实战 6.1 计划测试 6.1.1 分析系统阶段 6.1.2 定义测试目标 6.1.3 明确定义概念 6.1.4 编写性能测试计划 6.1.5 编写性能测试方案 6.1.6 编写性能测试用例 6.2 搭建测试环境 6.2.1 测试平台评估 6.2.2 数据生成 6.2.3 测试环境搭建手册 6.3 创建脚本 6.3.1 用户注册 6.3.2 用户查询 6.3.3 用户看帖 6.3.4 用户回帖 6.4 创建场景 6.4.1 场景设计 6.4.2 负载监控 6.5 运行场景 6.5.1 场景运行Checklist 6.5.2 场景运行记录 6.6 分析性能数据 6.6.1 性能调优原理 6.6.2 前端性能分析 6.6.3 后端性能分析 6.7 性能测试报告 6.7.1 平台对比性能测试报告 6.7.2 Phpwind85性能分析报告 6.7.3 DiscuzX2 VS Phpwind85性能对比报告 6.7.4 Phpwind85验收指标性能测试报告 6.7.5 Phpwind85压力测试报告 6.8 小结 第7章 性能测试组织 7.1 性能测试团队 7.2 性能测试流程分工 7.3 配置管理 7.4 性能测试自动化 7.5 小结 第8章 高级脚本开发 8.1 AJAX
服务器能力计算.docx
06-08
数据服务器处理性能( Ls) 的估算公式为 Ls=XYZ/( 1- β) /γ ( 1) 式中: X———用户连接数(连接/s) Y———数据表连接数 Z———数据访问值( tpm) β———系统自身消耗值, 取值范围为25%~35% 服务器能力计算全文共...
JMeter操作手册大全.docx
03-24
1.性能测试基本概念 1.1.RT -Response time 请求响应时间 从客户端发出请求到得到响应的整个时间 一般包括网络响应时间+server的响应时间。 用户接受准则: 例如2-5-10原则，即按照正常用户体验，如果用户能够在2...
压力测试概念及方法(TPS/并发量)
热门推荐
Andy Tools
03-22 7万+
最近在对代码进行压力测试，这里整理一下压测中的指标和方法。 文章目录1 压力测试中的指标1.1 TPS1.2 QPS1.3 平均处理时间（RT）1.4 并发用户数(并发量)1.5 换算关系1.5 TPS和QPS的区别2 压力测试方法3 相关文档 1 压力测试中的指标 1.1 TPS TPS 即Transactions Per Second的缩写，每秒处理的事务数目。一个事务是指一个客户机向服...
性能测试-电商系统tps计算方法【杭州多测师_王sir】【杭州多测师】
多测师_王sir的博客
05-08 1093
怎么计算得出tps指标？1.第一个通过运维那边给的生产数据，看一下生产进件有多少，计算得来的，如果没有生产数据，或者不过就看如下的方法2.第二个就是根据最近一个月的实际访问数据，比如每天调用了多少个接口，调用了哪些接口，把比例列出来 我举个例子，比如我们yshop系统，从2023-4-8到2023-5-8，最高的一天调用接口数量最高为100万次，那么tps的计算公式如下：tps=100000...
Jmeter 性能测试 —— 评估一个系统TPS与并发数！
最新发布
12-21 2799
问题：性能压测，如何评估一个系统的TPS和并发数？由业务部门或开发人员预估交易量和TPS指标 当一个系统还没有上线时，我们可以预判的是这个系统准备要给多少人使用如日常在线用户数量要支撑1000，那么并发用户参考值为：1000* 10%=100。如果规定该业务的平均响应时间不高于500毫秒，那么通过TPS=并发用户数/业务平均时间就可以得到TPS=100/0.5s=200笔/秒。为了系统健壮性考虑，我们还可以在预估计算得到的TPS基础上扩个1.5倍得到200笔/秒* 1.5=300笔/秒。即可得到该系统的
android开发获取应用本身耗电量_APP性能测试——Android
06-01
好的，针对您的问题，我可以给您提供一些参考答案。 在Android开发中，获取应用本身消耗的电量通常需要通过系统提供的电量统计API来实现。一般情况下，可以通过以下代码获取应用程序的电量统计信息： ```java BatteryManager bm = (BatteryManager) getSystemService(BATTERY_SERVICE); int energy = bm.getIntProperty(BatteryManager.BATTERY_PROPERTY_ENERGY_COUNTER); ``` 其中，`BATTERY_PROPERTY_ENERGY_COUNTER`是一个标识符，用于获取应用程序当前消耗的电量。需要注意的是，这个值是一个估计值，不是准确的电量值。 另外，在进行应用性能测试时，可以使用Android Studio自带的性能分析工具来帮助我们分析应用程序的性能瓶颈。具体操作流程如下： 1. 打开Android Studio，并打开要测试的应用程序项目。 2. 在Android Studio的工具栏中，点击"Run"按钮，启动应用程序。 3. 打开Android Studio的性能分析工具。在菜单栏中选择"Run"->"Profile"->"CPU/Memory/Network"，即可打开性能分析工具。 4. 在性能分析工具中，选择要测试的应用程序，并进行性能测试。测试完成后，可以查看测试结果，分析应用程序的性能瓶颈。 以上是我给您的参考答案，希望可以帮助到您。

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值