性能测试里的“错误率”，你真的理解了吗？

📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

---

在做性能测试时，我们经常会盯着 响应时间、吞吐量、并发数 这些指标，但有一个同样重要，却常常被忽视的指标——错误率（Error Rate）。

很多系统看似响应很快、吞吐量很高，但如果错误率居高不下，那说明系统其实根本“扛不住”。今天我们就来聊聊性能测试中的错误率。

什么是错误率？

👉 错误率 = 请求失败的比例

举个例子：

• 
  
• 在一次压测中，系统共收到了 1000 个请求
• 
  
• 其中有 20 个请求失败（返回 500 错误）
• 
  
• 那么错误率就是：

简单来说，错误率就是用户请求成功率的“反面指标”。

为什么错误率很重要？

稳定性的核心体现

• 响应再快，如果很多请求都失败了，对用户来说毫无意义。
• 想象一下：你点开购物车，页面 1 秒加载出来，但显示“系统异常，请稍后再试”，这体验就崩了。

暴露潜在问题

错误率往往是系统压力过大、资源耗尽、代码 bug 或依赖服务不稳的“信号灯”。

有时候 RT、吞吐量都看起来正常，但错误率升高了，就说明背后可能已经有隐患。

与 SLA 挂钩

很多系统的 SLA 里会明确规定：

错误率必须低于 0.1%

或者 99.9% 的请求必须成功

一旦超过这个阈值，就算响应再快，也不算达标。

常见错误类型

在性能测试中，常见的请求错误包括：

• HTTP 错误：500（服务器错误）、404（资源不存在）、502（网关错误）
• 
  
• 超时错误：请求超过设定时间没有响应
• 
  
• 连接错误：数据库连接池耗尽、网络断开
• 
  
• 业务错误：接口返回了业务异常信息（例如“库存不足”）

👉 测试人员要学会区分，是 系统压力导致的错误，还是 正常业务逻辑错误。

使用场景

高并发压测

当并发数逐渐增加时，错误率突然飙升，说明系统已经超过了承载极限。

回归验证

系统优化上线后，通过对比前后错误率，判断优化是否有效。

稳定性测试

长时间压测中，如果错误率持续上升，说明系统可能存在内存泄漏或资源回收问题

• 错误率 = 请求失败的比例
• 
  
• 它是衡量系统稳定性的重要指标，比单纯的响应时间更能反映真实体验
• 
  
• 错误率过高，说明系统已经不可靠，即使响应再快、吞吐量再高也没有意义

一句话总结：

👉 性能测试里，错误率是系统稳定性的晴雨表。没有低错误率，就没有好体验。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

​

​​​