先给结论：如何用AI生成测试用例，关键不是让AI凭空列出很多场景，而是先给它一个有边界的本地项目上下文：让墨刀AI客户端读取当前需求、接口说明、代码变更和已有测试，再把风险拆成正常、异常、边界、权限、数据和回归清单。AI负责发现测试点和整理初稿，研发与测试负责确认预期、补齐环境并执行验证。
真正有价值的结果不是“列出很多用例”，而是能回答三个问题：这次改动影响了什么、什么情况最容易出错、每个风险如何被验证。已有的AI生成测试用例通用教程适合看提示词和验证码登录示例，本文专门解决“本地项目里的研发测试任务怎么做”。
墨刀AI客户端生成测试用例，解决的是什么问题
常见的测试准备有两个断点：产品只给出业务目标，测试无法判断实现影响；研发只说明改了某个函数，测试又不知道用户路径和兼容范围。墨刀AI客户端的价值，是把本地项目中的多种证据放在一起分析：PRD或需求单说明“要实现什么”，路由和代码说明“实际上怎么实现”，现有测试说明“团队已经验证什么”，变更记录说明“这次哪里不同”。
它适合生成测试点、用例初稿、数据准备表、回归范围和待确认问题，不等于替团队执行全部测试，也不等于生成结果天然正确。涉及支付、权限、隐私、生产配置等高风险场景，必须增加人工评审和真实环境验证。
先准备一个最小可读的项目上下文
不要把整个电脑或共享盘直接作为项目根目录。建议准备一个只服务本次需求的文件夹，并把事实来源、工作草稿和评审结果分开：
| 目录或文件 | 建议内容 | 测试价值 |
|---|---|---|
00_context | 需求目标、范围、用户角色、非目标 | 防止AI把未计划的功能当成验收范围 |
01_sources | PRD、接口说明、数据字典、历史缺陷 | 提供可追溯的业务与技术事实 |
02_code或项目根目录 | 本次涉及的模块、配置和依赖 | 判断影响面、输入校验和错误处理 |
03_tests | 已有单测、接口测试、回归清单、测试数据 | 识别已有覆盖与缺口，避免重复劳动 |
04_review | AI初稿、冲突清单、评审意见、最终版本 | 保留变更记录，方便交接和回退 |
文件名最好包含版本和状态，例如 预约改期需求_v0.3_已确认.md、订单接口_历史参考.md。如果同一个规则在PRD、代码注释和测试脚本里不一致，要求AI先列出冲突，不要直接替你选一个“看起来合理”的答案。
先让AI分析变更影响，再生成用例
“帮我生成测试用例”通常过于宽泛。第一轮应该只做影响分析，让客户端回答：本次修改触及哪些用户路径、模块、数据字段、接口、权限和外部依赖？哪些现有测试可能失效？哪些规则在资料中找不到依据？
| 影响层 | 要查什么 | 输出示例 |
|---|---|---|
| 业务流程 | 入口、状态流转、角色和不可逆操作 | 普通用户改期、管理员代改、已完成订单禁止改期 |
| 数据 | 字段必填、类型、长度、枚举、重复和空值 | 日期为空、时区变化、重复提交、旧数据缺字段 |
| 接口 | 路由、参数、鉴权、幂等、错误码和超时 | 未登录、无权限、相同请求重放、下游超时 |
| 依赖 | 缓存、队列、第三方服务、数据库迁移 | 库存服务失败时是否回滚预约状态 |
| 兼容 | 旧版本客户端、浏览器、移动端和历史记录 | 旧订单打开新页面的展示与操作限制 |
这一轮的产物应是“影响面和待确认问题”，而不是一张已经盖章的测试计划。测试负责人可以先根据影响面缩小范围，再要求第二轮生成可执行用例。
一张高质量清单，至少覆盖六类测试点
研发测试容易只写“正常输入能成功”。对于一个新增的预约改期接口，可以要求AI按下面六类展开，并让每条用例带上前置条件、步骤、预期结果和数据：
- 主流程：合法用户在允许时间内提交一次有效改期。
- 异常流程：未登录、无权限、资源不存在、下游服务失败和服务器错误。
- 边界条件：截止时间前后一分钟、最短和最长日期范围、最大字符数、空数组和重复值。
- 数据一致性：状态、库存、日志、通知和重试结果是否一致，失败时是否可恢复。
- 安全与权限：越权修改他人记录、伪造ID、敏感字段回显和重复提交。
- 回归与兼容：既有查询、取消、退款、历史订单和旧版本页面是否受影响。
六类不是机械模板。若代码变更只涉及展示层，可以降低数据库和幂等测试的优先级；若改动触及支付或权限，则应提高安全、审计和回滚检查的权重。AI可以帮你提出候选点，但优先级必须由团队结合业务损失和发布计划决定。
可直接复用的墨刀AI客户端提示词
在客户端中用“目标—来源—输出—约束—验证”的结构，比一句“写测试用例”更稳定：
| 提示词部分 | 示例写法 |
|---|---|
| 目标 | 为预约改期功能生成研发测试初稿，重点识别本次代码变更带来的风险。 |
| 来源 | 只读取 00_context、01_sources、本次变更涉及的代码和 03_tests；标注每条结论的来源文件。 |
| 输出 | 先输出影响分析，再生成 Markdown 表格：用例ID、优先级、前置条件、步骤、数据、预期、关联需求、执行方式。 |
| 覆盖 | 至少包含主流程、异常、边界、权限、数据一致性、兼容和回归；对无法确认的规则单独列为待确认。 |
| 约束 | 不要修改源文件，不要虚构业务规则，不要把“建议”写成“已验证”，不要把未运行的测试标为通过。 |
| 验证 | 生成后列出遗漏风险、可能重复的已有用例、需要测试数据和需要研发确认的代码路径。 |
第一轮先让AI输出影响分析和疑问，产品、研发、测试确认后，再让它生成完整清单。这样能减少“格式很漂亮、前提却不对”的返工。
测试用例应该长什么样，才方便执行
建议每条用例都能独立执行和判定，至少保留这些字段：
| 字段 | 为什么需要 |
|---|---|
| 用例ID与优先级 | 支持回归筛选和发布风险排序 |
| 关联需求/变更 | 知道它为什么存在，需求变更时可定位 |
| 前置条件与角色 | 避免不同测试人员使用不同权限或状态 |
| 步骤与测试数据 | 让执行过程可复现，减少口头解释 |
| 预期结果 | 用可观察的页面、响应、数据或日志描述判定条件 |
| 执行方式 | 区分单元、接口、UI、手工、性能或安全检查 |
| 证据位置 | 记录截图、响应、日志、报告或缺陷链接 |
“接口返回成功”不是完整预期。更好的写法是“重复请求只产生一条改期记录，响应为约定的幂等结果，库存和通知状态与订单状态一致”。如果这些规则还没有确认，应标成“待决策”，而不是让AI自行补全。
生成之后，怎样完成真正的研发测试
生成清单后按四个门槛复核：
- 事实门：每个用例能回到需求、代码、接口或历史缺陷；没有来源的内容进入待确认区。
- 风险门：高优先级用例覆盖用户损失最大的路径，不能只按数量排序。
- 可执行门：前置数据、环境、账号、依赖和判定标准都写清楚。
- 证据门：执行结果留有日志、响应、截图或报告，失败项关联缺陷和版本。
墨刀AI客户端可以帮助你继续整理结果、修改文档或根据反馈补充用例；它不应被写成“自动通过测试”。实际执行仍由团队的测试环境、工具链和发布流程完成。若项目使用Git，先查看差异并在分支或可回滚副本上试验，再合并到正式分支。
把代码变更转成回归范围
每次提交都重新生成一整套测试用例，既慢又容易淹没重点。更有效的方式是让AI对比基线和当前变更，输出“新增、受影响、可保留、需要人工确认”四类清单：
- 新增：新接口、新状态、新权限、新错误处理对应的用例。
- 受影响：调用被修改函数的页面、服务、任务和数据迁移。
- 可保留：与本次变更无关且近期执行稳定的回归用例。
- 人工确认：资料不一致、依赖未启动或无法从静态文件判断的部分。
这样的变更影响报告比“回归全部功能”更适合评估发布成本，也方便测试负责人和研发负责人在同一份文档上做取舍。
把测试清单交给产品、研发和测试
一份可交接的结果至少包含：本次范围、输入文件版本、影响面、用例清单、待确认问题、执行环境、证据位置、未覆盖风险和下一步负责人。产品可以核对验收目标，研发可以确认实现边界，测试可以直接安排执行。需要多人评论和版本管理时，可将确认后的文档或原型带入墨刀工作台与企业空间继续协作。
如果团队还没有本地项目模板，可以先阅读墨刀AI本地项目怎么用，把来源、草稿、评审和归档目录建立起来；客户端的安装和能力总览见墨刀AI客户端使用指南。
常见问题
墨刀AI客户端能自动执行所有测试吗？
不能把它当成自动化测试平台来承诺。它更适合读取项目上下文、分析影响、整理测试点和生成文档初稿；具体执行要看团队的测试工具、环境、权限和当前客户端支持的操作。
已有一篇AI生成测试用例文章，为什么还要写这篇？
已有文章解决通用测试用例写法和验证码登录示例，本文解决的是本地项目场景：如何让需求、代码、接口、历史缺陷和变更记录一起参与分析，并把结果带入研发测试闭环。两者分别承接不同搜索意图。
应该把源码和生产配置都交给AI吗？
不建议。只开放当前任务需要的目录，先脱敏密钥、个人信息和客户数据，明确哪些文件只读、哪些文件可修改，并保留可回滚副本。涉及敏感或生产操作时，遵守组织安全制度并增加人工审批。
AI生成的用例越多越好吗？
不是。用例数量不是质量指标。优先保证高风险路径、边界和失败恢复可执行，再根据发布范围补充覆盖；重复、无法准备数据或无法判定的用例应合并或标为待确认。
墨刀AI客户端的正确用法，是让它把项目事实转成测试线索，把测试线索整理成可执行文档，再由团队用环境和证据完成验证。下载墨刀AI客户端，从一个可回滚的真实研发任务开始。
