| name | skill-qa-tester |
| description | QoderWork技能质量测试与验证工具。系统化测试技能的功能完整性、数据准确性、内部一致性和红线合规性。适用于技能首次发布前的全面测试、版本更新后的回归测试、多技能之间的一致性检查。当用户要求测试技能、验证技能质量、复核技能准确性、或打包发布技能前,自动应用此技能。 |
| version | 1.1.0 |
技能质量测试方法论
核心理念:以源文件为唯一真相源,逐行核验每一个事实声明。
适用技能类型
本方法论适用于以下类型的知识密集型技能:
| 类型 | 特征 | 测试重点 |
|---|
| 数据表格型 | 含大量数值、标准编号 | 每个数值和编号的行级核验 |
| 方法论型 | 教授思维框架 | 框架完整性、推理链正确性 |
| 审核工具型 | 检测其他内容的错误 | 错误检出率、分类准确性 |
| 模板输出型 | 按固定模板生成响应 | 模板格式合规性 |
五阶段测试流程
阶段一:全量读取
- 列出技能目录下所有文件
- 逐个读取全部源文件(不可跳读,不可摘要)
- 记录文件清单:文件名、行数、大小、最后修改日期
- 建立文件关系图:哪些文件互相引用、引用路径是否正确
阶段二:测试用例设计
设计原则:每种输出场景至少一个用例,每种边界条件至少一个用例。
2.1 覆盖矩阵
| 维度 | 必须覆盖 | 核验方法 |
|---|
| 输出模板 | 每种模板类型至少1个用例 | 对照SKILL.md中的模板定义 |
| 响应层级 | 每层至少1个用例(如适用) | 对照SKILL.md中的层级定义 |
| 跨技能路由 | 每条路由规则至少1个用例 | 对照路由规则定义 |
| 标准引用 | 高频标准+易混淆标准 | 核对编号、年份、名称 |
| 红线压力 | 至少2个对抗性用例 | 检查是否遵守红线规则 |
| 免责声明 | 每个用例均检查 | 逐句比对SKILL.md定义文本 |
2.2 测试用例模板
测试编号:T[N]
场景:[正常/边界/异常/对抗]
用户查询:[具体文本]
预期响应要点:
- [应包含的标准编号及数值]
- [应使用的输出模板]
- [应触发的路由规则]
核验锚点:[源文件名+行号,用于逐条验证]
2.3 对抗性测试设计
构造以下类型的查询来暴露技能薄弱环节:
| 对抗类型 | 查询设计思路 | 预期行为 |
|---|
| 诱导编造 | 条件不完整,诱导给出具体数值 | 应承认不确定并指明查阅路径 |
| 过时标准 | 查询已废止标准的最新版本 | 应提示新标准和替代关系 |
| 跨领域越界 | 问超出技能范围的问题 | 应识别并路由到正确技能 |
| 矛盾前提 | 查询中嵌入错误假设 | 应纠正错误假设后再回答 |
| 品牌诱导 | 询问"哪个品牌最好" | 应拒绝推荐品牌 |
阶段三:并行执行与逐项核验
3.1 执行方式
使用平台可用的并行执行能力启动独立测试用例:
- 每个子代理负责1-2个测试用例
- 子代理必须先读取全部源文件再模拟响应
- 模拟响应中的每个事实声明必须标注依据(文件+行号)
3.2 核验清单
对每个模拟响应逐项核验:
数据准确性
格式合规性
红线合规性
内部一致性
详细核验规则见 reference.md。
阶段四:修正与回归
4.1 精确修正
- 使用平台可用的精确编辑能力修改,一次只改一处
- 每次修正后搜索相关关键词验证修改结果
- 记录修正日志:修正前内容、修正后内容、依据、文件+行号
4.2 完整性扫描(修正后必做)
核心原则:修复N项时,必须验证修复是否覆盖了全部同类项,而非只验证已修复的N项。
每次修正后,立即执行以下完整性扫描:
同表/同节全量扫描:当修复涉及某个表格或章节中的某些行时,必须重新读取该表格/章节的全部行,确认所有行都遵循修正后的规则。逐行检查:
- 是否存在未被修复但存在同样问题的行?
- 修复后的模式是否在整个表格/章节内一致?
- 是否存在"相邻遗漏"(紧挨着已修复行的未修复行)?
同模式全文件扫描:当修复涉及一种格式规则(如状态标识系统、免责文本格式、编号格式等)时,搜索该规则覆盖的所有位置,确认无遗漏:
- 搜索旧模式关键词:确认旧模式在全文已彻底清除
- 搜索新模式关键词:确认新模式的覆盖数量与预期一致
- 计数比对(M + R = N):新模式匹配数 M + 旧模式残留数 R = 修复前旧模式总数 N,要求 R = 0
跨文件涟漪检查:当修复涉及一个标准编号、数值或状态变更时,检查其他文件中是否引用了同一数据:
- 搜索被修改的标准编号/数值在所有文件中的出现位置
- 逐处确认是否需要同步更新
4.3 回归测试
修正并确认完整性后,重新执行受影响的测试用例:
- 修正解决了原问题
- 修正未引入新问题
- 相关联的其他引用未受影响
- 同一表格/章节中的所有行都通过了与修复行相同的检查标准
4.4 回归失败模式清单
以下三类回归失败模式必须在每次修正后排查:
| 失败模式 | 描述 | 检测方法 | 典型案例 |
|---|
| 部分修复 | 表格/列表中有N项需修复,实际只修复了部分 | 修复后读取全表逐行检查 | Section 9共8行只修了5行,遗漏3行 |
| 涟漪遗漏 | 一处数据变更未同步到其他引用位置 | 搜索变更数据在所有文件中的出现 | A文件修了标准年份,B文件同一标准年份未改 |
| 模式残留 | 修复后同一结构内新旧模式共存 | 搜索旧模式关键词确认全文已清除 | 表格中部分行用🟢标识,部分行仍用纯文本 |
阶段五:报告与打包
5.1 测试报告模板
## [技能名称] 测试报告
**测试日期**:YYYY-MM-DD
**测试范围**:[文件清单]
### 测试用例设计
| 编号 | 场景 | 覆盖维度 | 核验项数 |
|------|------|---------|---------|
### 各用例核验结果
(按用例分节,逐项列出通过/不通过/警告)
### 发现并修正的问题
| 编号 | 文件 | 位置 | 问题 | 修正 | 依据 |
|------|------|------|------|------|------|
### 回归验证记录
| 修正编号 | 完整性扫描范围 | 旧模式残留数 | 新模式覆盖数 | 跨文件涟漪检查 | 结论 |
|---------|--------------|------------|------------|--------------|------|
| F1 | [表格/章节全量行数] | 0 | [预期数] | [涉及文件列表] | 通过/发现遗漏 |
### 改进建议
| 编号 | 类型 | 说明 | 处理状态 |
|------|------|------|---------|
### 测试结论
| 统计项 | 数值 |
|--------|------|
| 核验项总数 | X |
| 通过 | X |
| 不通过 | X |
| 警告 | X |
| 源文件修正 | X处 |
5.2 打包发布
- 仅打包技能定义文件(SKILL.md + 参考文件)
- 排除非技能文件:node_modules、.git、.env、数据库文件、残留空文件(nul等)
- 用 Compress-Archive 创建 .zip,重命名为 .skill
- 用 python zipfile 验证包内文件完整性
- 使用独立会话或子代理加载测试(功能冒烟测试),确认:
- 技能成功加载无报错
- 核心功能响应正确
- 免责提示正常附加
接口契约(IC-12 接收方)
本技能作为 QA 测试工具的接收方,遵循接口契约 IC-12(任何技能 → QA 测试工具)。完整 Schema 见 ../shared/interface-contracts.md §4.4 IC-12。
请求参数(与 IC-12-Request Schema 字段集一致,Schema 为 additionalProperties:false):
| 参数 | 必填 | 说明 |
|---|
| 被测技能 | 是 | 技能目录名(与 skills 目录一致) |
| 测试类型 | 是 | 首发测试 / 回归测试 / 跨技能一致性(按 IC-12 Schema 枚举) |
| 触发来源 | 是 | 发起方技能标识或 CG 编号,用于回归追溯 |
| 测试范围 | 否 | 文件清单,缺省为技能目录全部文件(阶段一全量读取) |
| 关注项 | 否 | 红线对抗/数据表格/路由规则等专项关注,缺省按覆盖矩阵全覆盖 |
响应内容:
| 字段 | 说明 |
|---|
| 测试结论 | 通过 / 有条件通过 / 不通过(枚举,不得自由表述;未执行用例不得计入通过) |
| 统计 | 核验项总数、通过、不通过、警告、源文件修正数 |
| 测试报告路径 | 报告落位路径(记录/ 或 成果/ 按项目规范) |
| 未决事项 | 未执行用例与原因、待人工确认项(存在时必返回) |
必填参数缺失时,返回"参数不足"并列出缺失项,不得假设后继续。
红线约束(禁止行为)
以下为本技能已注册红线摘要(全局编号),完整定义以 ../shared/redlines-registry.md §七为准:
| 编号 | 红线 | 摘要 |
|---|
| QA-R-P0-1 | 严禁伪造测试结果 | 未执行、未记录或无证据的测试不得标注为通过 |
| QA-R-P1-1 | 严禁测试集未执行却宣称全量完成 | 全量测试必须列出计划、执行、补跑、未执行状态 |
| QA-R-P1-2 | 严禁跳过红线触发测试 | 被测技能的 P0/P1 红线必须至少有一个对抗性用例 |
| QA-R-P1-3 | 严禁忽略回归来源 | 修复项必须能追溯到问题编号、修改文件和回归结论 |
| QA-R-P2-1 | 必须使用统一测试状态 | 状态限定为:计划/已执行/补跑通过/未执行/不适用 |
| QA-R-P2-2 | 必须区分报告结论与证据 | 索引只写最终状态,过程证据放报告正文 |
测试包模板
测试包最小构成(缺一即测试包不完整):
| 构成 | 内容要求 | 对应阶段 |
|---|
| 用例集 | 每个用例含编号、场景、预期响应要点、核验锚点(文件+行号) | 阶段二 |
| 覆盖矩阵 | 按 §2.1 六维度逐项标注覆盖用例编号 | 阶段二 |
| 红线对抗用例 | 被测技能 P0/P1 红线每条至少 1 个对抗用例(合计不少于 2 个) | 阶段二 |
| 回归记录 | 修正项的问题编号、修改文件、回归结论链路 | 阶段四 |
测试报告按阶段五 §5.1 模板输出,结论字段使用 IC-12 响应枚举。
与 GS/SSCV 的触发关系
| 场景 | 动作 | 契约 |
|---|
| 测试发现源文件错误并已修正 | 触发 GS 三层同步,并在 change-governance.md 登记 CG 编号 | IC-13 |
| 条文级内容取真存疑(疑似编造/版本冲突) | 转 SSCV 标准条文核验工具核验后再回归 | IC-11 |
| 标准版本有效性存疑 | 转 SR 标准复核工具核验 | IC-07 |
跨技能协作原则
当测试涉及以下专项技能时,应优先调用对应技能进行协同测试:
| 场景类型 | 优先调用技能 | 说明 |
|---|
| 装配式隔墙方案测试 | prefab-partition-wall-solution | 隔墙构造、隔声耐火性能、造价数据等专项测试 |
| 装配式装修材料综合咨询测试 | prefab-interior-materials-expert | 内装材料规范、工艺标准、质量验收等综合测试 |
| 标准复核测试 | prefab-standards-reviewer | 规范标准引用准确性、版本有效性等专项复核 |
| 防水工程测试 | waterproofing-expert(建筑装饰装修辅材技能合集) | 防水材料、构造做法、验收标准等专项测试 |
标准免责提示
每次测试报告末尾自动附加以下标准免责文本:
本回复基于知识库整理时间点的技术标准与行业通用实践整理,仅供技术参考。标准规范以官方发布的现行有效版本为准,引用内容可能存在时效性限制,重要项目请务必通过官方渠道核实最新版本。具体项目的设计、施工及验收应依据项目所在地适用的法律法规及标准规范执行,并由具备相应资质的专业人员负责。涉及结构安全、消防安全等重大事项的,请务必咨询相关专业机构。
常见问题模式
| 模式 | 检测方法 | 示例 |
|---|
| 标准年份过时 | 交叉比对多文件中同一标准的年份 | GB 55038-2024应为2025 |
| 状态标记滞后 | 对照实施日期和当前日期 | 已实施仍标"即将实施" |
| 数量统计不一致 | 实际计数 vs 声明数量 | "55项"实际56项 |
| 免责文本不完整 | 逐句比对SKILL.md定义 | 缺少"引用内容可能存在时效性限制" |
| 表头与数据列不匹配 | 列数对照 | 表头6列数据只有5列 |
| 边界符号混用 | 搜索≥和>的使用 | "≥"应为">" |
| 指标体系混淆 | 确认标准使用的指标类型 | GB 55038用DnT,w+C非Rw+C |
| 跨文件引用断裂 | 验证A文件引用B文件的路径 | reference.md不存在 |
| 示例与主表不一致 | 对比示例数值和主表格数值 | 示例写45dB主表写48dB |
| 部分修复遗漏 | 修复后读取全表/全节逐行扫描 | Section 9共8行只修5行,遗漏3行 |
| 格式模式残留 | 搜索旧模式确认全文清除 | 部分行用emoji标识,部分行仍用纯文本 |
注意事项
- 源文件是唯一真相源:核验以源文件为准,不以"常识"或"网上搜索结果"为准
- 每个声明都要有锚点:模拟响应中的每个事实必须能追溯到具体文件和行号
- 并行测试提效:用多个独立测试执行单元并行执行独立测试用例
- 修正必须精确:一次改一处,改完立即验证,避免连锁错误
- 回归必须完整:修正后不能只验证被修的那几行,必须对修复涉及的整个表格/章节/模式执行全量扫描,确认无部分修复、无模式残留、无涟漪遗漏(详见阶段四 §4.2)
- 区分"错误"与"警告":错误=与源文件不一致(必须修复),警告=可改进但不影响正确性
- 改进建议一并处理:测试报告中列出的改进建议应当场处理,不留尾巴
- 打包前清理:排除非技能文件(.git、node_modules、.env、数据库、空文件)
- 打包后必测:打包后的.skill文件必须做功能冒烟测试,确认加载和响应正常
双平台动作映射见 ../platform-adapter-reference.md。