导出 Excel 和 XMind 对不上那天,我把用例生成拆成了两层

上周评审登录模块，我把用例表发给产品。产品看完说要 XMind，我转了一份。测试组长要 Markdown 贴 Wiki，我又转了一份。

三份摆在一起，对不上。Excel 里的「前置条件」这一列，XMind 里没了。Markdown 的步骤顺序，跟 Excel 也不一样。更麻烦的是两条用例的预期结果：一个写「提示密码错误」，另一个写「返回错误码 1001」。

同一份需求，同一个模型出的，三种格式三种说法。评审会上没人敢用。

我复盘了一下，问题不在格式转换，在生成方式：我把 PRD、接口文档、页面截图一股脑塞进一个长 Prompt，让它直接吐表格。

这种干法怎么翻车，基本可以预测。

换一种输出格式，字段、步骤、预期结果就跟着变。因为模型每次都在重新理解一遍需求，而不是在翻译同一份结论。

截图里看不见的业务规则，被当成事实补出来。我们吃过一次亏：用例里写着「连续失败 5 次锁定」，实际规则是按设备算的，而且这条规则从来没写进任何文档。

接口用例只有一句「验证登录成功」，没有 method、path、请求参数，也不说断言什么。这种用例没法执行，只能用来凑数。

性能需求没定 SLA，它照样填上「响应时间小于 200ms、支持 1000 并发」。数字看着挺专业，但来源是我编的还是它编的，已经分不清了。

生成一百多条，看着很全，可需求覆盖、状态覆盖、异常覆盖，一条都证明不了。数量替代不了覆盖。

先产事实，再选格式。中间加一层统一案例模型。

所有输入——PRD、OpenAPI、Postman、页面截图、历史 Excel——先解析成同一份 JSON；所有输出——Excel、Markdown、XMind、CSV、JSON——都从这份 JSON 渲染出来。

拆开之后，前面那些坑大部分自己消失了。

actual_result，实际结果。生成阶段必须留空，它只能来自真实执行。我以前最常犯的错，就是让 AI 顺手把这一列也填了——填出来看着完整，其实是假的。

source_refs，来源引用。每条用例记着事实来自 PRD 哪一节、接口文档哪一段。评审时有人质疑「为什么会有这条用例」，我能直接翻回去，不用靠记忆吵架。

data，测试数据。接口请求体、字段值都放在这里，密码、Token 这类敏感值用变量占位，不进共享产物。

还有一条硬规矩值得单独说：需求没写的事，不许自己定。

生成器可以从「密码长度 8 到 64」推出 7、8、9、63、64、65 这些边界值，这是测试设计。但它不能在需求没说明的情况下，自己决定「失败 5 次锁定」。拿不准的就进待确认项，不伪造结论。

选一份输入，生成统一 JSON，跑结构检查和标准检查，导出 Excel，人工评审，格式回读。

六步，第一次跑通大概半小时。真正省时间的是中间那两个检查。

结构检查看必填字段、类型、编号有没有问题。标准检查按规则输出三级结论：error 是结构错或关键字段缺失，不能交付；warning 是要人工确认的，比如弱断言、覆盖不足；info 只是改进建议。

我给自己定了条规矩：warning 不许静默忽略。要么确认接受，要么改用例，要么回去补需求事实。以前我就是只看「检查通过」四个字，结果把一批弱断言用例放进了回归集，跑绿了但什么都没验证到。

用久了肯定要改。我踩过的顺序错误，就是直奔源码。

正确的顺序是从软到硬。

这么排的好处是：不熟悉代码的同事也能完成前三步，团队规范不会全被硬编码进脚本。现在我们组模板和规则是两个人分开维护的，互不打架——模板回答「交付长什么样」，规则回答「什么结果不能直接交付」。

用了三个月，最大的变化不是生成变快了，是我敢把生成结果发出去评审了。

因为每一步都有出处，每一种格式都能回读，每一条 warning 都有人认领。

AI 能替测试打草稿，但替不了测试做判断

判断的前提是事实可靠，而事实可靠靠的是把事实和格式分开存放，不是靠一个更长的提示词。

我是 下班倒计时学家，八年一线测试老手，专注 AI 辅助测试的真实落地。

既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。

THANKS FOR READING