搞测试的朋友应该都有过这种经历：需求文档翻了三遍，用例写了上百条，回归跑了一整天，结果上线第二天用户就报了个Bug，而且是个稍微想想就能发现的逻辑漏洞。这种挫败感我太熟了。所以当AI开始进入测试领域时，我最关心的不是“能不能取代测试工程师”，而是“能不能帮我把用例覆盖得更全、把隐藏Bug挖得更深”。这篇小项目实战，就是我过去一段时间反复折腾的总结：用AI大模型辅助设计测试用例，再结合自动化工具去执行和验证，最终真的挖出了几个手工编写用例时容易漏掉的隐藏问题。

这个项目本身不复杂，不需要你懂算法推导，也不需要你搭什么分布式集群。你只需要会一点基础的测试思维，能写点简单的提示词，再搭配现有的自动化测试工具（比如Playwright、pytest），就能把AI变成你的测试设计助手。整个过程中，我会把我踩过的坑、调过的参数、验证过有效的方法全部摊开来讲，包括哪些环节AI是真的能帮上忙，哪些环节它反而容易添乱。

1. 为什么AI适合做测试用例设计

先说一个容易被忽略的事实：测试用例设计本质上是一种“基于约束的搜索过程”。你给出输入空间、业务规则、边界条件，测试人员要做的就是穷举那些容易出错、容易被忽视的组合。

而大模型恰恰擅长两件事：理解自然语言描述的业务规则，以及基于已有知识进行推理和枚举。这跟传统的自动化测试工具完全不同——它们只会执行你写好的脚本，而AI能生成你没想到的测试思路。

我在实际项目中做过一组对比实验：同一个登录模块，人工编写了32条功能测试用例，让AI基于同样的需求描述生成用例，结果AI给出了58条，其中有不少是我确实没考虑到的情况，比如“连续快速点击登录按钮导致重复提交”“密码框粘贴带空格的密码”“验证码过期与输入同时发生”这类边界组合。

1.1 AI设计用例的核心优势

AI在测试设计上最大的优势不是“快”，而是“视角不同”。

人类测试工程师写用例时，容易受经验惯性影响：你测过很多电商系统，再测一个电商系统时，脑子里会优先跳出“价格计算、库存扣减、支付回调”这类常规场景。但AI没有这种路径依赖，它会根据你的提示词从多个角度去推演业务逻辑，尤其是异常路径、分支组合、状态冲突这种容易被忽略的角落。

举个具体例子，我在测试一个订单状态流转功能时，手工用例只覆盖了“待支付→已支付→已发货→已完成”这条主链路。但AI给出的用例里有一条是：“订单在退款处理中，用户再次申请退货”，同时“后台管理员同时审核通过退款和退货申请”。这种状态重叠的场景，正是隐藏Bug的高发区，因为开发在写状态机时往往只处理了单一状态流转，根本没考虑两个操作并发到达的情况。

1.2 AI与人工测试的分工边界

这里必须先泼一盆冷水：AI不是用来替代测试工程师思考的，它是用来扩展测试工程师思考边界的。

我的分工方式是：AI负责广度和覆盖率，人工负责深度和判断。AI生成用例后，我会逐个做两件事——先判断“这条用例对应的业务规则是否真实存在”，再补充“这条用例的预期结果是什么、该怎么设计步骤”。最终真正进入执行阶段的用例，仍然要经过人工筛选和修正。

原因很简单，AI经常会一本正经地编造业务规则。比如它可能基于通用的“购物车逻辑”生成一个“跨店铺商品合并结算”的用例，但你的系统根本没有跨店铺概念，这条用例就是废的。所以务必把AI当成一个“思路发散助手”，而不是直接出报告的机器。

2. AI设计测试用例的完整操作流程

我在这个项目中验证了一套相对稳定的操作链路，分四步走：写需求摘要、设计提示词模板、生成与过滤用例、转化为可执行用例。每一步都有细节要讲究。

2.1 第一步：压缩需求文档为“引导输入”

AI模型的输入窗口有限，而且长文本描述容易让模型“注意力稀释”——核心规则被无关细节冲淡，生成的用例就会偏。

我的做法是：先把需求文档压缩成一段结构化引导输入，固定包含四个部分：

功能名称： 核心业务逻辑（3-5句）： 关键业务规则（编号列出）： 涉及角色：

举个例子，测试“用户积分兑换”功能时，我压缩后的引导输入是这样的：

功能名称：积分商城兑换 核心业务逻辑：用户使用积分兑换商品券，兑换后扣减积分，生成兑换记录，商品券发放到用户账户。 关键业务规则： 1. 兑换需用户登录，未登录跳转登录页并记录回跳地址； 2. 积分余额不足时，兑换按钮置灰不可点击，但接口层仍需校验； 3. 同一种商品券每个用户限兑换1次； 4. 兑换成功后积分实时扣减，但商品券发放延迟不超过30秒。 涉及角色：普通用户、后台运营人员。

这段输入大概100多字，既保留了关键约束，又不会让模型陷入无关的页面布局、UI配色这类信息。实际测试下来，结构化输入的用例有效性比直接扔一大段文档高出非常多，废用例率能从一个模型打回重做的程度降到只需要少量删改。

2.2 第二步：设计高质量提示词模板

提示词是AI生成用例质量的直接决定因素。我先后迭代了三版提示词，最终固定成了一个模板。

第一版最粗糙，只写“为我设计这个功能的测试用例”。生成的用例大路货居多，全是“输入正确信息，验证功能正常”这种毫无价值的废条。第二版加上了“结合等价类、边界值、场景法等用例设计方法”，质量提升但覆盖仍偏理想化。第三版才真正稳定，核心是加了“角色代入”和“负面路径引导”。

我现在常用的完整提示词模板如下：

你是资深测试工程师，擅长功能测试用例设计。请基于以下功能描述，设计一份完整的测试用例集。 【功能描述】 （粘贴上面压缩好的引导输入） 【要求】 1. 覆盖正常流程、异常流程、边界场景、异常数据输入； 2. 单独关注并发操作、状态冲突、重复操作、权限越权场景； 3. 对每条用例给出：用例编号、测试步骤、预期结果、优先级； 4. 如果某项业务规则存在隐含依赖或前提条件，请单独指出； 5. 先输出用例列表，再输出你认为最容易出现隐藏Bug的风险点分析。 请直接开始设计，不要反问，不要解释你的设计思路，直接输出结果。

这个模板的关键在于“先输出用例列表，再输出风险点分析”——因为如果你不限定顺序，模型很容易在开头絮叨一堆“设计理念”，占掉有效输出长度，还干扰后续字段的稳定性。

2.3 第三步：多轮生成与交叉验证

单次生成的用例基本只能作为素材，我是用多轮生成+交叉验证来提升覆盖率的。

具体操作是：把同一份引导输入分别发给同一个模型两次（保持提示词一致），或者用两个不同倾向的模型各生成一次。然后对比两份结果：找出两边都覆盖到的用例（这些通常是核心场景），再找出两边都没覆盖到的遗漏点，最后把两份结果合并去重。

有一次我在测支付回调接口时，两轮生成的用例都覆盖了“回调重复通知”“回调签名错误”“回调金额不一致”，但只有第二轮模型额外生成了“回调延迟超过30分钟后，订单状态仍为待支付，用户再次发起支付”的用例。这条用例确实对应了一个真实存在的Bug：支付网关超时后，网关重试机制与订单系统的幂等校验没配合好，导致用户支付了两次。

这种交叉验证的价值就在于，它能降低单一视角带来的盲区。你无法控制模型每次生成完全一致的内容，但你可以利用这种“随机性”来做覆盖补全。

3. 从用例到执行：用Playwright落地自动化验证

AI生成用例只是第一步，如果不执行，再多的用例也只是文档。我选用了Playwright作为执行工具，原因后面细说，先说怎么把AI生成的用例转化成可执行的自动化脚本。

3.1 为什么选Playwright而不是Selenium

坦白说，我早期用的是Selenium，踩了不少坑之后换成了Playwright。核心差别有几个：

• Playwright自带自动等待机制，不需要手工写一堆sleep和显式等待，脚本稳定性提升非常明显；
• 它的选择器机制更灵活，支持文本、层级、CSS、XPath多种策略组合定位元素，对动态渲染的页面很友好；
• 它内置了浏览器上下文的并发能力，可以用一个浏览器实例管理多个tab页面，这在测试“多窗口/多角色”场景时极其顺手。

而且Playwright有录制功能，你可以先在浏览器里手工点一遍正常流程，它会自动生成脚本骨架，我再基于这个骨架去改造异常流程的用例脚本。这对不熟悉前端页面的测试人员来说，上手成本低很多。

3.2 把AI用例映射成自动化脚本的流程

我的做法是，先挑选出适合自动化的用例。标准有三个：能被稳定复现、有明确的页面或接口交互、验证点清晰。

对于前端页面交互用例，我直接把AI生成的测试步骤逐条翻译成Playwright脚本。比如AI生成了一条“用户输入已过期验证码，点击提交，前端提示‘验证码过期请重新获取’”这条用例，我对应的脚本长这样：

from playwright.sync_api import sync_playwright def test_expired_captcha(): with sync_playwright() as p: browser = p.chromium.launch(headless=True) page = browser.new_page() page.goto("https://example.com/login") page.fill("#captcha_input", "123456") # 假设这是已过期验证码 page.click("#submit_btn") # 验证提示文本 error_text = page.locator(".error_msg").inner_text() assert "验证码过期" in error_text browser.close()

有经验的测试工程师应该能看出来，这条脚本本身没写死验证码过期这个状态是怎么构造的，而是通过预先在测试数据准备里设置一个过期验证码来实现。这是自动化用例与AI生成用例对接时比较关键的一个环节——AI生成的步骤是“用户视角”的，你要在脚本层补足“测试数据构造”的细节。

3.3 使用代码生成与人工修正相结合

Playwright有自带的codegen命令，可以在浏览器里录操作用例，自动生成脚本。我的经验是，AI生成的用例如果流程比较标准（输入-点击-断言），用codegen生成一套骨架脚本是很快的。

以我刚才那条过期验证码用例为例，大致流程是：

1. 先手动执行一遍正常登录流程，codegen录下脚本；
2. 打开生成的Python脚本，把正常输入替换成异常输入，修改断言文本；
3. 运行脚本，确认断言通过（也就是Bug能稳定复现）；
4. 把这条用例录入回归脚本集。

这种做法适合批量转化AI生成的高优先级正常流程用例。但有一条要注意：codegen生成的脚本会包含很多无关的等待动作、鼠标移动操作，如果你直接保留会导致脚本臃肿，执行速度也变慢。我一般只挑出关键操作记录，清理重复等待，最终脚本瘦身效果明显。

4. 挖掘隐藏Bug的进阶玩法

单纯的用例生成+执行只能测出常规问题，真正让我觉得“AI在测试领域有独特价值”的，是下面这三个进阶玩法。

4.1 让AI从用户视角做“暴力探索”

传统测试里有一种技巧叫探索性测试——不按既定用例走，而是像个真实用户一样在系统里乱点乱试，看能不能触发异常。这个行为AI完全可以模仿。

我把AI当成一个“模拟用户”，设定它的行为倾向：比如“一个脾气急躁的用户”“一个喜欢连续快速点击的用户”“一个喜欢乱填数据的用户”。然后让它基于功能描述生成一批“恶意用户操作路径”。

实测最有效的有三类：

• 重复提交型：连续点击提交按钮，看是否产生重复数据；
• 输入污染型：在表单里输入超长字符、特殊字符、Emoji、SQL片段、HTML标签，看是否被正常处理或导致页面异常；
• 路径跳跃型：跳过中间步骤直接访问最终页面（比如不登录直接访问订单详情URL），看权限控制是否兜底。

我就是在用“输入污染型”路径挖到一个真实Bug的：在用户昵称输入框输入了一个包含引号和斜杠的特殊组合，昵称成功保存，但后续加载用户列表时，前端渲染脚本直接报错，整个页面白屏。究其原因，是后端保存时只做了长度校验，没有做HTML转义，前端渲染时又直接用了innerHTML。这种问题你要是只测正常输入，永远不会触发。

4.2 用AI做差异覆盖弥补测试盲区

TDD（测试驱动开发）和传统测试有个老问题：测试人员和开发对需求的理解往往高度同源，测试用例和学习到的业务逻辑存在认知盲区。

AI在这里可以部分扮演“另一个领域的测试专家”。方法是我会让AI基于完全不看原始需求的前提下，根据“这个系统是干嘛的”这个背景，独立生成一份它认为需要测的清单。然后把这份清单和原始需求驱动的用例交集、差集都拉出来。

差集就是盲区所在。有一次我测试一个内容管理后台，需求驱动的用例重点全在“发布-编辑-删除-回收站”这条链路上。但AI独立生成的清单里有一条值得我注意：“不同管理员同时编辑同一篇文章，保存时后者是否覆盖前者且无任何提示”。后来还真复现出来了——系统确实没有做并发编辑保护，两个编辑同时保存时，后保存的直接覆盖先保存的内容，且没有任何冲突提醒。

这种“差异覆盖法”不能每次都用，因为它要求你准备好一个与原始描述隔绝的独立生成条件。但如果你的系统涉及复杂的多角色协作或状态流转，值得一试。

4.3 把AI给出的风险点直接当Bug线索用

上面提到了，我的提示词里要求模型在末尾输出“最容易出现隐藏Bug的风险点分析”。这个输出经常能直接给出有价值的线索。

有一次测试文件上传功能，AI在风险点里写了一条：“大文件上传时如果在上传中取消或切换页面，后端可能残留半成品文件，且没有定期清理任务”。我顺着这个线索去查了一下服务端临时目录，发现确实积压了非常多未完成的临时文件，占用了几十个GB的磁盘空间，都是之前取消上传留下的。这个问题不在任何一条正常用例的覆盖范围内，而且线上环境已经持续运行了很久，如果不是AI提示然后我们去验证，根本不会有人注意到。

这类发现不一定都是代码逻辑Bug，也可能是运维隐患、设计缺陷、数据垃圾，但对系统来说都属于隐藏问题。AI的价值在于它不带预设，会把你在需求文档中“默认正常”的环节重新思考一遍。

5. 常见问题与排坑指南

AI辅助测试不是一条笔直平坦的路，期间我遇到过不少问题。把解决过程整理成一个速查表，方便你遇到类似情况时直接参考。

5.1 排坑技巧：限制模型的“自由发挥”

AI生成用例时一个常见的坏习惯是：它会把同一个场景用不同话术反复输出，导致你看着用例数量多，实际有效场景没几个。

我的处理方式是，在提示词里强制加入如下内容：

如果某条用例的核心操作步骤或业务前提条件与已输出的某条用例相似，不要重复输出，直接跳过。

另外，我会在需求描述的最后加一个“禁用假设”列表：

你不允许假设任何需求文档中不存在的功能。所有用例必须严格基于上述描述中的业务规则。

加了这两项之后，我明显感觉生成结果从“看起来很多”变成了“真正能用的比例大幅提高”。

5.2 排坑技巧：自动化的“等待陷阱”

Playwright虽然有自动等待，但依然有两个场景会踩坑。

第一个是“页面路由跳转”等待。当你点击一个链接后立刻进行下一步操作，有时Playwright会因为页面还在加载就去找元素，导致找不到。虽然概率不高，但解决方法是操作后用显式语义动作，比如page.wait_for_url("*/order/*")，比单纯等元素出现更稳。

第二个是异步弹层、Toast提示这类短暂出现的元素。AI生成的步骤里经常有“等待弹出成功提示”这样的描述，但Toast往往只显示两三秒，你定位晚了就没了。我的做法是，断言Toast文案前，先确认元素可见的等待时间设置合理，再抓取文本。

5.3 排坑技巧：面对AI“幻觉”的验证方法

前面提到AI会编造业务规则，最有效的验证方式就是“交叉验证+需求核对”。

获得AI生成结果后，我会抽检其中不完全确定的用例，直接去翻需求文档，找到对应的业务规则描述。如果文档里找不到，再去找开发和产品确认。有几次我判断需求文档不清晰，直接找产品经理对线的过程，还额外发现了几处开发实现与产品预期不一致的地方，这些信息最后也变成了Bug线索。

6. 这套方法的价值边界与适用场景

AI辅助测试这套方法，我测下来最适用的是那些“业务规则复杂、状态流转多、角色权限层次多”的系统。比如电商订单、支付结算、审批流、会员积分这类。因为这类系统往往有大量分支条件和状态组合，人工写用例写不全，而AI恰恰擅长批量生成组合路径。

但有些场景我建议你还是老老实实用传统方法：

• 界面视觉验证：AI生成不了你需要的像素级判断；
• 性能基线测试：并发压测、响应时间、资源占用，这些只能靠专业工具；
• 硬件交互场景：扫码枪、读卡器、打印机这类外设交互，AI没法理解真实环境下的信号时序问题。

我在项目里总结的经验是：AI适合把“测试设计”这张网撒得更广，适合把“遗漏率”降到更低，但它不适合帮你在网已经破了的地方补洞。真正决定测试质量的，仍然是你对业务的理解深度，以及你愿不愿意多追问几个“为什么”。

6.1 适用团队规模与技能要求

这套方法对一个测试工程师来说，只要你会写基本提示词、会跑一个简单的Python脚本，就足够用了。不需要专门的算法能力，也不需要搭什么独立服务。

如果你的团队已经有自动化测试的基础设施，比如有持续集成环境，那就更顺手了，直接把生成的脚本接入已有的执行环境中，跑完自动出报告。如果是零基础团队，建议先从单条核心链路做起，测通一条，再扩到全流程。

6.2 长期维护时的注意事项

自动化测试脚本最大的敌人是页面结构变动。AI生成的用例对应的脚本一旦页面元素改版，经常大面积报废。

我的应对策略是：脚本中的元素定位全部收敛在一个“页面对象模型”层里，页面变动时只改定位层的代码，测试用例层不用动。另外，在需求文档或版本发布单里看到前端改动时，提前跑一遍受影响的用例集，快速确认哪些地方需要更新，不要等全部执行失败再排查。

7. 一些想额外分享的经验

这个项目做下来，我最大的感触是：AI不会替你思考，但它可以逼着你思考。

你没法直接拿AI生成的58条用例去糊弄工作，因为你要逐条判断“这条用例对应的业务规则是不是真的存在”“这条用例的预期结果是不是正确”。这个过程本身就是对你业务理解的加深。我发现我用了AI生成了几轮用例后，再回来看需求文档，能看到很多之前没注意到的细节，脑子里会自动浮现出以前不会想到的异常路径。

另一个经验是，提示词写得越具体，输出的质量越好。刚开始我偷懒，提示词只写“帮我设计这个功能的测试用例”，输出结果又空又泛。后来我每次花时间把需求压缩成结构化描述，再认真设计提示词，输出质量完全是两个档次。这个时间花得一点也不冤枉。

如果说这套方法还有一个隐藏收益，那大概是：当你把你的测试思路、风险判断、业务理解都写进提示词里，其实等于你在把测试经验固化成一个可复用的模板。下次测一个类似功能时，把提示词掏出来改一改，就能立刻进入状态，不用每次从零开始理思路。

最后再分享一个我一直在用的细节技巧：每次AI生成完用例后，我都会把它给出的“风险点分析”单独存档，哪怕当轮没有利用到，这些分析在未来做回归测试时也能返回来作为参考。曾经有一条风险点提示，是在半年后的版本迭代中，真的对应上了新引入的一个回归Bug——这种感觉还是挺奇妙的。