概述
multi-ai-testing 提供测试驱动开发（TDD）工作流，通过独立验证防止“测试作弊”（test gaming），并确保测试覆盖充分。
用途：借助 TDD 生成高质量测试，达到 ≥80% 覆盖率（门槛）/ ≥95%（目标），防止智能体为自己的实现“量身定制”测试。
模式：基于工作流（共 4 个核心工作流）。
关键创新：通过分离的“测试智能体”与“实现智能体”实现独立验证，防止过度拟合与测试作弊。
核心原则（由 tri-AI 研究验证）：
- 测试先行——在实现之前编写测试。
- 独立验证——测试与实现由不同智能体负责。
- 全面覆盖——≥80% 门槛，借助 AI 发现边界用例可达 ≥95%。
- 非确定性评估——使用评分系统，而非简单的通过/失败。
- 自愈测试——测试可随代码变更自适应（据称可减少 80% 维护工作）。
何时使用
在以下情况使用 multi-ai-testing：
- 实施测试驱动开发（TDD）
- 生成全面的测试套件（单元、集成、E2E）
- 校验测试覆盖率（最低 ≥80%）
- 防止测试作弊（独立验证）
- 发现边界用例（AI 驱动的探索）
- 维护与演进测试（自愈适配）
前提条件
必需：
- 已安装测试框架（Jest、Vitest、pytest 等）
- 有待测试的代码或规格说明
- 可用的覆盖率工具
建议：
- multi-ai-implementation——用于在测试写好后实现代码
- multi-ai-verification——用于测试质量验证
需了解：
- TDD 概念（测试先行开发）
- 覆盖率指标（行、分支、函数）
- 所用语言的测试框架
测试工作流
工作流 1：TDD（测试驱动开发）
核心的测试先行开发工作流，可防止虚假实现与测试作弊。
用途：确保测试驱动实现，而不是反过来。
模式：测试 → 失败 → 实现 → 通过 → （独立）验证。
流程：
- 定义规格：在规格说明中写明函数签名、需求与边界用例（如 generateToken 接受 user 对象、返回 JWT 字符串、包含 userId、24 小时过期、非法用户抛错；边界用例包括 user 为空、缺少 id、未配置密钥等）。
- 先由测试智能体生成测试，明确要求覆盖正常路径、全部边界用例、错误场景与安全考量，写入指定测试文件，并声明“不要实现函数，测试初始应失败”。
- 运行测试确认失败（若测试通过则说明有问题）。
- 由另一个实现智能体按要求实现函数，要求“让测试全部通过、不要修改测试、遵循测试中的模式”。关键点：实现智能体看不到测试生成的推理过程，只能看到测试本身。
- 再次运行测试，确认全部通过。
- 由独立验证智能体审阅测试与实现，不读取实现对话，验证测试是否真正针对需求、边界用例是否充分、实现是否为高质量代码、安全考量是否覆盖，并给出 0–100 分与报告。分数 ≥90 视为通过。
产出：先写的测试、测试初始失败确认、实现通过全部测试、独立验证评分 ≥90、无测试作弊。
预计耗时：1–3 小时。
工作流 2：测试生成
生成覆盖单元、集成、E2E、属性测试与边界用例的全面测试套件。
用途：通过自动化测试生成达到 ≥95% 覆盖率。
模式：分析 → 生成（多种类型）→ 执行 → 校验。
流程：
- 分析目标代码或规格，识别可测试单元、函数签名与当前覆盖缺口。
- 分别由智能体生成：单元测试（面向每个导出函数/类，含正常路径、边界、错误场景，目标 ≥80% 覆盖该文件）、集成测试（跨组件流程，如令牌生成→校验、API 登录→返回令牌→校验、令牌过期→校验失败）、E2E 测试（完整用户旅程，使用 Playwright 或 Cypress）、属性测试（不变量，如所有令牌均为合法 JWT 格式、都含 userId、都带过期声明、校验与生成互为逆操作，使用 fast-check 或 Hypothesis）、边界用例测试（空值、最大输入、边界条件、非法格式、Unicode、并发、闰年、时区等）。
- 以上测试生成可并行执行。
产出：5 类测试的全面套件、约 ≥95% 覆盖率、发现的边界用例。
预计耗时：30–90 分钟。
工作流 3：覆盖率校验
测量测试覆盖率、识别缺口、生成缺失测试，直到达到 ≥80%（门槛）或 ≥95%（目标）。
模式：测量 → 识别缺口 → 生成测试 → 重新测量 → 报告。
流程：
- 运行测试套件并启用覆盖率（如 npm test -- --coverage 或 pytest --cov）。
- 从行、分支、函数、路径多个维度测量覆盖率，判断是否低于门槛。
- 找到未覆盖的代码行/函数/分支。
- 由智能体针对缺口生成测试（如错误处理分支、令牌刷新场景、特定函数）。
- 重新测量覆盖率，确认提升。
- 生成最终覆盖率报告，标明门槛通过情况与剩余缺口。
产出：各维度覆盖率测量、缺口分析、补生成测试、最终报告与门槛结论。
预计耗时：30–60 分钟。
工作流 4：独立验证
通过多智能体集成验证防止测试作弊。
用途：验证测试确实针对需求，而非过度拟合实现。
模式：启动独立验证者 → 集成评估 → 评分 → 报告。
流程：
- 启动未接触过实现过程的独立验证智能体，要求其对照规格说明与代码验证测试：是否匹配原始规格、边界用例是否充分、能否发现真实缺陷、是否过度依赖实现细节、是否含属性测试。各维度 0–20 分，合计 100 分，并输出报告。
- 对关键功能可启动 3 个独立验证者组成投票集成（无共享上下文），取中位数分数，并计算方差；若方差 >15，可再增加 2 个验证者组成 5 人集成。中位分 ≥90 视为高质量。
- 对照规格逐条交叉核验需求是否有对应测试，指出缺失项。
- 给出可执行的反馈（必须修复/高优先/中优先，含 What/Where/Why/How/Priority）。
产出：独立验证报告、0–100 质量分、规格交叉核对、可执行反馈、（如使用）集成评分。
预计耗时：45–90 分钟（集成方式增加约 30 分钟）。
与其他技能的集成
资料提及 multi-ai-testing 在 multi-ai-implementation 的第 3 步（增量实现）阶段被调用，原文在此处截断，具体集成方式暂未提供。
限制
资料仅描述了工作流本身，未提供具体收费、价格、支持平台列表或实际效果数据；相关细节暂未提供。