下面直接给你一套可落地的版本，从软件测试工程师的视角出发，力求做到拿来就能用。
我将内容分为三个部分：
- AI 用例质检 Prompt 模板（CRM系统版）
- 接口测试参数生成 Prompt 模板
- Playwright + pytest + Allure 的 AI 辅助落地流程图（文本版）
1）适合测试工程师的 AI 用例质检 Prompt 模板（CRM系统版）
核心思路：把 AI 当成“用例质检员”，而不是让它从零开始写整套用例。你先提供“用例骨架 / 需求规则 / 接口字段”，让它来查漏补缺、补充边界场景和风险点。
1.1 使用场景（你可以直接套用）
适用于 CRM 系统常见模块：
- 客户管理（新增/编辑/导入/查询）
- 线索分配
- 商机状态流转
- 合同审批
- 回款登记
- 权限控制（角色/数据范围）
- 列表筛选/导出
- 接口与页面联动一致性
1.2 Prompt 模板（通用版，可直接复制）
你现在扮演“资深软件测试工程师（企业级CRM系统方向）”，你的任务不是重写测试用例，而是对我提供的“用例骨架”做质量检查（质检），找出遗漏、模糊、不完整和高风险场景，并给出补充建议。
【你的工作目标】
1. 识别需求规则是否被完整覆盖
2. 识别测试用例中缺失的场景（尤其是边界/异常/权限/状态流转/数据一致性）
3. 识别用例描述不清、不可执行、不可验证的问题
4. 给出补充后的建议清单，并按优先级（P0/P1/P2）分类
5. 输出必须贴合CRM业务，不要泛泛而谈
【输出原则（非常重要）】
- 不要生成空泛描述（例如“验证功能正常”）
- 每条建议都必须包含：测试点、前置条件（如需要）、操作、预期结果
- 预期结果必须可验证（页面提示、字段值、状态变化、接口返回、数据库/日志校验点）
- 对于权限、状态流转、并发、重复提交、数据一致性必须重点检查
- 如果需求本身存在歧义，单独输出“需求澄清问题列表”
- 如果我提供的用例已经覆盖某点，不要重复建议
【输出格式（固定）】
请严格按以下结构输出：
一、覆盖性评估总结
- 已覆盖较好的部分：
- 明显遗漏的部分：
- 高风险缺口（优先补测）：
二、用例质量问题（对原用例骨架的质检）
按表格输出，字段如下：
- 原用例编号
- 问题类型（描述模糊/步骤缺失/断言缺失/前置条件缺失/优先级不合理/不可执行）
- 问题说明
- 修改建议（具体到可执行层面）
三、缺口补充清单（新增建议）
按 P0 / P1 / P2 分组输出，每条包含：
- 测试点名称
- 风险说明（为什么要测）
- 前置条件
- 测试步骤
- 预期结果
- 建议验证层（UI / 接口 / 数据库 / 日志）
四、需求澄清问题列表（如有）
- 用于评审会上反问产品/开发的问题，按影响程度排序
五、回归建议范围
- 本次改动影响的关联模块/功能点
- 建议补回归项（最小回归集）
【业务背景（可选但建议提供）】
- 系统类型：CRM系统
- 模块名称：{填写模块名}
- 角色类型：{如 销售、销售主管、运营、管理员}
- 数据权限模型：{如 仅本人/本部门/全部}
- 状态流转规则：{如 线索->商机->合同->回款}
- 环境说明：{测试环境/预发环境}
【需求说明】
{粘贴需求内容}
【业务规则】
{粘贴明确规则，如字段必填、唯一性、状态限制、权限限制、审批规则等}
【接口信息（如有）】
{接口路径、请求字段、响应字段、错误码、幂等规则等}
【现有测试用例骨架（待质检）】
{粘贴你现有的用例骨架}
请开始进行“质检式输出”，不要重写成一整套全新用例，重点是查漏补缺和指出质量问题。
1.3 CRM系统版（更具体，适合直接使用）
下面这版更贴近你常见的项目（客户/商机/合同/权限）。
你是资深测试工程师，长期负责CRM系统（客户、线索、商机、合同、回款、权限）测试。现在请你作为“用例质检员”，检查我给出的测试用例骨架是否存在缺口。
【重点质检维度（CRM系统必须覆盖）】
1. 字段规则
- 必填/非必填
- 长度边界
- 格式校验（手机号、邮箱、金额、日期）
- 特殊字符/空格/前后空格
- 枚举值合法性
- 唯一性（客户编码、合同编号等）
2. 业务规则
- 状态流转前置条件是否满足
- 不同状态下可操作按钮是否正确
- 是否允许回退、撤回、重复提交
- 是否有跨模块联动（例如合同通过后回款模块可见）
3. 权限与数据范围
- 不同角色看到的数据范围是否正确（本人/本部门/全部）
- 无权限用户是否可通过URL/接口越权访问
- 按钮可见 ≠ 接口可调用，需分别校验
4. 一致性与联动
- UI展示与接口返回一致
- 列表页与详情页一致
- 提交后列表状态、详情状态、操作日志一致
- 导出数据与页面筛选条件一致
5. 异常与稳定性
- 重复提交
- 并发操作（A审批同时B撤回）
- 网络抖动/超时后的重试影响
- 接口失败时前端提示是否明确
- 部分成功/部分失败场景是否有明确反馈
6. 可测试性与可维护性
- 用例是否可执行
- 预期结果是否可验证
- 是否缺少前置条件/测试数据要求
- 是否缺少清理步骤或恢复步骤
【输出要求】
- 先给“覆盖性评估”
- 再给“原用例质检问题”
- 再给“缺口补充清单（P0/P1/P2）”
- 最后给“评审澄清问题”和“最小回归集建议”
- 输出内容务必具体，不要写泛泛测试建议
【需求说明】
{这里贴需求}
【业务规则】
{这里贴规则}
【接口定义/错误码（可选）】
{这里贴接口文档信息}
【原用例骨架】
{这里贴用例骨架}
1.4 实际使用建议（很关键）
为了让 AI 输出稳定，建议你每次都固定这 4 个输入块（不要省略）：
如果只给需求而不给明确的规则，AI 很容易“脑补业务逻辑”，导致输出结果看起来合理，但实际上无法直接执行。
2）接口测试参数生成 Prompt 模板
核心目标：让 AI 帮你生成参数组合 + 异常输入 + 断言建议，而不是让它盲目编写接口测试代码。
2.1 使用场景
适合以下情况：
- Swagger/OpenAPI 已有接口定义
- 字段规则较多（必填、枚举、范围、格式）
- 负向场景多
- 想快速形成 pytest 参数化数据集
2.2 Prompt 模板（通用接口参数生成）
你现在扮演“资深接口测试工程师”，请根据我提供的接口定义，为该接口生成一份可用于接口测试的“参数测试集设计方案”。
【任务目标】
1. 提取字段约束（必填、类型、长度、格式、枚举、范围、默认值）
2. 生成正向参数样例（最小必要集）
3. 生成负向参数样例（高价值异常场景）
4. 生成边界值参数样例
5. 给出每类样例对应的断言建议（HTTP状态码、业务码、错误信息、响应字段）
6. 标记优先级（P0/P1/P2）
7. 如存在幂等、鉴权、权限、签名、时间戳等特殊规则，单独列出专项测试建议
【输出要求】
- 不要直接输出某语言代码（除非我明确要求）
- 输出要结构化，便于我转成 pytest 参数化数据
- 每条参数样例必须说明“测试意图”
- 区分“字段级校验”和“业务级校验”
- 对于可能引起环境污染的数据，请标记“需清理”或“建议使用唯一标识”
【输出格式（固定）】
一、接口测试分析摘要
- 接口名称：
- 测试重点：
- 高风险字段：
- 特殊机制（鉴权/签名/幂等/限流/分页/排序）：
二、字段约束提取表
字段：
- 字段名
- 类型
- 是否必填
- 规则（长度/范围/格式/枚举）
- 示例值
- 风险点
三、正向测试参数集（最小必要集）
每条包含：
- 用例ID
- 测试意图
- 请求参数（JSON）
- 前置条件（如有）
- 预期结果（HTTP状态码、业务码、关键字段断言）
- 优先级
四、负向/异常测试参数集（高价值优先）
按类别分组输出：
A. 缺失必填
B. 类型错误
C. 格式错误
D. 长度/范围越界
E. 枚举非法值
F. 业务规则冲突
G. 重复提交/幂等冲突
H. 权限/鉴权异常
I. 特殊字符/注入风险（如适用）
每条包含：
- 用例ID
- 测试意图
- 请求参数（JSON）
- 预期错误（HTTP状态码/业务码/提示）
- 优先级
五、边界值测试集
- 最小值/最大值
- 刚好合法边界
- 刚好越界
- 空字符串/null/空数组（按字段类型区分）
- 超长文本/特殊字符
六、断言建议清单
- 通用断言
- 字段级断言
- 业务级断言
- 数据一致性断言（如需校验DB/消息队列/下游系统）
- 错误响应断言规范（错误码、错误信息字段、traceId等）
七、回归建议（接口改动后）
- 关联接口
- 关联页面功能
- 关键回归路径
【接口定义】
{粘贴接口文档，建议包含路径、方法、请求头、请求体、响应体、错误码}
【业务规则补充】
{粘贴规则，如唯一性、状态限制、权限、审批条件、幂等规则、数据范围}
【已有测试约束（可选）】
- 环境限制：
- 测试账号权限：
- 是否可查库：
- 是否允许造脏数据：
- 唯一标识前缀规则：
2.3 如果你要转 pytest 参数化，再加这一段（增强版）
你可以在上面模板后面追加：
补充要求：
请在输出最后增加“pytest 参数化建议结构”，格式为：
- case_id
- title
- priority
- request_data
- expected_http
- expected_code
- expected_msg_keyword
- assert_path（需要断言的响应路径列表）
- pre_action（如需要）
- post_cleanup（如需要）
仅输出字段设计示例，不要写具体pytest代码。
这样 AI 会给你一份比较容易转成 @pytest.mark.parametrize 的结构化数据。
2.4 接口参数生成时常见坑（你要提前限制）
建议在 Prompt 里加一句，防止 AI 输出基于假设的“假规则”：
如果接口文档未明确某字段规则（例如长度、枚举、是否允许null），请明确标记“文档未说明，需确认”，不要自行假设。
这句非常有用，可以有效避免 AI 自行脑补出一堆看起来合理但未经确认的规则。
3）Playwright + pytest + Allure 的 AI 辅助落地流程图（文本版）
目标：你现在不是要用“AI替代自动化工程师”，而是建立一个可控的 AI 辅助流水线。重点是：AI 参与生成与分析，人负责规则制定、审核与最终准入。
3.1 总览流程图（文本版）
[需求/缺陷/变更输入]
|
v
[测试分析阶段]
- 人工提取业务规则
- AI做用例质检/补边界/补风险
|
v
[测试设计产出]
- 用例清单（P0/P1/P2）
- 接口参数测试集
- UI回归范围清单
|
v
[自动化候选筛选]
- 选择高频回归 + 稳定场景
- 排除一次性/强依赖人工判断场景
|
v
[AI辅助脚本生成（初稿）]
- 生成Playwright页面操作骨架
- 生成pytest测试函数骨架
- 生成参数化数据模板
- 生成Allure步骤描述
|
v
[人工审核与重构]
- 校验业务断言
- 校验定位策略（locator）
- 增加前后置处理
- 增加数据隔离/清理
- 抽取Page Object / Fixtures
|
v
[本地调试运行]
- 单条用例跑通
- 截图/trace/video验证
- 修复不稳定等待/选择器问题
|
v
[CI执行]
- pytest 执行
- Allure结果生成
- 失败产物归档（日志/trace/截图）
|
v
[AI辅助失败分析]
- 汇总报错堆栈/trace/截图
- 分类：脚本问题/环境问题/产品缺陷/数据问题
- 给出可能原因排序与修复建议
|
v
[回归闭环]
- 修正脚本/补充断言
- 更新测试数据模板
- 更新Prompt模板（沉淀为团队资产）
3.2 分阶段细化（实际落地时更有用）
阶段A：测试分析（AI做“质检”和“补漏”）
输入
- 需求文档 / 原型图 / 接口文档
- 变更说明（本次改了什么）
- 原有用例骨架
- 历史缺陷（可选）
AI参与点
- 检查用例缺口
- 补边界和异常路径
- 给回归范围建议
- 生成评审澄清问题清单
人工把关点
- 业务规则真实性
- 风险优先级判断
- 是否真的纳入本轮范围
产出
- 测试点清单（P0/P1/P2）
- 自动化候选清单
- 接口参数设计初稿
阶段B：接口测试设计（AI做参数组合与断言建议）
输入
- OpenAPI/Swagger
- 错误码文档
- 权限规则 / 幂等规则
AI参与点
- 字段约束提取
- 正向/负向/边界参数集生成
- 断言建议（HTTP/业务码/关键字段）
- pytest 参数化结构建议
人工把关点
- 业务断言是否准确
- 异常码是否符合系统约定
- 数据污染风险（造数与清理）
产出
- 参数测试集（json/yaml）
- 接口断言清单
- 特殊机制专项（幂等/权限/签名）
阶段C：UI自动化脚本生成（AI只写“初稿骨架”）
输入
- 页面流程
- 元素定位信息（尽量给
data-testid / 稳定locator）
- 已有框架规范（目录结构、命名、fixture）
- 断言规范（UI断言 + 接口断言）
AI参与点
- Playwright 操作步骤骨架
- pytest 测试函数结构
- Page Object 初稿
- Allure step 文案（可读性提升）
- 重复代码重构建议
人工把关点（关键）
- locator 稳定性（避免脆弱 xpath）
- 等待策略（显示等待、状态等待）
- 测试隔离（账号/数据/环境）
- 关键断言完整性（不仅点到成功提示）
产出
- 可运行脚本初稿
- Page Object / Fixture 补充
- Allure注释与步骤信息
阶段D：执行与报告（Allure）
执行链路（示例）
pytest 执行
-> 生成 allure-results
-> 生成/查看 Allure 报告
-> 收集失败截图、trace、日志
AI参与点
- 失败案例摘要（把长日志变成可读结论）
- 按失败类型聚类（定位器/超时/数据/接口/产品缺陷）
- 给修复优先级建议
人工把关点
- 最终缺陷归因
- 是否误判为脚本问题
- 是否需要加稳定性治理（重试/等待/数据隔离）
产出
- 失败分析摘要
- 缺陷单描述草稿
- 自动化脚本改进项清单
阶段E：沉淀（这一步决定你是否“成熟”）
很多人只用 AI 一次，产出不错，但不可复用。成熟的做法是把下面这些沉淀下来：
1）Prompt 资产化
- 用例质检 Prompt（CRM版）
- 接口参数生成 Prompt
- UI脚本骨架生成 Prompt
- 失败分析 Prompt
2）模板资产化
- pytest 参数化数据模板
- Allure step 命名规范
- 断言模板（成功/失败/权限/幂等）
3）经验库资产化
- 常见失败模式（元素不可点击、弹窗遮挡、数据脏、接口超时）
- 修复手段（等待策略、造数方案、清理方案）
3.3 可以直接执行的“最小落地版本”（建议先这样）
如果你想先尝试，不要一开始就搞得太复杂，按这个最小闭环来：
第1周（先验证价值）
1. 选CRM一个模块（如客户新增/编辑）
2. 用“用例质检Prompt”检查现有用例骨架
3. 用“接口参数Prompt”补一批负向参数
4. 选2~3条高频回归流程，AI生成Playwright+pytest初稿
5. 人工改到可运行，接入Allure
6. 跑一轮回归，收集失败日志
7. 用AI做失败分析总结（只做建议，不直接采纳）
目标：
- 提升用例覆盖率
- 缩短脚本编写时间
- 提高失败排查效率
3.4 一个后续可扩展的目录结构（示意）
如果你要做成团队内可复用的资产，可以这样组织目录（示意）：
project/
├─ prompts/
│ ├─ testcase_qc_crm.md
│ ├─ api_param_generation.md
│ ├─ playwright_script_draft.md
│ └─ failure_analysis.md
├─ tests/
│ ├─ api/
│ └─ ui/
├─ pages/
├─ fixtures/
├─ data/
│ ├─ api_cases/
│ └─ ui_cases/
├─ reports/
│ └─ allure-results/
└─ docs/
├─ assertion_rules.md
├─ locator_rules.md
└─ common_failure_patterns.md
最后给你一个实战提醒（很重要）
你要追求的不是“AI帮你写更多内容”，而是：
所以你现在这三个模板的方向是对的，已经是“成熟技术落地”的路线了。将这些模板和流程融入你的日常工作中，可以系统性地提升软件测试的效率和覆盖率。同时，善用人工智能作为辅助工具，能让你将精力更集中于高价值的判断与决策上。如果你有更多关于测试自动化或 AI 辅助测试的经验与想法，欢迎来 云栈社区 与大家交流分享。
发表于 13 小时前
|
查看: 5|
回复: 0
