性能测试单场景测试时，是设置并发读多个文件，还是设置不同的用户读不同的文件？
两种场景的核心区别
这两种设计的根本区别在于 测试的出发点和所要验证的系统瓶颈侧重点不同。
| 特性 | 场景一：并发读多个不同单据 | 场景二：不同用户读不同的单据 |
|---|---|---|
| 核心描述 | 更侧重于 “单据”本身 作为系统资源的承载能力。 | 更侧重于 “用户” 在系统内的操作行为以及系统对用户会话和权限的处理能力。 |
| 数据维度 | 单据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）的性能。 |
最佳实践：在实际项目中，建议两种场景都进行测试。
首先进行 场景一（极限压力测试），找到系统的绝对瓶颈和崩溃点。
然后进行 场景二（负载测试/压力测试），用更贴近生产的环境模型，验证系统在预期用户量下的表现是否达标。
通过这两种不同维度的测试，你可以对“单据详情页”这个功能的性能有一个全面而立体的了解。