自定义规则四层设计：让生成式AI产出可落地的测试用例

最近团队在推广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代表体验优化类每个级别附具体的判定标准。断言表述规范明确验证成功不能直接用要写出具体的可验证断言比如断言页面跳转至订单详情页且订单状态显示待支付断言接口返回code0、data.orderNo与请求参数一致。这些其实和你们手工用例的模板规范完全一致只是你要把这些规范转换成AI能识别的语言写进规则里。还有一个容易被忽略的点给AI提供正反示例。规则里光写断言要具体不够最好附上错误写法示例和正确写法示例各一两条。AI对示例的遵循能力远强于抽象描述这是我自己试过很多次以后确认的经验。2.4 第四层覆盖策略让AI按测试设计方法出用例覆盖策略这层规则是把测试方法论转译给AI。等价类、边界值、场景法、判定表、状态迁移法、错误猜测法这些经典的测试设计方法AI都懂但你不主动要求它就不会主动用。我的做法是在规则中显式列出对本模块适用的测试设计方法并给出应用指引。比如登录模块对用户名和密码字段应用等价类划分至少包括有效等价类、无效等价类中的空值、格式非法、长度越界对密码输入框应用边界值分析明确边界为6位和20位必须包含5位、6位、7位、19位、20位、21位的用例对登录失败场景应用错误猜测法考虑账号锁定、验证码错误次数达到上限、会话过期后提交等场景。这里有个实操细节覆盖策略规则如果只写请应用等价类划分方法AI生成的用例依然会趋同于常规路径。你需要把针对哪些字段、在什么边界条件下、必须包含哪些具体的用例也交代清楚。规则写得越接近可执行的状态AI输出的覆盖质量越高。为了便于落地我习惯把四层规则整理成一张速查表如下所示。规则层级解决的核心问题典型规则内容缺失时的后果业务规则让AI理解被测系统的业务本质产品定位、角色、核心流程、业务限制、历史缺陷区域用例跑偏覆盖不了真实业务风险技术约束让AI贴合当前技术栈和工具链测试形态、工具框架、接口风格、测试边界与Mock范围生成结果与现有流程脱节只能看不能用表达规范让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结合能发挥出11远大于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界面层面的模板是断言页面元素预期状态例如断言页面跳转至订单详情页订单状态元素显示待支付接口层面的模板是断言接口返回字段预期值例如断言code0、data.orderNo等于请求参数中的orderNo数据库层面的模板是断言数据表字段预期值例如断言订单表的order_status字段等于1。把不同层面的断言模板写进规则同时附上两个正确示例和一个错误示例AI输出的断言质量会有质的提升。最后整理一份问题速查表方便你在实际使用中快速定位现象根因解决策略规则写了但效果不明显规则表达过于抽象、方法论化把规则转成可执行指令逐条拆分具体场景和必测点输出格式不稳定格式约束不足缺少示例锚定提供完整输出样例附加必须与样例一致指令增加后处理校验总是生成主路径用例覆盖策略停留在方法名层面不够具体显式列出边界值、异常场景、必测分支要求逐条生成断言过于模糊断言规范缺位AI无从参照分别提供UI、接口、数据层的断言模板和正反示例生成的自动化脚本选择器失效规则中缺少选择器规范明确要求优先使用data-testid、getByRole等稳定选择器用例字段与现有Excel模板对不上没有对齐存量模板的列结构和枚举值将模板头和真实历史用例作为示例注入规则我和生成式AI配合写测试用例这大半年最大的体会是AI的能力边界在快速扩展但你的项目需要什么这件事没有任何模型能替你思考。自定义规则不是一个写一次就一劳永逸的东西它和你们的项目一样需要不断迭代维护。每发现一个AI生成结果的弱点就是一条新的规则素材每沉淀一条规则团队离AI辅助测试工业化就近了一步。踩过几次坑之后我的建议是从一个不大的模块开始跑通全流程把规则库先搭起来再逐步覆盖更多业务这条路走得最稳。最后再分享一个我自己常用的技巧每次让AI生成用例之后先不着急直接用把生成结果的缺陷记录一下反向补进你的规则配置文件里。坚持一两个月你会明显感觉到AI输出的用例越来越懂你们的业务到那个阶段AI才真正从一个对话框变成了你们测试团队靠谱的成员。