当前位置：首页 > news >正文

测试类型术语，使用指标，计算方式，使用场景总结

news 来源：原创 2025/5/16 9:26:12

系统测试（System Testing）包括负载测试、性能测试、压力测试、安全性测试等子类型。

定义：在完整集成的系统上验证功能和非功能需求是否满足要求，属于黑盒测试。
测试指标：功能正确性、系统稳定性、负载能力（如并发用户数）、性能（响应时间、吞吐量）、安全性、兼容性等。
过程：在集成测试之后、验收测试之前进行。
框架/工具：Selenium（功能测试）、JMeter（性能/负载测试）、Postman（API测试）等。

验收测试（Acceptance Testing）分为用户验收测试（UAT）、Alpha测试、Beta测试等

定义：由客户或用户验证系统是否满足业务需求，
测试指标：业务需求覆盖率、用户体验（界面友好度）、端到端流程正确性。
过程：在系统测试完成后
框架/工具：手动测试为主，工具如TestRail（用例管理）、Jira（缺陷跟踪）。

用户验收测试（UAT）

定义：用户验证系统是否符合实际业务场景的最终测试。
测试指标：业务流程正确性、用户操作流畅性、数据准确性。
过程：
- 在系统测试后执行，通常分为Alpha和Beta测试。
- Alpha测试在受控环境（开发环境）进行，Beta测试在用户真实环境进行。

Alpha测试与Beta测试

Alpha测试：由开发者或QA团队在开发环境中执行，检查界面错误、基本功能等。
Beta测试：由真实用户在真实环境中执行，收集反馈以改进产品。

负载测试（Load Testing）模拟正常至峰值负载。

定义：评估系统在预期负载（并发用户数或事务量）下的表现，
测试指标：响应时间、吞吐量、资源利用率（CPU、内存）。
工具：JMeter、LoadRunner。

性能测试（Performance Testing）

定义：评估系统在特定条件下的响应速度和稳定性。
测试指标：响应时间、错误率、资源使用效率。
与负载测试的区别：性能测试关注系统能力上限，负载测试关注特定负载下的表现。

压力测试（Stress Testing）

定义：测试系统在超出极限负载下的稳健性，如高并发或资源耗尽。
测试指标：系统崩溃阈值、恢复能力（如MTTR）。
与负载测试的区别：模拟极端条件，而非正常场景。

自动化测试：

适用场景：回归测试、重复性任务、性能/负载测试。
框架/工具：Selenium（Web）、Appium（移动端）、TestNG（框架）。

1. 负载测试和压力测试使用的指标不同吗？

负载测试（Load Testing）和压力测试（Stress Testing）确实有不同的关注点，但它们的很多指标是重叠的，例如：

吞吐量（Throughput）
响应时间（Response Time）
错误率（Error Rate）
CPU、内存、磁盘、网络带宽等资源利用率（Resource Utilization）

然而，在 具体应用上，它们对指标的关注点不同：

测试类型	关注的核心指标	是否关注吞吐量和响应时间？	示例
负载测试	吞吐量、响应时间、错误率、资源利用率	✅ 是	目标：在1000个并发用户下，平均响应时间 < 2秒，吞吐量 ≥ 500 TPS（Transactions Per Second）。
压力测试	系统崩溃点、错误率、恢复能力（MTTR）	⚠️ 部分关注，但更关注极限负载	目标：找到服务器的极限负载，例如 2000个用户时系统崩溃。或者模拟 CPU 100% 占用，观察恢复时间。

示例：不同测试对指标的关注

负载测试

场景：网站在 1000 并发用户 访问时，测量以下指标：

吞吐量：每秒多少个请求成功？（如 500 TPS）
平均响应时间：服务器返回数据的时间是否可接受？（如 2 秒内）
错误率：是否有大量失败请求？（应小于 1%）

压力测试

场景：找到服务器的极限：

并发用户增加到 2000 时，响应时间暴增，吞吐量下降到 100 TPS，服务器崩溃。
服务器崩溃后，恢复时间（MTTR） 是多少？是否会出现 资源泄漏，无法自动恢复？

结论

负载测试 主要衡量系统在特定负载下的性能，如吞吐量、响应时间、错误率。
压力测试 关注系统的极限，如崩溃阈值、恢复能力，虽然吞吐量和响应时间仍然重要，但它们更多是辅助手段，帮助分析崩溃点和瓶颈。

2. 这些测试使用的指标及其英文名、计算方法

以下是一些常见的指标、它们的计算方式及含义：

指标名称	英文名称	计算方法
吞吐量	Throughput (TPS/RPS)	`成功请求数 / 单位时间`（如每秒 500 个事务）
响应时间	Response Time (RT)	`请求完成时间 - 请求开始时间`（单位：毫秒 ms）
错误率	Error Rate	`(失败请求数 / 总请求数) * 100%`
CPU 使用率	CPU Utilization	`CPU 使用时间 / 总 CPU 时间 * 100%`
内存使用率	Memory Utilization	`已用内存 / 总内存 * 100%`
磁盘 I/O	Disk I/O	`读/写操作次数或读/写速率`
网络带宽	Network Bandwidth	`传输数据量 / 单位时间`
最大负载	Maximum Load	`系统可承受的最大并发用户数`
崩溃阈值	Breaking Point	`达到最大负载时，系统性能急剧下降的点`
平均故障修复时间	Mean Time to Repair (MTTR)	`总修复时间 / 失败次数`
平均故障间隔时间	Mean Time Between Failures (MTBF)	`系统正常运行时间 / 失败次数`

示例计算

示例 1（吞吐量）：

1分钟内处理了 6000 个请求
吞吐量 = 6000 / 60 = 100 TPS

示例 2（错误率）：

总请求数 10000，失败请求数 50
错误率 = (50 / 10000) * 100% = 0.5%

示例 3（MTTR）：

服务器崩溃了 5 次，每次修复时间分别是 10、8、12、9、11 分钟
MTTR = (10 + 8 + 12 + 9 + 11) / 5 = 10 分钟

3. 性能测试和负载测试、压力测试的关系？它们的工具、指标、参数是否相同？

是的，性能测试、负载测试和压力测试在工具、指标和参数上有很大的重叠，但关注点不同。

三者的关系

性能测试（Performance Testing） 是一个更广泛的概念，包含了 负载测试、压力测试、稳定性测试等。
负载测试 和 压力测试 是 性能测试的子集，专门关注不同的系统表现。

测试类型	关注点	常用工具	关键指标
性能测试	评估系统整体性能	JMeter、LoadRunner、Gatling	响应时间、吞吐量、错误率
负载测试	评估系统在正常负载下的表现	JMeter、LoadRunner	吞吐量、CPU、内存
压力测试	评估系统在极限负载下的稳定性	JMeter、Chaos Monkey	崩溃阈值、MTTR、系统恢复能力

工具是否相同？

是的，它们通常使用相同的工具，例如 JMeter、LoadRunner、Gatling。

JMeter：用于 Web 应用、API、数据库测试，适用于所有性能测试类型。
LoadRunner：企业级工具，支持更多协议，如 SAP、Oracle 等。
Gatling：基于 Scala，适用于开发人员自动化性能测试。

大部分测试指标相同，如：吞吐量，响应时间，错误率。资源利用率，但不同的测试关注的 参数设置 可能不同：

负载测试：并发用户数：100 ~ 1000（模拟正常负载）Ramp-up 时间：10~60秒（平稳增加流量），持续时间：如 30分钟 观察稳定性
压力测试：并发用户数：从 100 开始，逐步增长到 系统崩溃，CPU/内存限制：手动降低系统资源，测试抗压能力，故障恢复时间（MTTR）：测试系统自我修复能力

4. 总结

负载测试和压力测试使用的指标有部分相同，但关注点不同：
- 负载测试：关注 系统在设定负载下的表现
- 压力测试：关注 系统崩溃点和恢复能力
三者的关系：
- 性能测试 是一个大概念，包含 负载测试、压力测试。
- 所有测试通常使用相同的工具（JMeter、LoadRunner）。
- 测试指标相同，但参数设置不同（负载测试关注稳定，压力测试关注极限）。

1. 服务器崩溃的定义是什么？是不是彻底瘫痪？

服务器崩溃 并不一定意味着服务器彻底瘫痪，而是指 服务器无法正常处理请求，导致服务质量严重下降，甚至完全无法响应。常见的服务器崩溃现象包括：

(1) 服务器性能下降，但仍在运行

吞吐量下降（如从 1000 TPS 降到 100 TPS）
响应时间剧增（如从 500ms 上升到 30s）
错误率大幅上升（如 5% → 50%）
部分请求超时或失败（HTTP 500、502、503）

(2) 服务器完全停止响应

所有请求返回 HTTP 500 / 502 / 503 / 504
吞吐量下降到 0（即所有请求都失败）
CPU 或内存使用率达到 100%，系统无法处理新请求
日志中出现大量超时错误（如数据库连接失败、线程池耗尽）

所以，服务器崩溃不一定是硬件损坏，而是系统进入严重异常状态，影响正常运行。

2. 服务器的恢复时间（MTTR）指的是什么？

MTTR（Mean Time to Repair，平均修复时间） 用于衡量 服务器从崩溃状态恢复到正常工作的时间，通常是指：

服务器恢复到吞吐量接近正常水平
错误率恢复到正常范围
响应时间恢复到可接受范围

恢复过程示例

假设：

正常吞吐量：1000 TPS
崩溃时吞吐量：100 TPS
系统完全恢复时间：5 分钟

那么，MTTR = 5 分钟，即系统在 5 分钟内恢复到 1000 TPS。

如何衡量恢复？

可以通过 吞吐量 vs 时间曲线 观察：

时间（分钟） | 吞吐量（TPS）
---------------------------
0            | 1000
2            | 800
4            | 300
5            | 100
6            | 500
8            | 1000  (完全恢复)

MTTR = 8 - 5 = 3 分钟（服务器从最低点恢复到正常）

3. 错误率是否受并发影响？

是的，并发用户数增加通常会导致错误率上升，但不同系统的表现不同。影响错误率的因素主要包括：

服务器资源耗尽
- 线程池、数据库连接池耗尽 → 502 / 503 错误
- CPU 100% → 无法处理新请求
- 内存溢出（Out of Memory） → 服务器进程崩溃
超时问题
- 由于高负载，响应时间增加，部分请求超时
- 服务器可能主动拒绝连接（如 Nginx 限制最大连接数）
数据库崩溃
- 并发查询太多，数据库锁冲突或死锁
- 数据库连接池耗尽，导致应用无法查询数据