本片文章来自扬帆 EasonYang大佬针对性能测试相关业务知识概论,将大佬两篇文章进行汇总分享,
继自动化之后,再讲讲性能测试。相对于自动化,性能涉及的领域会更加广泛,比如架构、中间件、代码、监控等等。正因如此,本系列充其量也只能探其一二,权当给大家做个参考。话不多说,开始正文。
01. 性能及性能测试
提到性能,很多人会想到压测,再想到 LoadRunner 或 JMeter,但它们只是性能测试领域里很小的一部分。那么什么是性能呢?从用户的角度看来,当我们在使用一个应用(Web 或 APP)的时候,如果它能够在较短的时间内,给到相应的操作反馈,我们就认为这个应用的性能是好的。所以简单的性能可以理解为:系统处理用户请求所需的时间。
再扩展一下,有两个差不多功能的应用 A 和 B。A 在运行时,需要占用 50% 的 CPU,以及 300M 的内存;B 在运行时,只需要占用 30% 的 CPU,以及 100M 的内存。即便它们的反馈时间一样,我们肯定也认为 B 的性能比 A 更好。所以完善一下性能的定义:系统处理用户请求所需的时间以及消耗的资源。
性能主要包含两类关键指标:时间和资源。单一系统的性能指标在不同条件下的表现也不同,比如打开一个含有十张图片的相册,和打开一个含有一万张图片的相册,性能表现上肯定会有差异。因此在谈论性能的时候,还要加上相关场景的设定。那么所谓的性能测试就是:评估系统在特定场景下性能指标的测试方法。
对性能的容忍度在不同场景下的要求也不一样。比如我们购买一件商品,通常希望能够尽快下单成功,如果提交购买的页面一直在 Loading,很有可能就会放弃下单;而当我们需要下载一份历年的购买记录,即便等待 1-2 分钟,一般也可以接受。所以性能好坏的评价标准,其实是一个体验问题。
基于此,有很多性能优化手段并非以提升处理能力的方式来实现,而是在用户体验层面做出调整。比如较为常见的下载进度条、骨架屏、图片延时加载等等,先给到用户一个“我已经开始响应”的暗示,再逐步完成整个请求,让用户在主观感受上觉得会“更快”。关于这点,我们在后续的性能优化技术部分再慢慢展开。
02. 常见性能概念
我们来设置如下场景:景点有 3 个售票窗口,每个窗口 1 分钟可以接待 4 位游客。淡季时,景点每分钟迎来 3 位游客,那么窗口的接待效率完全可以满足要求,所有游客都能快速取票;旺季时,景点每分钟迎来 16 位游客,而窗口的最大接待量为 12人/分钟,这时必然会产生排队现象,部分游客就会因为排队时间过久而放弃。
在上面这个场景里,单个游客从开始排队到拿到门票的这个过程,我们称之为一个“事务”(Transaction),窗口每分钟可以完成 4 个事务,即代表系统处理每个事务的处理时间是 60/4 = 15s。游客在过程中花费的时间,我们称之为响应时间(RT,Response Time),在淡季时,游客因为完全不需要排队等待,响应时间等于事务处理时间,即 RT = 15s。
景点在单位时间内迎来的游客数,我们称之为请求量(RPS/RPM,Requests per Second/Minute)。比如淡季时每分钟景点到达的游客数是 3 ,即 RPS = 0.05/s 或 RPM = 3/min。景点在单位时间内可以完成的事务数,我们称之为吞吐量(TPS/TPM,Transactions per Second/Minute)。如上例,每分钟景点完成 3 个游客的接待,即 TPS = 0.05/s 或 TPM = 3/min。RPS/RPM 代表的是请求侧的输入频率,而 TPS/TPM 代表的是服务侧的处理效率。
还有一个类似的概念是点击量(HPS/HPM,Hits per Second/Minute)。比如景点需要靠班车才能抵达,每分钟一班,每班可载送 6 名游客,我们理解为一次运载(点击)带来 6 次游客访问(请求),所以此时 RPS = HPS * 6。HPS 与 RPS 的关系,更像是一种总与分的关系,但在实际应用中不太常见,有所了解即可。
对应的,TPS 也有一个相伴的概念是查询量(QPS/QPM,Queries per Second/Minute)。比如每位游客在购票时包括三个步骤:询问票价、提交证件、申请发票,我们理解为一次购票行为(事务)对窗口(系统)的查询量为 3,所以此时 QPS = TPS * 3。QPS 的定义有时比较模糊,也经常 与 TPS 混淆,不用过于在意。
03. 进一步理解
现在我们把每分钟的游客数提升到 12(假定游客以相同间隔时间匀速到来),刚好达到景点的最大接待量,窗口完全没有空闲时间,持续不停地在运转,游客仍然不需要排队,所以 RT 依然是 15s,而景点的 TPM 则达到了最高,为 12/min,我们称之为最大吞吐量。
当然,这种匀速的情况比较理想化,现实中往往不会如此。继续前面的案例,景点每分钟仍然有 12 位游客到达,但并不是匀速的。比如某个特定分钟内,第 1s 就来了 12 位游客,后面 59s 一个也没有来。这 1s 的时间,我们把它叫做访问高峰期,其余的 59s 叫做访问空闲期。
这时每个窗口会有 4 位游客同时到达,排在第一位的游客只要 15s 就可以完成取票,而第二位游客需要排队等待 15s,加上取票的 15s,总共要用 30s 才能完成取票,即 RT = 30s。以此类推,第三位游客 RT = 45s,第四位游客 RT = 60s,他们的平均响应时间就是 (15s + 30s + 45s + 60s)/4 = 37.5s。
而游客的耐心总是有限的,假设他们能够忍受的最长等待时间是 50s,那么在上面的情形下,第四位游客会因为等待时间过长而离开,我们把这个最长等待时间称之为连接超时时间。最终有 75% 的游客成功取票,那么我们就说成功率 = 75%,反之,失败率 = 25%。
到了旺季,每分钟的游客数上升到了 16(RPM = 16/min),超过了景点的最大接待量,那么会有部分游客的等待时间 > 连接超时时间,相比淡季时成功率下降,失败率上升。而窗口由于源源不绝的游客到来,TPM 一直维持在 12/min,因此可知,当 RPM > TPM(或 RPS > TPS)时,系统处于超载状态,失败率就会提高。
04. 全链路性能测试
前面提到,性能主要包含时间和资源两个指标。为了继续说明问题,以一次 Web 访问为例(比如在浏览器中输入 www.test.com),来看看其中到底发生了什么(这也是一道经典的面试题)。
首先由 DNS 服务器将域名解析为 IP 地址,而后客户端(浏览器)与该 IP (服务端)建立 TCP 连接。连接成功之后,客户端开始向服务端发送请求。服务端通常拥有一个网关,将请求动态分派至集群中的某个服务器。服务器接收到请求,执行相应的代码逻辑,并从数据库中获取数据,经过加工处理之后返回内容至客户端。
如果返回的是一个 HTML 文档,客户端往往还需要进一步下载 JS、CSS 以及图片等静态资源,以便完成对整个页面的渲染;如果是一个仅用于更新部分数据的异步请求,客户端一般也会进行局部区块的更新和渲染。待以上步骤全部完成之后,这次访问才算是真正结束。
整个过程的性能表现可以分成两个部分:前端和后端。前端从客户端接收服务端的返回开始,至页面渲染完成结束;后端从客户端提交请求开始,至服务端返回内容结束。注意这里有个陷阱是,后端并非是从接收客户端请求开始的,因为还包含前面的网络时间。
前端和后端的性能测试有一个重大区别:前端性能与单个客户端相关,不需要考虑并发问题;而后端是共享资源,需要模拟多用户的状况。所以后端的性能场景设计和性能分析,往往比前端要复杂很多。不过我们在做性能测试的时候,可以独立进行前端或后端的验证,以此降低问题的复杂度。
虽然我们在提到性能的时候,经常把注意力放在了后端性能上,但从用户侧来看,性能是指端到端的表现,所以前端性能和后端性能同样重要。所谓的全链路性能测试,即指从客户端到服务端的完整链路测试,包括前端界面、网关、后端服务、中间件、数据库等,模拟了真实的用户访问场景。
全链路性能测试算不上是新的技术,应该说是一种新的方案。以往的单模块(单链路)、基于测试环境或拟真环境的性能测试方案,或多或少都会与生产环境的真实情况有所差异,导致性能测试结果的参考意义比较有限。所以全链路性能是一种基于生产环境、完整业务链、接近真实流量和数据的性能测试解决方案。
05. Web 性能评测
开篇的时候讲过,性能在一定程度上是个体验问题。所以 Web 的性能表现,并不是以页面完成全部渲染的时间来衡量的。那么又该如何去评价 Web 的性能呢?其实并没有一个“唯一”指标能够全面代表,我们需要从多个维度去做一个综合评价。比如以下常见指标:
-
FP(First Paint):首次绘制时间,即屏幕上开始渲染画面像素的起始时间。
-
FCP(First Contentful Paint):首次内容绘制,与 FP 的区别是绘制的是内容,比如文本、图片。
-
FMP(Fist Meaningful Paint):首次有效绘制,有效指根据某种算法定义的主要内容区块。
-
LCP(Largest Contentful Paint):最大内容绘制,最大的可视区块开始出现的起始时间。
FP 和 FCP 表示的是屏幕开始出现视觉变化的时间点,而 FMP 和 LCP 表示的是屏幕开始出现对用户“有意义”内容的时间点。有些情况下,Web 性能会以 FMP 或 LCP 来做评估。当然了,这不是硬性规定,开发者可以自行决定和通过埋点上报当页面加载到何种程度时,我们认为自己的应用已经达到“可用”状态。
有许多工具可以用于评测 Web 性能,比如 Lighthouse、WebPageTest 等,甚至也可以使用 Chrome 自带的 DevTools 性能分析器。这些工具除了帮助我们得到一些指标值,还可以获得关于如何优化该指标的建议。以 Lighthouse 为例,报告给到了性能的评分、FCP/LCP 的值以及多项优化措施建议。
此外,图中还可以看到另外几个指标值:Total Blocking Time(TBT)、Cumulative Layout Shift(CLS) 以及 Speed Index。TBT 指的是页面不可交互时间,对响应有要求的应用具有重要参考;CLS 指的是页面的累计布局偏移,用于衡量页面的稳定性;Speed Index 则是一个综合指标,表示用户感受到的加载速度。
这些指标主要来自 Google Web Vitals。Google 提出了三个主要用户体验衡量指标:LCP、FID 和 CLS(FID 需要交互,静态检查下用了 TBT 作为替代),感兴趣的小伙伴可以自行学习。相似的,多年前 Yahoo 也提出过 Web 优化的 23 条军规,流浏览器有个 YSlow 插件即是基于这些规则做出性能评价。
Google 和 Yahoo 提出的是一些“最佳实践”,这些实践因为具备较好的参考价值而被广泛采纳,但并不意味着它们是需要被 100% 遵守的,这点需要辨明。另外,因为 Web 端的资源类指标(比如耗电等)在 PC 场景下相对不那么重要(个别时候也会有),所以这一节中也就未涉及关于资源指标的评测内容。
06. Web 性能优化
Web 的性能优化大致上可以从这几个方向去考虑:加载时序、请求数量、资源大小、缓存技术。
1)加载时序
加载时序的策略是,通过改变信息的加载顺序,来达到优化关键指标(FMP)的目的。比如常见的将 CSS 置于顶部(CSS 包含样式信息),以减少用户可见内容的渲染时间;以及将 JS 置于底部(JS 会阻断页面渲染),以避免加载过程出现“白屏”或“中断”。
分步加载也是常用的方式。比如页面上有张图片较大,加载时间可能较长,那么可以预先生成较小的缩略图,在访问页面时先加载缩略图,而后“慢慢”下载原始图片,待完成之后再替换掉缩略图。这种方式通过在视觉上的快速反馈,来达到更好的性能体验,类似的方法还有 Loading 图标、骨架屏等。
还有一种重要技术是延迟加载(Lazy load,也称懒加载)。比如页面的篇幅比较长,需要上下滚动屏幕才能完整查看,那么当访问页面时,只需要加载首屏内容即可,非可见区域的资源可以暂时不予下载,以节省时间和资源。延迟加载技术对移动端应用的作用尤为明显,为用户节约了大量的宝贵流量。
2)请求数量
在一次 HTTP 请求里,会有两个方面影响到性能:第一个是通信消耗的时间,包括域名解析、网络传输、TCP 连接等耗时;第二个是请求、响应本身会携带一些头信息,数量多了以后也会造成不必要的消耗。所以在成本可控的情况下,应当尽量减少 HTTP 的总体请求数。
我们一般通过合并同类资源的方式来达到这个目的。比如页面上存在很多小图标,那么可以把这些图标都放在一张图片上,通过 CSS Sprite 获取所需的图片区域,类似的还有合并 CSS、JS 等。不过也有观点认为,在当前的网络环境下,请求数量对整体性能的影响并不大,这点也就没有那么被重视了。
3)资源大小
GZIP 是最常用的一种 Web 资源压缩技术,通常可以拥有 3~10 倍的压缩比率,大幅减少传输所用的带宽和时间。GZIP 多用于 HTML、CSS 和 JS 的压缩,对图片的作用比较有限。原因是 GZIP 所采用的算法,更适用于重复度比较高(比如文本)的内容,但是图片的重复度往往不大。
另外一种压缩方法是去除 CSS 以及 JS 文件中的空格(空格并不影响脚本执行),也可以在一定程度上减少这两类文件的体积,这就是为什么我们在生产环境查看 CSS、JS 的时候,它们的文本“糊”在一起的原因。现在的很多前端构建工具(比如 Webpack)都可以支持去除空格的操作。
4)缓存技术
浏览器本身默认会对静态资源进行缓存。客户端识别响应头中的 Expires 和 Cache-Control 等信息,来决定要使用缓存中的资源或是重新从服务端获取。我们在浏览器中使用 Ctrl + F5,即是在要求浏览器强制更新所有资源。浏览器的静态资源缓存机制实际还比这复杂很多,这里不做扩展。
CDN(内容分发网络)也可以算是某类“缓存”机制。它的基本原理是,将静态资源分发到多个区域的节点上,当用户请求这些资源时,CDN 可以根据各个节点的负载、与用户的距离等因素,实时将请求定向到离用户最近(最快)的一个节点上,以提高用户访问的整体速度。
最后: 下方这份完整的软件测试视频教程已经整理上传完成,需要的朋友们可以自行领取【保证100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。