使用 AI 代理测试分布式系统

分布式系统测试技能 AI 编码代理的两项技能，用于为分布式和有状态系统设计和运行声明驱动的测试。他们共同制定了结构化的 Markdown 测试计划和调查结果报告，其中包含 9 种状态的判断以及明确的 SUT/线束/检查器/环境责任分类。审阅者阅读这两个工件并决定是否发布；无需重新运行其他任何操作。可与 Claude Code、Codex、Copilot CLI、Cursor、Gemini 或任何读取 Markdown 并运行 shell 的代理配合使用。技能是普通的 SKILL.md 文件。代理执行它们；计划和调查结果报告是输出。一项技能是设计计划。另一个运行它。计划从产品的声明开始，生成与这些声明相关的假设，并编写以每个试图伪造的声明命名的场景。对于一致性关键场景，每个场景还将抽象模型（寄存器 | 队列 | 日志 | 锁定 | 租赁 | 分类帐 | …）绑定到操作历史模式、命名检查器和具有可观察着陆证据的复仇者。该计划以覆盖充分性论证和保守的信心声明结束。为什么测试分布式和有状态系统的默认设置 - 编写一些集成测试并称之为完成 - 找到实际破坏生产中这些系统的一小部分错误：部分网络分区、非确定性并发、崩溃恢复、升级/回滚、重放下的幂等性、时间敏感的排序。这些技能强制执行固执己见的工作流程，该工作流程取自该领域来之不易的知识：声明驱动，而不是测试驱动。从产品的承诺开始。每种情况都会在一种过错下伪造一项索赔。以其声明命名的测试比以其设置命名的测试更难削弱。覆盖范围的充分性是可交付成果。该计划以一个论点结束，即所选择的场景足以交付，并列出了尚未验证的内容的诚实列表。重用 SUT 自己的工具箱。执行技能在发明任何新东西之前会发现现有的测试、运行手册和故障注入脚手架。模型+历史+检查器，不仅仅是混乱。为了安全性、持久性、幂等性、隔离、排序或成员身份声明，每个场景都声明一个抽象模型、一个操作历史模式、一个命名检查器（线性化、可序列化、会话一致性、无丢失确认、恰好一次……），以及如何处理不明确的结果（超时、未知提交、重试）。混沌加上模型和检查器，而不是单独的混沌。没有沉默的经过。每个 PASS 都会引用预言机执行证据以及证明故障实际触发的信号。判决来自 9 个州的集合，因此“混乱脚本运行干净”不能被解读为“索赔在故障中幸存下来”。每个 FAIL 都带有 SUT/线束/检查器/环境责任标签，以便复制者到达正确的队列。端到端，这两种技能会产生什么：testing-plans/.md ← §0–§9 的计划（见下文） test-sessions// ├── session-log.md ← 时间轴 + 工具箱 + env 探针 ├── 日志/ ← 每个场景 stdout/stderr ├── 指标/ ← 指标快照 ├── 工件/ ←短暂的利用、转储 └── discoverys/ ├── .md ← 每个场景的判决（写为运行过程） └── report.md ← 摘要 + 充分性 + 置信度增量 计划结构（审阅者可以阅读此内容并决定是否在不重新运行测试的情况下交付）： 0. 架构摘要 - 实际存在的系统 1. 范围 1b。受测试的权利要求 — 书脊 1c。发现缺失的声明 — 文档 ↔ 代码漂移 2. SUT 模型 3. 现有测试清单 — 已涵盖的内容 4. 故障模式假设 — 与声明 ID 相关 5. 覆盖矩阵 — 声明 × 假设 6. 技术选择 — 来自目录 6b.环境要求 7. 场景 — 每个场景都以声明命名，带有目标测试文件 + 骨架 7.M 模型/历史/ — 当场景伪造检查器纪律{安全性、持久性、幂等性、隔离、排序、成员资格}中的声明时，这是强制性的：测试中的模型、操作历史模式、命名检查器、复仇者 + 着陆证据、不明确结果处理、减少计划（SUT/harness/checker/env 责任）7b。覆盖充分性论证——为什么这些测试就足够了 7c。剩余不确定性——什么尚未得到验证，以及为什么可以 7d。置信度声明 — 审阅者的结论 8. 该计划不涵盖什么 9. 开放性问题/后续措施 示例 §7.M 块（计划摘录） ### 场景 S3：线性化_附加_下_分区 - 如果失败则伪造：C1（每个已确认的附加都是持久且可线性化的），C5（领导者选举在 5 秒内完成） - 工作负载：8 个客户端，70% 附加/ 30% 读取，5 分钟，密钥倾斜 zipf - 故障：非对称分区在 T+60 秒内将当前领导者隔离 30 秒 - Oracle：通过 Porcupine 对每个密钥历史记录实现线性化 §7.M（模型/历史/检查器规则） - 测试中的模型：日志 - 操作历史记录：默认 11 字段模式（操作 ID、进程 ID、调用/完成 ts、操作类型、键、输入、输出、错误、超时马