420b9e37fa
1. 新增文档源管理模块（documentSource） - 控制器：documentSourceController.py - DAO层：documentSourceDao.py - 模型：documentSourceModel.py - 服务层：documentSourceService.py 2. 新增技能管理模块（skill） - 控制器：skillController.py - DAO层：skillDao.py - 模型：skillModel.py - 服务层：skillService.py 3. 新增AI服务（aiService.py） 4. 新增配置文件 - AI配置：config/ai_config.py - 技能配置：config/skills/test-case-generator/ 5. 新增SQL脚本 - 文档权限：add_document_permissions.sql - 模块状态字段：add_module_status_field.sql - 文档源表：create_document_source_table.sql - 技能规则：skills_rules_pgsql.sql
102 lines
4.9 KiB
Markdown
102 lines
4.9 KiB
Markdown
---
|
||
name: boundary-case-testcase-generator
|
||
description: 从 PRD、需求文档、用户故事、功能说明、接口说明、UI 交互说明或业务规则中，生成、补充、优化和评审测试用例，尤其擅长边界值、极值、空值、越界、长度限制、状态切换、权限、时间、金额、枚举、组合条件等场景。只要用户要根据需求生成测试用例、完善测试点、补充边界场景、检查是否遗漏边界条件，就应优先使用此 Skill。
|
||
---
|
||
|
||
# 边界值测试用例生成
|
||
|
||
请将输入的 PRD、需求说明、业务规则、接口文档或 UI 说明，转换为适合入库的测试用例 JSON。
|
||
|
||
## 适用场景
|
||
|
||
当用户希望你：
|
||
- 根据 PRD 或需求文档生成测试用例
|
||
- 补充边界值、异常值、极限值测试点
|
||
- 评审某个功能是否遗漏关键测试场景
|
||
- 将模糊需求拆成更细的测试点
|
||
- 为接口、页面、流程、规则、权限生成详细用例
|
||
|
||
如果信息不足，不要自行编造需求；应使用“待确认”标记不明确部分，并继续围绕已知信息生成可验证的测试点。
|
||
|
||
## 任务目标
|
||
|
||
你的目标不是写总结，而是输出可直接入库的测试用例数据。重点是：
|
||
- 覆盖边界值、异常输入、临界状态和业务限制
|
||
- 用更细的粒度拆解测试点，避免一个用例覆盖太多内容
|
||
- 保持用例名称具体、步骤清晰、预期可检查
|
||
- 严格遵守固定 JSON 输出结构
|
||
|
||
## 分析步骤
|
||
|
||
### 1. 先识别需求对象
|
||
从输入中提取：
|
||
- 业务目标
|
||
- 功能模块与子模块
|
||
- 输入字段、参数、条件、状态
|
||
- 约束规则：长度、范围、格式、时间、金额、频率、并发、权限、依赖关系
|
||
- 成功路径与失败路径
|
||
|
||
### 2. 再提取边界点
|
||
优先寻找以下边界：
|
||
- 数值边界：最小值、最大值、临界值、0、负数、极大值、小数精度
|
||
- 字符边界：空字符串、仅空格、最短、最长、特殊字符、中文/英文/表情
|
||
- 集合边界：无数据、1条、最大条数、重复项、顺序变化
|
||
- 时间边界：起止时间、跨天、跨月、当前时间、过期、时区
|
||
- 状态边界：未开始/进行中/已完成/已失效/已取消
|
||
- 权限边界：未登录、无权限、角色切换、越权访问
|
||
- 组合边界：多个限制同时触发
|
||
|
||
### 3. 设计用例
|
||
每个用例都要尽量单一、具体、可执行：
|
||
- title 写成“具体场景 + 测试点”
|
||
- module_name 写明父模块/子模块/叶子模块
|
||
- precondition 写清楚前置条件；没有就写“待确认”
|
||
- steps 用数字编号逐行写
|
||
- expected_result 也必须逐行编号
|
||
- priority 默认按风险和影响判断；若无明确规则，优先级可保守取 2
|
||
- case_type 使用平台要求的枚举值；若无更多信息，按功能/边界验证类用例理解为 1
|
||
- tags 至少保留“AI生成”
|
||
|
||
### 4. 输出前自检
|
||
检查是否满足：
|
||
- 是否覆盖边界值与异常值
|
||
- 是否存在编造需求的内容
|
||
- 是否每条用例都足够具体
|
||
- 是否 steps 和 expected_result 都是编号格式
|
||
- 是否完全符合固定 JSON 结构
|
||
|
||
## 输出约束
|
||
|
||
必须只输出一个 JSON 对象，不要输出 Markdown、解释、代码块或多余文本。
|
||
|
||
固定输出结构如下：
|
||
|
||
{"cases":[{"title":"用例名称/测试点名称","module_name":"父模块/子模块/叶子模块","precondition":"前置条件","steps":"1. 步骤1\n2. 步骤2","expected_result":"1. 预期结果1\n2. 预期结果2","priority":2,"case_type":1,"tags":["AI生成"]}]}
|
||
|
||
## 编写原则
|
||
|
||
- 以需求为准，不臆造不存在的规则
|
||
- 细化到可执行层级，不要把多个独立场景揉成一个大用例
|
||
- 边界值优先于笼统的“正常/异常”描述
|
||
- 预期结果要可观察、可判断、可入库
|
||
- 当需求模糊时，保留“不确定项”，并围绕已知规则生成用例
|
||
|
||
## 示例
|
||
|
||
输入示例：
|
||
“用户在注册页输入手机号，手机号为 11 位，验证码 6 位，密码长度 8-20 位。”
|
||
|
||
输出示例：
|
||
{"cases":[{"title":"手机号输入位数下限边界校验","module_name":"注册页/手机号输入","precondition":"用户进入注册页","steps":"1. 在手机号输入框输入 10 位手机号\n2. 点击获取验证码或提交","expected_result":"1. 系统提示手机号格式不正确\n2. 不允许继续提交","priority":2,"case_type":1,"tags":["AI生成"]},{"title":"密码长度上限边界校验","module_name":"注册页/密码输入","precondition":"用户进入注册页","steps":"1. 在密码输入框输入 20 位密码\n2. 点击提交","expected_result":"1. 密码可正常通过长度校验\n2. 若其他字段满足要求，提交成功","priority":2,"case_type":1,"tags":["AI生成"]}]}
|
||
|
||
## 处理信息不足的方式
|
||
|
||
如果需求中没有明确说明：
|
||
- 是否允许空值
|
||
- 最大长度是多少
|
||
- 时间范围如何计算
|
||
- 是否支持特殊字符
|
||
- 权限边界如何定义
|
||
|
||
则在用例里明确写“待确认”，不要推测具体规则；同时继续生成基于已知条件的边界值测试点。
|