AI 拆解测试用例，输入数据应该包括什么

输入只有“新增会员导出”，AI也能生成十几条看似专业的用例，但可能漏掉企业真正的权限和数据规则。高质量AI用例依赖明确目标、需求验收、有效文档、历史风险和测试环境，并且每条用例都要可追溯。落地时每个结论都要回到版本、需求、用例、缺陷或知识库证据，AI只负责分析、解释和提醒。

给AI一个需求标题，它几乎总能写出测试用例。问题是，这些用例常常格式完整、业务空心。它知道要测试成功、失败和边界，却不知道公司如何定义会员、哪些字段受权限控制、历史上最容易坏在哪里。

AI拆用例的价值不是替测试人员批量写表格，而是基于完整输入扩大覆盖，并把每条用例追溯到需求和风险。

只给 AI 一条需求标题，它只能生成一份“看起来像用例”的列表

需求标题是“支持云盘外发链接设置密码”。AI 生成了创建链接、输入正确密码、输入错误密码三条用例，格式很整齐。但实际规则还包括过期时间、下载权限、访问次数、修改密码后旧会话是否失效、外部访问日志和管理员强制关闭。这些信息不在标题里，AI 不可能凭空知道。

所以“AI 会不会拆用例”不是第一个问题。第一个问题是需求、验收标准、交互原型、接口规则和历史缺陷是否已经进入同一个可读的输入包。

六类输入决定用例是否可用

版本目标说明本版最重要的结果；需求描述和验收标准定义业务承诺；原型、接口和规则文档补足交互与数据；历史缺陷提示回归风险；环境信息说明平台、账号、网络和测试数据；发布范围决定优先级。

这些资料必须是当前有效版本。把三个互相冲突的PRD同时交给AI，只会更快地产生一套无法确认的结果。

每条用例都要有来源

用例至少包含编号、名称、所属版本、关联需求、关联验收标准、前置条件、步骤、预期结果、优先级和负责人。AI生成时标记引用的资料和具体段落。

来源让测试人员快速判断“为什么要测”。需求变化后，系统也能找到受影响用例并标记需更新，而不是重新生成一大批重复内容。

AI适合补充四类容易遗漏的场景

正常业务路径由产品和测试最熟悉；AI更适合系统化补充异常、权限、兼容与历史回归。它可以根据字段规则组合边界，根据角色矩阵生成越权测试，根据历史缺陷识别高风险模块。

但AI不能自己决定业务优先级。P0用例必须由测试负责人结合版本目标确认，避免模型把罕见边界排在核心交易前面。

正确流程是生成草稿，不是直接入库

在嘟哩项目中，测试负责人选择版本后，系统读取目标、范围、需求、验收标准和绑定知识库，AI生成草稿。负责人可以合并、删除、修改、分配执行人，确认后才成为正式用例。

如果需求没有验收标准或资料已过期，系统应先列出缺失项，允许生成“待补充草稿”，但不能显示为已覆盖。

用例失败要继续连到缺陷

执行失败后，一键创建缺陷，自动继承版本、需求、验收点和用例关系。缺陷修复后，用例进入待复测；复测通过才能关闭。

这样AI生成不是一次性文档，而是进入测试执行和版本判断。发布检查能直接看到关键验收点是否有用例、是否通过。

如何验收AI拆用例功能

选择一个已经完成测试的历史需求，隐去原用例，只提供当时有效资料，让AI生成，再与真实缺陷和用例比较。看核心业务覆盖、历史缺陷命中、无效重复和人工修改量。

不要先追求“生成100条”。能生成20条有来源、可执行、少修改的用例，比一张庞大清单更有价值。

AI 拆解前的六类输入不能省

输入	提供什么	缺失后会漏什么
需求范围	用户、业务目标、不做范围	生成与本版无关的大量用例
验收标准	前置、动作、结果和例外	只有正常路径，不能判断通过
原型/交互	入口、页面状态、提示和返回	漏界面状态和操作路径
技术方案	接口、权限、数据状态、异常码	漏权限、并发、幂等和恢复测试
平台矩阵	终端、系统、版本、屏幕和网络	只验证开发者本机
历史缺陷	相关模块过去出过的问题	重复遗漏已知高风险场景

生成的每条用例要保留来源，例如“来自验收标准 AC-04”或“基于历史缺陷 BUG-218 补充”。AI 自行扩展的边界用例单独标记，由测试负责人选择保留、修改或删除。未经人工确认的草稿不进入正式用例库。

测试 AI 功能时，不要只统计它生成了多少条

选 5 条已经由资深测试人员完成的需求，隐藏原用例后让 AI 生成草稿。对比验收标准覆盖率、有来源用例比例、无效重复数、人工修改时间和遗漏的历史高风险项。只有当审阅成本也下降时，“一次生成 100 条”才是价值，否则只是把写用例改成删用例。

AI 拆用例前要先检查输入是否够用

测试让 AI 给一个“商户风险通知”需求拆用例。如果只有一句需求标题，AI 会生成很多看似完整的通用用例；但缺少触发条件、角色、通知渠道和失败处理，真正测试时仍然要返工。

环节	要记录什么	通过标准
需求	用户角色、入口、触发条件、成功结果	能拆主流程
验收标准	边界、异常、提示、权限、日志	能拆异常流程
设计/文档	页面、字段、接口、状态	能拆前后端校验
版本目标	本版范围、不做范围、优先级	能控制用例规模

嘟哩的用例管理板块应先给输入完整度评分。资料不足时，AI 生成的是“待补充问题”，不是直接生成一堆测试用例让测试背锅。

怎么验收

拿同一个需求分别在资料完整和资料缺失状态下拆用例。缺资料时能主动追问，完整时能关联需求和文档，才算可用。

真正落到产品页面时，要看到这些东西

项目经理进入嘟哩项目生命周期页面时，第一眼应该看到一个真实版本的当前状态，而不是一段功能介绍。入口动作也要直接：从新建版本开始补目标、人员、需求、用例和知识库绑定。用户每做一步，系统都要把输入、确认人、状态和产物留下来，后面 AI 才有可靠上下文。

页面区域	业务字段	系统状态	AI 动作
需求	用户角色、入口、触发条件、成功结果	当前状态、责任人、来源链接、更新时间	AI 检查“能拆主流程”，并给出缺口待办
验收标准	边界、异常、提示、权限、日志	当前状态、责任人、来源链接、更新时间	AI 检查“能拆异常流程”，并给出缺口待办
设计/文档	页面、字段、接口、状态	当前状态、责任人、来源链接、更新时间	AI 检查“能拆前后端校验”，并给出缺口待办
版本目标	本版范围、不做范围、优先级	当前状态、责任人、来源链接、更新时间	AI 检查“能控制用例规模”，并给出缺口待办

一天的真实使用路径可以这样设计：早上先打开看板看今日待确认事项；上午补齐缺失资料或接口数据；下午让 AI 生成分析、脚本、用例、风险或方案；执行前由负责人确认关键动作；晚上把结果、问题和下一步沉淀到同一个项目。这样用户不会觉得自己在“找 AI 聊天”，而是在推进一件有开始、有负责人、有产物、有复盘的工作。

产品里还要保留两个不太讨好、但很重要的状态：一个是“资料不足，不能判断”，另一个是“超出当前范围，建议拆分或延期”。这两句话会让页面看起来没有那么神奇，却能减少错误决策。企业场景里，靠谱比炫技更值钱。

边界说明

产研工作流的前置条件是项目对象要结构化。目标、验收标准、用例、缺陷和发布检查没有补齐时，AI 只能提示缺口，不能替管理者做上线判断。

读者真正会感受到的变化

以前项目经理靠群里追问版本状态；现在从版本目标、需求、用例、缺陷和发布检查里直接看结论。产品知道本版重点，测试知道验收边界，研发知道阻塞是谁，管理者不用再把任务数量当成上线依据。这段体验变化要在试点中被记录下来：用了几个入口、问了几个人、返工发生在哪一步、最终产物是否能被下一次复用。只有这些细节存在，文章里的方案才不是概念说明，而是能被团队带回去照着检查的工作方法。

常见问题

AI生成用例能减少多少时间？

需要用真实需求对比。应记录生成、审核和修改总耗时，不能只计算模型生成的几秒钟。

没有历史缺陷还能使用吗？

可以，但回归风险识别会弱一些，可先从验收、接口和权限规则生成。

AI是否可以执行用例？

部分自动化场景可以，但手工交互、视觉和复杂业务判断仍需测试人员或专门测试工具参与。