AI 新技术在测试的应用

• 核心定义：Harness 不是教模型怎么答，而是设计模型怎么工作（从 Prompt 工程 → Context 工程 → 机制设计的演进）
• Harness 全貌：上下文管理 / 工具编排 / 验证机制 / 状态管理 / 可观测性 / 人类接管
• 工程师建设的主体：Skill（工具编排的核心）/ SDD（工作流） / Hook（拦截机制）/ MCP（外部工具）/ 项目空间（知识 + 经验 + 约束 + 执行层）等等

• 知识层（knowledge/）：接口契约、错误码表、领域规格；按需加载，Agent 推理的原材料
• 经验层（experience/）：团队错题本；写"陷阱条件"不写个人偏好；任务关键词触发；少而精
• 约束层（hooks/）：Hook 自动拦截不合规输出；DoD 门禁阻止未评审用例进入执行
• 执行层（skills/ commands/ agents/）：Skill 封装工作流，Agent 定义角色，SDD 命令串联流水线

• 干预即信号：AI 反复编造 → 补知识层；评审反复驳回 → 补经验层；Agent 总忘规则 → 固化为 Hook
• 维护铁律：每次只加一条规则，单独验证，无效回滚；采纳率走低是 Harness 老化先行信号
• 自动进化闭环：评审驳回 + 执行失败轨迹 → 聚类归因 → 生成规则补丁 → 人工审批入库；安全红线：禁止把"真缺陷"规则化掩盖

• 用例设计：基于测试依据、领域知识、历史缺陷生成可溯源的用例集
• 可测试性：接缝设计、测试接口约定、环境构造——决定 Agent 能否可靠执行
• 可观测性：结构化日志、状态事件埋点、指标采集——决定 Agent 能否读懂系统状态
• 执行 + 自愈 + 诊断：Agent 驱动执行循环、失败分类与自愈、根因诊断
• 可测试性和可观测性是 Agent 的感知基础设施：两者不足，Agent 就只是代码生成器

• Skill = 封装"怎么干这件测试活"：步骤固定但需 AI 推理，单职责、可跨 Agent 复用
• MCP Server= 确定性 API，接入已有稳定工具（缺陷系统、监控平台）
• Agent = 持角色、带工具白名单，驱动"观察-决策-行动"循环；单 Agent 负责一个明确角色
• 多 Agent = 生成/评审/执行/诊断各司其职，独立上下文防自评估污染
• SDD= 结构化工件驱动的有状态流水线，命令（/gen-cases、/diagnose）是入口，每阶段起干净 Session

• 为什么分离：同一上下文内 Agent 幻觉检出率显著低于独立评审；最小模型 = 生成 Agent + 独立评审 Agent
• 为什么注入知识：无领域知识只产出"通用软件"用例，工程意义有限；来源：系统规格、接口契约、历史缺陷库、可观测性数据

• 可观测性是推理前提：日志格式不规范时 Skill 降级为关键词匹配，无法还原问题时序
• 三步流水线：预处理脚本（时钟校正、窗口截取）→ 推理提示词模板（固化"现象→假设→证据→验证"框架）→ Hook（拦截无行号引用的假设）
• 输入/输出 Schema：日志片段 + 时间窗口 + 错误码表 → 根因假设（按概率排序，引用行号）+ 验证手段；无证据标 [推测]
• [演示] 混杂日志 → 预处理 → 根因报告（含行号引用与置信度标注）

• 两档选型：现象单一 → 单 Agent 沿用 3.1 流水线；多源跨层复杂故障 → 多 Agent 并行深度定位
• 三角色编排：
  ○ Orchestrator：读预处理摘要，生成 3–5 条根因假设，并行派发 InvestigatorAgent
  ○ InvestigatorAgent × N：各持一条假设，独立读原始日志，输出findings/hypothesis_N.md
  ○ SynthesisAgent：汇读全部 findings，输出根因排序 + 验证手段 + 故障模式三元组
• 工程约束：状态只靠文件传递，各 Agent 独立 Session，无共享内存
• 知识沉淀：故障模式三元组回填经验层，下次同类故障自动 few-shot 注入
• [演示] 三角色编排自主执行：混杂多服务日志输入 → 三 Agent 并行独立推理 → 汇总输出根因排序

• 场景特点：工具调用驱动为主，LLM 负责解读异常；工程化比提示词设计权重更高
• 工具调用组合：端口/进程/配置检查 → API 健康探针 → 依赖服务连通性；每步结果独立记录
• 输入/输出 Schema：待检清单（预期状态）+ 工具返回 → 逐项 PASS/FAIL/SKIP + 修复建议（机器可读）；P0 项 FAIL 时中止并抛阻断信号

• 核心手段：模板驱动——Harness 存放报告模板，LLM 只负责叙事填充；统计数字由脚本计算，不过 LLM
• 输入/输出 Schema：执行结果 JSON + AC 映射表 + 报告模板 → 结构化报告；模板版本化管理

• 数据代表性：模拟数据必须覆盖真实负载分布（正常 / 峰值 / 容量边界），不能随机生成
• 时序关联：性能问题往往藏在时序关联里（A 指标先升，B 指标延迟跟升），单点阈值无法发现
• 瓶颈多因性：多指标同时异常时需多假设并行推理确定主因

• 参数化设计：负载模式（正常 / 峰值 / 容量边界）、时间粒度、业务场景权重
• 边界场景覆盖：满载、空载、冷启动、长时间跑批
• [演示] 生成三类负载模式的压测数据集

• 时序预处理：归一化时间轴、填充缺失点、对齐多指标时间戳
• 拐点识别：区分噪声与真实退化；多指标关联推理，输出"主因假设 + 支撑证据 + 验证手段"
• 容量预测：基于历史趋势外推，输出"X 时间后触达水位边界"预警
• [演示] 从参数到诊断报告的完整 Skill 链（数据生成 → 压测执行 → 趋势诊断）

• 核心差异：功能 / 性能测试是"执行 → 观察 → 判定"，SQL 优化辅助是"采集 → 分析 → 建议 → 人工决策"
• AI 的合理边界：禁止自动执行 DDL / DML；每条建议须附推理依据，不确定的标 [需人工验证]

• 慢查询日志结构化：按问题类型分类（全表扫描 / 缺失索引 / N+1 / 锁等待）
• 改写建议：说明"为什么慢 + 改写后为什么快"；P0（线上已影响）/ P1（潜在风险）/ P2（优化空间）
• 安全约束：输出建议文档，不输出可直接执行的 SQL；附"预估影响"字段

• 对比链：原始 SQL + 执行计划 → 改写建议 → 测试环境执行 → 新执行计划 + 耗时对比
• 常见慢查询模式整理进 Harness 知识层，下次分析自动 few-shot 注入
• [演示] 慢查询日志 → 结构化分析 → 改写建议报告（含推理链 + 优先级）

Skill 的主要风险是静默退化——提示词或模型变更后输出结构悄然变化，没有任何报错。

• 每个 Skill 维护固定输入 + 关键锚点清单，不做全文匹配，只检查必要结构字段是否存在
• /diagnose-log 锚点示例：「根因假设」标题、至少一处行号引用、「置信度：」字段
• 主动升级 Schema 时同步修改 checklist；模型升级引起失配时先判断改进还是退化再决定接受或回滚

核心问题：输入不完整时，Skill 是诚实降级还是幻觉出正常结论？

• /diagnose-log：未知错误码输出 [未知]，不编造含义；日志超长标注「仅分析前 N 行」，不静默截断后给完整结论
• /sql-review：无执行计划时标 [推测]；高副作用改写标 [需人工验证]，不输出可直接执行的 SQL
• 判定：含降级标注且无幻觉断言为 PASS；边界输入产出完整正常结论为 FAIL

• 独立评审 Agent：快照和边界测试只查结构，语义逻辑用独立上下文的评审 Agent 来查；每次 Skill commit 触发，每周随机抽真实输出批量评审
• Hook 约束：提示词是建议，Hook 是门禁；只写机器可验证的条件（关键词 / 字段存在性），影响下游结果的用 BLOCK，建议用 WARN；每条 Hook 须用坏输入验证能真正触发
• 幂等验证：同一输入连续调用三次均通过 Hook 检查；不通过说明提示词对上下文有隐式依赖

• 个人层（本地）/ 项目层（Git 管理）/ 团队层（共享仓库 + 安装脚本）
• 按"测试类型 × 能力域"建目录：功能测试 / 性能测试 / 优化辅助 × 用例设计 / 诊断分析 / 数据生成
• 每个 Skill 必须有 README（用途 / 输入输出 Schema / 使用示例 / 限制说明）

• 共享仓库 → 安装脚本（一键部署）→ 贡献规范（PR 模板 + Review checklist）
• Skill Hub 是团队规范传递的核心载体，新成员 Onboarding 的起点

• 脱敏 + 通用化改造：去除业务特有名词，从"适用于本系统"升级为"适用于同类场景"
• 以"问题 + 解法"为单位贡献，比直接开放整个 Hub 更易获得社区反馈

• 场景一（基线）：结构化日志，字段完整 → 设计 /diagnose-log Skill，触发 Hook 拦截缺少行号引用的输出
• 场景二（噪音）：日志混杂多服务，时间戳偏差，字段缺失 → 预处理脚本如何处理？Skill 如何标注证据不足？
• 场景三（知识缺口）：日志含系统特有错误码，模型不识别 → 如何注入错误码表？对比注入前后诊断准确度
• 场景四（规模约束）：日志超出上下文窗口 → 从"截取窗口"升级为"事件序列压缩"；诊断结论写入故障模式库
• 场景五（讨论）：根因根本没有被日志记录——Skill 应该输出什么？如何沉淀可观测性改进建议？

• 场景一（基线）：指标完整，有明显拐点 → 设计 /analyze-perf-trend Skill，识别拐点输出瓶颈假设
• 场景二（缓慢退化）：无明显峰值，持续缓慢劣化 → 如何区分噪声与真实退化？设计趋势外推与容量预警
• 场景三（数据缺失）：指标时序有缺失段 → Skill 如何降级处理？何时必须标注"诊断不可信"？
• 场景四（多因瓶颈）：CPU / 内存 / IO 同时异常 → 设计 /gen-perf-data Skill，链式组合进 SDD，验证幂等性

• 场景一（基线）：明显缺失索引的慢查询 → 设计 /sql-review Skill，输出带推理链的 P0/P1/P2 建议
• 场景二（安全边界）：复杂多表 JOIN，改写可能有副作用 → 如何加置信度标注和安全约束？
• 场景三（执行计划缺失）：只有 SQL 和耗时，无执行计划 → Skill 如何降级？如何推动补充采集？
• 场景四（知识积累）：同类问题反复出现 → 慢查询模式整理进知识层，验证 few-shot 自动注入效果

• 对完成的 Skill 做边界输入测试（空输入、异常格式、超长文本）
• 按 Hub 规范补充 README，提交到模拟 Hub 仓库走 PR + 评审流程
• 复盘：各学员分享一个"在递进场景里发现的真实问题"