终端用户视角下的性能测试，体验与度量的融合

传统的性能测试的度量标准是什么

响应时间（Response Time）：

这是从客户端发出请求到接收到完整响应所需的时间。响应时间是衡量系统性能的重要指标，特别是在面向用户的应用中，因为它直接影响用户体验。
而用户体验的度量原则如下：
3秒原则：对于大多数Web应用和交互式应用，90%的接口响应能在3秒内通常被认为是理想的，能够提供流畅的用户体验。
5秒原则：5秒内的响应时间对于多数用户而言仍然是可接受的，尽管可能会感觉到轻微的延迟。
8秒原则：8秒通常是用户开始感到不耐烦的临界点。超过此时间，用户流失率显著增加。

每秒查询率（Queries Per Second）：

它衡量的是一台服务器每秒钟能够响应的查询次数。这个指标主要用于描述服务器处理查询请求的能力，特别适用于那些主要职责是接收和处理查询的系统，比如数据库服务器、DNS服务器或其他专注于查询服务的组件。
度量标准如下

• 对于一般的Web应用，QPS可以从几十到几千不等，具体取决于应用的性质和规模。
• 对于高性能的数据库系统或云服务，QPS可能高达数万甚至数十万次。

吞吐量（Throughput）：

表示单位时间内系统能够处理的请求数量，通常以每秒的事务数（Transactions Per Second, TPS）、点击数（Hits Per Second, HPS）或查询数（Queries Per Second, QPS）来衡量。

并发用户数（Concurrency）：

是指系统同时处理的活跃用户数量。它可以帮助评估系统在高并发访问下的性能和稳定性。

CPU使用率（CPU Utilization）：

衡量处理器的繁忙程度，即CPU在单位时间内用于处理任务的时间百分比。

内存使用率（Memory Utilization）：

表示系统中可用内存与已分配给应用程序的内存的比例。过高的内存使用率可能导致系统响应变慢或出现内存泄漏等问题。

I/O操作（Input/Output Operations）：

包括磁盘读写操作的频率和速度，以及网络数据传输速率，它们对数据库和文件系统密集型应用的性能有重要影响。

网络延迟（Network Latency）：

是数据包从源地址到达目的地所需的时间，对分布式系统和互联网应用的性能至关重要。

错误率（Error Rate）：

表示在特定时间段内发生的错误请求占总请求的比例，是系统可靠性和稳定性的一个指标。

以用户感受为核心的性能指标升级

在我多年的从业经历中，我深刻认识到性能并非仅是一组冷冰冰的技术指标，而是最终落实为终端用户切身的感受。这种感受源于用户与系统的每一次互动，特别是当系统响应迟缓，导致用户在期待与现实之间产生落差时，性能问题便变得尤为显著。

例如，在一年一度的购物狂欢节——双11期间，用户在抢购心仪商品时，最直观的体验莫过于支付环节的顺畅与否。当支付按钮反复点击却无响应，那种焦躁与失望感油然而生，这时，性能问题不再抽象，它成了用户心中挥之不去的阴影。

性能，本质上是一种主观体验，它随个体差异而变化。尽管专业测试人员对性能有着严谨的定义和标准，但在真实的使用场景中，当系统面临高负载挑战，连最基本的功能都无法保障时，任何技术上的优越性都将黯然失色。

在定义性能指标时，我们应超越单一视角，采取更加全面和用户导向的方法：

用户感知层面：以终端用户的真实反馈为出发点，将用户体验置于首位。
硬件资源层面：考虑现有硬件配置的限制，优化资源利用效率。
系统单元层面：分析各组件资源消耗，确保系统内部协同高效。
外部服务层面：考量第三方服务的稳定性与性能，避免成为系统瓶颈。

性能优化是一个持续的过程，它要求我们在项目早期阶段就开始规划，从设计之初就融入性能考量，而非事后补救。这是一项挑战，特别是在资源有限、环境多变的条件下，但正如任何技能的成长一样，持之以恒的努力定能带来显著的提升。

这样的表述既强调了性能测试与用户体验的紧密关联，也提出了一个更为全面的性能指标定义框架，同时鼓励持续优化和早期介入的重要性。

站在用户的角度上来说，用户关注的是什么？

• 响应时间（Response Time）
• 每秒查询率（Queries Per Second）
  基于此实际性能测试过程中，需要去关注用户层面的指标，当然实际测试执行过程中不同业务和不同时间所需要的性能指标是差异化的。

1.响应时间的差异化

• Web应用
  2-5-10原则：2秒以内响应被认为是快速的，5秒以内是可接受的，而10秒是许多用户愿意等待的极限。
• 移动应用
  移动应用的响应时间期望通常与Web应用相似，但考虑到移动网络的潜在延迟，有时标准会稍微放宽。
• 游戏和实时应用
  对于游戏和需要高度实时性的应用，响应时间可能需要更低，例如100毫秒或以下，以减少输入延迟。
• 数据密集型应用
  对于数据密集型或计算密集型应用，如大型数据库查询或科学计算，响应时间可能较长，但仍需在合理范围内，以确保工作效率。
• 工业自动化和控制系统
  在这类系统中，响应时间可能需要精确到毫秒级别，以确保系统的实时性和安全性。

1.每秒查询率的差异化

不同行业和应用领域对QPS的要求各不相同。例如，金融交易系统可能需要极高的QPS以保证实时交易的顺畅，而小型企业网站的QPS需求则可能相对较低，在实际应用中，QPS的度量标准需要根据具体的服务类型和业务需求来确定。通常，系统架构师和运维团队会设定一个目标QPS，以确保系统能够在预期的负载下稳定运行

文章原创首发于微信公众号 软件测试微课堂，更多内容欢迎关注微信公众号查看