企业官网建设流程全解析

如果你最近让 AI 帮你写测试用例，大概率会跟我有同一种感觉：它生成的用例越来越像模像样，标题规范、步骤清晰、断言也有模有样，可一旦真的拿去执行，又总觉得哪里不对劲。更奇怪的是，换 ChatGPT、Claude、DeepSeek 这几款主流 AI 助手，结果都差不多。

我过去一年多一直在做测试设计和自动化落地，团队里也陆续引进了 AI 辅助写用例的工作方式。从最早的一惊一乍，到现在逐步回归理性，我想把这段时间观察到的真实情况写出来：AI 写测试用例的问题不在“生成能力”，而在“验证能力”。它没有能力判断一个测试用例是不是真的有意义。这个问题，目前几个主流模型都还没有解决。

1. 先说结论：问题不在“生成”，而在“验证”

1.1 “看上去合理”和“真的有效”是两码事

很多人第一次用 AI 生成测试用例，都会被它的输出质量唬住。你让它给一个登录接口设计用例，它能给你写出正常登录、密码错误、用户不存在、账号锁定、参数为空、SQL 注入、并发请求等等一长串用例，每条还都像模像样地配上“前置条件、操作步骤、预期结果”。单看文档格式，比不少新人写的还规范。

但测试用例的价值从来不在格式，而在两个地方：第一，它能不能发现缺陷；第二，它能不能在回归阶段守住业务底线。这两个问题，AI 回答不了。

我把这种情况叫作“表面合理”。AI 生成的东西符合人类对测试用例的刻板印象，但它没有经过真实系统的验证，也没有业务规则做支撑。这就像让一个只看过菜谱封面的人给你写一道菜的完整做法，步骤写得再完整，火候、油温、什么时候下料，全都只能靠猜。

1.2 为什么现在的体感是“越来越不靠谱”

你可能觉得奇怪，AI 模型一代比一代强，怎么测试用例反而“越来越不靠谱”了？

我的体感是：不是能力退化了，而是我们对它的判断标准变了。早期用 AI 生成用例，大家预期低，看到它能写出规范用例就觉得惊艳。等到真的把用例放进测试管理平台、跑完一轮回归、发现漏掉几个关键场景之后，再回头看 AI 的输出，就会觉得“不过如此”。这种落差感被放大，就成了“不靠谱”。

更重要的是，大模型的训练目标是“预测下一个词”，它学的是人类文本中的统计规律，不是软件系统中的真实行为。它知道测试用例文档通常长什么样，但它不知道你的系统里某个字段能不能为空、某个状态能不能回退、某个异常是不是真的会被触发。它写出的用例，本质上是在做“填空题”：用常见的测试模式填充你的提示词，至于这些模式适不适用，它没有概念。

再加上现在模型普遍支持长上下文，你可以把需求文档、接口定义、页面原型全丢给它，这反而让输出看起来更流畅、更自信。流畅不等于正确，自信也不能代替验证。于是越来越多团队发现：AI 生成用例的“可用率”并没有随着模型升级而明显提升。

2. 三个主流AI都绕不开的硬伤

2.1 空有语言概率，没有需求上下文

先说最核心的问题：语言模型不懂业务上下文。

你给它一段接口描述，它知道这个接口叫“login”，它见过大量关于登录功能的测试文档，于是就从记忆里提取“权限校验、密码错误、验证码、锁定策略”这些高频标签，拼出一份看起来覆盖面很全的用例集。但你的系统可能不是标准登录流程：可能是扫码登录、可能是短信验证码登录、可能支持第三方 OAuth、可能在触发风控时需要滑块验证，这些特殊规则在通用语料里出现得少，AI 就默认不写。

ChatGPT、Claude、DeepSeek 都一样，它们的输出高度依赖你给的提示词里有没有点明这些约束。你给了，它能在你给的约束范围内展开；你没给，它只能用最常见的假设补全。

我做过一个小实验：用完全相同的提示词让三个模型给一个订单取消接口生成用例，三个模型都覆盖了“已支付订单取消、未支付订单取消、重复取消、订单不存在”这些常规场景。但当我补充一句“只有订单状态为待发货且退款金额未超过限额时才能自动取消，否则需要人工审批”之后，输出质量出现了明显分化：有的模型能正确拆出“自动取消通过、自动取消失败转人工、金额超限、状态不允许”等边界；有的模型还是停留在“取消成功/失败”二选一。

这说明什么？AI 不是在“理解”需求，而是在“匹配上下文”。上下文给得越充分，输出越接近可用；上下文给得粗糙，它就还你一套标准模板。

2.2 预期结果含糊，断言全靠想象

测试用例三要素里，最核心的是“预期结果”。没有明确预期结果的用例，写了等于没写。

AI 生成用例时，预期结果往往是这样的：

• 登录成功
• 返回错误提示
• 状态码为 200
• 系统不允许删除
• 数据保存成功

看着没问题，但执行时你根本没法验证。什么叫“登录成功”？是返回了 token，还是跳转了页面，还是创建了会话记录？“返回错误提示”是提示“密码错误”、提示“账号不存在”，还是提示“请求过于频繁”？“数据保存成功”是数据库多了一行记录，还是页面刷新后能看到新数据？

这些细节 AI 不会给你。不是它不想给，是它看不到你的接口返回体、看不到你的页面交互、看不到你的数据库表结构。它只能根据通用经验写一个“听起来正确”的断言。一旦断言模糊，自动化用例就无法落成判定代码，手工用例也没法让执行者知道到底是 PASS 还是 FAIL。

我见过最典型的情况：AI 生成了一条“用户输入正确用户名和密码，登录成功”的用例，预期结果写的是“系统提示登录成功”。但实际系统登录成功后还会下发一条站内信，同时清除连续失败计数。AI 完全没有感知这些附带行为，于是执行者只验证了“能跳转首页”，漏掉了站内信和计数重置的检查。这两个遗漏，恰好在一次版本改动中引发了线上事故。

2.3 覆盖盲区：它不知道你不知道什么

测试设计的核心价值，在于找到“预期之外的缺陷”。而 AI 生成用例的核心逻辑，是“从已知模式中采样”。这两个方向天然相悖。

等价类、边界值、判定表、场景法这些经典方法，AI 确实学得不错。它知道 18 到 60 岁的边界要测 17、18、60、61；它知道金额为 0、负数、超大值要测；它知道并发、超时、重复提交这些异常场景要覆盖。但真实系统的缺陷往往藏在业务规则交叉的地方：员工离职后，待审批的单据应该转给谁？优惠券叠加规则变更后，历史订单怎么展示？库存超卖后，支付环节是否需要回滚？

这些问题没有现成模板，AI 不会“想”到它们。它会用“看起来完备”的常规用例掩盖盲区，让你误以为覆盖率很高，实际上真正容易出问题的链路一条都没测。

这其实是“测试预言（Test Oracle）问题”的延伸。AI 能轻松生成输入，但生成输入不是难点，难点是判断“这个输入对应的输出到底应该是什么”。这个判断需要真实需求、真实数据和真实业务规则，而 AI 手里一个都没有。

3. 我踩过的坑：AI 生成的用例到底离可用差多远

3.1 从一个登录接口的实操现场说起

有次我负责一个模拟项目 X 的接口重构，需要快速补充一批回归用例。我用 AI 辅助生成，提示词写得很简单：

“请为登录接口设计测试用例，包含正常流程和异常流程。”

几分钟后，AI 输出了一份 26 条用例的清单。表面看，覆盖了：

• 账号密码正确登录成功
• 密码错误
• 账号不存在
• 账号被锁定
• 参数为空
• 请求头缺少 Content-Type
• SQL 注入尝试
• 暴力破解导致的频繁请求限制

我把这份用例发给团队里一位新同学去执行，结果执行完一轮，他提出了几个问题：这个接口用的是手机号加验证码登录，根本没有密码；验证码有效期是 5 分钟，同一验证码只能使用一次，超过次数要重新发送；登录成功后如果设备指纹变化，会触发二次验证。这些关键场景，AI 一条都没写。

也不是完全没用，它给出了“频繁请求限制”这个观察角度，但限制策略具体是几分钟内几次、返回什么错误码、是否需要滑块验证，它全都没有。我后来意识到：我给的提示词本身就是问题，没有告诉 AI 这是验证码登录，它只能按“账号密码登录”的通用模板来生成。

3.2 给用例“挑刺”时最常发现的五类问题

之后我又做了大量类似的生成实验，逐渐总结出 AI 用例最常见的五类问题。

第一，断言模糊。前面已经提过，这里补充一点：AI 特别爱写“页面正常展示”“系统无异常”“操作成功”这类无法落地的断言。自动化用例里，这类断言等于没有。

第二，数据不闭环。AI 让你用“已注册用户”“已登录用户”“有库存的订单”，但不告诉你这些数据从哪来、前置条件怎么构造。实际执行时，你需要自己造数、清理数据、调整状态，AI 生成的步骤只到“使用一个已注册用户”就停了，真正耗时的数据准备它完全没参与。

第三，命名面向实现而不是面向业务。AI 起的用例标题经常是“test_login_with_empty_username”，而不是“未输入手机号时应提示请输入手机号”。前者是代码视角，后者才具备业务含义，回归执行时你一眼就能看出这条用例在守护什么。

第四，场景串不起来。AI 擅长写单步用例，不擅长写业务链路。比如“用户下单 -> 支付 -> 库存扣减 -> 退款 -> 优惠券返还”这条链路，AI 会把每一步拆成独立用例，很少考虑前一步的产物如何传递到后一步。这导致你执行完所有用例，也没覆盖到真正的端到端问题。

第五，覆盖靠“感觉”而不是靠数据。AI 不会告诉你它的覆盖依据是什么，更不会告诉你它漏了什么。你问它“还有没有遗漏”，它会补充几个新场景，但你永远不知道它是否还有盲区。相比之下，传统的覆盖率工具能告诉你哪些分支没走到，AI 做不到这一点。

3.3 直接照着 AI 用例去执行，会发生什么

说一个比较典型的失败案例。某开发者在内部项目里采用 AI 生成的测试用例做回归，用例清单写得漂漂亮亮，也通过了评审。但在一次涉及订单状态流转的版本修改后，团队直接跑这份用例，所有用例都是绿色 PASS。

结果上线第二周，用户反馈“退款申请无法撤销”。排查后确认，问题出在订单状态从“退款中”回到“待发货”的边界分支上。回看 AI 生成的用例，只覆盖了“退款成功”和“退款失败”，根本没写“退款申请被撤销”这个状态回退场景。

这个问题的根源不是 AI 不努力，而是它没有看到系统的状态机。它不知道订单状态之间存在多少种合法迁移路径，更不知道哪些迁移路径会在真实用户操作中出现。它默认“退款失败”就是终态，但业务上还允许用户手动撤销退款。于是这条缺失的用例，恰好是线上最关键的链路。

从那以后我定了一个规矩：AI 生成的用例只能当“初稿”，不允许直接进测试计划。必须经过至少一轮人工补全和预期结果重写。

4. 不是不能用，是用法错了：人机协作的改进方案

4.1 让 AI 写“骨架”，不要让它写“结论”

现在很多团队对 AI 的态度是两个极端：要么完全不信，要么直接照搬。我试下来，比较靠谱的定位是：让 AI 负责“批发初稿”，人负责“精修预期结果”。

具体操作上，我会把 AI 当成一个特别勤奋但缺乏业务常识的实习生。它会按我的提示词快速列出几十条候选场景，我再逐条做三件事：删掉不符合业务规则的场景；补上它遗漏的关键链路；把所有“预期结果”改写成可验证的具体断言。

这个过程消耗的时间，比从零开始写用例少很多，但质量最终由人掌控。AI 的价值是降低“空白页焦虑”，而不是替你下结论。

4.2 一份可以直接照抄的上下文模板

想让 AI 输出更靠谱，最简单的改进就是给足上下文。我总结了一份提示词框架，目前用下来效果不错，你可以直接替换成自己的内容：

• 被测功能：一句话说明功能名称和用户价值
• 需求原文：贴需求文档原文或产品描述，不要只贴标题
• 操作流程：用户在这个功能里经历了哪些步骤，按顺序写清楚
• 接口定义：如果有接口，贴出 URL、请求方法、入参、出参结构（最好给 JSON 示例）
• 页面规则：页面有什么跳转、有什么提示文案、有什么交互限制
• 数据约束：哪些数据是枚举值、哪些字段允许为空、哪些组合不合法
• 已覆盖场景：说明已经测过什么，让 AI 避免重复
• 输出要求：明确要几条用例、每条用例要包含前置条件、测试数据、操作步骤、预期结果四块

举个例子，你不应该这样写：

“给登录功能生成测试用例。”

你应该这样写：

“登录功能支持手机号加验证码，验证码有效期 5 分钟，同一验证码只能使用一次。用户连续输错验证码 5 次后需要等待 60 秒。如果用户更换设备，需要重新验证。请设计覆盖发送验证码、超时、重发、错误验证码、限制等待、更换设备这六类场景的测试用例，每条用例都需要包含具体的测试数据和可验证的预期结果。”

同样的模型，同样的能力，后一种写法的输出质量明显高于前一种。因为你不是在问一个没有上下文的通用模型，而是在让它做一道有明确约束的题目。

4.3 把测试意图写进提问词

如果你用过 AI 写代码，一定知道“给我一个排序算法”和“给我一个对包含空元素的数组排序、时间优先用快排、空间优先用堆排、异常输入返回错误标识的算法”是完全两回事。测试用例也一样，测试意图必须写清楚。

我常用的提问思路是：先描述用户角色，再描述业务规则，最后描述风险点。

举例，一个注销账号的功能，我会这样写：

“当前功能允许用户注销账号，注销后无法恢复，但近 30 天内有未完成订单的用户不能注销。注销需要发送短信验证码确认，验证码 60 秒内有效。注销成功后，用户的优惠券、收藏夹、积分余额应清空，已绑定第三方账号需要解绑。请你设计测试用例，重点覆盖：30 天内订单边界、验证码超时和重发、第三方账号解绑失败、注销过程中断网、并发注销请求。每条用例的预期结果请写成可断言的状态和数据变化，比如‘数据库中的状态字段从 NORMAL 变为 CANCELLED’。”

你看，我没有只丢功能名，而是把关键边界和风险点都点出来了。AI 在这种输入下生成的内容，才可能接近可用的初稿。

4.4 用覆盖率工具和变异测试反向找漏

前面说过，AI 最大的问题是它不知道自己的盲区。那你就要用工具来补盲区。

对后端接口，跑一遍自动化用例，然后看代码覆盖率报告。哪个模块的分支覆盖率低于 80%，就让 AI 专门针对那个模块再生成一批用例。这时候 AI 的“通用模板”会变得有价值，因为你可以让它集中输出边界值、异常分支、超时、并发这些场景，再手动筛选。

对核心逻辑，还可以引入变异测试。简单说，变异测试会故意在代码里做一点小改动，比如把>改成>=、把&&改成||，然后跑你的测试用例。如果用例没有把变异的代码打死，就说明你的断言不够严格，或这条用例根本没覆盖到那个分支。这一招对 AI 生成的用例特别有效，因为 AI 用例往往“有步骤、没断言”，变异测试能把断言弱的问题直接暴露出来。

工具上，Java 项目可以用 PIT，Python 项目可以用 mutpy，C# 项目可以用 Stryker.NET。这些工具虽然不能直接帮 AI 写用例，但它们能给你一份“这里还缺用例”的证据。有了证据，你再让 AI 补场景，效率会高很多。

5. 给测试工程师的实践建议与速查清单

5.1 人机分工的基本原则

经过大量踩坑，我把 AI 在测试用例这件事上的职责做了重新划分。

AI 适合做的事：

• 从需求描述中快速生成第一版场景清单
• 按等价类和边界值批量罗列输入组合
• 把口语化的验收标准改写成测试步骤
• 生成测试数据的造数脚本或 SQL
• 辅助编写符合格式的代码骨架、JSON Mock、接口调用样例

AI 不适合做的事：

• 判断预期结果是否正确
• 理解业务状态迁移和复杂规则
• 识别隐含的业务链路
• 决定“哪些场景可以不在本次版本回归”
• 评估测试覆盖率是否完整

如果你发现自己在让 AI 做后面这些事，趁早停下来。这不是 AI 的能力边界，是测试的职责边界。

5.2 我目前比较顺的混合流程

现在我负责的模块，基本跑的是下面这套流程：

第一步，人工整理需求上下文，按 4.2 的模板输出给 AI。这一步不能省略，因为 AI 能不能回答好，80% 取决于问题本身。

第二步，AI 生成初稿，我先把“预期结果”全部标记出来，逐个重写成可验证的断言。凡是写“成功”“失败”“正常”的，全部改掉。

第三步，把初稿导入用例管理平台，按业务链路重新排序、合并。AI 生成的单步用例，我手动串成场景流，保证前置事件的连续性。

第四步，执行自动化用例，收集覆盖率报告。如果发现遗漏分支，回到第一步，把具体的模块信息补充给 AI，让它聚焦补场景。

第五步，核心模块加变异测试，验证断言强度。这一步会持续暴露 AI 初稿里“看起来能跑但实际守不住缺陷”的用例。

这套流程走下来，AI 生成的内容大概有三分之一会被直接删除，三分之一会被重写预期结果，只有三分之一能保留骨架。即便如此，整体效率也比我从空白开始写要快，因为最花时间的“列全场景”部分，AI 帮我完成了大半。

5.3 常见问题排查速查表

最后贴一份我在实践中整理的速查表，遇到对应问题可以直接按表操作。

我最后的体会是：AI 写测试用例这个场景，真正卡脖子的不是“生成”，而是“判断”。你可以让 AI 用最快的速度列出所有可能的输入组合，但只要没有一个人能拍板说“这个预期结果是系统真实的、唯一的、可验证的表现”，这些用例就无法进入回归集。ChatGPT、Claude、DeepSeek 再强，也只是让你生成得越来越快，而不是让你判断得越来越准。

反过来想，如果 AI 有一天真的能自动判断测试用例是否正确，那它需要的就不只是语言模型，而是对被测系统的完整认知，包括代码、数据、状态、业务规则和线上行为。到那时候，测试工程师担心的恐怕就不是“AI 写用例不靠谱”，而是“AI 把测试也做完了”。在那之前，我们还是老老实实把人的判断力放在回路里，把 AI 当一个快点很多、但依然需要盯着的协作者。