北京
传统测试分布式系统的方式——写几个集成测试就完事——漏掉了生产环境真正致命的bug：网络分区、非确定性并发、崩溃恢复、升级回滚、重放幂等性、时序敏感排序。这些场景不是边缘情况，它们是常态。
这套方法给AI编码代理设计了两个技能，用纯Markdown文件实现，不挑工具：Claude Code、Codex、Copilot CLI、Cursor、Gemini都能跑。一个技能设计测试计划，另一个执行。输出是两份结构化文档：一份测试计划，一份带9种状态裁决的发现报告。审阅者读完就能决定能否发布，无需重新运行任何测试。
计划从产品的"声称"出发，而非从测试用例出发。每个场景都绑定一个待证伪的声称，场景命名直接对应声称内容。这比"test_user_login"更难被弱化。对于一致性关键的场景，还要绑定抽象模型（寄存器、队列、日志、锁、租约、账本等）、操作历史schema、具名检查器，以及带可观测落地证据的"复仇女神"故障注入。
执行技能会先发现系统已有的测试、运行手册和故障注入脚手架，而非重新造轮子。对于安全、持久性、幂等性、隔离性、排序或成员资格的声称，每个场景必须声明：抽象模型是什么、操作历史如何记录、用哪个检查器（线性一致性、串行化、会话一致性、无丢失确认、恰好一次等）、以及如何处理模糊结果（超时、未知提交、重试）。混沌只是手段，模型+历史+检查器才是验证核心。
裁决不是简单的PASS/FAIL。9种状态确保"混沌脚本干净运行"不会被误读为"声称经受住了故障"。每个PASS必须引用预言机执行证据和故障实际触发的信号。每个FAIL必须打上SUT/工具链/检查器/环境的责任标签，让复现者知道该找谁。
计划以覆盖充分性论证收尾：选定的场景为何足够发布，以及坦诚列出仍未验证的内容。这不是测试驱动，是声称驱动。不是混沌工程，是可验证的混沌。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
