大家好,欢迎来到IT知识分享网。
一、 性能测试术语解释
1. 响应时间
响应时间即从应用系统发出请求开始,到客户端接收到最后一个字节数据为止所消耗的时间。响应时间按软件的特点再可以细分,如对于一个 C/S 软件的响应时间可以细分为网络传输时间、应用服务器处理时间、数据库服务器处理时间。另外客户端自身也存在着解析时间、界面绘制呈现时间等。

响应时间主要站在客户端角度来看的一个性能指标,它是用户最关心、并且容易感知到的一个性能指标。
2. 吞吐率
3. 用户数
二、 性能测试方法及目标
1. 性能测试方法
1.1基准测试(Benchmark Testing)
基准测试是基于一定规模的数据量上进行单业务或按实际用户操作同比例组合业务的测试,目的在于量化响应时间、吞吐率的指标,便于后续比对。
方法是做多组不同场景的测试,观察结果,抽取出几个关键数据做好记彔,用于以后进行性能对比和评价。
1.2 性能测试(Performance Testing)
通过模拟生产运行的业务压力量和使用场景组合,测试系统的性能是否满足生产性能要求。
特点:
(1) 主要目的是验证系统是否具有系统宣称的能力。
(2) 需要事先了解被测系统的典型场景,并具有确定的性能目标。
(3) 要求在已确定的环境下运行。
1.3 负载测试(Load Testing)
通过在被测系统上不断增加压力,直到性能指标,例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。
特点:
(1) 主要目的是找到系统处理能力的极限。
(2) 需要在给定的测试环境下进行,通常也需要考虑被测系统的业务压力量和典型场景,使得测试结果具有业务上的意义。
(3) 一般用来了解系统的性能容量,或是配合性能调优使用。
1.4 压力测试(Stress Testing)
测试系统在一定饱和状态下,例如CPU、内存等在饱和使用情况下,系统能够处理的会话能力,以及系统是否会出现错误。
特点:
(1) 主要目的是检查系统处于压力情况下是应用的表现。
(2) 一般通过模拟负载等方法,使得系统的资源使用达到较高水平。
(3) 一般用于测试系统的稳定性。
1.5 配置测试(Configuration Testing)
通过对被测系统的软/硬件环境的调整,了解各种不同环境对系统性能影响的程度,从而找到系统各项资源的最优分配原则。
特点:
(1) 主要目的是了解各种不同因素对系统性能影响的程度,从而判断出最值得进行得调优操作。
(2) 一般在对系统性能状况有初步了解后进行。
(3) 一般用于性能调优和规划能力。
1.6 并发测试(Concurrency Testing)
通过模拟用户的并发访问,测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
特点:
(1) 主要目的是发现系统中可能隐藏的并发访问时的问题。
(2) 主要关注系统可能存在的并发问题,例如系统中的内存泄露、线程锁和资源争用方面的问题。
(3) 可在在开发的各个阶段使用,需要相关的测试工具的配合和支持。
1.7 可靠性测试(Reliability Testing)
通过给系统加载一定的业务压力(例如资源在70%~90%的使用率)的情况下,让应用持续运行一段时间,测试系统在这种条件下是否能稳定运行。
特点:
(1) 主要目的是验证系统是否支持长期稳定的运行。
(2) 需要在压力下持续一段时间的运行。
(3) 需要关注系统的运行状况。
1.8 失效恢复测试(Failover Testing)
针对有冗余备份和负载均衡的系统设计的,可以用来检验如果系统局部发生故障,用户是否能够继续使用系统;以及如果这种情况发生,用户将受到多大程度的影响。
特点:
(1) 主要目的是验证在局部故障情况下,系统能否继续使用。
(2) 还需要指出,当问题发生时“能支持多少用户访问”的结论和“采取何种应急措施”的方案。
(3) 一般来说,只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。
2. 性能测试目标
概况来说,可分为4个方面:
2.1 能力验证
在系统测试或验收测试时,我们需要评估系统的能力,衡量系统的性能指标。系统的能力可以是容纳的并发用户数,也可能是系统的吞吐率;系统的性能指标可以是响应时间,也可以选择 CPU、内存、磁盘、网络的使用情况。
特点:
(1) 要求在已确定的环境下进行。
(2) 需要根据典型场景设计测试方案和用例。
一般采用的方法是:性能测试、压力测试、可靠性测试、失效恢复测试。
2.2 能力规划
评估某系统能否支持未来一段时间内的用户增长或是应该如何调整系统配置,使得系统能够满足增长的用户数的需要。
特点:
(1) 属于一种探索性的测试
(2) 可被用来了解系统的性能以及获得扩展性能的方法,例如系统扩容规划。系统容量可以是用户容量,也可能是数据容量,或者是系统的吞吐量(系统的处理能力)。对于集群服务我们更多的是用吞吐率作为容量。
方法是①先对各子系统、组件进行性能测试,找出它们之间的最优配比;②然后再通过各环节的水平扩展,计算出整体的扩容机器配比。
一般采用的方法是:负载测试、压力测试、配置测试。
2.3 性能调优
为了更好的发挥系统的潜能,定位系统的瓶颈,有针对性的进行系统优化。
方法是在进行系统调优时,我们需要做好基准测试,用以对比性能数据的变化,并反复调整系统软硬件的设置,以使系统发挥最优性能。当然在进行系统优化时,我们会选取关键的指标进行优化,返时可能要牺牲其他的性能指标。如目标是优化响应时间,我们可能选取的策略是以空间换时间,以牺牲内存或扩大缓存为代价,还需要我们在各个性能指标中找到平衡点。
一般对系统的调整包括以下3个方面:
(1) 硬件环境的调整
(2) 系统设置的调整
(3) 应用级别的调整
一般采用的方法是:基准测试、负载测试、压力测试、配置测试和失效恢复测试。
2.4 发现缺陷
和其他测试一样,性能测试也可以发现缺陷。特别是严格并发访问时是否存在资源争夺导致的响应时间过慢,或大量用户访问时是否导致程序崩溃。
方法是设置集合点,实现严格并发用户访问;或者设置超大规模用户突发访问等这样的性能测试用例进行测试。
一般采用的方法是:并发测试。
三、 性能需求分析
1. 性能需求获取
四、 性能测试范围
1. 业务范围
关键业务功能点描述。
2. 设计范围
网络接入层、接口层、中间件、存储层等被测组件及拓扑结构描述。
五、 并发数计算方法
做过一些性能测试的童鞋刚开始比较纠结某个或某一类接口的并发数如何计算,其实并发数可以从用户业务和服务器的2个角度来看。
1. 80/X原则
适用范围:无限制
以一项目为案例,母亲节当天接口服务器访问量分布如下所示,如何计算当天平均并发数和高峰并发数?
公式(2)计算并发用户数峰值: C’≈ C+3根号C
C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
假如一个系统需支撑10万在线用户数访问,如何通过性能需求分析来计算并发用户数?大家可以通过以上内容学习,独立思考下?
六、 性能测试用例与场景
- 脚本模板
- 场景模板
七、 性能测试工具选择

4.2 监控平台
监控机器主要对被测集群服务器的服务或资源使用情况进行监控,比如各种开源的监控工具,MRTG:流量监控;CACTI:流量预警,性能报告Smokeping:IDC 质量监控;综合监控:Nagios、Zenoss、Ganglia 、Zabbix、Sitescope、Hyperic HQ 等,如下所示:
八、 性能测试结果分析
1. 指标分析
性能测试的指标可分为产品指标和资源指标两类。对测试人员而言,性能测试的需求来自于用户、开发、运维的三方面。用户和开发关注的是与业务需求相关的产品指标,运维人员关注的是与硬件消耗相关的资源指标。

以上说明了测试人员在选择指标时需站在用户角度去思考,另外为了后续能够更好地分析问题,更需掌握与被测组件特性或运行原理相关的性能指标。

随着单位时间流量的不断增长,被测系统的压力不断增大,服务器资源会不断被消耗,TPS 值会因为这些因素而发生变化,而且符合一定的规律。
即整理得
系统每小时PV处理剩余量 = 系统每小时最大处理的PV数 — 系统每小时处理的PV数
假设该网站用户负载基本呈线性增长,现有系统用户数为70万,根据运营推广计划,1年内该网站发展用户将达到1000万,即增长了14倍。即整理得:
系统每小时PV处理增加量 = 当前系统每小时处理的PV数 * 14 — 当前系统每小时处理的PV数
每天系统负载增加率 = 100% / 365 = 2.74 % (备注:此处将未来系统用户数达到1000万的负载定义为 100% )
系统每天PV处理增加量 = 系统每小时PV处理增加量 * 每天系统负载增加率 * 24
所以,我们可以知道在正常负载条件下:
系统可支持正常运行天数 = 系统每小时PV处理剩余量 * 24 / 系统每天PV处理增加量
假设该网站后续部署升级天数已知,这样我们可以知道提前升级的天数:
系统可支持正常运行天数 — 部署升级天数。
九、 性能测试通过标准
总结:
感谢每一个认真阅读我文章的人!!!
作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。
软件测试面试文档
我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://haidsoft.com/120811.html








