git:20260311.13a323e to git:20260325.34f3a7e

55 added, 453 removed. Audit A to A.

---
name: testcase-generator
description: 测试用例生成器 - 同时支持“计划驱动”和“文档驱动”。计划驱动:基于业务流程与用户场景分析、等价类划分、边界值分析、因果图分析等理论,按测试点(POINT)分批生成高质量测试用例,输出为 Markdown 与 Excel。文档驱动:当用户粘贴 PRD/需求/接口文档时,默认运用通用测试设计策略(正向/反向/边界/等价/状态/场景),并可结合 references 与 assets 模板组织输出。当用户执行 /testcase-gen 命令或请求生成测试用例时触发。
allowed-tools: Read, Write, Bash, Glob
---
# 测试用例生成器(testcase-generator)
## 1. 目标
根据测试点生成结构化测试用例,覆盖核心业务、正向、反向、边界、异常等场景。
## 2. 输入输出
- **输入**:`test-case/plan.md`、`clarified-requirements/index.md`、`CLAUDE.md`
- - **输出**:`test-case/{ITEM}/{POINT}.md`、`test-case/all_cases.md`
+ - **输出**:`test-case/{ITEM}/{POINT}.md`、`test-case/all_cases_测试用例.xlsx`、`test-case/all_cases_思维导图.xmind`
## 3. 核心原则
1. **策略指导**:提供判断标准,而非强制数量
2. **场景驱动**:基于实际场景复杂度生成用例
3. **数据具体**:测试数据必须具体不用占位符
4. **可验证性**:预期结果必须明确可验证执行
---
- ## 文档驱动工作流
+ ### 工作流
当用户提供 PRD、需求说明或接口文档文本,并请求“根据文档生成测试用例”时,按如下流程执行:
1. 识别文档类型与结构
- 功能/业务需求、接口说明、性能/SLA、安全要求或其组合
- 提取:模块/接口清单、约束(必填/可选、长度/格式/范围)、状态与角色、错误码、性能指标等
2. 默认测试设计策略(始终启用)
- 正向用例(正常路径/happy path)
- 反向/异常用例(非法输入、越权、错误码、不产生副作用)
- 边界值(最小/最大/临界/空/极值)
- 等价类(有效/无效代表值,必要时与边界结合)
- 状态与流程(合法迁移、非法操作、回退/中断、角色切换)
- 场景法/端到端(典型用户目标串联多模块)
3. references 与模板协同
- - 功能类标准:请参考 `references/functional-testcases-standard.md`
- - 本技能参考提示:`testcase-generator/references/PROMPTS.md`
- - 若用户指定 Word/Excel 模板(assets),按模板列名/顺序组织输出;否则沿用本技能既定 Markdown 文本协议,并可使用 `scripts/to_excel.py` 导出
+ - **`references/theory.md`** - 测试理论详解(等价类、边界值、因果图、场景法)
+ - **`references/format-standard.md`** - 格式规范详细说明
+ - **`references/prompts.md`** - 提示词模板(文档驱动模式)
4. 输出要求
- 严格遵循本技能“用例格式规范/文本协议”与“测试类型枚举(12种)”
- 步骤与预期结果编号从 1 连续递增,数量一致;字段间不留空行
- 预期结果需可验证,错误场景对应明确错误码/提示/状态不变
5. 质量自检
- 每个核心功能/接口至少 1 条正向用例
- 关键输入约束具备异常/反向覆盖
- 所有范围/长度/数量限制具备边界用例
- 如涉及状态机/流程,覆盖合法迁移与非法操作
- 测试类型与优先级明确,便于导出与后续执行
-
- ## 4. 核心理论
-
- ### 4.1 等价类划分法
-
- 将输入数据划分为若干等价类,从每类中选取代表性数据测试。
-
- **应用示例**:
- ```
- POINT: 用户名密码登录
-
- 输入项: 用户名、密码
-
- 用户名等价类:
- 有效: [6-20字符,字母数字下划线] → "test_user123"
- 无效: [<6] "ab" | [>20] "verylongusername12345" | [特殊字符] "user@name" | [空] ""
-
- 密码等价类:
- 有效: [8-20字符,含大小写+数字] → "Test1234"
- 无效: [<8] "Test12" | [缺大写] "test1234" | [空] ""
-
- 生成原则: 一次测试一个等价类,其他保持有效
- ```
-
- ### 4.2 边界值分析法
-
- 边界是最容易出错的地方。
-
- **边界三点法**: 离点(min-1) | 上点(min) | 内点(中间值) | 上点(max) | 离点(max+1)
-
- **应用示例**:
- ```
- 用户名长度 6-20 字符:
- - 离点-下: 5字符 "abcde" → 失败
- - 上点-下: 6字符 "abcdef" → 成功
- - 内点: 13字符 "test_user_123" → 成功
- - 上点-上: 20字符 "test_user_1234567890" → 成功
- - 离点-上: 21字符 "test_user_12345678901" → 失败
- ```
-
- ### 4.3 因果图
-
- 将输入条件(因)和输出动作(果)之间的逻辑关系图形化,再转换为判定表。
-
- **应用示例**
- - 因:投币、选饮料、库存充足
- - 果:出货、找零、提示"售罄"
- - 约束:未投币不能选饮料(E约束)
-
- ### 4.4 场景法/流程分析法
-
- 基于用户实际业务流程设计测试用例。
-
- **应用示例**
- - 基本流:浏览→选餐→登录→填写地址→支付→成功
- - 备选流:未登录时选餐→登录后继续→支付
- - 异常流:支付时余额不足→充值→继续支付
- - 异常流:支付超时→订单取消
-
- ### 4.5 用例数量判断
-
- 不强制数量,根据场景复杂度自适应调整。
-
- **判断标准**:
- - 输入项数量:输入项越多,用例越多
- - 业务规则复杂度:规则越复杂,用例越多
- - 风险等级:Critical 和 High 需要更多用例
- - 测试关注点:关注点越多,用例越多
-
---
- ## 5. 用例格式规范
-
- ### 5.1 Markdown文本协议格式
-
- 每个测试点生成一个 `.md` 文件,格式如下:
-
- ```markdown
- ## [P0] 用例标题
- [测试类型] 功能
- [前置条件] 前置条件描述
- [测试步骤] 1. 步骤1。2. 步骤2
- [预期结果] 1. 预期1。2. 预期2
-
- ## [P1] 用例标题
- [测试类型] 功能
- [前置条件] 前置条件描述
- [测试步骤] 1. 步骤1。2. 步骤2
- [预期结果] 1. 预期1。2. 预期2
-
- ## [P2] 用例标题
- [测试类型] 功能
- [前置条件] 前置条件描述
- [测试步骤] 1. 步骤1。2. 步骤2
- [预期结果] 1. 预期1。2. 预期2
-
- ## [P3] 用例标题
- [测试类型] 功能
- [前置条件] 前置条件描述
- [测试步骤] 1. 步骤1。2. 步骤2
- [预期结果] 1. 预期1。2. 预期2
- ```
-
- ### 5.2 字段说明
-
- - **优先级**:P0-P3(必填)
- - P0: 核心功能正向流程
- - P1: 基本功能正向流程
- - P2: 核心功能异常场景
- - P3: 边界条件、低频场景
- - **测试类型**:功能、接口、性能、安全、兼容、易用、安装部署、可靠、本地化、可维护、可扩展、配置(12选1)
- - **前置条件**:测试前的准备工作:环境准备、数据准备
- - **测试步骤**:操作步骤,用句号分隔;(导出excel时序号需要换行处理)
- - **预期结果**:期望的结果,与步骤一一对应;(导出excel时序号需要换行处理)
-
- ### 5.3 测试类型枚举(12种)
-
- ```
- 功能
- 兼容性
- 易用性
- 性能
- 稳定性
- 安全性
- 可靠性
- 效果(AI类、资源类)
- 效果(硬件器件类)
- 可维护性
- 可移植性
- 埋点
- ```
-
- **注意**:
- - 不能写"功能测试",必须是"功能"
- - 括号必须是中文括号
- - 大小写敏感
-
- ### 5.4 步骤格式规范
-
- **推荐格式**: 使用中文句号分隔,编号连续
-
- ```markdown
- [测试步骤] 1. 打开登录页面。2. 输入用户名test_user。3. 输入密码Test1234。4. 点击登录按钮
- [预期结果] 1. 页面正常显示。2. 用户名输入框显示内容。3. 密码输入框显示密码。4. 登录成功,跳转到首页
- ```
-
- **重要**: 编号必须从1开始,连续递增;测试步骤和预期结果的编号数量必须一致。
-
- ### 5.5 测试数据要求
-
- 必须具体,不用占位符:
-
- **正确示例**:
- - 用户名:test_user
- - 密码:Test1234
- - 手机号:13800138000
- - 金额:99.99
-
- **错误示例**:
- - 用户名:{valid_username}
- - 密码:{password}
- - 手机号:{phone}
- - 金额:{amount}
-
- ### 5.6 预期结果要求
-
- 必须明确可验证:
-
- **正确示例**:
- - 跳转到 /home 页面,顶部显示"欢迎,test_user"
- - 提示"密码长度不足,请输入8-20位密码"
- - 订单状态变为"已支付",库存减少1
-
- **错误示例**:
- - 登录成功
- - 提示错误信息
- - 系统正常处理
-
- ### 5.7 目录结构
-
- ```
- test-case/
- ├── plan.md
- ├── {ITEM}/
- │ ├── {POINT1}.md
- │ ├── {POINT2}.md
- │ └── ...
- └── all_cases.md
- ```
-
- ### 5.8 合并规则
-
- 将所有 `{ITEM}/{POINT}.md` 合并到 `all_cases.md`:
+ ## 4. 检验流程
- 1. 按 ITEM 分组
- 2. 每个 ITEM 下按 POINT 排序
- 3. 添加分隔标记:`# ITEM 名称` 和 `## POINT 名称`
+ ### Step 1: 每个测试项生成完毕后
- ---
+ 调用校验脚本检查格式:
- ## 6. 用例生成流程
+ **校验项**:
+ - Schema格式
+ - 必填字段(优先级、测试类型、测试步骤、预期结果)
+ - 测试类型枚举(12种)
+ - 步骤编号连续性
+ - 步骤与预期结果数量一致性
+ - 等价类覆盖检查(`--check-equivalence`)
+ - 边界值覆盖检查(`--check-boundary`)
+ - 重复检测(`--check-duplicates`)
- ### Step 1: 准备上下文
+ #### validate.py(一定执行该技能scripts目录下的脚本)
```bash
- cat test-case/plan.md
- cat clarified-requirements/index.md
- cat CLAUDE.md
- ```
-
- ### Step 2: 理解测试点
-
- 对每个 POINT:
- - 读取 POINT 名称、风险等级、测试关注点
- - 读取需求文档中的相关描述
-
- ### Step 3: 识别输入项
-
- - 列出所有输入项(字段、参数、操作等)
- - 识别输入项的约束条件
-
- ### Step 4: 划分等价类和边界值
-
- - **有效等价类**:符合规则的输入
- - **无效等价类**:违反规则的输入
- - **边界值**:临界点(最小值、最大值、临界值)
-
- ### Step 5: 设计测试用例
-
- 基于以下策略设计:
-
- **核心思考框架**:
-
- 1. **输入分析**
- - 该场景涉及哪些输入项?
- - 每个输入有什么约束(长度、格式、范围)?
-
- 2. **等价类识别**
- - 有效等价类:正常情况下的典型值
- - 无效等价类:各种异常情况(空值、越界、格式错误)
-
- 3. **测试价值评估**
- - 这个等价类失败时,会暴露不同的缺陷吗?
- - 如果和其他等价类的测试逻辑相同,是否可以合并?
- - 测试关注点中提到的场景,如何在用例中体现?
-
- 4. **覆盖判断**
- - 有效流程至少有一个用例
- - 核心异常场景已覆盖
- - 边界条件根据实际情况选择
-
- 5. **用例设计**
- - 核心正向用例(P0):最常见的成功场景
- - 基本正向用例(P1):其他有效等价类
- - 核心异常用例(P2):关键失败场景
- - 边界条件/低频场景用例(P3):边界值测试、不常见但需覆盖的场景
-
- **用例质量标准**:
- - 数据具体("test123",不要"正确用户名")
- - 预期结果可验证("显示错误提示'用户名不能为空'",不要"提示错误")
- - 命名规范(可以不以"验证"开头,但是必需能用自然语言描述清晰,清楚测试用例的意图)
-
- ### Step 6: 生成完毕后统一校验
-
- - 每个测试项(ITEM)生成完毕后,调用校验脚本检查格式
- - 全部测试项生成完毕后,再次调用校验脚本进行整体检查
- - 校验脚本路径:`testcase-generator/scripts/validate.py`
-
- ---
-
- ## 7. 示例
-
- ### 示例1:正确的用例(用户名密码登录)
-
- ```markdown
- ## [P1] 验证有效用户名和密码登录成功
- [测试类型] 功能
- [前置条件] 已注册用户test_user,密码Test1234
- [测试步骤] 1. 输入用户名test_user,输入密码Test1234,点击登录。2. 验证跳转到首页并显示用户名
- [预期结果] 1. 登录请求成功。2. 跳转到/home页面,顶部显示'欢迎,test_user'
-
- ## [P2]验证用户名为空时登录失败
- [测试类型] 功能
- [前置条件] 进入登录页
- [测试步骤] 1. 不输入用户名,输入密码Test1234,点击登录。2. 验证提示'用户名不能为空'
- [预期结果] 1. 登录请求被拒绝。2. 停留在登录页,用户名输入框下方显示红色提示'用户名不能为空'
-
- ## [P3] 验证密码长度边界值(8位)
- [测试类型] 功能
- [前置条件] 已注册用户test_user,密码Test1234
- [测试步骤] 1. 输入用户名test_user,输入8位密码Test1234,点击登录。2. 验证登录成功
- [预期结果] 1. 登录请求成功。2. 跳转到/home页面
- ```
-
- ### 示例2:综合场景(多输入项)
-
- **POINT**: 广告账户列表-筛选功能
-
- **输入项分析**:
- 1. 时间范围: [今天|昨天|近7天|自定义]
- 2. 账户名称: [文本模糊搜索]
- 3. 账户状态: [正常|封禁|审核中]
-
- **生成用例(8个)**:
-
- ```markdown
- ## [P0] 验证单一条件:时间筛选成功
- [测试类型] 功能
- [前置条件] 广告账户列表页面,有10个账户
- [测试步骤] 1. 选择时间"近7天",点击查询。2. 验证返回符合条件的账户
- [预期结果] 1. 列表刷新。2. 仅显示近7天有数据的账户
-
- ## [P0] 验证单一条件:账户状态筛选成功
- [测试类型] 功能
- [前置条件] 广告账户列表页面,有10个账户,有6个账户状态正常,其余封禁
- [测试步骤] 1. 选择账户状态"正常",点击查询。2. 验证返回符合条件的账户
- [预期结果] 1. 列表刷新。2. 仅显示账户正常的数据
-
- ## [P0] 验证多条件组合筛选成功
- [测试类型] 功能
- [前置条件] 同上
- [测试步骤] 1. 选择时间"近7天",输入名称"test",选择状态"正常",点击查询
- [预期结果] 1. 列表刷新。2. 仅显示同时满足3个条件的账户
-
- ## [P2] 验证时间超过365天筛选失败
- [测试类型] 功能
- [前置条件] 同上
- [测试步骤] 1. 选择自定义时间,开始日期2023-01-01,结束日期2024-01-02,点击查询
- [预期结果] 1. 显示提示"时间范围不能超过365天",列表不刷新
-
- ## [P2] 验证不完整的账户名筛选返回相关数据
- [测试类型] 功能
- [前置条件] 同上
- [测试步骤] 1. 输入不完整的账户名"test_1",点击查询
- [预期结果] 1. 列表刷新。2. 列表显示所有模糊匹配test1的账户
-
- ## [P2] 验证不存在的账户名筛选返回空
- [测试类型] 功能
- [前置条件] 同上
- [测试步骤] 1. 输入不存在的账户名"nonexistent123",点击查询
- [预期结果] 1. 列表刷新。2. 显示"暂无数据"
-
- ## [P2] 验证筛选条件清空功能
- [测试类型] 功能
- [前置条件] 已应用筛选条件
- [测试步骤] 1. 点击"重置"按钮。2. 验证所有筛选条件清空,列表恢复默认
- [预期结果] 1. 所有筛选项恢复默认值。2. 列表显示全部账户
-
- ## [P3]验证结束时间早于开始时间提示错误
- [测试类型] 功能
- [前置条件] 同上
- [测试步骤] 1. 选择自定义时间,开始日期2024-01-02,结束日期2024-01-01,点击查询
- [预期结果] 1. 显示提示"结束时间不能早于开始时间"
- ```
-
- **说明**:
- - 中等复杂度 POINT(多输入项)生成 8 个用例
- - 覆盖:有效组合、无效边界、清空操作
- - 选择**代表性用例**,覆盖主要场景
-
- ### 示例3:错误的用例
-
- ```markdown
- ## [P0] 验证登录成功
- [测试类型] 功能
- [前置条件] 用户已注册
- [测试步骤] 1. 输入用户名{username},输入密码{password},点击登录
- [预期结果] 1. 登录成功
- ```
-
- **为什么错误**:
- - 测试数据使用占位符({username}、{password})
- - 预期结果不可验证("登录成功"太模糊)
-
-
- ### 示例4:重复的用例
-
- ```markdown
- ### [P2] OTA升级-检测有最新固件版本
- [测试类型] 功能
- [前置条件] 已进入网关详情页,点击OTA升级按钮
- [测试步骤] 1. 点击OTA升级按钮。2. 查看页面弹窗。3. 查看弹窗内容。
- [预期结果] 1. 弹出OTA升级弹窗。2. 页面检测到有最新固件版本。3. 显示升级按钮。4. 显示当前版本号和最新版本号。
-
- ### [P2] OTA升级-显示升级按钮
- [测试类型] 功能
- [前置条件] OTA升级弹窗检测到有最新固件版本
- [测试步骤] 1. 查看OTA升级弹窗。2. 查看升级按钮显示。
- [预期结果] 1. 显示""立即升级""按钮。 2. 升级按钮样式清晰可见。 3. 升级按钮可点击。
- ```
-
- **为什么错误**:
- - 显示升级按钮已经代表检测有最新固件版本
- - 预期结果已经验证显示了升级按钮,就不需要再有测试用例来验证是否显示升级按钮
-
- ---
-
- ## 8. 检验流程
-
- ### Step 1: 每个测试项生成完毕后
+ # 单文件校验
+ python .agent/skills/testcase-generator/scripts/validate.py --single "test-case/{模块}/{测试点}.md"
- 调用校验脚本检查格式:
+ # 全局校验
+ python .agent/skills/testcase-generator/scripts/validate.py "test-case/"
- ```bash
- uv run C:/Users/EDY/.iflow/skills/testcase-generator/scripts/validate.py \
- --single "test-case/{模块}/{测试点}.md"
+ # 仅重复检测
+ python .agent/skills/testcase-generator/scripts/validate.py "test-case/" --duplicates-only
```
脚本会输出日志,指出格式问题(如优先级错误、字段缺失等)。AI 分析日志,决定是否需要修改。
+
### Step 2: 全部生成完毕后
再次调用校验脚本进行整体检查:
```bash
- uv run C:/Users/EDY/.iflow/skills/testcase-generator/scripts/validate.py "test-case/" --check-duplicates
+ python .agent/skills/testcase-generator/scripts/validate.py "test-case/" --check-duplicates
```
脚本会检查重复用例、格式一致性等。脚本只提供日志,不直接修改文件。AI 分析日志,决定是否需要调整。
### Step 3: 生成质量报告
- 统计用例数量(按 ITEM、按优先级)
- 统计等价类覆盖率
- 统计边界值覆盖率
- 列出重复用例(如果有)
- - 如果有重复用例,就直接剔除
- 列出描述不清晰、不确定的测试用例(如果有)
- - 如果有不清晰、不确定的测试用例需要标记为待定
+ ### Step 4: 导出文件(to_excel.py、to_xmind.py)(一定执行该技能scripts目录下的脚本)
- ## 9. 检查清单
+ ```bash
+ # 从目录导出
+ python .agent/skills/testcase-generator/scripts/to_excel.py "test-case/" -o "test-case/export.xlsx"
+ # 从单个文件导出
+ python .agent/skills/testcase-generator/scripts/to_excel.py "test-case/{模块}/{测试点}.md" -o "output.xlsx"
+
+ # 导出xmind格式的思维导图
+ python .agent/skills/testcase-generator/scripts/testcase_to_xmind.py "test-case/"
+ ```
+
+ ---
+
+ ## 5. 检查清单
+
### 生成前检查
- [ ] 已读取 `test-case/plan.md`
- [ ] 已读取 `clarified-requirements/index.md`
- [ ] 已读取 `CLAUDE.md` 业务背景
- [ ] 理解测试项(ITEM)和测试点(POINT)的层级关系
+ - [ ] 理解需求文档或测试计划
+ - [ ] 识别所有功能模块
+ - [ ] 明确输入约束和业务规则
### 每个POINT生成时检查
- [ ] 每个 POINT 都已生成用例文件
- [ ] 用例数量合理(基于场景复杂度)
- [ ] 所有用例都有优先级(P0-P3)
- [ ] 所有用例都有测试类型(12种之一)
- [ ] 测试数据具体(无占位符)
- [ ] 预期结果可验证(无模糊描述)
- [ ] 测试步骤与预期结果数量一致
- - [ ] 用例标题可以不用"验证"开头,但是需要自然语言描述清楚,清晰的知道测试用例的目的
+ - [ ] 用例标题可以不用"验证"开头,但是必须要自然语言描述清楚用例的目的
### 治理阶段检查
- - [ ] 执行了全局校验脚本
- - [ ] 检查了重复用例
+ - [ ] 执行了全局校验脚本(已通过 validate.py 检查)
+ - [ ] 检查了重复用例(已通过 validate.py --check-duplicates 检查)
- [ ] 格式符合规范(已通过 validate.py 检查)
- - [ ] 已生成 all_cases.md
- - [ ] 无重复用例(已通过 validate.py --check-duplicates 检查)
- [ ] 已生成质量报告
-
- ---
-
- ## 10. 脚本接口
-
- ### validate.py
-
- ```bash
- # 单文件校验
- uv run C:/Users/EDY/.iflow/skills/testcase-generator/scripts/validate.py \
- --single "test-case/{模块}/{测试点}.md"
-
- # 全局校验
- uv run C:/Users/EDY/.iflow/skills/testcase-generator/scripts/validate.py "test-case/"
-
- # 全局校验 + 重复检测
- uv run C:/Users/EDY/.iflow/skills/testcase-generator/scripts/validate.py "test-case/" --check-duplicates
-
- # 仅重复检测
- uv run C:/Users/EDY/.iflow/skills/testcase-generator/scripts/validate.py "test-case/" --duplicates-only
- ```
-
- **校验项**:
- - Schema格式
- - 必填字段(优先级、测试类型、测试步骤、预期结果)
- - 测试类型枚举(12种)
- - 步骤编号连续性
- - 步骤与预期结果数量一致性
- - 等价类覆盖检查(`--check-equivalence`)
- - 边界值覆盖检查(`--check-boundary`)
- - 重复检测(`--check-duplicates`)
-
- ### to_excel.py
-
- ```bash
- # 从目录导出
- uv run C:/Users/EDY/.iflow/skills/testcase-generator/scripts/to_excel.py "test-case/" -o "test-case/export.xlsx"
-
- # 从单个文件导出
- uv run C:/Users/EDY/.iflow/skills/testcase-generator/scripts/to_excel.py "test-case/{模块}/{测试点}.md" -o "output.xlsx"
- ```
+ - [ ] Excel导出成功
+ - [ ] Xmind导出成功
---
- ## 11. 异常处理
+ ## 6. 异常处理
| 错误 | 处理方式 |
|------|----------|
| 单文件校验失败 | 重试3次,仍失败则跳过并记录 |
| 用例数过多(>15) | 提示检查是否有冗余等价类 |
| 缺少边界用例 | 警告并建议补充 |
| 缺少无效等价类 | 警告并建议补充异常场景 |
| 步骤编号不连续 | 报错并要求修正 |
| 测试类型不在枚举 | 报错并要求修正 |
| 步骤与预期数量不一致 | 报错并要求修正 |
| 导出失败 | 检查openpyxl依赖 |
---
- ## 12. 停止点
+ ## 7. 停止点
✅ **用例生成完成**
**产物**:
- `test-case/{ITEM}/{POINT}.md` - 各测试点的用例文件
- `test-case/all_cases.md` - 所有用例汇总
+ - `test-case/all_cases_测试用例.xlsx` - Excel格式
+ - `test-case/all_cases_思维导图.xmind` - Xmind格式
**质量保证**:
- 核心功能场景化覆盖所有业务场景
- 基于等价类理论生成
- 边界值全覆盖
- 用例数量合理(基于场景复杂度)
- 因果图分析法
**统计示例**:
```
📊 生成统计:
- 测试项: 8个
- 测试点: 20个
- 测试用例: 75个
覆盖率:
- 有效等价类: 100% (每POINT至少1个)
- 无效等价类: 80% (主要异常全覆盖)
- 边界值: 90% (所有范围型输入)
用例分布:
- P0(核心正向): 27个(35%)
- P1(基本正向): 15个(20%)
- P2(核心异常): 18个(25%)
- P3(边界条件/低频场景): 15个(20%)
```
**下一步**:
- - 人工审核测试用例
+ - 人工审核测试用例,根据业务理解调整用例
- 导出为 Excel 格式(必选)
- - 根据业务理解调整用例
+ - 导出为 Xmind 格式(必选)