场景列表
压测覆盖的业务链路清单，共 5 个产品 60 条链路。与客户对齐测试范围时以本表为准。
压测模拟的是具体用户操作——打开需求列表、新建工作项、编辑 wiki 页面—— 每个完整操作对应一条业务链路（定义见基本概念）。 下表中的「步骤数」即该链路包含的 HTTP 请求数。
一、覆盖概览
| 产品 | 链路数 | 覆盖的典型操作 |
|---|---|---|
| 项目（project） | 32 | 列表、详情、筛选器、工作台、创建/编辑/流转、排序查询 |
| 知识库（wiki） | 18 | 页面浏览、详情、创建/编辑、搜索、附件上传下载 |
| 测试（testcase） | 7 | 用例库、用例列表、创建/修改用例、测试计划 |
| 账号（account） | 2 | 成员列表、用户组列表 |
| 产品管理（product） | 1 | 产品管理首页 |
二、项目 project
数量最多、也最能反映 数据规模影响的一组。
列表与详情
| 链路 | 说明 | 步骤数 |
|---|---|---|
project-list-home | 项目列表首页 | 12 |
project-overview | 项目概览 | 15 |
project-requirement-list-table | 需求列表·表格视图 | 14 |
project-requirement-list-detail | 需求列表·窄详情 | 32 |
project-filter-list-detail | 筛选器列表·窄详情 | 33 |
project-directory-component | 项目目录组件 | 9 |
窄详情类链路的步骤数明显偏高（30 以上），因为打开详情面板会并发请求属性、评论、
工时、关联、附件等多个接口。该类链路的 workflow_duration 更贴近用户实际感知。
工作台与筛选器
| 链路 | 说明 | 步骤数 |
|---|---|---|
project-workbench-overview | 工作台概览 | 4 |
project-workbench-filter | 工作台筛选器 | 29 |
project-workbench-filter-by-project | 工作台筛选器·按项目 | 33 |
project-filter-attributes | 筛选器属性取值 | 12 |
写操作
| 链路 | 说明 | 步骤数 |
|---|---|---|
project-issue-create | 创建工作项 | 45 |
project-issue-create-and-query | 创建工作项后立即查询 | 2 |
project-issue-edit-title | 修改工作项标题 | 12 |
project-issue-edit-attributes | 修改工作项属性 | 19 |
project-issue-edit-label-and-query | 修改标签后立即查询 | 4 |
project-issue-status-transit | 流转工作项状态 | 10 |
*-and-query 两条为写后读链路：写入后立即查询，用于观察写入至可见的延迟。
批量写入后的检索可见性属另一议题，见索引时长。
搜索
| 链路 | 说明 | 步骤数 |
|---|---|---|
project-search-workitem | 搜索工作项 | 2 |
project-advanced-search | 高级搜索 | 5 |
查询与排序（数据规模梯度）
单请求链路，用于量化候选数据量对查询耗时的影响—— 即客户最常提出 的「数据量增长后查询是否会显著变慢」。
同一条查询在 1000 / 2000 / 3000 / 5000 / 10000 五档候选数据量下各执行一轮， 横向对比即可判断耗时增长是线性还是陡增。陡增说明该查询在目标量级下存在风险。
| 链路前缀 | 排序依据 | 候选数据量档位 |
|---|---|---|
project-onesql-plain-* | 普通字段（如标题、状态） | 1000 / 2000 / 3000 / 5000 / 10000 |
project-onesql-computed-* | 计算属性（查询时实时计算） | 1000 / 2000 / 3000 / 5000 / 10000 |
project-onesql-pure-list-1000 | 纯列表查询，无层级结构 | 1000 |
普通字段直接从库中读取，计算属性需在查询时实时计算。两组对比可分离出计算开销， 并单独观察其随数据量的增长趋势。
客户提出「某接口需支撑 500 TPS」时，若按混合流量加压，该接口在全部请求中仅占少数， 无法准确测定其吞吐量。
收敛到单条链路后，压测端设定的到达率即等于该接口的 TPS，无需换算。 详见并发公式。
权限与配置
| 链路 | 说明 | 步骤数 |
|---|---|---|
project-settings-permission | 项目权限设置 | 4 |
project-space-permission | 页面组权限 | 3 |
project-object-type-relation | 关联关系配置 | 9 |
三、知识库 wiki
浏览与阅读
| 链路 | 说明 | 默认权重 |
|---|---|---|
wiki-read-page | 阅读页面 | 35 |
wiki-browse-space | 浏览页面组 | 25 |
wiki-space-list | 页面组列表 | 25 |
wiki-search | 搜索页面 | 15 |
wiki-shared-pages | 与我共享的页面 | 10 |
wiki 是唯一默认权重不均等的产品，阅读操作显著多于写入，贴近真实使用比例。 其余产品的链路默认权重均为 10（等权），可在客户配置中覆盖。
wiki-search 走后端搜索引擎，单请求开销最大，高并发下通常最先成为瓶颈。
页面详情（四种入口）
| 链路 | 入口 | 步骤数 |
|---|---|---|
wiki-page-detail-recent | 最近访问 | 22 |
wiki-page-detail-pinned | 置顶 | 21 |
wiki-page-detail-cross-space | 跨页面组 | 21 |
wiki-page-detail-via-link | 直接链接 | 21 |
wiki-page-switch | 页面间切换 | 13 |
四个入口打开的是同一类页面，但前置请求不同（最近访问需查询访问记录、 跨页面组需额外鉴权），分别压测才能定位具体是哪个入口存在瓶颈。
编辑
| 链路 | 说明 | 步骤数 |
|---|---|---|
wiki-page-create-wiz | 新建页面 | 25 |
wiki-page-edit-wiz | 编辑页面 | 23 |
附件（按文件大小分档）
上传与下载各三档，用于定位性能开始劣化的文件大小区间。
| 档位 | 大小 | 上传链路 | 下载链路 |
|---|---|---|---|
| 小 | 64 KB | wiki-attachment-upload-small | wiki-attachment-download-small |
| 中 | 2 MB | wiki-attachment-upload-medium | wiki-attachment-download-medium |
| 大 | 20 MB | wiki-attachment-upload-large | wiki-attachment-download-large |
附件链路的耗时受带宽影响极大。压测机与被测环境之间若经由公网， 测得的主要是网络耗时而非服务端能力，因此压测机应与被测环境同机房。
四、测试 testcase
| 链路 | 说明 | 步骤数 |
|---|---|---|
testcase-overview | 测试管理概览 | 3 |
testcase-library-list | 用例库列表 | 1 |
testcase-library-case-list | 用例库·用例列表 | 15 |
testcase-plan-list | 测试计划列表 | 3 |
testcase-plan-case-list | 测试计划·用例列表 | 8 |
testcase-case-create | 创建测试用例 | 13 |
testcase-case-edit | 修改测试用例 | 8 |
五、账号 account 与产品管理 product
| 链路 | 说明 | 步骤数 |
|---|---|---|
account-member-list | 成员列表 | 4 |
account-user-group-list | 用户组列表 | 3 |
product-home | 产品管理首页 | 3 |
账号类链路数量虽少，但成员规模（默认规划量级 6,000）会显著影响成员列表与用户组列表的耗时， 不应因链路数量少而跳过。
六、按客户裁剪
上表为产品模板的全集。实际为某客户压测时通常不会全部执行，需按三种方式裁剪：
- 停用不相关链路 —— 客户未采购测试管理时，
testcase-*全部停用； - 调整权重 —— 按客户真实业务比例重新分配，不沿用默认等权；
- 收敛至单条链路 —— 执行单接口吞吐验收时仅保留一条，见本页查询与排序一节。
裁剪结果写入客户配置，产品模板本身不作修改。配置方法见工具执行手册。
以本表询问客户「其中哪些属于高频操作」，比要求客户从零描述场景更为高效。 客户无法回答时，可改问「当前最担心哪个页面的响应速度」， 通常可直接定位到 2 至 3 条链路。