Casely 是一个虚拟 QA 负责人（Virtual QA Lead）工具，面向需要把需求快速转成可评审、可导入测试管理系统（TMS）的测试用例的 QA 团队。用户在一个连续对话中附上需求文档（有条件时再附上团队已有的测试用例样例），并说明需要什么，Casely 会依次完成格式学习、覆盖规划、生成前确认、用例生成与导出全过程。无需键入斜杠命令，也无需手工搭建项目脚手架；附件按 Claude 原生方式读取，在 Claude Code、claude.ai 网页版和 Claude 桌面应用中行为一致。
用途与背景
手工编写测试用例大约占用 QA 工程师 40% 的时间；需求往往以 PDF、DOCX、XLSX 等碎片化格式出现；每个团队都有各自的列结构、命名约定与写作风格。Casely 针对这些问题提供了流程化处理：直接读取需求文档（无需单独的解析步骤或额外依赖）、从团队自己的示例测试用例中提取正式的风格规则、在写任何一条用例之前先给出具体测试计划并等待确认、使用真正的测试设计技术而非简单复述需求、导出为单个 Excel 文件供 TMS 一次性导入；对于 API 层面的用例，还会生成 Postman 集合，并把 base URL、token、id 等环境相关值抽取为变量，使同一文件无需修改即可运行于 dev、staging 或 CI。
使用方式与流程
Casely 的对话分五个阶段，全部在同一对话内完成。阶段 1–2 与 4–5 不会在每一步都请求许可；阶段 3（测试计划）总是停下，等待明确批准后才生成任何内容。用户只需附上文件并说明需求，顺序不限，可一条或多条消息。例如："Here are the requirements for the Payments module and a couple of example test cases my team writes. Give me test cases for the refund flow."
阶段 1 — 接收与范围界定：直接读取所有附件（PDF、DOCX、XLSX、TXT、MD）。例外情况：若示例测试用例文件为 .xlsx 或 .csv，则用简短 Python 片段（openpyxl 或 pandas）打开，因为列顺序与精确的表头文本决定后续一切。区分需求文档与示例测试用例；若含糊则询问。解析范围：用户已指定功能/模块/章节则沿用；需求较短或明显只覆盖一个功能则处理整份文档；较长或跨多个不相关模块则列出检测到的模块并询问，用户未选择则默认整份文档。同时判断是否为 API 功能（method + path 端点、OpenAPI/Swagger 文件、curl 示例、请求/响应 schema、状态与错误码、认证章节等信号）。若未附示例测试用例文件，询问一次是否有；若无，则使用默认结构（ID | Title | Preconditions | Steps | Expected Result | Priority）继续。
阶段 2 — 风格指南（来自示例）：从示例中提取精确的列标题及顺序，完整保留每个表头（包括看似冗余的如 Comments、Author），因为 TMS 导入映射到这些列。记录 ID 方案与团队已用到的编号，新用例延续该方案。检测语言、语气与措辞模式。检查格式中是否有源需求列；多数团队格式没有，不应臆造，但需在计划中说明。用一两行总结风格指南，完整指南保存在 test_style_guide.md；此阶段不停留等待批准。
阶段 3 — 测试计划（批准闸口，总是停下）：从需求中提取模块/端点/逻辑块。按级别（API、Integration、E2E）分类并确定覆盖规模（Smoke 1–3 条/模块，覆盖最简黄金路径；Critical 约 80% 路径，聚焦高风险如金融/认证；Full 覆盖所有分区与边界）。按模块评估风险（高风险：金钱、认证、数据丢失；中：业务逻辑；低：UI）。构建 RTM 预览：需求或章节 ID → 计划用例数。标注测试数据需求。跨章节核对数字，收集范围内的所有限制、阈值、超时与计数，并逐一对照示例与其它章节，发现矛盾。报告需求中的缺口（不可测试、含糊、矛盾或未描述错误路径的内容），并特别检查两类模式：规范以某术语为行为门槛却从未定义；外部依赖失败却从未描述。说明本次是否包含 Postman 集合，若阶段 1 发现 API 层面需求，则给出数量并让同一批准覆盖它；若需求只描述流程而无端点，则请用户提供 API 文档或 OpenAPI 文件，不臆造路径。以表格呈现计划（Module | Level | Estimated Cases | Type | Notes）并给出总用例数，Type 列的每个值都必须能出现在生成套件中。然后停下请求批准。
阶段 4 — 生成测试用例（仅在阶段 3 批准后）：应用等价类划分、边界值、判定表、状态转换、错误猜测等技术，而非把每句需求转成一条用例。质量要求：原子性、独立、确定性的预期结果、真实数据值。一个文件 = 一条测试用例（1 ID = 1 场景），每条用例保存为 results/ 下独立的 Markdown 文件，命名 {type}{id}{short_description}.md。严格匹配风格指南。格式契约：每个文件恰好一个 Markdown 表格（表头行、分隔行、单个数据行）；单元格内换行写为 <br>；文本中的字面管道符转义为 |，否则导出会丢用例。为每个 API 用例编写请求规格（当计划承诺集合时），在 api/ 下保存小 JSON 文件。三条关键规则：只用路径不用主机；任何地方不得出现真实凭证（token 用 {{authToken}}）；所有环境相关值都用 {{variable}}，而被测试的值保持字面量。断言写成 expect 块而非 JavaScript；预期结果为邮件或渲染屏幕的用例保持手动。继续前检查覆盖。
阶段 5 — 导出：每次运行都导出 Excel。运行 scripts/export_to_xlsx.py，默认生成单个工作簿（每用例一行），导出为 exports/all_test_cases.xlsx；仅在用户明确要求每用例一个文件时使用 --split。非零退出表示用例被拒绝，消息会指出文件和原因，需修复 Markdown 后重跑。若计划承诺 Postman 集合，运行 scripts/build_postman_collection.py 生成 v2.1 集合、环境文件与 README（含导入与 Newman 说明）。交付全部文件，并用一句话说明用户如何使用。
适用场景
适合需要把碎片化格式的需求文档系统化转化为可评审、可导入 TestRail、Qase、Zephyr、Xray 等 TMS 的测试用例的 QA 团队；适合希望从团队既有示例中学习并延续列结构、命名约定、语气与语言风格的场景；适合同时需要书面用例与可执行 API 测试（Postman/Newman、CI 运行）的团队。
限制
资料中未提供关于收费、价格、平台支持范围（除 Claude Code、claude.ai、Claude 桌面应用外）以及效果保证的明确说明，这些信息暂未提供。若需求只描述流程而无端点，Casely 不会臆造 API 路径，而是请用户提供 API 文档或 OpenAPI 文件。预期结果为邮件或渲染屏幕的用例保持手动，不强行转成请求。