「性能测试」概论

爱吃香菜

于 2024-08-21 14:59:48 发布

阅读量407

点赞数 9

分类专栏：软件测试程序员自动化测试文章标签：软件测试功能测试测试工具性能测试压力测试程序员单元测试

本文链接：https://blog.csdn.net/wx17343624830/article/details/141393992

版权

软件测试同时被 3 个专栏收录

2998 篇文章 39 订阅

订阅专栏

程序员

2650 篇文章 2 订阅

订阅专栏

自动化测试

2487 篇文章 14 订阅

订阅专栏

本片文章来自扬帆 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 场景下相对不那么重要（个别时候也会有），所以这一节中也就未涉及关于资源指标的评测内容。