最近有朋友在准备性能测试方向的面试，分享了自己的简历，然后群友作为面试官，提出来多个面试题目，我选了其中最具代表性的 6 个面试题，并提供了详细的答题思路，希望对大家有所帮助。

性能、负载、压力、稳定性测试，有什么区别？

这四类测试的本质区别在于测试目标不同。

性能测试关注的是系统在 “正常负载” 下的表现，而压力测试、负载测试和稳定性测试则分别侧重极限承载能力、负载曲线响应、以及系统长时间运行的稳定性。

具体来说，性能测试用于回答 “系统是否满足当前性能需求”，例如日常请求下接口响应时间是否在 500ms 以内。负载测试则是在不同并发压力下逐步升压，观察系统响应时间、吞吐量和资源使用趋势，用于描绘性能曲线。压力测试则将负载推到极限甚至超出承受范围，测试系统在高压下是否宕机，以及是否能平滑降级或自动恢复。稳定性测试关注时间维度，评估系统在长时间运行下是否存在资源泄露、性能下降或异常重启等问题。

在我的项目中，我们对电商优惠券系统进行了一系列完整的性能验证。例如，在双 11 活动前，我们通过负载测试确定系统在 1000 并发下的响应稳定性；通过压力测试确认系统极限 TPS；同时通过 8 小时的稳定性测试，发现了 Redis 连接池长时间使用后泄露的问题并进行了修复。

性能测试平台你负责了哪些模块？平台如何服务多业务线？

我在性能测试平台中负责核心功能设计与开发，目标是实现业务方自助压测、数据可视化和多版本性能回归分析。

平台设计之初，我们聚焦于 “提升使用门槛低” 和 “结果可解释性强” 两个目标。在具体实现中，我主导了流量录制与回放系统的设计，通过参数模板化替换技术，帮助业务快速生成真实场景压测用例。同时，实现了基线版本标记功能，允许用户指定历史构建作为对比基线，平台在测试结束后自动生成性能回归报告，清晰展现每项指标的变化趋势。

为了服务多业务线，我们通过模块化设计将平台拆为任务管理、执行引擎、数据分析三个子系统，并通过 API 接口支持各类自动化流水线接入。业务方可以在平台上通过 YAML 或图形界面发起压测，也可以将其集成到 CI 流程中，实现日常构建级别的性能验证。

平台目前已服务 70+ 内部用户，支撑 2000+ 次压测任务，成为部门级核心基础设施之一。其可复用、低维护、高交互的特点，也极大提升了团队协作效率。

请描述一次你主导的性能调优经历

在我主导的调优案例中，我们成功将关键接口的 P99 响应时间从 3 秒降到 600 毫秒，提升了 3 倍系统吞吐。

问题起源于活动预热期间，某推荐接口在高并发下响应变慢，部分请求甚至超时。我们首先使用 APM 工具和链路追踪系统分析了端到端响应流程，确认接口本身处理时间异常。进一步查看服务日志发现，大量请求在访问缓存时发生阻塞，而缓存 miss 后的数据库查询存在慢 SQL。

接着，我们采用火焰图分析 CPU 时间分布，发现热点集中在 Redis 获取某类 key 上。这些 key 对应的用户特征数据高度集中，形成热点，造成单点锁竞争。同时数据库端也因缺少联合索引导致查询慢。

优化策略上，我们对热点 key 进行了拆分，并使用 Lua 脚本减少 Redis 往返次数。同时，在数据库端补全索引，改写慢查询逻辑。最终，我们通过压测验证接口 P99 降至 600ms，系统整体吞吐量提高 3 倍以上，保障了后续大促活动稳定上线。

如何实现流量录制与替换？遇到什么难点？

流量录制与替换的关键在于构造一个 “可复现、高还原度、可维护” 的压测流量。

在平台中，我设计了一套流量采集模块，能够实时拦截线上或预发布环境中的业务请求。采集下来的请求以 JSON 格式存储，并配套记录响应体和上下游依赖信息。随后进入解析与模板化阶段，我们使用正则表达式和 JSONPath 技术抽取动态参数，比如用户 ID、时间戳、token 等，并将其替换为占位符。

在替换逻辑中，我们引入了模板引擎（Jinja2）来处理复杂结构，确保每次回放都能自动生成合法的请求数据。为了提升准确性，我们还对关键字段（如签名、加密字段）进行了预处理逻辑，保障录制和回放数据的一致性。

最大的挑战在于接口间存在依赖关系，如 “下单接口” 依赖 “用户登录” 生成的 token。为此，我们建立了一个变量注入系统，支持回放阶段动态调用其他接口获取依赖值，保证测试链路顺畅。通过该模块，业务方不再需要手写复杂脚本，压测的便捷性与稳定性显著提升。

AI Agent 巡检系统如何实现自动化日志分析？

AI Agent 系统的核心目标是 “让机器代替人完成故障巡检和初步定位”，实现值班自动化和响应提速。

我基于 FastAPI 框架搭建了一个轻量级服务端，结合 LangChain 实现了大模型对日志的自然语言处理能力。巡检任务启动后，系统会自动拉取对应服务的日志数据，并调用内置分析器对日志进行聚类、异常检测和关键错误摘要提取。

在这一过程中，大模型负责识别异常模式、归因错误来源，并根据预设提示词生成清晰的诊断报告。例如当日志中出现多次堆栈 trace 或 error 关键字时，模型会结合上下文判断是否为超时、依赖失败或资源耗尽等问题，并给出排查建议。

整套流程从告警触发到分析完成不超过 5 分钟，最终将报告通过企业微信机器人发送至责任人群组。上线后，平均故障处理时间从 30 分钟缩短至 5 分钟，周末值班人数从 2 人减少到 1 人，大幅降低了人工干预成本。

你们是如何在 CI/CD 中集成性能测试的？

我们在 CI/CD 流程中集成了 “轻量性能回归检测”，实现了测试左移与自动拦截。

在日常开发流程中，性能问题往往被视为 “上线前才关心” 的事情，导致问题积压难以及时发现。为了解决这个痛点，我们在构建阶段引入了压测平台的 API，支持在 MR 合并前或构建阶段，自动对关键接口进行轻量压测（例如运行 1 分钟/200 并发的短压任务）。

平台会将测试结果与历史基线版本进行对比，若发现响应时间、错误率等关键指标回退超过阈值（如 15%），则直接打断构建流程，并将性能回退报告发送给开发者。同时，所有性能数据会沉淀在可视化平台中，供后续版本对比分析。

该机制推动了性能问题 “前置发现、及时回归”，也促使开发团队在日常开发中更加关注接口设计质量。实施后，我们的构建失败率略微上升，但用户反馈问题大幅减少，构建效率提升 40%，测试左移效果显著。

FunTester 原创精华

从 Java 开始性能测试

故障测试与 Web 前端

服务端功能测试

性能测试专题

Java、Groovy、Go

测试开发专题

测试理论、FunTester 风采

视频专题