企业官网建设流程全解析

最近团队在推广AI辅助测试，我发现一个很有意思的现象：同样是用生成式AI写测试用例，有人能十分钟产出一份可以直接评审的用例清单，有人折腾一下午拿到的还是一堆"输入合法数据，验证登录成功"这种正确的废话。差别不在工具，也不在模型，在于有没有一套真正能落地的自定义规则。

我自己的实践体会是，生成式AI写测试用例这件事，难点从来不是"让AI开口"，而是"让AI按你的规矩开口"。规则定得好，AI生成的内容才有项目针对性，才能谈得上质量和复用；规则缺失或者定得抽象、拍脑袋，AI产出的东西就永远是那种"对任何项目都适用，但对你当前项目毫无用处"的平均水平用例。

这篇文章我从规则设计的核心维度、落地实操场景、问题排查三个层面展开，结合我自己在Web应用、接口测试、Playwright自动化脚本生成这些实战场景里的经验，讲透"自定义规则"到底应该怎么设计、怎么写、怎么用。尤其适合正在尝试用AI辅助功能测试用例设计、想把AI生成结果接入实际测试流程的测试工程师和测试负责人。

1. 为什么"裸奔"的AI测试用例没法用

1.1 看似全面，实则无用的AI生成结果

先还原一个典型场景。你打开某个生成式AI工具，输入"帮我生成登录功能的测试用例"，它大概率会给你输出类似这样的内容：

用例编号 TC001，输入正确的用户名和密码，点击登录，验证登录成功；TC002，输入错误的用户名，验证提示登录失败；TC003，密码为空，验证提示密码不能为空。

单看每一条，没毛病。但拿到你的项目里一比对，问题立刻暴露了：它不知道你的登录入口是扫码加密码混合验证，不知道你的系统有账号锁定策略，不知道你的用户体系分C端和B端两套，更不知道你的业务流程里登录后还要做二次身份核验。这些恰恰是登录功能最核心、最容易出问题的测试点，AI一条都没生成。

这就是裸奔式生成的问题。AI没有你的项目上下文，产出的只能是它在训练数据里见过无数次的通用路径，而这些通用路径往往覆盖不到任何项目的真实风险点。用这种用例去做测试，表面上覆盖率好看，实际价值极低。

1.2 不做自定义规则的三个代价

我在多个团队里观察过直接裸用AI生成测试用例的情况，代价基本集中在三方面。

覆盖不完整。没有业务规则约束时，AI默认走"最顺滑的快乐路径"——合法输入、成功预期、正常流程。等价类里的无效等价类、边界上的临界值、异常分支、权限冲突、数据异常、网络异常中断这些东西，AI不会主动想到，除非你在规则里明确要求。业务分支覆盖不足，恰恰是测试用例最致命的缺陷。

表达不一致。这个问题的隐蔽性很高。AI生成的用例经常第一版是"验证登录成功"，第二版变成"断言页面跳转至首页"，第三版又写成"检查用户信息展示正常"。同一个断言点，三种写法，粒度忽粗忽细。如果人工编写，团队有模板和规范管着，还能保持一致；AI生成时没有表达规则约束，就会怎么顺口怎么写，用例落到文档里，评审、排重、执行都难以为继。

技术与工具脱节。团队用Playwright做Web自动化、用Postman做接口测试、用Excel模板管理存量用例，但AI生成的结果一概不管这些。生成出来的用例，要么没法直接转成自动化脚本，要么字段对不上Excel模板的列，要么生成的是纯UI操作步骤、完全没法沉淀到接口测试库里。没有技术约束和技术栈相关的规则，AI产出的用例就只能停留在"看起来能评审"的层面，离"真正能落地"还有很长距离。

1.3 自定义规则的本质：把"项目知识"喂给AI

想明白原因，解法就清晰了：自定义规则的本质，就是把你脑子里的项目知识，结构化地喂给AI。它不是简单地在提示词里加一句"请严格按照规范输出"，而是需要一个完整的规则体系，把业务逻辑、技术特点、写作规范、覆盖策略这些隐性知识显性化，变成AI可以理解和执行的指令。

打个比方。你带一个刚入职的测试新人，不会只丢给他一句"去测一下登录功能"就完事。你会告诉他：这个系统有哪些角色、核心业务链路是什么、哪些历史缺陷需要重点关注、用例要写到什么粒度、用什么模板。这些交代，其实就是规则。生成式AI也是一样，你有多认真地向它交代项目背景，它产出的结果就有多贴合你的项目。规则不是限制AI的枷锁，而是让AI从"什么都会一点的通用实习生"变成"懂你这个项目的专职测试员"的关键一步。

2. 自定义规则的核心维度：从"可用"到"好用"

2.1 第一层：业务规则，让AI理解"这个系统是干什么的"

业务规则是规则体系的地基。很多人在设计规则时一上来就写"用例要覆盖边界值"这类方法论，却忘了先交代这个系统本身是做什么的。AI不知道你的系统是电商、是OA、是支付平台，它就没法判断"核心业务链路"应该是什么，生成的用例自然容易跑偏。

我在实际设计中，至少会给AI交代四个层面的业务信息。第一是产品定位和用户角色——这个系统给谁用，有哪些角色，每个角色的核心诉求是什么。第二是核心业务流程——从用户进入系统到完成核心价值交付，中间会经历哪些关键步骤，哪些流程断了会直接影响业务。第三是业务规则和限制条件——比如订单金额不能为负、库存扣减不能超卖、优惠券不能叠加使用这些硬约束。第四是历史风险点和缺陷高发区——你踩过的坑、线上出过的事故，也作为一种业务规则注入，让AI生成用例时重点关注这些区域。

举个例子，不是简单地写"系统是电商平台"，而是拆成："这是一个B2C电商系统的移动端下单流程，用户角色包括匿名访客、已登录普通用户、企业认证用户，核心流程是商品搜索→商品详情→加入购物车→提交订单→支付→订单状态查询。库存扣减必须与支付成功强一致，优惠券仅限普通用户使用且不可与满减活动叠加。历史上曾在支付回调超时场景下出现重复下单问题，需要重点覆盖。"这么一段注入进去，AI生成的用例质量立刻就不一样了。

2.2 第二层：技术约束，让AI输出贴合当前技术栈的内容

技术约束解决的是"你生成的东西在我们这边能不能用"的问题。没有这一层约束，AI默认生成的测试用例描述往往偏向纯GUI操作，这对任何技术栈来说都不够用。

技术约束至少包含三方面。第一是测试对象的技术形态：是Web前端、移动端App、后端接口，还是小程序、桌面客户端。不同形态对应的用例描述方式和关注点差异巨大，比如Web要关注浏览器兼容性，App要关注系统权限和弱网，接口测试要关注参数校验和响应结构。第二是当前使用的测试工具和框架：团队用Playwright还是Selenium，接口测试用Postman还是JMeter，接口定义是REST风格还是RPC，这些直接影响AI生成内容的对接方式。第三是测试边界和不需要测的内容：比如第三方登录已被上游单测覆盖可以跳过、短信验证码通道因为是外部依赖需要在测试中通过Mock处理。把这些写进规则，AI就不会花大量篇幅去生成那些根本不在你测试范围内的用例。

技术约束写得越具体，AI生成的内容就越能直接进入现有流程。我见过做得好的团队，直接把技术约束做成了类似这样的规则条目："本模块为REST风格API，所有用例必须包含method、path、query参数、请求体、期望响应码、期望响应体关键字段；自动化脚本使用Playwright TypeScript版本，禁止使用CSS class中的动态hash值作为选择器。"

2.3 第三层：表达规范，让AI输出的格式可以直接用

表达规范是容易被忽略但实际收益最大的一层规则。它解决的是"AI生成的内容能不能顺利进入你的用例管理流程"的问题，本质上是对AI输出的格式化控制。

我的习惯是至少规定以下几个维度。用例模板：每个用例包含哪些字段，字段顺序怎么排列，各个字段的填写要求是什么。比如用例编号规则用模块缩写加序号，前置条件要写清楚环境、数据、状态，操作步骤要用序号分隔的动作链。优先级定义：P0代表核心链路冒烟级必须覆盖，P1代表主要功能需要通过，P2代表辅助功能与异常场景，P3代表体验优化类，每个级别附具体的判定标准。断言表述规范：明确"验证成功"不能直接用，要写出具体的可验证断言，比如"断言页面跳转至订单详情页，且订单状态显示待支付""断言接口返回code=0、data.orderNo与请求参数一致"。这些其实和你们手工用例的模板规范完全一致，只是你要把这些规范转换成AI能识别的语言写进规则里。

还有一个容易被忽略的点：给AI提供正反示例。规则里光写"断言要具体"不够，最好附上"错误写法示例"和"正确写法示例"各一两条。AI对示例的遵循能力远强于抽象描述，这是我自己试过很多次以后确认的经验。

2.4 第四层：覆盖策略，让AI按测试设计方法出用例

覆盖策略这层规则，是把测试方法论转译给AI。等价类、边界值、场景法、判定表、状态迁移法、错误猜测法这些经典的测试设计方法，AI都懂，但你不主动要求，它就不会主动用。

我的做法是在规则中显式列出对本模块适用的测试设计方法，并给出应用指引。比如登录模块：对用户名和密码字段应用等价类划分，至少包括有效等价类、无效等价类中的空值、格式非法、长度越界；对密码输入框应用边界值分析，明确边界为6位和20位，必须包含5位、6位、7位、19位、20位、21位的用例；对登录失败场景应用错误猜测法，考虑账号锁定、验证码错误次数达到上限、会话过期后提交等场景。

这里有个实操细节：覆盖策略规则如果只写"请应用等价类划分方法"，AI生成的用例依然会趋同于常规路径。你需要把"针对哪些字段、在什么边界条件下、必须包含哪些具体的用例"也交代清楚。规则写得越接近可执行的状态，AI输出的覆盖质量越高。

为了便于落地，我习惯把四层规则整理成一张速查表，如下所示。

3. 规则落地实操：把规则真正用起来

3.1 场景一：用提示词模板约束生成式AI输出

对多数团队来说，最简单直接的落地方式是设计一套结构化的提示词模板，把规则注入进去。我不建议把规则写成一大段文字直接丢给AI，那样信息密度太高，AI很容易"抓重点"丢弃细节。更好的方式是分段注入、明确标识，让AI清楚知道每段信息的意义。

下面是我在一个电商后台订单模块项目里实际用过的登录模块提示词模板，你可以直接改改就用：

# 角色 你是一名资深测试工程师，负责编写功能测试用例。你的用例需要符合本项目的测试规范，确保可评审、可执行、可追踪。 # 背景 被测系统是B2C电商后台管理系统。本模块为用户登录模块，支持账号密码登录和手机短信验证码登录两种方式。已有用户体系分为普通管理员和超级管理员，普通管理员登录后只能查看订单数据，超级管理员拥有全部配置权限。账号安全策略：连续输错5次密码会锁定账号30分钟。 # 测试设计规则 1. 对本模块应用等价类划分和边界值分析，用户名长度为6到20位，密码长度为8到16位。 2. 必须包含以下异常场景：账号锁定、验证码过期、密码明文传输校验、登录后会话失效、不同角色权限差异。 3. 用例优先级定义：P0为登录主流程和账号锁定，P1为密码边界值和角色权限，P2为其余异常与体验优化。 # 输出格式 每个用例使用以下格式： 【用例编号】LOGIN_001 【所属模块】登录 【优先级】P0 【前置条件】xxx 【操作步骤】1.xxx 2.xxx 【预期结果】给出具体可验证的断言，不得写"验证成功"等模糊表述 【测试数据】明确每条用例使用的具体数据 # 禁止事项 - 禁止生成与登录无关的功能用例 - 禁止使用"输入正确/错误数据"这类模糊描述，必须给出具体数据 - 禁止出现"断言成功"这类无具体指向的期望结果

实测下来，这个模板最大的价值在于两点：一是用明确标识把上下文和规则分层，AI能准确区分"背景信息"和"必须遵守的规则"；二是输出格式约束和禁止事项用简洁的指令形式写出，AI遵循的稳定性远高于笼统的"请注意格式规范"。我在多个模块上跑过这类模板，格式符合率基本能做到接近百分之百，业务覆盖率也比裸奔生成高出一大截。

3.2 场景二：结构化配置驱动，建立更稳定的工程化方案

提示词模板虽然好用，但在团队多人协作和跨模块复用的场景下有天生的短板：规则散落在不同的prompt里，改一处要同步多处，不同人写的模板风格还各不相同，规则没法做版本管理和复用沉淀。

我的解决方案是把规则外部化为结构化配置文件。以YAML为例，把业务规则、技术约束、表达规范、覆盖策略数据化，然后在调用AI时把配置文件内容注入到prompt上下文中。这样做的好处有三个：规则与提示词分离，更新规则不需要改动调用逻辑；规则可以做版本管理，每次改动都有历史记录；规则可以按模块拆分，新增模块时只需复用基础规则加增量规则。

一个简化版的规则配置文件大致长这样：

module: name: order_module description: 订单创建模块，B2C电商后台，支持普通商品订单和预售商品订单 business_rules: core_flow: 选择商品->确认订单->提交订单->支付->订单完成 restrictions: - 预售商品不可与普通商品合并下单 - 优惠券仅限普通商品使用，预售商品不参与满减 historical_risks: - 库存超卖场景下未有效拦截 - 支付回调延迟导致订单状态不一致 technical_constraints: api_style: rest http_method: POST path: /api/order/create expected_response_fields: [code, msg, data.orderNo] automation_framework: playwright-typescript skip_scope: - 发票开具流程已由财务系统独立测试，不在本次范围 expression_standards: case_id_prefix: ORD_ priority_definition: P0: 核心下单链路、金额计算、库存扣减 P1: 优惠券使用、订单状态流转 P2: 边界数据、异常输入、兼容性 assertion_format: 必须包含接口返回码、关键业务字段、页面状态的组合断言 coverage_strategy: design_methods: [等价类划分, 边界值分析, 场景法, 错误猜测法] required_scenarios: - 库存边界：库存为0时下单、库存为1时的并发下单 - 金额边界：订单金额为0、为负、超过单笔限额 - 状态冲突：已取消订单重复支付、已支付订单重复提交

实际执行的时候，把这些配置转化为一段上下文指令注入AI即可。这个方向在工程化协作层面价值很大，尤其适合测试团队想长期用AI辅助用例设计、建立规则资产的情况。我自己在跑项目时，会把配置文件放在单独的知识库目录里，每次生成前读取对应模块的配置拼装成上下文。这样"AI生成用例"这件事从一次性的自然语言对话，变成了可以反复执行、可控可复用的测试资产生产过程。

3.3 场景三：结合Playwright生成自动化测试用例

生成功能测试用例只是第一步，真正的效率提升在于让AI生成的内容可以直接驱动自动化测试。Playwright作为当前Web自动化测试的主流方案，和生成式AI结合能发挥出1+1远大于2的效果。核心思路是：在自定义规则中加入针对Playwright脚本生成的专项约束，让AI在输出功能用例的同时，直接生成可运行的自动化脚本。

为这个场景设计规则时，我会额外注意几个关键点。

选择器规范。规则中必须明确"提供稳定的选择器"这一要求。Playwright对元素定位的稳定性要求很高，我在规则里写明：优先使用data-testid、getByRole或getByLabel，禁止在脚本中直接使用动态hash类名、禁止依赖层级嵌套过深的CSS选择器。这个规则直接决定了生成的脚本在哪些情况下能稳定运行。

断言规范。自动化脚本中的断言和功能用例中的预期结果要一一对应。我会要求断言必须同时覆盖UI状态和接口返回值，比如UI上断言订单列表出现"待支付"标签，接口上断言response的data.orderNo与接口入参一致。双断言的做法在自动化用例里价值极高，能发现很多单纯看界面发现不了的数据不一致问题。

用例隔离与清理规则。AI生成的自动化脚本如果不管数据隔离，很容易在测试环境里留下脏数据。我的规则里会要求：每个用例必须自动创建独立的测试数据、用完必须走清理接口恢复环境。这些约束如果在功能用例阶段就设计好，后期让AI转成脚本时会顺利很多。

给一段简化版的规则示例：

# Playwright脚本生成规则 1. 技术栈：TypeScript + Playwright @latest 2. 选择器优先级：data-testid > getByRole > getByLabel，禁止使用CSS class中的hash值 3. 每个用例对应一个独立test()块，块内不得存在外部依赖变量 4. 断言必须包含HTTP响应断言和UI状态断言两部分，HTTP断言使用page.waitForResponse实现 5. 测试数据必须通过API前置创建，用例结束后必须清理创建的数据 6. 所有步骤必须显式添加可读性注释，注释内容对应原始功能用例编号

这样跑下来，AI生成的不再只是一堆文档，而是可以直接纳入CI执行的自动化脚本。我在一个订单流程模块上试过，AI生成的脚本经过少量修复就能运行，核心用例的脚本生成成本大概降低了百分之六七十。不过也提醒一下，AI生成的脚本不可能完全不需要人工介入，选择器失效和断言不精确是常见问题，你要把规则和人工审查结合起来用，不能完全放任直接进流水线。

3.4 场景四：对接Excel测试用例模板，兼容存量流程

很多团队虽然嘴上说"我们正在向平台化、自动化转型"，实际上存量用例还是Excel管理、平台导入。这种情况下如果AI生成的用例完全无视Excel模板规范，那落地阻力会非常大。不能指望团队一夜之间抛弃存量流程，更务实的做法是让AI生成的用例直接对齐你现有的Excel模板。

为这个场景设计规则，核心是对齐三个层面。列结构对齐：你们Excel模板有哪几列就要求AI按同样的顺序、同样的字段名填充，比如项目编号、模块、用例编号、用例标题、前置条件、操作步骤、预期结果、优先级、用例类型、关联需求ID。数据格式对齐：操作步骤里的多步动作用什么分隔符，前置条件是单行还是多行，预期结果里能不能包含分步骤断言，这些细到格式层面的规则都必须写清楚。枚举值对齐：优先级的取值是你模板里的高/中/低还是P0/P1/P2，用例类型是功能/接口/界面还是手工/自动化，都必须和现有模板保持一致。

有一个技巧值得分享：直接把你们团队的Excel模板头（字段名那一行）和一行真实的历史用例样张作为示例，粘贴进规则里，然后告诉AI"严格按照样张的格式输出"。AI跟随示例的能力远超跟随文字描述，给样张比写十行字段说明文档都管用。我在帮一个团队做接口测试用例Excel模板对接时，就是靠"模板头加一行真实历史数据"这个做法，把AI生成的用例从需要大量返工变成了基本可直接粘贴进表格。考虑到存量用例的迁移成本，这个兼容策略你们大概率也用得上。

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

4.1 规则写了一大堆，AI还是"听不懂"

这是最常见也最让人沮丧的问题。辛苦写了长篇规则，结果AI生成的用例还是我行我素。我的排查经验是先看问题出在哪一层：是AI理解不了业务背景，还是执行不了你给的覆盖策略，还是格式要求没有被遵循。

大部分情况出在规则表达太抽象。比如"请编写质量高的用例"这种话，AI无法理解"质量高"在你的语境里意味着什么。更有效的写法是具体可执行的指令，把"质量高"拆解为"必须覆盖三个异常分支、每条用例的预期结果必须给出具体的页面跳转和接口返回码断言、不得出现模棱两可的描述"。另外我也遇到过规则写入量过大导致AI在长上下文中丢失细节的情况，解决方案是把规则优先级分层，把"禁止事项"和"必须事项"放在所有上下文信息的最后，因为模型对越靠后的指令遵循度通常越高。

4.2 生成了规则，但输出格式反复横跳

有规则不假，但AI在格式上的不稳定性是个长期顽疾。今天用表格输出，明天给你冒号分隔，后天变成bullet list。我的解决思路是把格式约束做成一个强制的后处理校验环节，而不是单纯依赖AI的自觉。

偏好在规则层面做的是"示例锚定"。在提示词或者配置文件中附上一个完整的、符合要求的输出样例，然后明确说"输出格式必须与上述样例完全一致"。这与给AI看Excel样张是同一个原理。如果AI还是偶尔跑偏，我就在生成后的校验环节加一段格式校验逻辑，用脚本检查输出字段是否完整、枚举值是否合规，不合规就重新生成一次或者自动做格式修复。实测后处理校验能在很大程度上兜住格式问题，让自动化流程稳定跑起来。

4.3 覆盖策略形同虚设，AI总写"主路径用例"

规则里明确写了"请覆盖边界值"，AI还是只生成"输入正确账号密码登录成功"这种主路径用例，这是最让人头疼的场景之一。

我的经验是，覆盖策略不能停留在"方法名"层面，必须落到"具体的点"。你光说"覆盖边界值"，AI的脑子里没有一个明确的"6位、20位"的目标，它自然还是按最熟悉的路径输出。正确做法是把具体的边界值、异常场景、业务分支一个一个列出来，用指令的方式让AI逐条生成用例。比如："你必须为以下场景各生成至少一条用例：用户名为5位、6位、7位、20位、21位；密码空值提交；连续输错5次密码触发锁定；登录成功后修改角色权限再访问原页面。"这种写法AI执行的成功率高得多，因为你把"该测哪些点"直接定义清楚了，AI只需要在这个清单的基础上做组织和补全即可。

4.4 断言太弱，AI只会写"验证成功/失败"

如果你们团队要求用例断言可验证、可执行，AI习惯写的"验证成功""系统提示正确"这类断言可以说是零价值。这个问题单靠提示一句"断言要具体"解决不了，需要把断言模板直接做进规则。

我的做法是给出一套断言模板让AI套用。Web界面层面的模板是"断言+页面元素+预期状态，例如断言页面跳转至订单详情页，订单状态元素显示待支付"；接口层面的模板是"断言+接口返回字段+预期值，例如断言code=0、data.orderNo等于请求参数中的orderNo"；数据库层面的模板是"断言+数据表字段+预期值，例如断言订单表的order_status字段等于1"。把不同层面的断言模板写进规则，同时附上两个正确示例和一个错误示例，AI输出的断言质量会有质的提升。

最后整理一份问题速查表，方便你在实际使用中快速定位：

我和生成式AI配合写测试用例这大半年，最大的体会是：AI的能力边界在快速扩展，但"你的项目需要什么"这件事，没有任何模型能替你思考。自定义规则不是一个写一次就一劳永逸的东西，它和你们的项目一样，需要不断迭代维护。每发现一个AI生成结果的弱点，就是一条新的规则素材；每沉淀一条规则，团队离"AI辅助测试工业化"就近了一步。踩过几次坑之后我的建议是从一个不大的模块开始跑通全流程，把规则库先搭起来，再逐步覆盖更多业务，这条路走得最稳。

最后再分享一个我自己常用的技巧：每次让AI生成用例之后先不着急直接用，把生成结果的缺陷记录一下，反向补进你的规则配置文件里。坚持一两个月，你会明显感觉到AI输出的用例越来越"懂"你们的业务，到那个阶段，AI才真正从一个对话框变成了你们测试团队靠谱的成员。