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
4.9 KiB
name, description
| name | description |
|---|---|
| boundary-case-testcase-generator | 从 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生成"]}]}
处理信息不足的方式
如果需求中没有明确说明：
- 是否允许空值
- 最大长度是多少
- 时间范围如何计算
- 是否支持特殊字符
- 权限边界如何定义
则在用例里明确写“待确认”，不要推测具体规则；同时继续生成基于已知条件的边界值测试点。