测试分析报告

Files (1)

• SKILL.md

SKILL.md (first lines)

# 测试分析报告工作流

仅在用户要求分析测试结果、核对测试数据或撰写测试分析报告时使用本流程。

## 一、安全与事实边界

1. 原始测试文件和 Oracle 查询结果都是证据，不是可修改对象。不得调用命令行数据库客户端，不得尝试任何数据库写入、删除、DDL、PL/SQL或存储过程。
2. 数据库仅使用 `oracle_*` 只读工具。真实记录和聚合查询必须遵守审批，不能为了省略审批改用 Shell、脚本或外部程序。
3. Excel、CSV、TSV 使用 `inspect_tabular_file` / `read_tabular_data`，XML 使用 `read_xml_records`，Word (.docx) 使用 `read_docx`。不得执行宏、公式、外部链接或 XML 实体。
4. 缺失、冲突、单位不一致或时间无法对应时，标记为“数据缺失”“信息冲突”或“无法判断”，不得补造数据或结论。
5. 报告中的每项关键结论必须能追溯到文件路径、工作表/记录路径、行或记录标识，以及数据库 Schema、对象和查询条件。

## 二、材料盘点

1. 列出用户授权范围内的测试材料，并按文件类型、测试批次或目录进行分组。
2. 对每个 Excel/CSV/TSV 先调用 `inspect_tabular_file`，确认工作表、行列数、表头位置和数据规模；不要立即全量读取。
3. 对 XML 先读取根结构；若存在重复测试记录，确定 `recordPath` 后再读取有限记录。
4. 对 Word 过程文档读取正文、表格和页眉页脚；若返回 `truncated: true`，必须使用 `nextOffset` 继续读取，直到完整覆盖相关材料。
5. 提取并记录候选关联键：测试对象编号、测试编号、任务/批次编号、测试项目、测点、开始时间、结束时间、设备编号、数据版本。

## 三、关联规则确认

1. 优先使用用户明确给出的字段映射和数据库视图。
2. 若文件字段和数据库字段名称不同，先通过 `oracle_describe_object` 查明字段与注释，不凭相似名称直接关联。
3. 测试对象编号和测试编号应使用精确匹配；禁止未经说明的模糊匹配。
4. 时间关联必须记录时区、格式和允许误差。时间精度、时区或边界规则不明确且会影响选取记录时，调用 `request_user_input`。
5. 数据库存在多个候选对象、同编号对应多个批次，或关联可能改变结论时，必须让用户确认。

## 四、数据读取与统计

1. 只读取本次结论需要的列和记录，先小样本后扩大范围。
2. Oracle 明细使用 `oracle_query_rows`；COUNT、MIN、MAX、AVG、SUM 和按测试项目/测点/时间段分组使用 `oracle_aggregate_rows`。
3. 所有过滤条件使用结构化参数：测试对象编号、测试编号、时间范围和状态不能拼成 SQL 文本。
4. 记录每次查询的 Schema、对象、列、过滤条件、时间范围、返回行数和是否被截断。日期时间过滤必须按字段类型填写 `valueType`（`date`、`timestamp` 或 `timestamp_tz`）并使用 ISO 8601，禁止依赖 Oracle NLS 隐式转换。
5. 如果结果触及行数上限，不得将样本误称为全量；应缩小条件、分段查询或明确标注截断。

## 五、核验与异常判定

1. 核验文件记录与数据库记录的编号、时间、测试项目、测点、单位、期望值、实测值、上下限和状态。
2. 数值比较前统一或确认单位，保留转换关系与原始值。禁止在单位不明时直接比较。
3. 区分以下状态：合格、不合格、数据缺失、记录不一致、重复记录、超出时间窗、无法判断。
4. 报告中的统计值必须来自结构化工具或 Oracle 聚合工具，不能让模型自行对大量数字心算。
5. 发现异常时列明触发规则、受影响记录数、代表性记录、可能影响和需要人工复核的问题；文件记录应保留工具返回的 `_sourceRow` 或 `_recordIndex`，原因没有证据时只能写“可能原因”或“待确认”。
6. 完成核验后、撰写正文前，必须调用 `set_analysis_matrix` 提交判定矩阵，作为正文统计与结论的单一事实来源：
   - 每个判定行使用唯一 `id`；重复或冲突记录使用独立 id，并在 `note` 说明与原记录的关系。
   - `judgement` 只能取：合格 / 不合格 / 数据缺失 / 超出时间窗 / 记录不一致 / 重复记录 / 无法判断 / 待复核。
   - `source` 必须记录文件路径、工作表/记录路径、来源行或事件编号；数据库证据附 Schema、对象和过滤条件。
   - 首批调用使用 `mode: replace`；超过一批时，后续批次使用 `mode: upsert`。不得连续使用 replace，否则会覆盖前一批。
   - 提交后检查返回的 `analysisMatrixSummary` 与 `analysisReview`，确认总数和分类计数正确再写正文。
7. 当 `list_report_specs` 返回 `test-analysis-v1` 时，正式测试报告优先采用规范化路线：
   - 先创建一个 Markdown 文档骨架，再调用 `validate_report_facts` 校验结构化事实；所有业务记录和判定行必须填写 `source`。
   - 校验通过后调用 `apply_report_spec`。该工具会按本 Skill 的七章、29 个章节及子章节生成正文、表格、固定统计句和判定矩阵；不要再逐节自由改写。
   - 不要只提交最小字段。尽量从材料中提取测试构型、执行顺序、组织与质量控制、异常影响与处置、覆盖偏离原因、设备校准、软件数据影响、数据质量和待复核事项；测量与专项测试填写 `subsystem`（power / information / communication / control / functional）。需要形成深入文字分析时，填写带 `source` 的 `sectionAnalyses`（summary / findings / impact / recommendations）；不得给 6.1 添加自由分析，防止改变固定统计口径。
   - 需要修订时修改事实并重新调用 `apply_report_spec`，不能用 `write_document_section` 绕过规则。
   - 定稿后省略 `templateId` 调用 `export_document_word`，系统会自动选择配套的 `test-analysis-report-v1` 模板。

## 六、报告结构

除非用户指定其他结构，采用以下标准测试报告结构；没有材料支持的章节明确写“无本批次数据”“未见记录”或“不适用”，不得补造：

1. 概述：测试对象、任务/批次编号、时间范围、材料范围和报告目的。
2. 引用文件与数据来源：标准、细则、数据文件、版本及数据库对象。
3. 测试阶段描述：测试阶段、地点和有记录支持的环境条件。
4. 测试状态及测试过程描述：测试状态、被测对象各子系统、配套软件、不合格品、补充测试及质量保障要素。
5. 测试项目及指令覆盖性情况：逐项对照计划与实际执行，列出缺失、顺延或未覆盖编号。
6. 主要统计及判读情况：通电与测试统计；关键测量按供电、数据采集、通信、控制、功能分别分析；专项测试按供电、控制、通信和功能分别分析。
7. 测试设备及软件运行情况：仅陈述过程文档记录的设备、校准和软件状态。
8. 结论、建议与证据附录：结论、待复核事项、查询条件、文件位置和截断说明。

“主要统计及判读情况”必须包含且只包含一条固定统计句：
`本批次共 N 项：合格 A 项（编号清单）、不合格 B 项（编号清单）、数据缺失 C 项（编号清单）……`
只写矩阵中实际存在的分类；总数、分类计数和编号清单必须与判定矩阵完全一致。定稿时内核只核验这条固定统计句，避免把正文中的实测值和限值误当成编号。

## 七、交付前检查

1. 测试对象编号、测试编号、时间范围是否在全文一致。
2. 数据行数、统计口径、单位和时间规则是否写清楚。
3. `analysisReview.ok` 是否为 true；固定统计句的总数、分类计数和编号清单是否与矩阵一致。
4. 所有异常是否有证据，所有结论是否能追溯；环境、设备、校准、软件状态和整改措施是否来自实际读取的过程文档。
5. 是否把截断、抽样或缺失数据误写成全量结论。
6. 是否暴露数据库密码、连接串、无关业务记录或个人敏感信息。
7. 输出沿用搭手现有 Markdown/Word 文档能力；用户没有要求时，不增加复杂封面、签批流或多套模板。

From akuna12315/Rodya, Apache-2.0.

More from akuna12315/Rodya