两种场景的核心区别
这两种设计的根本区别在于 测试的出发点和所要验证的系统瓶颈侧重点不同。
| 特性 | 场景一：并发读多个不同单据 | 场景二：不同用户读不同的单据 |
|---|---|---|
| 核心描述 | 更侧重于 "单据"本身 作为系统资源的承载能力。 | 更侧重于 "用户" 在系统内的操作行为以及系统对用户会话和权限的处理能力。 |
| 数据维度 | 单据ID 是核心变量。系统需要处理大量不同的单据数据。 | 用户凭证（Token/Session） 和 单据ID 都是核心变量。 |
| 缓存友好性 | 不友好。由于每次请求的单据ID都不同，很可能每次都会穿透缓存，直接访问数据库，对数据库造成巨大压力。 | 相对友好。虽然用户和单据都在变，但单个用户可能重复查看某张单据，或者系统对热门单据有缓存，可以测试缓存在多用户下的表现。 |
| 主要压力点 | 数据库 （查询、连接池）、后端服务（数据处理逻辑）。 | 应用服务器 （用户会话管理、权限验证）、缓存 、数据库。 |
| 模拟的真实情况 | 系统内所有用户都在查看完全不同的单据（例如：大促时，每个顾客看的商品详情页都不同）。 | 系统内多个用户 在各自 的权限范围内，查看自己相关的单据（例如：一个ERP系统，张三看A订单，李四看B订单，王五也看A订单）。 |
测试重点是什么？
尽管侧重点不同，但两者共享一些核心的测试重点，只是优先级和关注点略有差异。
共同的测试重点
-
响应时间
-
这是最直观的指标。在并发下，查看单据详情页的API接口的平均响应时间、90%分位值、95%分位值 是否在可接受范围内（如：200ms以内）。
-
重点关注高并发时，响应时间是否平稳，还是会急剧上升。
-
-
吞吐量
- 系统在单位时间内（如：每秒）能成功处理多少個"查看单据"的请求。这是衡量系统处理能力的核心指标。
-
错误率
- 在并发压力下，请求是否会出现错误？例如：5xx服务器错误、4xx客户端错误（如因资源竞争导致的锁超时）、超时等。错误率需要控制在极低水平（如<0.1%）。
-
系统资源消耗
-
CPU使用率：应用服务器和数据库服务器的CPU是否成为瓶颈。
-
内存使用率：检查是否有内存泄漏或内存占用过高的情况。
-
磁盘I/O：数据库的读写IOPS和延迟。
-
网络带宽：网络是否成为瓶颈。
-
场景一特有或重点关注的测试点
-
数据库压力
-
SQL查询效率 ：由于单据ID不同，每次查询可能都是新的SQL执行。需要关注数据库的QPS 以及慢查询日志。
-
数据库连接池：大量的并发查询会迅速占满数据库连接池，需要监控连接池的使用情况，是否出现"等待获取连接"的超时。
-
锁竞争：虽然"读"操作通常共享锁，但如果单据数据涉及关联表或复杂查询，仍可能引发锁等待。
-
-
缓存穿透与击穿
-
这是本场景的核心风险点。因为每个请求的单据都不同，缓存可能无法命中，导致所有请求都直接落到数据库上，引发"缓存穿透"。
-
如果恰好在缓存失效的瞬间有大量并发请求访问同一个单据，则会发生"缓存击穿"。
-
测试重点：验证系统是否有应对缓存穿透/击穿的策略（如：布隆过滤器、缓存空对象、互斥锁等）。
-
-
后端服务处理能力
- 验证后端服务从数据库获取到数据后，进行数据组装、业务逻辑处理的性能极限。
场景二特有或重点关注的测试点
-
用户会话与认证授权
-
会话管理：系统需要为每个并发用户维持一个会话（Session）。这会对应用服务器的内存和Session存储机制（如Redis）造成压力。
-
权限验证：每次请求都需要验证当前用户是否有权限查看该单据。这个权限校验逻辑（如查询用户-角色-权限表）的性能至关重要，可能成为瓶颈。
-
-
缓存效率
- 测试在真实的多用户环境下，缓存的命中率如何。例如，如果多个用户查看同一张单据，系统是否能有效地利用缓存，减轻数据库压力。
-
数据隔离性
- 验证系统是否能严格保证用户A无法通过任何方式（如修改ID）查看到用户B的单据。这虽然是功能测试点，但在性能压力下，也需要确保权限校验逻辑不会出错。
-
负载均衡
- 多个用户的请求会被负载均衡到不同的应用服务器上。需要测试在这种"用户分散"的模式下，集群的处理能力是否线性增长。
总结与建议
| 场景 | 设计目的 | 关键挑战 | 推荐测试策略 |
|---|---|---|---|
| 并发读多个不同单据 | 探测系统极限，寻找瓶颈。尤其关注数据库和缓存机制在最坏情况下的表现。 | 缓存穿透、数据库连接池瓶颈、慢查询。 | 1. 准备海量的测试单据数据。 2. 使用工具（如JMeter）循环或随机读取不同的单据ID。 3. 重点监控数据库的各项指标。 |
| 不同用户读不同的单据 | 模拟真实用户行为，验证系统在真实场景下的稳定性。 | 用户会话管理、权限校验性能、缓存命中率。 | 1. 准备一批测试用户和与之关联的单据数据。 2. 在测试脚本中实现用户登录->获取Token->带着Token查询关联单据 的完整流程。 3. 重点监控应用服务器 和缓存（如Redis）的性能。 |
最佳实践 ：在实际项目中，建议两种场景都进行测试。
-
首先进行 场景一（极限压力测试），找到系统的绝对瓶颈和崩溃点。
-
然后进行 场景二（负载测试/压力测试），用更贴近生产的环境模型，验证系统在预期用户量下的表现是否达标。
通过这两种不同维度的测试，你可以对"单据详情页"这个功能的性能有一个全面而立体的了解。