测试面试及实用功能解读

在敏捷开发中，测试团队如何确保快速迭代下的测试僵盖率?

一、核心策略与实施方法

1. 分层测试与自动化策略

• 测试金字塔分层

  • 单元测试（占比70%）：开发人员编写，快速反馈代码逻辑问题（工具：JUnit、Pytest）。

  • 接口/服务测试（占比20%）：验证API功能、数据一致性（工具：Postman、RestAssured）。

  • UI/E2E测试（占比10%）：覆盖核心用户流程（工具：Selenium、Cypress）。

  • 自动化原则：优先自动化高频执行、高价值场景（如核心业务流），减少重复手工测试。

• 分层覆盖率指标

  • 代码覆盖率（JaCoCo、Coverage.py）>80% + 需求覆盖率（需求条目100%关联测试用例）。

2. 测试左移（Shift-Left）

• 需求阶段介入

  • 测试团队参与用户故事拆分，定义清晰的验收条件（AC）。

  • 使用行为驱动开发（BDD）工具（如Cucumber、SpecFlow）将需求转化为可执行的测试用例。

• 静态代码分析

  • 集成SonarQube、ESLint等工具，在代码提交阶段发现潜在缺陷。

3. 持续集成与持续测试（CI/CT）

• 流水线设计

  • 每次代码提交触发自动化测试（单元测试→接口测试→静态分析→构建部署）。

  • 工具链示例：GitLab CI + Jenkins + Docker（快速搭建测试环境）。

• 快速反馈机制

  • 失败测试实时通知开发人员（Slack/钉钉集成），阻断问题代码合并。

4. 基于风险的测试（Risk-Based Testing）

• 优先级排序

  • 根据功能模块的风险等级（如支付、鉴权）分配测试资源。

  • 使用「风险矩阵」评估影响范围（如高频率使用功能优先覆盖）。

• 探索性测试补充

  • 在迭代末期预留时间，针对复杂场景进行探索性测试（Session-Based Test）。

---

二、敏捷测试流程优化

1. 迭代计划阶段

• 测试任务拆分

  • 将测试任务拆分为「可并行执行」的子任务（如功能测试、性能测试）。

  • 使用看板（Jira、Trello）可视化进度，避免测试阻塞。

• 测试数据管理

  • 提前准备测试数据集（如Mock数据生成工具：Mockaroo、Faker）。

2. 迭代执行阶段

• 每日站会同步

  • 测试团队同步缺陷状态、阻塞问题，推动跨职能协作。

• 增量式测试

  • 开发完成一个功能模块后立即测试，而非等待迭代末期集中测试。

3. 迭代评审与回顾

• 缺陷根因分析（RCA）

  • 统计高频缺陷类型（如接口超时、数据格式错误），针对性优化测试用例。

• 覆盖率复盘

  • 使用工具（如TestRail）分析测试用例对需求的覆盖情况，补充遗漏场景。

---

三、关键工具与技术

场景	工具示例	用途
自动化测试框架	Selenium, Cypress, Robot Framework	执行UI/接口自动化测试
接口测试与Mock	Postman, WireMock, MockServer	模拟依赖服务，验证API逻辑
性能测试	JMeter, k6, Gatling	压测核心接口，发现性能瓶颈
测试覆盖率分析	JaCoCo, Istanbul, Coverage.py	统计代码覆盖率，识别未覆盖分支
缺陷与用例管理	Jira + Zephyr, TestRail, qTest	管理测试用例，跟踪缺陷闭环
环境容器化	Docker, Kubernetes	快速部署测试环境，隔离资源冲突

---

四、应对挑战的实战技巧

1. 时间不足时的取舍策略

• 优先级排序

  • 优先测试核心功能（如用户登录、支付流程），次要功能通过冒烟测试覆盖。

  • 使用「金丝雀发布」逐步验证新功能（仅部分用户可见）。

2. 需求频繁变更的应对

• 用例模块化设计

  • 将测试用例拆分为原子步骤（如“登录→添加商品→支付”），通过组合应对需求变更。

  • 使用数据驱动测试（DDT）分离测试逻辑与数据。

3. 跨团队协作

• 开发与测试结对

  • 开发人员编写单元测试，测试人员设计端到端场景，共享测试脚本。

  • 定期开展「缺陷预防」研讨会，减少重复问题。

---

五、成功案例参考

案例：电商App的敏捷测试实践

• 背景：两周一个迭代，需求变更频繁。

• 解决方案：

  1. 接口自动化覆盖80%核心链路（商品搜索→下单→支付）。

  2. 利用Docker快速搭建测试数据库，每次构建重置环境。

  3. 使用k6在CI流水线中执行性能基准测试。

• 结果：迭代内缺陷减少40%，测试覆盖率从60%提升至85%。

---

六、总结

在敏捷开发中，测试覆盖率的核心是“精准”而非“全面”。通过分层测试、自动化策略、持续反馈和风险驱动的方法，测试团队可以在快速迭代中：

• 确保核心功能稳定，

• 快速响应变更，

• 最大化测试投入产出比。
  最终目标是为用户交付高质量的可工作软件，而非追求100%覆盖率的“数字游戏”。

某在线支付系统在用户提交订单时偶尔出现“支付失败”的错误,但无法稳定复现。请描述你的排查思路。

1. 收集详细的错误信息

• 用户反馈：确认出现错误的具体场景，用户是否能够提供详细的错误提示、错误码或其他相关信息。
• 日志信息：收集系统的前端日志、后端日志、支付网关的日志等，重点查看出现错误时的系统状态和任何可能的异常信息。

2. 分析问题出现的频率与条件

• 时间和频率：确定错误发生的时间点（是否出现在特定的时间段或某个高峰期），是否与系统负载、并发量等有关。
• 用户设备和网络环境：了解支付失败是否与特定的设备、操作系统、浏览器或网络环境有关。比如，某些设备或浏览器可能导致支付请求失败。
• 订单的特征：确认是否支付失败与特定的订单信息有关，如订单金额、商品种类、优惠券、支付方式等。

3. 重现支付失败场景

• 模拟不同场景：尽量模拟多种支付操作环境（如不同的设备、浏览器、网络环境、支付方式等），观察是否能复现“支付失败”问题。
• 异常操作：测试用户在支付过程中可能进行的异常操作（如中途刷新页面、网络不稳定等），看看是否会导致支付失败。

4. 查看前端和后端日志

• 前端日志：检查前端页面提交支付请求时的日志，查看是否有接口请求失败、超时、请求格式错误等问题。
• 后端日志：重点查看支付系统后端处理支付请求的日志，是否有报错或异常（如数据库错误、支付网关返回错误等）。
• 支付网关日志：检查与支付网关（如支付宝、微信支付等）交互的日志，确认支付请求是否被正确发送并收到响应。

5. 检查支付网关和第三方服务状态

• 支付网关问题：检查是否支付网关或第三方支付平台的服务不稳定，导致偶尔支付失败。支付网关的宕机、响应慢或网络延迟都可能是原因。
• 支付请求参数：验证请求支付接口时传递的参数是否正确，是否符合支付网关的规范，包括金额、商户号、订单号等。

6. 性能和负载分析

• 系统负载：分析系统是否在某些高并发场景下出现性能瓶颈，导致请求超时或处理失败。
• 资源使用：查看服务器的资源（如 CPU、内存、磁盘 I/O、网络带宽）是否在错误发生时达到了瓶颈。

7. 查看数据库与事务管理

• 事务一致性：检查支付请求和订单状态的数据库事务是否一致，确保支付成功后的状态更新没有问题。
• 数据库错误：查看数据库日志，确保没有由于数据库连接池问题或查询失败导致的支付失败。

8. 检查重试机制与幂等性

• 重试机制：确认系统是否在支付失败时自动进行重试，并确保不会由于重试导致重复支付。
• 幂等性问题：检查支付请求是否具有幂等性，防止由于网络波动或请求重复提交造成系统异常（例如重复扣款或订单状态不一致）。

9. 测试支付失败后的回调处理

• 回调与通知机制：确保支付成功后的回调处理是否可靠，确认支付状态更新逻辑是否正确，避免支付成功后状态未正确更新，导致订单显示支付失败。

10. 开展压力和负载测试

• 并发压力测试：模拟大规模并发支付请求，检测系统在高并发下的稳定性和性能瓶颈，观察支付失败问题是否和高并发相关。
• 慢请求和超时测试：模拟支付请求的延迟，查看支付流程在网络不稳定或响应慢的情况下是否仍能稳定执行。

11. 逐步回归测试

• 逐步回退版本：如果系统近期有更新，逐步回退到先前版本，观察支付失败问题是否得到解决。可能是新版本引入的Bug或功能引起的。
• 功能逐一排查：如果系统进行了多项新功能或配置变更，可以逐一禁用新功能或调整配置，看看支付失败问题是否消失。

12. 与支付平台技术支持合作

• 如果经过上述排查仍无法定位问题，可以向支付网关或第三方支付平台的技术支持寻求帮助。提供详细的日志信息和请求参数，看看是否能得到更详细的反馈和帮助。

13. 用户行为分析

• 用户操作路径：分析用户在支付前后的行为，是否在支付流程中进行了不当操作（如频繁切换页面、点击过快等），导致支付失败。

性能测试关键指标及其作用

1. 响应时间 (Response Time)

• 定义：响应时间指的是从发送请求到收到响应之间的时间，通常以毫秒(ms)为单位。
• 重要性：响应时间直接影响用户体验。如果响应时间过长，用户可能会感到不满意，从而导致用户流失。
• 组成：响应时间通常包括网络延迟、服务器处理时间以及数据库访问时间等。

2. 吞吐量 (Throughput)

• 定义：吞吐量指的是在单位时间内，系统能够处理的请求数，通常以请求/秒 (RPS) 或字节/秒 (Bps) 表示。
• 重要性：吞吐量衡量系统处理请求的能力，较高的吞吐量通常意味着系统能够在短时间内处理更多的请求。

3. 并发用户数 (Concurrent Users)

• 定义：并发用户数指的是在某一时刻，系统能够同时处理的用户请求数量。
• 重要性：这反映了系统的并发处理能力，较高的并发用户数通常表示系统的负载能力较强。

4. 事务处理时间 (Transaction Processing Time)

• 定义：事务处理时间是指一个完整事务（包括多个操作）的处理时间，从用户发起请求到事务完成的时间。
• 重要性：这个指标用于衡量一个完整操作（例如支付或订单处理）的处理效率。

5. 成功率 (Success Rate)

• 定义：成功率是指系统在执行测试时成功完成请求的比例，通常以百分比表示。
• 重要性：成功率越高，表示系统的稳定性越好。如果成功率较低，说明系统存在很多请求处理失败的情况。

6. 错误率 (Error Rate)

• 定义：错误率是指请求在执行过程中发生错误的比例，通常以百分比表示。错误可以是 4xx（客户端错误）或 5xx（服务器错误）等。
• 重要性：错误率过高通常意味着系统的稳定性或可用性较差，影响用户体验，需要及时定位并修复问题。

7. 资源利用率 (Resource Utilization)

• 定义：资源利用率指的是系统各项硬件资源（如 CPU、内存、磁盘、网络等）的使用情况。
• 重要性：较高的资源利用率可能表明系统存在瓶颈，过低的资源利用率则可能是资源浪费。通常需要关注 CPU 使用率、内存使用率、磁盘 I/O 等。

8. 最大负载 (Maximum Load)

• 定义：最大负载是指系统在一定时间内能够处理的最大并发用户数或请求数，而不至于出现崩溃或严重性能下降。
• 重要性：它是系统能承受的负载极限，通常用于评估系统的容量和处理能力。

9. 延迟 (Latency)

• 定义：延迟是指从请求发起到收到响应之间的时间，通常与响应时间密切相关，但更侧重于网络层面。
• 重要性：较高的延迟可能会导致页面加载缓慢，影响用户体验。

10. 系统可用性 (Availability)

• 定义：可用性指的是系统在一定时间内处于正常运行状态的比例，通常以百分比表示。
• 重要性：高可用性是用户体验和系统稳定性的关键指标。大多数系统要求 99.9% 或更高的可用性。

11. 系统容量 (System Capacity)

• 定义：系统容量是指在一定的时间内，系统可以处理的最大工作负载。它包括最大并发用户数、最大请求数、最大数据传输等。
• 重要性：了解系统容量有助于进行容量规划，避免在高负载情况下出现性能下降或系统崩溃。

12. 负载均衡效率 (Load Balancing Efficiency)

• 定义：负载均衡效率指的是负载均衡机制在多个服务器之间分配请求的效果。良好的负载均衡能确保所有服务器的负载均衡，避免某些服务器过载。
• 重要性：如果负载均衡不均衡，可能导致某些服务器过载，而其他服务器闲置，影响系统性能和响应时间。

13. 数据库响应时间 (Database Response Time)

• 定义：数据库响应时间是指在系统执行请求时，数据库查询和响应的时间。
• 重要性：数据库响应时间通常是性能瓶颈的重要来源之一，数据库查询效率的提升能显著提高系统性能。

14. 系统启动时间 (System Startup Time)

• 定义：系统启动时间是指系统从启动到完全可用所需的时间。
• 重要性：如果系统的启动时间过长，可能影响部署和扩展的效率，尤其是在高并发场景下。

15. 缓存命中率 (Cache Hit Rate)

• 定义：缓存命中率是指从缓存中获取数据的成功比例。
• 重要性：缓存命中率越高，说明缓存机制越有效，能够减少数据库的负担，提高系统性能。

16. 并发处理能力 (Concurrency Handling)

• 定义：并发处理能力指的是系统同时处理多个请求的能力，通常与并发用户数和吞吐量有关。
• 重要性：高并发处理能力能够确保系统在大量用户同时访问时保持稳定，防止因请求过多而崩溃。

17. 系统停机时间 (Downtime)

• 定义：停机时间是指系统无法使用的时间段，通常用于衡量系统的可靠性。
• 重要性：减少停机时间是提高系统可用性和稳定性的关键。停机时间通常用于计算系统的 SLA

举例解读jmeter中线程数、循环次数、Ramp-up 时间参数

示例场景

假设我们有一个简单的性能测试场景：测试一个电商网站的登录功能。我们希望模拟 100 个用户同时访问，并且每个用户执行 10 次登录操作，测试持续 1 分钟。以下是这些参数如何设置的。

1. 线程数 (Number of Threads)

线程数代表我们想要模拟的虚拟用户数。每个线程代表一个独立的虚拟用户，能够独立地发起请求。

假设：

• 我们希望模拟 100 个用户 同时访问登录页面。

设置：

• 线程数：100
• 这意味着在测试期间，会有 100 个虚拟用户同时执行请求。

影响：

• 线程数设置为 100，意味着在测试过程中，JMeter 会启动 100 个虚拟用户，同时发起请求。这将模拟电商网站的 100 个用户并发访问。

2. 循环次数 (Loop Count)

循环次数决定了每个虚拟用户会重复执行某个操作多少次。这个参数可以帮助我们控制每个用户执行请求的次数。

假设：

• 我们希望每个用户执行 10 次登录操作。

设置：

• 循环次数：10

影响：

• 每个虚拟用户会执行 10 次登录请求。所以，如果线程数是 100，每个用户执行 10 次请求，那么总共会执行 100 × 10 = 1000 次请求。

3. Ramp-up 时间 (Ramp-up Period)

Ramp-up 时间是 JMeter 在启动所有线程时所花费的时间。它是一个渐进的过程，JMeter 不会一开始就启动所有的线程，而是逐步启动，直到启动完所有线程。

假设：

• 我们希望在 20 秒内启动所有 100 个用户。

设置：

• Ramp-up 时间：20 秒

影响：

• 在 20 秒内，JMeter 会逐步启动 100 个线程。如果线程数为 100，Ramp-up 时间为 20 秒，那么 JMeter 会大约每 0.2 秒启动一个线程。这意味着每隔 0.2 秒会有一个新线程启动，从而模拟一个渐进的负载过程，而不是让 100 个虚拟用户瞬间涌入系统。
• 这样做的好处：如果立即启动所有线程，可能会导致系统瞬间承受过大的压力，导致不真实的性能测试结果。渐进启动线程有助于模拟更真实的用户负载。

---

完整的例子

• 线程数 (100)：模拟 100 个虚拟用户。
• 循环次数 (10)：每个用户执行 10 次登录操作。
• Ramp-up 时间 (20 秒)：在 20 秒内启动 100 个线程。

结果：

• 测试将会模拟 100 个用户，并且每个用户会执行 10 次登录操作（总共 1000 次请求）。
• 所有线程会在 20 秒内逐步启动，模拟一个渐进的用户负载。
• 每个用户会在测试期间间隔一定的时间进行操作，而不会立即执行所有操作。

什么是压力测试?它与负载测试的区别是什么。

什么是压力测试 (Stress Testing)？

压力测试 是一种性能测试，用于评估系统在极限条件下的表现。它的主要目的是找出系统的承载极限，并测试系统在超出正常工作负载时的稳定性和恢复能力。压力测试会让系统遭遇极端或超出其处理能力的负载，目的是找出系统崩溃、故障或性能急剧下降的点，并分析其如何恢复。

常见的压力测试场景包括：

• 突然的流量高峰（例如突发的用户访问量）
• 系统的硬件资源（如 CPU、内存、磁盘 I/O 等）达到饱和时的表现
• 系统出现资源瓶颈时如何处理

什么是负载测试 (Load Testing)？

负载测试 是一种性能测试，用于评估系统在预期负载下的表现。负载测试的主要目的是验证系统是否能够在正常的、预期的用户访问量下正常运行，并确保系统在负载下不会发生性能下降或出现故障。

负载测试通常用来模拟常见的工作负载，以查看系统在日常使用中是否能处理并发用户请求、事务和操作等。通过负载测试，开发者能够确定系统是否符合性能需求。

压力测试与负载测试的区别：

特点	压力测试 (Stress Testing)	负载测试 (Load Testing)
目的	评估系统的极限承载能力，找出系统崩溃或失败的临界点。	评估系统在正常负载下的表现，确保它能够处理预期的用户数量和流量。
测试场景	超过正常负载，模拟极限情况下的流量或请求，如突然的流量激增或负载。	模拟真实的用户行为和负载，确保系统能处理日常操作。
目标	找出系统在压力下的弱点，例如性能瓶颈、系统崩溃或资源耗尽。	验证系统是否能够在正常负载下满足性能要求，保持稳定运行。
测试重点	系统在超出负载时的反应和恢复能力。	系统在正常负载下的性能，如响应时间、吞吐量等。
负载类型	极端负载，远超出预期或正常操作的负载。	预期负载，模拟预设的用户并发量和事务量。
测试结果	系统崩溃、性能急剧下降、错误、恢复时间等。	响应时间、吞吐量、并发能力等是否达到预期要求。

简单总结：

• 负载测试 关注的是在正常负载范围内，系统的性能是否符合要求，确保它能够在日常操作中正常工作。
• 压力测试 则是测试系统在超负荷情况下的表现，旨在发现系统的瓶颈、崩溃点以及应急恢复能力。

怎么做压力测试和负载测试（具体实例）

1. 负载测试实现步骤

目标：模拟多个用户同时访问系统，测试系统在指定负载下的性能。

假设：我们要测试一个在线电商网站的负载能力，模拟1000个并发用户同时访问。

步骤：

1. 确定负载测试目标

• 目标：模拟1000个并发用户，执行浏览商品、加入购物车、结算等操作。
• 指标：响应时间、页面加载时间、并发用户数、系统吞吐量。

2. 选择负载测试工具

• 工具：Apache JMeter 或 Gatling 都是常用的负载测试工具。
• 以 Apache JMeter 为例：

3. 使用 JMeter 进行负载测试

1. 安装 JMeter：

   • 下载并安装 Apache JMeter（官网）。
   • 启动 JMeter 后，进入主界面。

2. 创建测试计划：

   • 在 JMeter 中，创建一个 Test Plan（测试计划）。

3. 添加线程组：

   • 右键点击 Test Plan，选择 Add > Threads (Users) > Thread Group。一个线程组表示一个虚拟用户，线程组可以设置并发的虚拟用户数、循环次数等。
   • 设置线程数（即并发用户数）为 1000，循环次数为 1。

4. 模拟用户行为：

   • 右键点击 Thread Group，选择 Add > Sampler > HTTP Request，添加 HTTP 请求。
   • 配置每个 HTTP 请求模拟用户浏览商品、加入购物车、结算等操作的具体请求。例如：
     • 请求商品列表页面：GET /products
     • 加入购物车：POST /cart/add
     • 提交订单：POST /checkout

5. 添加监听器：

   • 右键点击 Thread Group，选择 Add > Listener > View Results Tree 或 View Results in Table，以便查看测试结果。

6. 执行负载测试：

   • 点击 Start 按钮，开始模拟1000个并发用户访问系统。
   • JMeter 会生成测试数据，并显示每个请求的响应时间、吞吐量等。

7. 分析结果：

   • 查看响应时间、页面加载时间等指标，检查是否在负载下出现性能瓶颈。如果响应时间过长或出现大量错误，说明系统可能无法承载这个负载。

4. 调整优化

• 如果测试结果显示响应时间过长或系统崩溃，可以进一步进行优化。例如：
  • 优化数据库查询：通过增加索引或优化查询语句来减少数据库响应时间。
  • 负载均衡：使用负载均衡器（如 Nginx 或 AWS Elastic Load Balancer）分散请求，减少单个服务器的压力。

---

2. 压力测试实现步骤

目标：模拟系统超出正常负载，测试系统崩溃点。

假设：我们要测试同一个电商网站，模拟用户数从1000增加到5000，测试系统的极限。

步骤：

1. 确定压力测试目标

• 目标：测试系统在5000并发用户下的性能，找出崩溃点。
• 指标：最大用户数、系统响应时间、崩溃日志、资源使用率（如 CPU、内存）。

2. 选择压力测试工具

• 工具：与负载测试一样，可以使用 JMeter 或 Gatling 进行压力测试。

3. 使用 JMeter 进行压力测试

1. 创建压力测试计划：

   • 在 JMeter 中，创建一个新的 Test Plan。

2. 设置线程组（模拟负载）：

   • 创建一个新的 Thread Group，设置线程数逐步增加。例如，首先设置为1000个用户，然后逐渐增加到5000个用户。
   • 可以使用 Gaussian Random Timer 或 Constant Throughput Timer 控制每秒请求数量，模拟逐步增加的负载。（以下有注释）

3. 模拟用户行为：

   • 按照负载测试中的方法，模拟用户行为，如浏览商品、加入购物车、提交订单等。

4. 逐步增加负载：

   • 运行测试并逐步增加并发用户数，从1000个开始，逐渐增加到5000个，观察系统在不同并发量下的表现。

5. 监控系统资源：

   • 使用 JMeter 监控每秒请求数、响应时间，并使用 系统监控工具（如 top、htop 或 Prometheus）来监控服务器的 CPU 和内存使用率，查看是否存在资源瓶颈。

6. 分析结果：

   • 查看日志，找出在增加负载时系统崩溃的原因。例如，可能是数据库连接数过多、内存溢出、或者服务器 CPU 使用率达到 100% 等问题。

4. 调整优化

• 查找瓶颈：通过分析系统崩溃的日志，可以找出系统瓶颈。比如数据库连接池容量不足、应用服务器内存不足等。
• 扩展资源：增加服务器资源，调整数据库连接池、缓存策略，或优化应用代码，确保系统能够处理更高的并发。

---

总结：

负载测试：

• 目的是确保系统在常规负载下的正常运行。
• 实现时模拟指定数量的用户访问，确保响应时间和吞吐量在可接受范围内。

压力测试：

• 目的是找出系统的崩溃点，测试系统在超负荷情况下的表现。
• 实现时模拟逐步增加的负载，直到系统无法承受并崩溃，分析崩溃原因并进行优化。

使用 Gaussian Random Timer 或 Constant Throughput Timer（常数吞吐量定时器） 控制每秒请求数量，模拟逐步增加的负载

1. Gaussian Random Timer（高斯随机定时器）

作用： Gaussian Random Timer 用于模拟用户请求之间的随机延迟，使用高斯分布（又叫正态分布）来生成延迟时间。这个定时器适用于模拟用户请求之间的自然波动，比如模拟一些用户可能在操作过程中暂停、思考等行为。

工作原理：

• 高斯分布是一个常见的概率分布，它会根据设定的平均时间和标准差生成一个请求间隔。
• 它的特点是：大多数请求延迟时间会集中在一个平均值附近，但也有少部分请求会有较长的延迟时间。
• 具体来说，定时器会在一个平均时间（如 200ms）周围生成带有波动的延迟，波动的范围是由标准差来控制。

配置方式：

• Thread Delay (ms)：每个请求之间的平均延迟时间（单位：毫秒）。例如，设置为 200ms，意味着大多数请求会有大约 200ms 的延迟。
• Deviation (ms)：延迟的标准差，用于控制高斯分布的波动范围。比如，设置 50ms，意味着大部分请求会在 150ms 到 250ms 之间随机延迟。

使用场景： Gaussian Random Timer 适用于模拟用户在进行操作时，有些请求间隔会随机波动，且这种波动是对称的（大多数请求延迟接近平均值，少数请求延迟较长）。它可以用来模拟较为“自然”的用户行为。

2. Constant Throughput Timer（恒定吞吐量定时器）

作用： Constant Throughput Timer 用于精确控制请求的吞吐量，即每秒（或每分钟）发出的请求数量。这个定时器会根据设定的目标吞吐量来动态调整请求的间隔时间，确保每秒的请求数保持在一个恒定值。

工作原理：

• 它通过调整请求间隔来保证系统的请求速率恒定。比如，你设置吞吐量为 10 请求/秒，那么它就会自动调整每个请求之间的间隔，以确保请求的总速率为 10 次每秒。
• 如果有多个线程组使用该定时器，JMeter 会尝试将吞吐量分配给每个线程组，从而尽量保证整个系统的请求速率恒定。

配置方式：

• Target Throughput (requests per minute)：这是你希望在一分钟内发送的请求数量。例如，如果你设置为 600，请求速率将为 10 请求/秒。
• Calculate Throughput based on：此设置决定计算吞吐量的时间单位。可以选择按每秒（Seconds）、每分钟（Minutes）或每小时（Hours）来计算吞吐量。
• Throughput Control Mode：在多线程环境中，你可以选择吞吐量的控制模式，通常是通过线程组内的请求总数来保持吞吐量的一致性。

使用场景： Constant Throughput Timer 适用于你想要精确控制请求速率的场景。比如，你需要确保系统在负载测试中能够始终维持一定的请求频率，从而模拟一定的负载。这种方式更接近模拟压力和负载的恒定测试，适合用来精确控制系统的吞吐量和并发请求数。

3. 模拟逐步增加的负载

如果你需要模拟逐步增加的负载，可以结合这两种定时器进行设置，具体步骤如下：

使用 Constant Throughput Timer 来控制吞吐量

• 你可以设置 Constant Throughput Timer 来逐渐增加系统的负载。例如，在最开始的几轮中，可以设置目标吞吐量为 10 请求/秒，然后逐渐增加到 50 请求/秒、100 请求/秒等。
• 随着负载逐渐增加，系统会自动调整请求的间隔时间，以确保每秒的请求数量符合设定的吞吐量。

使用 Gaussian Random Timer 来模拟随机延迟

• 在每个请求间加上 Gaussian Random Timer，使得请求之间存在一定的随机波动。你可以选择将每个请求的平均延迟时间设置为 200ms，标准差为 50ms，这样请求的间隔时间会在 150ms 到 250ms 之间随机变化，从而模拟更真实的用户行为。

示例：逐步增加负载

假设我们希望模拟一个逐步增加负载的场景，设定如下：

• 第 1 步：100 个并发用户，每秒 10 个请求。

  • 使用 Constant Throughput Timer 设置目标吞吐量为 600 请求/分钟。
  • 使用 Gaussian Random Timer 设置平均延迟为 200ms，标准差为 50ms。

• 第 2 步：200 个并发用户，每秒 20 个请求。

  • 修改 Constant Throughput Timer，将吞吐量目标设置为 1200 请求/分钟。
  • 同样保持 Gaussian Random Timer 的设置不变。

• 第 3 步：400 个并发用户，每秒 40 个请求。

  • 修改 Constant Throughput Timer，将吞吐量目标设置为 2400 请求/分钟。
  • 继续使用 Gaussian Random Timer 来模拟用户行为。

常数吞吐量定时器配置

（1）、目标吞吐量（每分钟的样本量）（Target throughput （in samples per minute））：每分钟的吞吐量

（2）、基于计算吞吐量（Calculate Throughput based on）：

只有此线程（this thread only）：控制每个线程的吞吐量，选择这种模式时，总的吞吐量为设置的target Throughput 乘以该线程的数量

所有活动线程（all active threads）：设置的target Throughput 将分配在每个活跃线程上，每个活跃线程在上一次运行结束后等待合理的时间后再次运行。活跃线程指同一时刻同时运行的线程

当前线程组中的所有活动线程（all active threads in current thread group）：设置的target Throughput 将分配在当前线程组的每一个活跃线程上，当测试计划中只有一个线程组时，该选项和all active threads 选项的效果完全相同

所有活动线程（共享）（all avtive threads （shared））：与all active threads的选项基本相同。唯一区别是，每个活跃线程都会在所有活跃线程上一次运行结束后等待合理的时间后再次运行

当前线程组中的所有活动线程（共享）（all active threads in current thread group （shared））：与all active threads in current thread group 基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程的上一次运行结束后等待合理的时间后再次运行