常州h5网站建设,深圳网站制作必找祥奔科技,网站建设 佛山,wordpress+用户前台赶鸭子上架要我搞性能测试#xff0c;怎么办#xff1f;
我第一次真正意义上搞性能测试是在2014年。项目组要求搞性能测试#xff0c;我之前也没搞过#xff0c;对服务端也不熟悉。就那么一脸懵逼地开始搞性能。当时我连linux上有哪些能看系统资源的命令都不知道。稀里糊涂…
赶鸭子上架要我搞性能测试怎么办
我第一次真正意义上搞性能测试是在2014年。项目组要求搞性能测试我之前也没搞过对服务端也不熟悉。就那么一脸懵逼地开始搞性能。当时我连linux上有哪些能看系统资源的命令都不知道。稀里糊涂地进行了好几轮地性能测试之后我最大的感受是对于非专家的测试人员来说搞性能测试是一个团队活动而非个人活动。整个过程中我更多地是借助团队地力量来搞。系统监控不会找运维帮忙软件架构不懂找架构师帮忙服务器参数不会调开发替我调。而在这次做完这一波性能测试之后我下决心要搞懂性能测试到底是怎么搞的。毕竟刚毕业的时候就听说了自动化测试和性能测试这俩方向好但我从来没听谁把“性能测试到底是怎么回事”讲清楚过。我自己在后面的工作中琢磨了很多年直到最近这两年才琢磨得差不多了很想跟大家分享一下。 想搞性能测试要学什么东西
2006年我还在读书的时候学校里的软件质量课程里老师跟我们讲“用win runner做性能测试”。2008年我毕业进第一家公司的时候公司里的培训老师跟我讲“用load runner做性能测试“。2011年我在另一家公司做接口测试的时候我们用soapUI做功能测试soapUI的公司的网站上跟我讲“用loadUI做性能测试”。2012年我在自学的时候又网上看到了“用jmeter做性能测试”。而后来gatlinggrinderlocusttsung工具多得数不胜数。那么我早就想问了性能测试就是使用这些测试工具吗 搞性能测试并不只是搞搞工具
性能测试最需要的东西不在于工具而在于对整个待测系统的理解。首先要理解整个待测系统它的软件架构硬件架构网络架构理解它是如何运行的。它由哪些部分组成各个部分之间是怎样交互的。用户怎样使用这个系统。在理解系统的基础上我们可以得出系统的各个部分的性能要求是怎样。也就是性能需求。
而测试的过程也就是验证和探索这些性能需求。
为各种性能需求设计测试场景再编写测试脚本执行测试脚本汇总测试结果再分析测试结果进行调优再重复测试与调优最后产出测试报告。指明系统是否符合性能需求哪里还达不到要求。
这其中跟性能测试工具有关的只有“编写测试脚本执行测试脚本”。其他的所有步骤需要的是计算机科学与技术的各方面综合知识、对业务的理解、对待测系统技术实现的理解。至于性能测试的工具我们可以选用开源工具也可以选择自己开发工具。当我们全盘理解性能测试之后就可以针对具体的需求开发性能测试工具来解决各种实际问题。注意自己开发的性能测试工具与开源工具的区别自己开发的工具可以很有针对性而开源工具需要考虑兼容性与普适性。两者的开发重点完全不同。开源工具以推广这个工具为目标而自己写的工具以最快/最经济解决实际问题为目标。 搞性能测试如何入门
说了这么多性能测试到底要如何入门呢。
一方面工具仍旧是要的建议使用jmeter等开源工具作为入门学习的工具。照着用户手册操作一遍花个几天时间就能上手。
更重要的另一方面我们需要理解性能测试的原理做性能测试的基本步骤场景设计的基本策略。不知道这些光拿个工具有什么用呢。现实业务千变万化往往需要测的东西并不是那么简单拿个工具随便搞搞就能搞好的东西。
一、什么是性能测试 二、性能测试的目的 三、如何做性能测试 四、性能测试关注的指标 五、性能结果分析 六、性能测试资源分享 一、什么是性能测试
是不断的通过不同场景的系统表现去探究系统设计与资源消耗之间的平衡。
我们可以认为性能测试是通过在测试环境下对系统或构件的性能进行探测用以验证在生产环境下系统性能是否达到预估的性能需求发现系统可能存在的性能瓶颈进而改善优化并系统的性能提高系统的可扩展性、稳定性。
从上面的描述可以看出性能测试的主要工作包括获得预估的性能需求、搭建测试环境、执行测试、分析测试结果。其中最为重要两个工作是确定测试的目的、方案并对结果进行分析。
二、性能测试的目的
(1)验证系统是否满足预期需求;
(2)验证系统在高压下的表现;
(3)验证系统是否能持续稳定的运行;
(4)探测系统的瓶颈和产生瓶颈的原因;
(5)探测系统设计与资源之间的最佳平衡改善并优化系统的性能。
三、如何做性能测试
1. 负载测试 找到系统稳定时或满足性能需求下的最大吞吐量要有响应时间、成功率的限制比如定义99.9%的响应时间必需在1ms之内平均响应时间在1ms以内100%的请求成功
2. 稳定性通过浸泡测试soak test 以系统稳定时的最大吞吐量或满足性能需求时的最大吞吐量长时间对系统进行测试已检查系统是否稳定
3. 压力测试 找到系统极限值系统瓶颈系统崩溃临界值要求响应时间可以变慢但系统不能崩溃根据测试目的选择是进行负载、压力、稳定性还是几种测试 4. 并发有两个概念
多个用户同时进行相同操作访问同一接口——单个业务接口并发
多个用户同时访问系统但进行不同的操作访问不同的接口——系统级并发在性能测试过程中根据 具体场景和业务 选择合适的方案一般第2种更符合实际场景。以上2种都需要进行测试
5. 测试流程 确定测试目的与需求——根据需求与场景梳理测试要点——根据测试目的制定测试方案——准备测试环境与数据——测试执行脚本或工具——统计测试结果——分析结果——测试报告
PS
1 .测试执行时执行多次取平均结果更为准确。
2. 单机并发不够时采用多机分布式并发
3. 测试过程一定要尽可能模拟实际应用场景 四、性能测试关注的指标
测试人员关注单次业务相关指标
并发用户数
响应时间TP百分比分布统计
吞吐量tps/qps
成功率
失败率
开发人员关注系统层面指标
1. Tomcat、数据库等
2. 容量系统能承载的最大访问量是多少系统最大的业务处理量是多少
3. 稳定性是否支持7*24小时一周的业务访问
运维人员关注硬件资源相关指标
硬件资源消耗情况CPU、内存、I/O读写速度、网络带宽等 五、性能结果分析
以下相关指标分析时需注意
1.响应时间不要光看平均值平均值不靠谱。要求最好定成99.9%请求必须1s所有的平均响应时间必须1s这两个条件限制
2.响应时间要和吞吐量TPS/QPS挂钩 系统的性能如果只看吞吐量不看响应时间是没有意义的。我的系统可以顶10万请求但是响应时间已经到了5秒钟这样的系统已经不可用了这样的吞吐量也是没有意义的。
我们知道当并发量吞吐量上涨的时候系统会变得越来越不稳定响应时间的波动也会越来越大响应时间也会变得越来越慢而吞吐率也越来越上不去如上图所示包括CPU的使用率情况也会如此。所以当系统变得不稳定的时候吞吐量已经没有意义了。吞吐量有意义的时候仅当系统稳定的时候。
所以吞吐量的值必须有响应时间来卡。比如TP99小于100ms的时候系统可以承载的最大并发数是1000qps。这意味着我们要不断的在不同的并发数上测试以找到软件的最稳定时的最大吞吐量。
3. 响应时间吞吐量要和成功率挂钩
不难理解如果请求可以并发10w但是成功率只有40%那也没什么用。
性能测试的失败率的容忍应该是非常低的。对于一些关键系统成功请求数必须在100%一点都不能含糊。
4. CPU、内存等硬件资源占比持续超过90%说明性能存在瓶颈
5. 带宽波动起伏很大说明带宽受限 六、性能测试资源分享
下面是配套资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你【保证100%免费】 凡事要趁早特别是技术行业一定要提升技术功底。希望对大家有所帮助……
