企业官网建设流程全解析

做了这么多年测试，我越来越觉得，写测试用例这件事最耗精力的不是“设计”，而是把脑子里的判断翻译成一行行看得见、能执行、不重不漏的表格。尤其是功能测试用例，字段一多、分支一多，光是把等价类和边界值铺开就能铺一整天。从去年开始，我尝试把AI引入这个环节，让大模型直接基于PRD、接口文档生成测试用例，目前已经在几条产品线上跑顺了。这篇文章是“AI实战”系列的第一篇，核心只聊一件事：AI生成测试用例这件事，到底怎么落地才能不翻车。

文章会从最容易被忽略的“输入工程化”讲起，然后给出一套可以直接复用的Prompt模板，再分别用功能测试和接口测试两个真实案例跑一遍完整流程，最后聊一聊AI生成用例之后如何接入自动化测试、代码Review和Harness工程化，以及我踩过的那些坑。适合正在做功能测试、接口测试，想用AI提效但不知道怎么下手的测试同学，也适合测试开发顺手把用例生成纳入流水线的场景。

1. 从需求到用例：AI真正帮上忙的环节在哪

1.1 用例设计流程里哪些工作适合交给AI

测试用例的产生路径大致是：需求获取、需求分析、测试点提取、用例设计、用例编写、用例评审、后续维护。很多人一听到“AI生成测试用例”，第一反应是让AI一口气把最终用例表格吐出来，结果往往不尽人意。我的经验是，AI在不同环节的“可用度”差异非常大。

我一般把环节分成三档：

• 高可用：测试点提取、正向场景铺开、参数组合计算、边界值批量生成、用例格式规范化。这些工作规则明确、重复度高，AI输出质量很稳定。
• 中可用：异常流程补全、业务规则到断言的转换、接口参数依赖分析。这些需要一定业务理解，AI能做，但需要把规则讲清楚，或者用示例“喂”一下。
• 低可用：隐性需求识别、业务优先级判断、模糊需求的澄清决策。这些靠的是长期业务沉淀，AI目前只能帮忙列问题，不能替人拍板。

所以我的结论很简单：AI不是要替代测试设计，而是把你“想清楚但没时间铺开”的部分加速完成。设计环节依然由人主导，AI负责把设计意图变成成片的用例。

1.2 AI不是替代测试设计，而是替代“打字”和“查找”

我刚入行时用Excel一条条手动写用例，后来用思维导图梳理测试点，再后来用xmind转用例工具，效率一直在涨，但瓶颈始终是：测试点一旦确定，把每个点按“前置条件、步骤、预期结果”的格式展开，仍然是纯体力活。

真正让我转变的是一次版本迭代：一个下单页面的PRD有十几个字段、七八条业务规则，按老办法至少要大半天写用例。我用AI先列出了字段级等价类和边界值矩阵，再人工补充了运费的叠加规则，整个过程不到两小时，其中AI生成的部分至少省掉了三个小时。

需要很清楚一点：AI生成的用例，并不一定比老测试手写的更“聪明”。它的优势在于，只要规则明确，它不会漏写某一个分支，不会嫌麻烦，也不会因为写了三十条正向用例就开始烦躁。而人的价值则在于判断哪些分支真正重要、哪些异常场景值得投入自动化。把这两者结合起来，才是AI生成测试用例最正确的位置。

2. 喂给AI的“原料”怎么样才够味：输入工程化

2.1 PRD、接口文档、历史用例：三类输入的整理方法

AI生成用例的效果，七分靠输入，三分靠Prompt。很多团队把PRD直接丢给AI，得到的用例自然不忍直视。问题不在于模型不行，而在于原始需求文档本身就是一团乱麻。

我处理PRD通常分几个步骤：

• 先提取纯文本。PDF、Word里的PRD，先转成Markdown或文本，去掉目录、页眉页脚、营销描述，只保留功能相关的章节。
• 再补全字段信息。PRD里最常见的坑是“字段表不完整”，比如只写了“手机号，必填”，没写长度和格式。遇到这种情况，我先把原始文档里的零散规则汇总成字段清单，再让AI根据常识列出“缺失信息清单”，和人确认后再生成用例。
• 最后拆分功能模块。一个大PRD如果包含登录、搜索、下单、支付，一次喂给AI，大概率后半段内容会被模型忽略。我建议按功能模块拆分，每个模块单独生成用例，最后再合并去重。

接口文档相对好处理一些。如果是Swagger/OpenAPI格式，直接导出JSON或Markdown；如果是YApi、Apifox，也能导出接口列表。关键是要把每个接口的请求参数、必填项、类型、长度限制、枚举值、响应结构、错误码一并保留。接口文档本身就是结构化数据，AI从里面提取参数边界，准确率比从PRD里提取要高得多。

历史用例则是最好的“输出格式样本”。AI有很强的Few-Shot能力，你把之前维护良好的用例贴两三条进去，它就会照着同样的风格和字段去生成，比你在Prompt里反复强调“请按照标准格式输出”有效得多。

2.2 把需求“翻译”成AI能懂的结构化描述

我曾经让AI直接读一句“用户通过手机号和密码登录，密码错误超过5次锁定账号”来生成用例，结果它生成的密码规则五花八门：有的假设6位以上，有的假设必须包含特殊字符，还有的假设锁定时间是24小时。原因很简单，这条需求本身就是残缺的。

后来我把需求整理成结构化描述，再喂给AI，效果立刻不一样。下面是我常用的一个信息模板：

把这个模板发给AI之后，我还会额外加一句：“如果发现需求描述中缺少必要字段或存在歧义，请先列出问题清单，不要自己臆测规则。”这一句能挡住AI乱编需求，非常重要。

整理结构化描述看似多花了几分钟，实际是成本最低的一步。因为规则一旦明确，AI生成用例的准确率会高出一个量级，人工评审的返工量直线下降。这叫“输入工程化”，是AI生成测试用例所有技巧里最核心的一条。

3. 把测试设计方法写进Prompt：等价类、边界值与场景法的落法

3.1 一个高复用度的AI测试用例Prompt模板

很多测试同学问我要Prompt，我给的答案往往是：别去抄那些花里胡哨的“角色扮演型”提示词，你需要的是把测试设计的约束讲清楚。下面这个模板是我目前在功能测试用例里使用频率最高的，几乎可以直接照搬：

你是一名资深测试工程师，擅长功能测试用例设计。请根据下面的需求描述生成测试用例。 需求描述（结构化）： [这里粘贴整理好的需求说明] 测试设计方法要求： 1. 对每个输入字段使用等价类划分法，列出有效等价类和无效等价类； 2. 对每个有取值范围或长度限制的字段，使用边界值分析法，覆盖上点、下点、内点； 3. 用场景法覆盖主流程、备选流程和异常流程； 4. 重点关注业务规则组合，不要遗漏条件分支。 输出格式： Markdown表格，包含以下列： | 用例ID | 优先级 | 前置条件 | 操作步骤 | 预期结果 | 约束： 1. 不要编造需求中未提及的业务规则； 2. 如发现需求不完整，请先输出“信息缺口清单”，等待补充后再生成用例； 3. 预期结果必须包含明确的断言（页面提示、请求返回码、数据库状态等）。

这个模板看起来平平无奇，但每一句都有用。角色设定让模型切换到测试专家的知识体系；“测试设计方法要求”是核心，防止AI只写“快乐路径”，不会自己去做等价类和边界值计算；输出格式限定避免AI自由发挥成小作文；最后三条约束则精准打击了AI生成用例最常见的三个毛病。

3.2 让AI按判定表或正交法补充组合场景

单字段的等价类和边界值，AI完成得很好，但一旦出现多条件组合，AI就会开始偷懒。举个例子，商品搜索有四个条件：关键词、分类、价格区间、排序方式。如果要求“覆盖所有组合”，可能会有上百条用例，既不现实也无必要。这时我一般会让AI用判定表法或正交法来缩减。

我在Prompt里会增加一句：“如果输入条件超过3个，请先用判定表列出条件组合，再用正交法或业务判断选取代表性组合生成用例，不要穷举所有笛卡尔积。”AI通常会给出类似下面的分析：

• 条件：关键词（有/无）、分类（选中/未选中）、价格区间（设置/未设置）、排序（有业务影响/无业务影响）
• 在全组合的基础上，用正交表或Pairwise思想挑选覆盖单缺陷和双缺陷的代表性组合
• 最终生成用例时，标注“本用例覆盖的组合点”

如果你用的是支持插件或工具的AI助手，也可以直接要求它调用Pairwise工具来生成组合。只要是选对了方法，AI生成的组合用例命中率很高，能覆盖到最容易漏的“分类选中但价格区间未设置”这类场景。

还有一点值得提醒：AI对“边界值”的计算通常是可信的，但你要明确告诉它边界取几个点。比如密码长度8到20位，如果你不强调，它可能只写8和20，漏掉7和21。我在Prompt里固定写法是“覆盖上点、下点、内点”，必要时再加一句“特别注意刚好小于最小值、刚好大于最大值的非法输入”，这样AI才会把边界两边的邻值补全。

4. 从PRD到功能测试用例：跑通第一个真实案例

4.1 案例背景：商城登录与商品搜索

理论讲再多，不如动手跑一遍。我拿一个B2C商城的两个功能来做演示：手机号密码登录，以及商品关键词搜索。第一步，我把需求整理成前文说的结构化描述，然后直接丢给AI。

登录功能的需求描述要点：

• 手机号规则：11位，1开头，仅限中国大陆号码，输入框内可输入数字，禁止粘贴非数字字符
• 密码规则：8-20位，必须包含字母和数字，允许特殊字符
• 账号锁定：连续输错5次锁定，锁定30分钟，期间正确密码也不能登录
• 验证码：登录失败累计3次后需要输入图形验证码，验证码4位数字，有效期2分钟
• 会话：登录成功后生成Token，有效期24小时，多端登录互不挤掉

商品搜索的描述要点：

• 关键词：1-50个字符，支持中文、英文、数字，不支持特殊符号
• 分类：单级分类，可不选
• 价格区间：最低价与最高价均可不填；最低价不得大于最高价；价格区间为0-99999
• 排序方式：综合、销量、价格升序、价格降序，默认为综合

这里有一点很关键：这些规则不全是PRD字面上写的，有一部分是我通读了整份需求文档、和产品确认才拿到的。AI能不能生成好用例，完全取决于这步输入做得到不到位。

4.2 完整对话过程与生成结果

我把上述结构化描述放进3.1的Prompt模板里，AI生成的第一版用例节选如下：

这版生成结果已经具备基本可用度，能覆盖登录和搜索的核心链路。但请注意，我没有指望它一次生成就完美，而是把重点放在下一步的人工评审上。

4.3 用例评审：AI生成的用例里哪些要改

AI生成的用例拿来就能用？不可能。以这个案例为例，我评审时至少发现了三处需要修改的问题：

• 臆测验证码规则：AI在登录异常流程里自动假设“验证码4位数字”。这条规则确实存在，但原需求里只写了“验证码为4位”，没写“是否区分大小写、是否允许纯数字重复”。我最后和人确认后补全，AI原本的用例一旦用错规则，测试执行时就会产生误报。
• 缺少并发会话用例：AI没有覆盖“同一账号在手机端和PC端同时登录”的场景。这个场景在需求里其实属于“多端登录互不挤掉”，但AI没有主动推到这一层。需要我在结构化描述里写清楚，或者评审时人工补上。
• 断言不够明确：TC-LOGIN-005写的是“提示手机号格式不正确”，但没写前端提示的具体文案和后端状态码。如果前端的提示文案改了，这条用例的可维护性就很差。我通常会在评审时要求AI把所有预期结果补上“具体提示文案或状态码”。

评审AI生成的用例，我建议带着一张检查清单去看，而不是逐条读。我的清单里固定有几项：所有字段规则是否覆盖到边界；业务规则分支是否都有正反用例；异常场景是否包含了权限、状态、超时等维度；预期结果是否可断言；用例ID是否规范、能否和需求条目建立追溯关系。把这张表过一遍，比逐字阅读AI输出效率高得多。

5. 接口测试用例怎么设计：AI在参数矩阵上的优势

5.1 接口文档转用例的Prompt策略

功能测试用例讲完，再聊接口测试。AI在接口用例生成上的表现，其实比功能用例更稳定，因为接口文档是天然的半结构化数据，参数名、类型、是否必填、边界条件都清清楚楚。AI最擅长的就是从这种明确规则里批量产出参数矩阵。

我在接口场景下用到的Prompt策略和功能测试略有不同。核心是先把接口文档片段粘贴进去，然后明确要求AI按参数维度生成用例：

请根据以下接口文档生成接口测试用例。 接口名称：查询商品列表（GET /api/v1/products） 接口文档： [粘贴OpenAPI或接口文档片段] 要求： 1. 对每个请求参数分别生成：合法值用例、空值用例、超长/超界用例、类型错误用例、非法枚举用例； 2. 参数之间存在依赖关系时，生成组合用例（例如分类ID存在校验、价格区间大小顺序校验）； 3. 覆盖鉴权相关场景：未携带Token、Token过期、Token权限不足； 4. 覆盖业务状态：分类不存在、分类下无商品、商品全部下架、价格区间无匹配商品； 5. 输出格式：用例ID、接口路径、请求参数示例、预期状态码、预期响应关键字段。

这个Prompt比功能测试的Prompt多了一项“参数之间存在依赖关系时生成组合用例”，这是接口测试区别于功能测试的关键。因为单参数异常基本靠等价类和边界值就能覆盖，真正容易漏的是参数之间的逻辑关系，比如“分类ID存在但分类被禁用”“价格下限小于0”，这类跨字段的异常，AI在接口文档驱动下反而更容易列出来。

5.2 参数校验、业务规则、异常链路三类用例的生成

接口用例我习惯分成三大类，让AI分别生成，而不是一次性混在一起：

第一类是参数校验用例。每个参数都要覆盖：必填参数不传、传入空字符串、类型传错、长度超上限、长度低于下限、未在枚举范围内等。AI最擅长机械地把每个字段遍历一遍，几分钟就能生成几十上百条。

第二类是业务规则用例。这里考验的是对业务的理解。比如查询商品列表里，categoryId传了一个存在但属于父级分类的ID，系统是返回空列表还是返回该分类下所有子类商品？priceMin传了负数是直接参数校验失败还是被规整为0？这些规则通常不在接口文档里，而是埋在后端代码或PRD中。我的处理方式是：在Prompt里把已知规则一条条列出来，让AI逐条对应生成用例；对未知规则，则让AI标出“需要产品确认”，不要自行假设。

第三类是异常链路用例。包括数据库超时、第三方库存服务不可用、返回数据字段缺失等。这类用例很多团队只在手工测试里偶尔想到，自动化用例里很少维护。AI生成的价值在于，它会按“正常、鉴权、参数、依赖服务、并发”几个维度去罗列，不容易漏掉“库存服务超时”这类非功能但容易出问题的场景。

5.3 接口用例生成后如何落到Postman或自动化脚本

接口用例生成只是第一步，真正发挥价值还得落到可执行的工具上。我目前有两种落地方式。

一种是把AI生成的用例整理成JSON/CSV，导入Postman、Apifox或YApi。AI的Markdown表格输出，可以再让它转成符合Postman Collection格式的JSON，人工校验后直接导入，断言和请求参数一次性建好，省掉手动敲接口的功夫。

另一种是让AI直接把用例转成自动化脚本。如果团队用的是Python + pytest + requests，我会要求AI输出参数化用例代码，例如：

import pytest import requests BASE_URL = "https://api.example.com" @pytest.mark.parametrize( "params,expected_status", [ ({"keyword": "手机"}, 200), ({"keyword": ""}, 400), ({"keyword": "a" * 51}, 400), ({"categoryId": 99999, "page": 1, "size": 10}, 200), ({"priceMin": 100, "priceMax": 50}, 400), ({"page": 0}, 400), ({"size": 101}, 400), ] ) def test_search_products(params, expected_status): resp = requests.get(f"{BASE_URL}/api/v1/products", params=params) assert resp.status_code == expected_status

这里要特别提醒：AI生成的自动化脚本只适合作为初稿，别直接上流水线。第一个坑是断言太弱，比如只判断状态码，没判断核心业务字段；第二个坑是测试数据依赖，比如categoryId=99999不一定恒定为不存在，需要结合测试环境的数据准备策略；第三个坑是没有清理逻辑，参数化用例里创建的数据如果不清理，反复跑会污染环境。

6. AI生成用例只是起点：与自动化测试、代码Review和Harness工程化的关系

6.1 从用例到自动化脚本的“半自动”路径

如果你把AI生成的用例只停留在Excel或Markdown文档层面，那其实只发挥了它三成的价值。真正的提效路径，是让AI生成的用例直接变成自动化测试的输入。

我的做法是两步走：第一步，AI生成结构化的用例集，用JSON保存，字段包含接口路径、请求参数、预期状态码、预期核心字段；第二步，写一个简单的转换脚本，把JSON转成pytest的parametrize参数，或者转成测试平台可识别的用例描述。这个过程不复杂，但它能让“需求变更 -> 重新生成用例 -> 更新自动化脚本”的反馈周期从几天缩短到几小时。

如果你用的是测试平台，比如MeterSphere、TestRail这类工具，AI生成的用例也可以通过OpenAPI或CSV导入进去，配合平台本身的执行、报告能力。关键是不要让AI的输出成为一座孤岛，务必在生成时就考虑后续的机器可读性。

当前端接口或后端实现发生变化时，AI用例生成的“增量更新”能力特别值得用。不要每次重新生成全部用例，而是把变更的接口文档片段和原有用例一起喂给AI，让它只生成“受影响用例”和“新增用例”，再把变更标注出来，这样既降低评审成本，也避免回归范围失控。

6.2 用AI做代码Review时如何把测试用例当验收标准

很多团队做代码Review，主要靠人肉看代码风格、逻辑漏洞，缺少一个明确的需求验收标准。AI生成测试用例之后，我建议把测试用例清单直接变成Review的输入之一。

具体操作是：在Review某个接口的实现时，把该接口相关的AI生成用例集合和代码diff一起发给AI，让它逐条核对“代码是否满足这条用例对应的预期结果”。这样做有三个好处：

• 代码Review从“看代码是否顺眼”变成“看实现是否履约”，口径更客观
• AI能快速定位到“代码没有处理password为空时返回400”这类具体问题，而不只是说“这里有逻辑风险”
• Review产出物和测试用例强相关，后续回归时知道该回归哪些点

举个例子，某次我在Review登录接口时，把AI生成的TC-LOGIN-005（手机号非1开头）和TC-LOGIN-006（密码长度7位和21位）喂给代码Review的Prompt，AI立刻发现后端只用正则校验了11位数字，但没有校验“1开头”，导致非1开头的号码也能通过。这类问题如果只靠人工Review，可能需要盯很久才能发现。

6.3 Harness工程化：为什么用例生成需要纳入流水线

最后聊一个偏测试基建的概念：Harness工程化。Harness这个词，测试领域一般指“测试夹具”或“测试框架的承载层”，再往大说就是围绕测试运行的整套工程化能力：用例管理、执行引擎、数据准备、结果收集、环境管理。AI生成用例这件事，如果不和Harness结合，就只是提高了一个环节的效率，没办法形成系统性的杠杆。

我的设想和落地路径是这样的：需求文档合并到指定分支后，触发CI流水线，流水线里有一个“AI用例生成”任务。这个任务会自动读取变更的PRD或接口文档，调用大模型生成增量用例，提交到用例管理系统，同时打上“AI生成待评审”的标签。测试同学在评审通过后一键转正，再自动同步给自动化脚本生成器，更新参数化用例，触发冒烟测试。

这套链路里最值得做的一环是“需求变更跟踪”。很多测试团队最头疼的不是第一次写用例，而是需求频繁变更后用例没人同步更新。把AI生成嵌入流水线后，至少能在每次变更时自动生成“受影响用例草稿”，提醒测试同学去更新。不要指望全自动，能达到“变更后半小时内拿到AI初稿”这个状态，就已经比大多数团队领先很多了。

当然，这个工程化改造不是一蹴而就的。如果团队还没有持续集成流水线，先从“AI生成用例 + 人工评审 + 批量导入用例管理平台”开始，也能收到很明显的提效效果。

7. AI生成测试用例的翻车现场与应对经验

7.1 最常见的四类错误：臆造字段、遗漏异常、断言模糊、格式混乱

再顺手的工具也有翻车的时候。我在使用过程中，AI生成测试用例最容易犯的错集中在四类，我列了一个速查表：

这四类问题，前两类最要命，因为会直接导致漏测和误测。后两类虽然不影响执行，但会给后续评审和自动化落地带来很大的麻烦。所以我在每次找AI生成用例时，都会先把这四条写成一个“检查项”放在Prompt末尾，让AI生成完后自己对照检查。

7.2 我的使用建议：模型选型、上下文长度、迭代方式

模型选型上，我日常使用频率最高的是国内可直接使用的几款大模型：豆包、DeepSeek、通义千问，以及GPT系列。不同模型的风格差异很明显：豆包和DeepSeek对中文PRD的理解很稳，长文本处理能力也不错，适合直接贴需求文档；GPT系列在复杂业务规则推理和格式控制上更强，适合处理判空、组合爆炸这类逻辑密度高的场景。我的做法是让不同模型打配合：第一版用豆包快速生成，复杂模块用DeepSeek或GPT做二次精调。

上下文长度是另一个容易翻车的地方。大模型的上下文窗口虽然越来越大，但你一次性塞入整本PRD后，生成质量会明显下降，尤其是后段规则经常被模型遗忘。我的经验是，单次生成时输入不要超过5000字，重要的规则放在Prompt的靠前位置，或者拆成多个模块分别生成。对于超过这个体积的文档，先做章节切分，再按功能模块逐个喂。

另外一个关键经验是迭代式生成，不要追求一次到位。我先让AI读需求并列出“信息缺口清单”，确认完规则后再让它生成用例。生成后如果不满意，不是推翻重来，而是针对局部给修正指令，比如“把TC-LOGIN-005的预期结果补充为具体的状态码和文案”，这样AI会在原基础上修改，比重新生成稳定得多。

7.3 一套可复用的检查清单

最后分享我现在每天都会过一遍的检查清单。AI生成的任何一批测试用例，在进评审和进自动化之前，我都会逐项确认：

• 每条用例是否有唯一ID，且ID规则稳定，能追溯到需求条目
• 是否覆盖所有已知业务规则的正反场景
• 是否包含每类输入字段的有效等价类和无效等价类
• 所有长度、取值范围字段的边界值是否覆盖上点、下点、内点
• 是否覆盖主流程、备选流程、异常流程三大类
• 参数依赖类用例是否覆盖（如价格下限大于上限、分类ID不存在）
• 鉴权、权限、状态类异常是否覆盖（如Token过期、商品下架）
• 预期结果里是否有明确断言（状态码、页面提示、数据库状态）
• 生成格式能否被后续自动化脚本或用例平台直接消费

这套清单，AI可以在生成时自我对照，人工评审时也会再核一遍。双保险下来，AI生成的用例已经能达到“可评审”而不是“可观赏”的状态。

最后分享一个小技巧：不要把AI生成的用例当作最终答案，而是把它当成一个“基础完备但缺少轻重缓急”的草稿。AI不知道哪些用例在老板眼里最值钱，也不知道哪条用例对应的功能下周就要上线。优先级判断、业务判断、成本判断永远是人来做。把AI能做的铺开，把人该做的想清楚，这条“AI + 测试”的路才算真正走通。