StatusPath Reports使用指南
为什么 Time in Status 报表缺少某个 Jira 状态列
即使 Jira 工作流中存在某个状态，Time in Status 报表仍可能不显示对应列：StatusPath 在运行报表数据源时，会从符合条件的历史中发现动态指标列，然后应用列可见性。对于新的数据源结果，如果没有已选工作项包含可计算的 QA 区间，就无法添加 QA；以前发现或保存过的 QA 列也可能保留，但所有行显示横线。如果 Columns 中已有 QA 但未勾选，则应在列管理器中显示它。
工作流里有状态，不代表报表一定有对应列
Atlassian 将状态定义为团队工作流中的步骤。工作流包含 QA，只能证明这个步骤已经配置；它不能证明当前报表范围内的工作项在计算历史窗口中进入过 QA。
StatusPath 的 Time in Status 状态列是动态列。某个报表数据源的计算数据包含状态值时，报表就能发现对应列；以前发现或保存过的列选择，也可能在后续运行中继续显示，即使当前每一行都变成横线。表格视图文档说明了根据结果生成列、Columns Manager 可见性、横向滚动、筛选，以及缺失值与真实零值的区别。状态区间的基础算法见如何计算 Jira Cloud 中的状态停留时间。
首先确认实际遇到的是哪一种情况：
| 现象 | 在当前表格中的含义 | 首要检查 |
|---|---|---|
| 没有 QA 表头，Columns Manager 中也没有 QA | 报表数据源没有发现符合条件的 QA 时长记录 | 数据范围、工作项日期范围、Trim History 和 Jira History |
| Columns Manager 中有 QA，但没有勾选 | 动态列已经存在，但被列配置隐藏 | 勾选 QA 并保存列配置 |
有 QA 表头，但所有行都显示 - |
已保存或以前发现的列仍保留，但当前行没有 QA 值 | 当前范围、日期控件、Trim History 和已保存配置 |
有 QA 表头，但某一行显示 - |
该工作项在计算窗口中没有 QA 区间记录 | 查看该工作项的 History；不要把横线替换成时长 |
| 有 QA 表头，但看不到预期的 QA 工作项 | 表格筛选可能隐藏了证据行；表格也可能已经滚动离开该行 | 清除表格筛选并检查完整表格 |
真实 Jira 场景：围绕三次 QA 转换比较两个范围
发布经理知道项目工作流包含 QA，但包含六个工作项的发布报表没有 QA 列。受控报表使用以下配置：
| 设置 | 值 |
|---|---|
| 报表 | Time in Status |
| Calendar | 已配置的 24×7 日历 All time (UTC) |
| Format | Decimal Hours |
| 工作项日期范围 | 留空 |
| Trim History | 关闭，计算完整历史 |
| 固定报表时间 | 2026 年 7 月 20 日 22:00 UTC |
All time (UTC) 是为这个可复现报表配置的日历名称，不代表每个安装环境的默认日历都使用这个名称。
较窄的 JQL 范围为：
project = SR
AND issuekey IN (SR-4001, SR-4002, SR-4003, SR-4004, SR-4005, SR-4006)
ORDER BY issuekey ASC
这六个工作项都没有进入 QA：
| 工作项 | UTC 下的相关状态历史 | QA 时长记录 |
|---|---|---|
SR-4001 |
To Do 07:00 → In Progress 08:00 → Done 13:00 | 无 |
SR-4002 |
To Do 07:00 → In Progress 09:00 → Done 13:00 | 无 |
SR-4003 |
To Do 06:00 → In Progress 07:00 → Blocked 13:00 → Reopened 15:00 → In Progress 16:00 → Done 18:00 | 无 |
SR-4004 |
To Do 08:00 → In Progress 09:00 → In Review 16:00 → Done 18:00 | 无 |
SR-4005 |
To Do 07:00 → In Progress 09:00 → Ready for Release 14:00 → Done 16:00 | 无 |
SR-4006 |
To Do 08:00 → In Progress 09:00 → In Review 13:00 → Done 16:00 | 无 |
随后，经理只扩大工作项范围：
project = SR
AND issuekey IN (SR-4001, SR-4002, SR-4003, SR-4004, SR-4005, SR-4006, SR-4007, SR-4008, SR-4009)
ORDER BY issuekey ASC
SR-4007、SR-4008 和 SR-4009 提供了缺失的证据：
| 工作项 | 进入 QA | 进入 Done | QA 时长 |
|---|---|---|---|
SR-4007 |
2026-07-20 12:00 UTC | 2026-07-20 14:00 UTC | 2h |
SR-4008 |
2026-07-20 14:00 UTC | 2026-07-20 18:00 UTC | 4h |
SR-4009 |
2026-07-20 14:00 UTC | 2026-07-20 20:00 UTC | 6h |
Atlassian 文档说明，工作项的 Activity → History 会记录字段编辑和工作项在工作流中的移动。这个 History 视图提供了每个 QA 进入和离开时间戳的来源证据。
人工验算缺失状态与恢复状态
在较窄范围中，QA 贡献者数量为零：
QA 贡献者 = 0 / 6
QA 时长记录 = 无
从业务角度把这六条历史相加，QA 总时长为零小时；但表格不会虚构一个空的 QA = 0.00 列，因为没有可用于生成这个动态列的 QA 时长记录。
扩大范围后：
SR-4007 QA 时长 = 2026-07-20 14:00 - 2026-07-20 12:00
= 2 小时
SR-4008 QA 时长 = 4 小时
SR-4009 QA 时长 = 6 小时
QA 贡献者 = 3 / 9
QA 总时长 = 2h + 4h + 6h = 12.00 小时
因此，预期表格为：
| 工作项 | QA |
|---|---|
SR-4001 |
- |
SR-4002 |
- |
SR-4003 |
- |
SR-4004 |
- |
SR-4005 |
- |
SR-4006 |
- |
SR-4007 |
2.00 |
SR-4008 |
4.00 |
SR-4009 |
6.00 |
横线代表每一行缺少对应值，而不是六个数值零。整列缺失和单个单元格为空是两种不同状态。
按固定顺序排查缺失的状态列
1. 确认准确的状态名称
打开一个已知工作项，从 Jira History 中复制状态名称。不要假设 QA、In QA、Quality Assurance 和 Testing 可以互换。Atlassian 指出，重命名状态会更新使用该状态的工作流，也可能影响报表显示。本步骤只用于找到预期名称；跨项目状态身份和国际化问题需要单独核查。
2. 在 Jira 中证明工作项范围
以同一个用户身份运行准确的 Project、已保存 Filter、JQL、Sprint 或 Epic 范围。在这个场景中，应对比两条明确列出工作项键的查询，确认只有扩大后的查询包含 SR-4007、SR-4008 和 SR-4009。
JQL 也可以查找发生过 QA 变更且当前用户有权访问的工作项：
project = SR
AND status CHANGED TO "QA"
ORDER BY issuekey ASC
Atlassian 的 JQL 运算符参考说明，CHANGED 支持 TO、FROM、BEFORE、AFTER 和 DURING 等条件。该查询用于寻找证据工作项，不能计算时长。
3. 单独检查工作项日期范围
工作项日期范围可以根据 Created、Updated 或 Resolved 日期移除原本匹配的工作项。如果它排除了全部三个 QA 贡献者，最终数据就会失去 QA 值。对于新的数据源发现，QA 列可能完全不存在；如果保留了已保存或以前发现的 QA 选择，表头可能还在，但所有行都会显示横线。为了复现本例，应先清空这个控件；解释清楚列以后，再恢复业务所需的边界。
4. 对照 QA 区间检查 Trim History
Trim History 会改变每个已选工作项中参与计算的历史范围。如果裁剪窗口排除了 SR-4007、SR-4008 和 SR-4009 的全部三个 QA 区间，扩大后的结果就没有 QA 时长记录。根据 QA 是已经被发现，还是从已保存配置中恢复，后续表格可能不显示该列，也可能保留列但显示横线。单项边界核对应使用 SR-4007 在 7 月 20 日 12:00–14:00 的区间。日期范围和历史裁剪指南详细说明了工作项筛选和计算边界的区别。
5. 打开 Columns Manager
如果 QA 可选但未勾选，应勾选并保存。如果根本没有 QA 选项，仅改变可见性无法解决问题；应返回检查工作项范围和计算历史。Saved Report可以保存列选择，但保存的是配置，不是 Jira 数据的冻结副本。
6. 清除行筛选并检查完整宽度
表格筛选会改变可见行。它可以隐藏一个或全部三个 QA 贡献者，但不能生成缺失的 QA 历史记录。清除当前筛选、展开指标列组并横向滚动，再判断整列是否缺失。
7. 人工核对一个工作项
对于 SR-4007，在 Jira History 中核对 12:00 进入和 14:00 离开，计算两个时间戳之差，并确认在 24×7 UTC 日历与 Decimal Hours 格式下显示 2.00。然后核对 SR-4008 = 4.00 和 SR-4009 = 6.00，再确认总计为 12.00 小时。如果报表使用工作日历，则应只计算与工作时间表的重叠部分，不能期待得到这些自然时间结果。
常见错误
把工作流图当成时长证据
已配置的 QA 状态是一个可能经过的工作流步骤，不能证明任何已选工作项真正进入过 QA。
只检查 Jira 当前状态
status = "QA" 只查找当前处于 QA 的工作项，可能漏掉以前经过 QA 的已完成工作项。历史证据应使用 History 以及合适的 WAS 或 CHANGED 查询。
期待 JQL 计算缺失时长
JQL 用于选择工作项，也能检查状态历史条件，但不会把两次变更之间的区间直接转换为 Time in Status 值。
证据行不在工作项范围内，却只修改 Trim History
Trim History 无法把 SR-4007、SR-4008 或 SR-4009 加入只包含六个工作项的 JQL 结果。应先修正工作项范围，再设置计算窗口。
期待表格筛选生成或删除已发现的列
表格筛选作用于当前行。它可以把全部三个 QA 贡献者隐藏起来，但能否计算 QA 值取决于数据源和历史。
把横线、整列缺失和零值当成同一件事
在已有 QA 表头下显示横线，表示该行没有计算出的 QA 值；没有 QA 表头则属于列发现或可见性问题；显示出来的零时长是第三种独立状态。
在查明报表原因之前修改 Jira 工作流
不要为了让报表出现某一列就添加、删除或重命名状态。应先判断原因是否属于范围、历史、名称或列可见性。只有流程本身确实有问题，并且相应 Jira 管理员已评估影响时，才应修改工作流。
常见问题
没有工作项进入 QA 时，可以强制显示空 QA 列吗？
当前 Time in Status 表格根据计算后的报表数据生成基础状态列。如果 Columns Manager 中没有 QA，应纳入能够产生 QA 值的适当工作项和历史窗口；不要把虚构的零值列当成已记录历史。
Columns Manager 中有 QA，为什么表格中看不到？
QA 可能没有勾选、位于宽表格的屏幕外，或包含在已折叠的指标列组中。应勾选并保存配置，然后展开列组并横向滚动。
status CHANGED TO "QA" 会计算 Time in Status 吗？
不会。它只筛选发生过符合条件状态变化的工作项。Time in Status 仍需要进入和离开时间戳、历史窗口、日历和时长格式。
表格筛选会删除 QA 列吗？
表格筛选从当前网格中移除可见行，可能隐藏唯一具有 QA 值的行；已发现的列本身仍属于列配置问题。如果表头完全不存在，应检查范围、计算历史和 Columns Manager。
为什么 Saved Report 之后又缺少某个状态列？
Saved Report 保存配置，不保存冻结结果。当前 Jira 工作项范围、权限、状态历史或工作流名称可能已经变化。应使用一个包含已知证据的小范围重新运行，并与已保存配置比较。
应该修改 Jira 工作流来恢复这一列吗？
通常不应该。如果已知工作项确实进入过 QA，应先修正报表范围、历史窗口或可见性。只有预期流程本身确实缺少 QA 时才修改工作流，不能把工作流修改当成报表变通办法。
相关指南
- 如何计算 Jira Cloud 中的状态停留时间
- 如何使用 JQL 创建 Jira Time in Status 报表
- Jira Time in Status 日期范围如何裁剪历史
- 如何查找 Jira 工作项进入某个状态的日期
- Jira Average Time in Status 报表中的横线与零值
- Jira 状态重命名和本地化后如何核对工作流报表
用证据恢复状态列，而不是靠猜测
使用 StatusPath Reports 重新运行包含已知 QA 区间的最小范围，核对时间戳，然后选择已发现的 QA 列。按照表格视图：动态列、Columns Manager 和筛选保存可审核的列配置，并确保最终结果与 Jira History 一致。