企业官网建设流程全解析

1. 为什么我放弃了“让AI直接列测试点”这个偷懒方案

先说个结论：如果你只是把需求文档扔给ChatGPT，让它“生成测试点”，十分钟后你确实能拿到一版看似工整的清单，但它大概率长这样——“验证手机号为空时提示”“验证密码错误时提示”——全是废话，和你自己对着需求文档划重点没什么区别，甚至更啰嗦。

我真正开始把AI测试点生成跑进日常流程，是在我摸索出一套前置动作之后：先把需求转成结构化模型，用模型去约束AI的输出边界。这个思路改变的不只是产出质量，而是整个测试设计的工作方式。

我的核心用法是：需求模型扮演“知识底座”，AI负责“在底座之上做枚举和扩展”。没有底座，AI就是在裸奔；有了底座，AI的每个输出都能追溯回需求本身，评审的时候你可以问它“这条是哪条规则推出来的”，它答得上来，你才敢用。

这篇文章是“AI测试工程笔记”的第三篇，前两篇我聊了AI在用例生成和缺陷分析里的应用，这次重点拆解从需求模型到测试点的完整链路。内容会偏实操，会给出提示词模板、模型结构和运行记录，也会把踩过的坑原样摆出来。

适用对象很明确：正在做功能测试、测试设计，手里有AI工具但总觉得“生成的东西用不上”的测试工程师。如果你是测试开发，或者对提示词工程有一定基础，这篇文章里的思路可以直接平移到你自己的自动化测试设计场景里。

2. 需求模型不是流程图，是可被AI消费的结构化素材

2.1 需求模型到底长什么样

很多测试同学一听到“需求模型”四个字，第一反应是画用例图、时序图、状态图。这些UML产物当然有用，但它们更多是给人看的，用来交流、评审、归档。而AI最擅长消费的，是清晰、分域、带规则的文本结构。所以我在实践中把需求模型简化成三个互相独立又互相关联的模块：

• 信息结构：系统里都有哪些核心数据对象，它们的属性、格式、约束是什么。比如“用户”有手机号、密码、昵称；“订单”有订单号、金额、状态。
• 操作流程：用户完成某个目标需要经过哪些步骤，每一步的入口、动作、出口是什么。流程不必画图，用编号列表描述清楚即可。
• 业务规则：系统在特定条件下必须遵守的约束，包括必填项、长度限制、格式校验、状态流转条件、唯一性约束、权限限制等。

这三块拆完，需求模型就有了。它不需要多复杂，关键在于“完整性”和“确定性”——每一条信息都能回溯到原始需求文档，而不是你脑补出来的。

2.2 为什么模型必须前置，直接让AI读需求文档不行吗

你可以把需求文档理解成一篇散文，把AI理解成一个擅长揣测的学生。你让一个擅长揣测的学生读散文然后写总结，他可能写得很好，也可能跑题跑到天上——因为散文的语义太模糊，每个人理解不同，AI的“理解”只是概率预测，它会在你最意外的方向上给你惊喜。

而模型的作用，是把“散文”翻译成“应试大纲”。大纲里每一条都是明确的、原子的、无歧义的。AI拿到大纲之后做的，不是“理解”，而是“排列组合”。它基于大纲里的规则去枚举可能的场景、条件、异常，准确性会大幅提升。

我实测过两组对照，同一份支付需求：

• 直接投喂原始需求文本：AI生成40条测试点，其中有效可用的约50%，大量内容集中在“正常支付成功”和“余额不足”这种表面场景。
• 先建模再投喂：AI生成36条测试点，可用率超过85%，而且边界、异常、状态冲突这些靠人肉容易漏掉的场景覆盖明显更全。

这组数据我没法给你做出严格的实验报告，但对比样本跑了十几次，趋势始终一致：模型前置之后，AI生成的稳定性显著变好。

2.3 建模时最常见的三个误区

第一，把流程画得过于复杂。流程的目的是让AI知道“操作顺序”，不是让你炫技。一个登录流程，用三步描述清楚“输入-校验-跳转”，比画一张十个节点的流程图有效得多。

第二，规则和流程混着写。AI分不清“步骤”和“约束”时，生成的测试点容易错位，比如把“密码长度6-20位”这种规则当成一个独立操作步骤输出。建议在模型里用明确的标签区分两者。

第三，遗漏隐性规则。需求文档里只写“校验手机号格式”，但没写格式具体是什么。如果你建模时不补上“11位、以1开头”，AI生成的边界测试点就会凭空捏造规则。建模的过程本质上是需求澄清的过程，你在建模型时发现的所有不确定项，就是后续要拉产品经理确认的清单。

3. 手把手教你把需求文本拆成AI可用的需求模型

3.1 从一个最简单的登录需求开始

我用登录模块来演示，因为大家都熟悉，容易跟上思路。假设原始需求是这样的：

用户输入手机号和密码，点击“登录”按钮，系统校验通过后进入首页。手机号需为11位数字，密码长度6-20位。连续输错5次密码，账号锁定30分钟。

这段话信息量不大，但真扔给AI让它生成测试点，它往往会生成二三十条“手机号为空”“密码为空”“手机号格式错误”这种很表面的内容。你现在跟我一起，把这段需求拆成三块模型：

信息结构：

• 手机号：必填，11位数字，以1开头（这里“以1开头”是常识补全，需求没写，但所有国内手机号校验都这么干，我就写进模型里了，写进去AI才能生成“以0开头的11位数字”这种边界用例）
• 密码：必填，字符串，长度6-20位
• 账号状态：正常、锁定（锁定时长30分钟）

操作流程：

1. 用户进入登录页，输入手机号、密码
2. 点击“登录”按钮
3. 系统校验输入格式
4. 系统校验账号密码是否匹配
5. 匹配成功 → 进入首页；匹配失败 → 返回错误提示

业务规则：

• 手机号必须是11位数字，且以1开头
• 密码长度必须在6-20位之间
• 密码连续输错5次，账号锁定30分钟
• 锁定状态下，即使密码正确也不能登录
• 锁定时间到达后自动解锁

3.2 信息结构怎么提炼，四个字：对象、属性

信息结构不是让你把页面上所有字段抄一遍，而是提炼出“系统里真正承载业务的对象”以及它们的“关键属性”。判断标准很简单：这个属性会不会影响业务流程分支？如果不会，就不写。登录例子里的“记住我”勾选框就不会影响登录成功与否，我不会写进去；手机号和密码会影响，必须写。

实际操作中，我习惯用“名词提取法”：通读一遍需求，把所有名词圈出来，再逐个判断“这个词是不是一个独立业务对象”。订单、商品、用户、优惠券，是；系统、页面、按钮，这些技术名词不算。

再强调一次：信息结构里每个属性都要带上约束。约束通常有这些类型——必填性、长度、格式、取值范围、唯一性、时效性。你在建模型时把这些约束显式列出来，AI生成测试点的时候才会围绕约束做边界枚举。

3.3 操作流程怎么拆，关键在“步骤粒度”

粒度太粗，AI不知道在哪一步插入异常；粒度太细，模型又变成一堆啰嗦的“点击、输入、滑动”描述，分散AI的注意力。我的经验是：一个操作流程控制在4-8步，每一步都是一个完整动作。

比如支付流程，我通常拆成：

1. 用户提交订单，进入支付页
2. 用户选择支付方式（余额/银行卡/第三方）
3. 用户点击“确认支付”
4. 系统创建支付单并扣款
5. 系统回调更新订单状态
6. 用户看到支付结果页面

第4步里“扣款失败”怎么处理？那是异常分支，是业务规则要解释的，不要在流程里展开成十几个分支。流程保持主路径清晰，分支交给规则区。

支撑我这么做的直觉是：AI在流程里擅长识别“顺序关系”，而所有对立关系（成功/失败）、条件关系（如果…则…）交给规则区处理，它的枚举能力才能发挥出来。混在一起，AI输出的结构会混乱，你评审的成本反而更高。

3.4 业务规则的设计，每个规则都要能独立成为测试点

业务规则区是整个模型的精华，也是AI生成高价值测试点的核心素材。我写规则时遵循两条标准：

• 一条规则只表达一个约束
• 每个约束都能被翻译成“如果违反会怎样”

以登录需求为例，规则“密码连续输错5次，账号锁定30分钟”，翻译成测试点就是：输入4次错误密码后第5次输入正确密码，能否正常登录；输入5次错误后是否提示锁定；锁定期间尝试登录是否被拒绝；锁定29分钟后尝试登录是否仍被拒绝；锁定满30分钟后是否自动解锁。

这一条规则就能推演出5-6个测试点，而你建模型的时候只是写了一句规则。AI之所以在模型前置后生成质量高，靠的就是这种“规则-场景”的推演能力。

我还建议你在规则区把“尚未定义的规则”也列出来，用“待确认”标记。比如：手机号已注册但未验证，能不能登录？这个需求没写。你把它列进模型的“待确认规则”里，AI会在生成测试点时把这部分作为风险点标出，或者你也可以在提示词里要求它“对未定义的规则输出风险说明”。这等于用AI帮你做了需求查漏。

4. AI生成测试点的提示词模板与运行实例

4.1 提示词结构，五个要素缺一不可

模型建好了，接下来是把它“投喂”给AI。我用的提示词不是一个简单的“帮我生成测试点”，而是一套固定结构，包含五个部分：

• 角色设定：告诉AI它是谁，专业背景是什么
• 任务描述：清晰说明要做什么，输出什么形态的结果
• 输入素材：把需求模型完整贴进来
• 输出格式：规定分类方式、字段结构
• 约束与边界：明确禁止做什么，避免生成废话

把五个要素串起来，我常用的模板长这样：

# 角色 你是一名有10年经验的测试工程师，擅长功能测试设计，熟悉边界值分析、等价类划分、错误推测法。 # 任务 基于以下需求模型，为[功能模块名称]设计测试点。 # 需求模型 【信息结构】 - 用户：手机号（必填，11位数字，以1开头）、密码（必填，字符串，长度6-20位）、账号状态（正常/锁定，锁定时长30分钟） 【操作流程】 1. 用户打开登录页，输入手机号和密码 2. 点击“登录”按钮 3. 系统校验输入格式 4. 系统校验账号密码是否匹配 5. 匹配成功则进入首页，失败则返回错误提示 【业务规则】 - 手机号必须是11位数字且以1开头 - 密码长度必须为6-20位 - 连续输错5次密码，账号锁定30分钟 - 锁定期间即使密码正确也不允许登录 - 锁定30分钟后自动解锁 # 输出要求 1. 将测试点按以下分类输出：功能测试、界面测试、异常场景、边界测试、安全测试、兼容性测试 2. 每个测试点包含：编号、测试点名称、前置条件、操作步骤、预期结果 3. 对需求模型中“待确认”的规则，单独输出一条风险提示 4. 不要输出与需求模型无关的测试点 5. 不要输出类似“验证系统正常运行”这种无实际操作的通用描述

模板的关键在“输出要求”的后两条。很多AI生成的测试点让人想摔键盘，就是因为AI喜欢补各种“合理但不属于当前需求”的场景。你在输出要求里明确“不要输出无关测试点”，效果立竿见影。

4.2 实测：同一个模型，三种提示词效果的直观对比

我拿上面的登录模型跑了三次，三种提示词策略结果差异很大：

• 策略A（直接要求）“生成登录模块测试点”：输出30条，全部集中在功能正常路径和常见错误，类似“验证正确手机号密码可以登录”“验证错误密码提示失败”。没有一条涉及锁定状态或边界格式，通用性极强，可用性很差。
• 策略B（贴模型，但没写约束）：输出42条，覆盖了锁定、边界格式等模型里的规则，但有大约10条是“验证密码包含特殊字符”“验证手机号包含中文”这种需求根本没定义的情况。这些加进来不能说错，但会把用例库撑得很虚。
• 策略C（贴模型+完整约束）：输出36条，功能11条、异常9条、边界8条、安全5条、兼容3条。每条都能从模型里找到依据，没有多余内容。

所以说，提示词的成本不在于“写得长”，而在于“想清楚边界”。约束写到位，你的评审工作量能少一半。

4.3 让AI“先建模再出测试点”，二段式提示词结构

对于稍微复杂的模块，直接给一个完整建模的大提示词，AI有时候会“顾此失彼”——模型没建透就开始出测试点。这时候我把流程拆成两步：

第一步，让AI基于需求文本自己建模：

你是资深测试工程师。请阅读以下需求文本，输出该功能的需求模型，模型需包含信息结构、操作流程、业务规则，并标出需求中未定义但你认为是关键风险的点。 需求文本： [粘贴原始需求]

第二步，把AI生成的模型人工校对后，再作为输入跑一遍测试点生成的提示词。

这个做法多了一次人机交互，但好处是能看到AI的“理解过程”，把模型错误扼杀在源头。我在处理新项目、业务规则密集的模块时都用两步法；熟悉的模块、规则清晰的场景，直接一步到位。

5. AI生成测试点的质量不高？问题往往出在提示词外

5.1 AI容易漏掉“状态冲突”和“时序相关”的测试点

测试设计里有一类场景，靠“规则枚举”推不出来，它需要“组合状态”的想象力：比如订单已支付但回调失败，或者用户已注销但缓存里还有登录态。这类状态冲突测试点，AI经常漏。

原因是：需求模型的规则区是静态的，AI在静态规则基础上做枚举，本来就缺少“动态变化”的维度。你需要主动在建模阶段补一张“状态流转表”，把对象的每个状态以及触发迁移的事件列出来，再让AI基于状态表做测试点生成。

实操建议：建模时增加“状态流转”小节，不要只依赖信息结构。信息结构管“字段”，状态流转管“对象生命周期”，两者组合起来，AI才能覆盖到“从已支付到已取消”这种跨状态的测试点。

5.2 权重分配：AI适合枚举，人工负责判断哪些值得测

AI的另一个问题是“平均用力”。它生成的测试点里，有10分重要的核心流程，也有1分重要的边缘场景。如果你照单全收，测试用例库会变得臃肿、冗余，执行成本直线上升。

我现在的做法是把AI生成的测试点当成“测试点子池”，最后一定要人工做一轮优先级标注：

• P0：核心流程、主路径、涉及资金/安全的关键规则
• P1：主要异常路径、边界值、状态切换
• P2：体验类、兼容类、低频场景

这一步没法完全自动化，至少目前我还没找到可靠的让AI自动判优先级的方法。但AI帮你把池子扩大了，你筛选的空间就大了，这本身已经价值很大——以前你可能因为时间紧只测了P0，有了AI的完整清单，你会发现很多原本没时间想到的P1场景。

5.3 提示词之外的护栏：建立“测试点验收清单”

我在团队里推行一套简单的验收标准，每一条AI生成的测试点都要过这四关才能进用例库：

这套验收清单AI也可以辅助执行，比如让AI“自查”一遍，但最终保留判断权在测试工程师手里。AI是扩展你的视野上限，不是替代你的判断能力。

6. 新一代AI Agent 在测试点生成上的实战玩法

老读者知道我一直在测各种AI Agent工具，而“测试点生成”这个场景恰好特别适合Agent化——固定的角色、固定的输入结构、固定的输出要求，就是一套标准化流程。我把这些模板打包成Agent后，产物已经不再是“提示词文本”，而是一个“测试点生成工作台”。

6.1 把模板固化进Agent：一次配置，长期复用

我现在的做法是把上面的提示词模板嵌入到支持的Agent工具里，像Codex、Claude Projects、自建的Prompt工作流都能干这件事。配置一次之后，后续每次拿到新需求，只需要把“需求文本”替换进去，Agent会自动完成“建模→提示词执行→输出格式化”这一套流程。

这里要提醒一句：Agent环境里跑测试点生成，一个重要差别是“上下文长度”。测试点生成吃的上下文不大，一般几千字完全够，所以不用太担心Agent的窗口限制。但如果你把整个需求文档不加整理直接塞进去，Agent可能在你没注意的地方把上下文费用烧得很高。我建议只投喂整理后的需求模型中相关章节，不要“喂全文档”。

6.2 用AI Agent自动做“测试点去重”和“相似测试点聚类”

AI生成的测试点几乎必然有重复，例如“手机号格式错误提示”可能同时出现在功能、异常、边界、安全四个分类里。人工去重等于重复劳动，这类工作交给Agent处理正合适。

我踩过的坑是用传统的字符串匹配做去重，遇到“输入11位数字但第一位不是1”和“输入12位数字”这种语义相关但文本不同的测试点，它分不出来。Agent的优势在于能结合上下文语义判断“这些测试点是否覆盖同一个规则”，我实测下来，对一个36条的测试点池做去重聚类，Agent能合并掉6~8条重复项，准确率稳定维持在“肉眼复核基本无错”的水平。

具体的Agent提示词模板，可以复用上面的结构，只需在“输出要求”里增加一条：“对相似测试点进行聚类合并，输出合并原因。”这里不再重复贴模板，因为本质上是对已验证模板的组合应用。

6.3 从测试点到测试用例的延伸

测试点生成完之后，下一步自然就是转成可执行的测试用例。我在实际流程里也是用Agent做这个转换：让AI把每个测试点展开为标准用例字段——用例编号、优先级、前置条件、测试数据、步骤、预期结果。转换之后再加一层“从测试点反查需求模型”的追踪矩阵，追踪覆盖率。

这个做法能顺手解决“测试点覆盖了但用例漏了”这种低级问题。追踪矩阵以前手工维护很痛苦，现在Agent生成初稿，人工复核，效率提升明显。更细节的内容，我计划在下一篇笔记里专门讲测试用例自动生成与覆盖率追踪，这里先不展开。

7. 常见问题与排查技巧实录

7.1 AI生成的测试点重复率太高，怎么办

重复率高主要有三个原因：分类边界不清晰、业务规则粒度太粗、AI在多个分类里都试图“覆盖全面”。排查路径：先检查模型的业务规则是不是一条规则包含了多个约束，比如“手机号必须是11位数字且以1开头”其实是两条独立约束，拆开写之后，AI在边界测试和安全测试里的输出自然就不重叠了。

7.2 生成的测试点太“通用”，放到哪个项目都能用

这是“需求模型信息密度不足”的信号。你的模型里只有“手机号、密码、登录”这种通用信息，AI就只能给出通用结果。解决方法是把项目特有的规则写进模型，比如“连续输错5次锁定30分钟”这种项目专属逻辑。模型越具体，输出越有项目特色。我见过有人把需求模型揉成一句话就丢给AI，那和直接丢需求文档没区别，效果自然好不了。

7.3 AI漏掉了产品经理口头说的需求，该怎么防

这是最危险的一类问题：需求文档本身没写，但产品经理在评审时口头补充了一条规则，你忘了更新到模型里，AI当然也不会知道。我的防范办法是：每次评审会结束，立刻把口头补充的需求写进模型的“业务规则”区，标注来源是“评审会议”。

有一段时间我偷懒，周五评审会的内容拖到周一才更新模型，结果周五下午老板让我出一版登录功能的测试点给开发看，AI生成的结果完全没覆盖评审会刚确认的“同一手机号30天内只能注册3次”规则，我拿出去的方案当场被开发怼了。那次之后我养成了“会议结束当天更新模型”的习惯，也建议你在团队里把这个流程固化下来。

7.4 生成结果太长，一个登录功能给了60条测试点

数量多不一定是好事，用例库膨胀会直接增加执行和维护成本。我在提示词里加了一个“测试点数量范围”的约束，比如“控制在25~35条之间，如果超出，按优先级排序并删除最低优先级的内容”。生成稳定之后我再做一轮人工筛选，效果比我逐条删轻松得多。

7.5 常见问题速查表

8. 当前这套流程能解决什么问题，边界在哪里

我现在跑这套“模型→AI→测试点”的流程跑了大半年，稳定应用在Web端和App端的日常迭代里。它的真实价值在于：把测试设计从“经验驱动”慢慢转变成“模型驱动+AI枚举+人工裁决”，对于新功能、需求频繁变更的项目，效果尤其明显——模型一旦建好，需求改一条规则，AI重新生成一次的成本几乎为零。

但也要说清楚它的边界。第一，完全陌生的业务领域，你建模时如果缺乏行业常识，AI生成的点也会跟着跑偏，这时候需要领域专家补位。第二，AI生成的是“测试点”，不是“测试策略”，它不会告诉你“这个模块应该重点做探索性测试”还是“这个功能应该上全量回归”，这种策略判断还得测试负责人来做。第三，依赖AI生成测试点之后，如果团队没有维护模型和用例库的习惯，三个月后模型过时了，AI的输出质量会像断供的煤气灶一样——火越来越小。

所以，我现在的态度很明确：AI在测试设计里扮演的角色是高效率的参谋，而不是替代你的决策。把模型建好，把提示词配好，把验收关把好，剩下的大量重复枚举工作交给AI，你才有时间做真正体现测试价值的事情——理解业务、判断风险、设计策略。

如果你已经在用AI生成测试点，不妨试一下先把需求文档转成“信息结构+操作流程+业务规则”三件套，再投喂给AI。我自己是在跨过这一步之后，才感觉AI生成的东西真正“能打”了。