之所以很多人去学习性能测试,但实际工作中很难展开测试的原因,总结下来无非是以下几点:
●了解性能知识,知道一些指标意思
●有选择性的学习,只了解一部分,基本都是浮于表层
●没有想法,只会使用工具进行性能测试
●对被测系统或应用本身不了解
●无效测试,生成性能报告万事大吉;
●可查询的顶级实践太多,对刚入「门的朋友不友好;
●浅了看不上,深了看不懂,无法持续学习;
●看不懂性能测试报告,无法定位问题等。
通过总结我们可以看到:其实并不是你不努力,也不是因为学的知识不对,而是你努力错误了!
仅仅只是掌握性能测试最基础的知识,了解执行性能测试步骤,但没有对性能测试的理解,没有项目环境检验,没有经验做支撑,没有性能测试的想法及考虑,当然也就只能通过别人的经验,说着别人的故事,莫名其妙成为了一个伪性能专家,从而无法对团队进行赋能。
再加上很多公司,都会有专门去测试性能的部门,所以大部分从事测试的人员人,也不了解如何开展性能测试。
那么接下来我们说下如何展开性能测试的。
为了尽可能透彻讲清楚这个问题,本文行文结构如下:
1、重点介绍:性能测试工作流程
2、为做好性能测试,你需要知道的性能测试指标
3、为做好性能测试,你还需要知道的性能测试的类型
4、为做好性能测试,你还需要知道的性能测试开展原则
5、为做好性能测试,再为你补充性能测试学习视频教程
一、重点介绍:性能测试工作流程
性能测试的具体步骤因组织和应用程序而异。这取决于企业认为最重要的绩效指标。尽管如此,性
能测试的总体目标在很大程度上是相同的,因此大多数测试计划都会遵循一定的工作流程。
步骤1、需求分析
性能需求分析是整体性能压测的基础,这块如果没有明确,那么之后数据构造并执行测试没有任何意义。所以我们要弄清楚以下几点:
目标:是否需要做性能测试,性能测试的目的?
系统背景:明确被测是什么系统,被测系统相关技术信息。
业务背景:被测系统的基本业务,关键业务场景,用户行为,请求调用频率和路径。
测试风险:流量风险,数据风险,实践成本,技术能力等。避免测试时影响线上用户。
步骤2、定义性能标准
确定证明测试成功的约束、目标和阈值。
主要标准将直接来自项目规范,但应充分授权测试人员设置更广泛的测试和基准。
步骤3、准备测试环境
测试环境压测
预生产环境压测
线上压测
搭建线上压测集群
步骤4、计划和设计测试
考虑一下使用范围的变化,编写自动化脚本,然后创建适应所有可行用例的测试场景。相应地设计测试并概述应捕获的指标。
数据构造,压测数据保证缓存命中率符合预期,压测请求流程路径符合预期
链路梳理,梳理出接口请求的所有服务
对链路梳理排出优先级,存在风险或不能压测的节点进行针对性的设计处理
步骤5、运行性能测试
执行测试,通过人工执行并随时观察系统情况。调度执行,通过调度流量来执行,常态化压测,对服务做好压测相关的改造,周期性执行压测任务,对服务性能可以进行捕获并监控结果。
步骤6、性能报告分析及重测
分析测试结果。
与项目团队分享调查结果。
影响服务压测性能结果因素:
服务内部原因错误,编码问题导致。
服务外部原因,下游服务,数据库,共享池资源。
人为因素,即人为操作失误,压测结果失真等。通过解决已识别的性能缺陷来微调应用程序。重复测试以确认每个问题都已最终消除。
步骤7、性能报告总结
写明压测场景,压测时参数,压测过程记录,压测结论。用以分析系统性能,缩小问题范围,为调优调优提供充分数据支持。
步骤8、性能测试注意点提醒
将性能测试环境与线上环境分开。
多次运行测试以获的对应用程序性能的准确测量。例如,如果你正在运行负载测试,请多次运行相同的测试以确定结果是否一致,然后再将性能标记为可接受或不可接受。
不要在测试之间更改测试环境
二、做好性能测试,你需要知道的性能测试指标
1、服务器负载
不管是网站服务器,应用程序还是网游,服务器有时候都会面临超出服务器配置的访问。负载测试过程中,一段时间内模拟预期的并发用户和事务数,以验证预期的响应时间并定位瓶颈。以此来确定该应用程序或系统,在上线之前可以处理多少用户。通常团队可以将负载测试作为持续集成流程的一部分。
导致服务器端负载的因素包括:服务器资源不足、服务器过载、内存泄漏,最终影响用户网络连接速度。但可以通过使用 CDN、优化数据库、监控 PHP 使用、配置缓存或压缩脚本来解决
2、API 延迟
API延迟:是指用户操作和服务器对该操作的响应之间的往返时间。理想情况下,应用程序应该优化到大约 1 秒的响应时间,这样可以无缝地来回通信。如果延迟很高,用户将会放弃使用产品
3、网络带宽
一般使用计数器Bytes Total/sec来度量,Bytes Total/sec表示为发送和接收字节的速率,包括帧字符在内。判断网络连接速度是否是瓶颈,可以用该计数器的值和当前网络的带宽比较
4、TTFB
TTFB是发出页面请求到接收到应答数据第一个字节所花费的毫秒数。TTFB 慢,是受以下几个因素影响:网络延迟、流量高、服务器配置和性能、动态内容、DNS响应时间。
TTFB 测量从用户最初发出请求到请求数据的第一个字节出现在最终用户的设备上所经过的时间。通常,任何低于 100 - 200 毫秒的都很好。良好的 TTFB 可确保应用程序响应时间符合用户的期望。
5、HTTP 调用
HTTP 调用构建请求和响应,以在应用程序用户和服务器之间进行有效通信。应用程序向后端服务器发出的完成用户请求的请求越多,应用程序就越有变慢或崩溃。
减少调用或请求、清空 SRC 或 HREF 标签以及避免 HTTP 404 错误,可以显着增加服务器响应时间,从而增加用户与业务的互动。大约 0.1-0.3 秒的响应时间为用户提供了即时响应,没有或不明显的中断。
6、DNS 查询
当用户访问应用程序,DNS 查找就会发送一个对域名的查询。这将会把应用的域名映射到 IP 地址。通常来讲,DNS 查找需要 20-120 毫秒。减少 DNS 查找可以提高应用程序性能、改善用户体验
7、吞吐量
吞吐量是衡量应用程序可以处理的与时间相关的请求/响应/流量的数量。应用程序需要运行的吞吐量目标——每小时特定数量的请求。高吞吐量往往意味着在给定的时间内完成更多的事务。需要测试轻量级和重度使用时的实时用户。
三、做好性能测试,你还需要知道的性能测试的类型
有多种类型的性能测试,这些类型是针对软件的不同方面而设计。下面为你介绍这些:
1、负载测试
负载测试的重点是:检查软件在预期用户数量下的加载和执行能力。它主要目标是:检测用来是否可以处理目标数量的用户。如果你进行负载测试,它将用来将帮助你立即检测错误,并防止问题滞后。
2、压力测试
压力测试涉及在极端流量下对软件进行测试。用来分析应用程序,是否可以同时管理大量使用该应用程序的用户。其目的是确定软件的断点或极限。
3、容量测试
在容量测试方面,大量数据被上传到数据库以监控应用程序的行为。其目标是:监控系统在一定数据量下的行为和性能。
4、耐久性测试
耐久性测试是:检查软件在很长一段时间后,确保应用程序可以管理大量数据而不会失去响应能力。用来检查系统的性能在未来是否仍然流畅且相同。
5、尖峰测试
尖峰测试是测试应用程序对流量的反应的过程,类似于压力测试。除了在流量高时检查系统的行为外,还用来测试其对流量突然减少的反应。
6、可扩展性测试
可扩展性测试的主要焦点是:确定软件在扩展方面的有效性。用来测试是否会支持用户负载的增加,并帮助计划软件系统是否需要额外的容量。
四、最好性能测试,你还需要知道的性能测试开展原则
性能监控是一个很大的话题。要从小处着手,然后慢慢增加更多复杂性。
以下是一些需要牢记的性能测试最佳实践:
1)负载测试应在开发过程的早期进行。这将有助于避免陷阱。还可确保应用程序按预期运行。
2)性能测试对于成功的项目和单个模块或单元都很重要。
3)为获的最佳结果,应进行多次性能测试并取平均值。
4)让产品、测试人员和开发人员参与创建测试环境。
5)基准性能提供了确定测试成功或失败的起点。
6)对通常的性能指标或测试参数进行超越。
7)性能测试环境应与其它测试环境隔离。避免干扰。最重要的是,确保只有合格的工人才能进行测试。
8)测试环境的一致性对于任何项目的成功都至关重要。
9)希望这四个领域——CPU、内存、磁盘和网络能够帮助你入门。
五、做好性能测试,再为你补充你需要知道的最常见的性能测试问题
1、加载时间差
加载时间是指软件启动所需的总时间,必须保持在最低限度。虽然有些应用程序无法在一分钟内加载,但最好尝试在几秒钟内实现加载时间。
2、响应时间差
响应时间是指用户将数据上传到软件所需的总时间。用来必须很快,因为糟糕的响应时间会导致他们失去兴趣并卸载应用程序。
3、编码错误和硬件问题
软件系统中的障碍,包括编码和硬件问题,会影响其整体性能。解决它唯一关键是检测问题的根源并进行修复。
4、网络瓶颈
最后一个需要关注的资源利用率指标是“网络”。如今,随着在云上运行的分布式应用程序的增长,这变的更加重要。需要注意的是:
网络延迟——通过网络连接发送数据包所需的时间
网络往返——由你的应用程序生成的客户端-服务器请求和响应
数据传输——从浏览器传输到网络服务器的信息量。
以前,现在以及将来,性能测试都会是提高测试人员薪资的重要筹码。因为性能测试一把来说,比人们的自动化测试还高一级,薪资是相当不错。