2026年4月26日 · 阅读 —

未命名

Agent 与 Skills测试与评测

📝 未命名

使用 brainstorming 和 graphify 两个技能来整理：你的想法可行，而且很适合做成“测试知识图谱 + 影响分析工作台”。但关键不是单纯把资料喂给 graphify，而是要先把资料分层、打标签、建立稳定的“实体关系模型”，否则后面查询会有噪声。

我看了当前目录，已经有基础雏形：

01-raw/requirements/、01-raw/testcases/、01-raw/bugs/、01-raw/notes/、01-raw/code-diff/
以及已有输出：graphify-out/graph.json、graphify-out/GRAPH_REPORT.md、graphify-out/graph.html、graphify-out/memory/query_*.md

  • 推荐方案：测试知识图谱系统 v 1* 核心目标：把“需求、用例、Bug、测试笔记、代码 diff、未来代码工程”统一沉淀成一张可查询的测试资产图谱，用于：
  1. 新需求影响范围分析
  2. 测试用例设计辅助
  3. 风险评估与工作量评估
  4. 提测前 code review test
  5. 历史功能点、缺陷、边界场景召回
  • 目录建议* 保留你现在的 01-raw，但建议按“项目/迭代”再分一层：
01-raw/
  2026-04-检测报告瑕疵打点-PMO/
    requirements/
    testcases/
    bugs/
    notes/
    code-diff/
    code/
    meta.md

meta.md 用来记录迭代信息：项目名、时间、系统模块、负责人、版本号、上线时间、资料清单。这会让图谱查询更稳定。

  • 图谱实体模型* 建议重点抽这些节点：
需求 / 功能点 / 页面 / 接口 / 字段 / 业务规则 / 状态流转
测试用例 / 测试点 / 边界条件 / 风险点
Bug / 缺陷原因 / 修复方案 / 关联需求
代码模块 / 文件 / 函数 / Git diff / 变更点
系统角色 / 业务流程 / 外部依赖

关系可以这样设计：

需求 -> 包含 -> 功能点
功能点 -> 影响 -> 页面/接口/字段
功能点 -> 覆盖于 -> 测试用例
Bug -> 发生于 -> 功能点
Bug -> 暴露 -> 风险点
Git diff -> 修改 -> 代码模块
代码模块 -> 支撑 -> 功能点
新需求 -> 类似于 -> 历史需求
新需求 -> 可能影响 -> 历史 Bug/测试点/代码模块
  • 处理流程* 每次迭代完成后走固定流水线：

  1. 资料归档
    把需求、用例、Bug、笔记、diff 放入对应迭代目录。

  2. 资料标准化
    将 docx/xmind/csv/diff 尽量转成 Markdown/CSV/TXT，保留原文件，同时生成可读文本。

  3. 图谱更新
    使用：

graphify 01-raw --update --mode deep

或者针对单个迭代：

graphify 01-raw/2026-04-检测报告瑕疵打点-PMO --mode deep
  1. 查询沉淀
    每次影响分析结果保存到：
graphify-out/memory/

你现在已经有类似文件了，例如：

graphify-out/memory/query_20260426_014505_检测报告有改动_整理下影响范围.md

  1. 产出报告
    每次新需求或代码变更，输出固定模板：
影响范围清单
相关历史需求
相关历史 Bug
相关测试用例
高风险链路
建议新增/回归测试点
测试工作量评估
证据来源路径

  • 三个使用场景怎么落地*

  • 场景 1：新迭代影响分析*

输入：

本次需求：检测报告增加瑕疵打点逻辑，请分析影响范围

系统查询：

功能点 -> 页面 -> 接口 -> 字段 -> 历史 Bug -> 测试用例 -> 代码模块

输出：

影响模块：检测报告、车况详情、报告生成、C端展示
历史风险：字段缺失、状态不同步、报告渲染异常
建议回归：报告生成链路、C端查看链路、异常数据、老报告兼容
证据：引用 01-raw/... 和 graphify-out/...
  • 场景 2：code-review-test*

输入 git diff 后，把 diff 放入：

01-raw/<迭代>/code-diff/

然后查询：

这些改动涉及哪些历史功能、Bug、测试点？

输出重点不是“代码审查结论”，而是：

改动文件影响的业务链路
可能遗漏的测试点
历史缺陷是否可能复现
是否需要补充接口/数据兼容/回归测试
  • 场景 3：需求完整性检查*

拿到新需求文档后，先更新图谱，再问：

这个新需求涉及哪些历史功能？有没有遗漏的状态、字段、异常分支、历史 Bug？

它能辅助你做需求评审，尤其适合发现：

只写了主流程，没写异常流程
只写了前端展示，没写接口字段
只写了新增逻辑，没写老数据兼容
只写了业务规则，没写权限/状态/边界
  • 我建议先做 v 1，不要一开始做太重* v 1 目标很明确：让图谱能回答“这个需求/代码改动会影响什么，我该测什么”。

暂时不急着做：

自动生成完整测试用例平台
复杂 Neo4j 后台
多项目权限系统
自动 CI 集成

先把这几个能力跑通：

  1. 统一资料目录
  2. 统一资料转换
  3. graphify 增量更新
  4. 固定查询 Prompt
  5. 固定影响分析报告模板
  6. 每次分析结果落盘复用
  • 推荐推进路线*

第一阶段：整理规范
建立 01-raw/<迭代>/ 标准结构和 meta.md 模板。

第二阶段：跑通图谱
用当前已有资料，如 01-raw/requirements/C端业务知识资料库.docx、01-raw/bugs/淘车车2026年迭代-全部Bug1.csv、01-raw/notes/检测报告瑕疵打点&改装完善.md 做一次 v 1 图谱更新。

第三阶段：沉淀查询模板
做 3 个固定查询模板：

新需求影响分析
代码 diff 风险分析
测试用例设计辅助

第四阶段：做自动化脚本
封装成一个命令，例如：

uv run python 70-System/70.03-Scripts/test-graph/update_graph.py --iteration <name>

第五阶段：长期运营
每次 PMO/迭代结束后，只需要归档资料 + 运行更新 + 保存分析报告。

  • 我的判断* 这件事非常值得做。它的价值不在于“AI 替你测”，而是让你过去做过的需求分析、Bug 经验、测试用例、代码风险判断不再散落在文件夹里，而是变成可召回、可追踪、可复用的测试知识资产。

我建议采用“轻量知识图谱 + 固定测试分析模板 + 逐步自动化”的路线。先做 v 1，目标是 1 周内跑通一个真实迭代闭环。你确认这个方向后，我可以继续帮你把它落成一份正式方案文档，放到这个知识库里。

Continue reading

继续阅读