TTokenySpace
返回 Skills 列表

Qa Test Case Design

当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。适用于将前面的分析产出物整合为 P0-P3 分级、可追溯的标准格式测试用例。

#中文
下载 ZIP 来源页面
0

安装到 Tokeny（自动）

下载 ZIP
安装"qa-test-case-design"技能
技能信息：
- 名称: Qa Test Case Design
- 标识: qa-test-case-design
- 描述: 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。适用于将前面的分析产出物整合为 P0-P3 分级、可追溯的标准格式测试用例。
- 版本: 1.0.0
下载地址：
https://www.tokeny.space/api/skills/qa-test-case-design/download
继续

复制上方内容到 Tokeny 客户端并在会话中发送即可自动安装；也可直接 下载 ZIP并拖动到技能窗口安装。

SKILL.md

高级测试用例设计专项

核心原则

测试用例设计的核心——明确"测什么"，而非"怎么测"。

我们专注于：用例结构设计、场景覆盖策略、分类优先级、测试点识别组织。

重要限制：禁止读取代码——测试用例必须基于需求文档，不得读取代码实现。确保验证"系统应该做什么"，而非"系统如何实现"。

详细的设计方法、覆盖策略和评审标准参见 references/ 目录：

  • references/design-methods.md — 10种设计方法详解 + 复杂场景覆盖
  • references/coverage-and-quality.md — 覆盖维度 + 质量指标
  • references/review-standards.md — 需求文档要求 + 评审标准

设计理念

为什么测试步骤留空？

同一个"登录"功能，不同系统实现完全不同。
AI不知道你们系统用的是哪种实现方式：
- 强制生成步骤 → 步骤与实际不符 → 测试人员需要大量修正 → 增加工作量
- 测试步骤留空 → 用户基于实际系统补充 → 只需补充细节 → 减少工作量

测试用例结构设计

重要：输出格式、用例分级、编号规则是固定的，必须严格遵守。

标准用例字段模板

📖 完整的字段模板、用例编号规则、级别定义、输出格式和报告结构详见 references/output-template-full.md。

本节保留核心字段概览，详细模板按需加载以节省 context。

使用方法

触发场景

当用户提供以下类型的请求时，此技能自动激活：

  1. 生成测试用例："帮我设计用户登录功能的测试用例"
  2. 完善用例："这些测试用例不够全面，请补充异常场景"
  3. 审查用例："检查一下这些测试用例是否有遗漏"
  4. 评审辅助："我需要准备测试用例评审，生成一套完整的用例"
  5. 覆盖优化："这个功能还缺哪些测试场景"
  6. 质量评估："评估一下这些测试用例的质量"

输入要素

为生成高质量的测试用例，尽量提供以下信息：

  1. 需求描述：功能需求的详细说明
  2. 业务背景：该功能在整体产品中的定位
  3. 约束条件：技术限制、合规要求等
  4. 目标用户：主要使用人群及其特征
  5. 关联系统：涉及的其他模块或第三方服务
  6. 风险点：已知的高风险区域
  7. 历史缺陷：类似功能的历史问题

输出内容

  1. 完整测试用例集：涵盖所有识别出的测试点
  2. 测试优先级排序：按P0-P3分级展示
  3. 覆盖率说明：已覆盖的测试维度列表
  4. 缺失风险提示：可能存在的测试盲区建议
  5. 测试建议：针对测试执行的建议

最佳实践

用例设计原则

✅ DO - 推荐做法

  • 每个用例只验证一个明确的目标
  • 使用清晰的数字序号标记预期结果
  • 预期结果使用"应该/必须/会"等确定性词汇
  • 包含正向和反向两种情况的验证
  • 标注敏感信息的脱敏处理方式
  • 为复杂场景添加截图或伪代码说明
  • 测试步骤留空，由用户根据实际系统补充

❌ DON'T - 避免做法

  • 模糊的描述如"检查是否可以正常工作"
  • 一次性验证过多无关功能
  • 忽略前置条件和环境配置
  • 混合多个验证点在一个预期结果中
  • 使用主观判断代替客观测量
  • 忽略异常处理流程
  • 强制生成可能与实际不符的测试步骤

用例评审要点

  1. 完整性检查：是否覆盖所有需求点和隐性场景
  2. 独立性检查：用例之间是否存在强依赖关系
  3. 可执行性检查：预期结果是否清晰、客观可测量
  4. 可维护性检查：命名规范、变更可追溯
  5. 优先级合理性：P0用例是否真正关键
  6. 覆盖全面性：功能、数据、权限、集成是否覆盖

输出示例

示例1：电商下单功能测试用例设计

## 订单模块 - 商品下单 - P0

### TC_ORDER_CREATE_001 正常下单流程

**测试类型**: 功能测试
**功能模块**: 订单管理
**子功能**: 商品下单
**用例级别**: P0
**预置条件**:
1. 用户已登录且账户余额充足
2. 商品库存大于0
3. 收货地址已配置

**测试步骤**:
（留空，由用户根据实际系统补充）

**预期结果**:
1. 进入订单确认页
2. 订单金额计算准确（含运费优惠）
3. 订单创建成功，返回订单号
4. 库存扣减正确
5. 收到订单confirmation通知

**实际结果**: 待执行

示例2：用户注册功能异常场景

## 用户模块 - 注册 - P1

### TC_USER_REGISTER_002 邮箱格式错误

**测试类型**: 功能测试
**功能模块**: 用户管理
**子功能**: 用户注册
**用例级别**: P1
**预置条件**: 访问注册页面

**测试步骤**:
（留空，由用户根据实际系统补充）

**预期结果**:
1. 邮箱字段显示红色错误提示
2. 提示内容明确告知格式要求
3. 无法继续提交表单
4. 控制台无报错日志

**实际结果**: 待执行

示例3：页面跳转测试用例设计

## 商品模块 - 列表跳详情 - P0

### TC_PRODUCT_LIST_001 正常跳转详情页

**测试类型**: 功能测试
**功能模块**: 商品管理
**子功能**: 列表跳详情
**用例级别**: P0
**预置条件**:
1. 用户已登录
2. 商品列表页有数据

**测试步骤**:
（留空，由用户根据实际系统补充）

**预期结果**:
1. 成功跳转到商品详情页
2. URL包含正确的商品ID（如/product/12345）
3. 详情页展示的商品信息与列表一致
4. 商品图片、价格、库存等关键信息正确
5. 详情页功能按钮（购买、收藏等）可用

**实际结果**: 待执行

检查清单

测试用例设计完成后检查：

  • 是否覆盖了所有需求点和隐性场景？
  • 是否包含了正常、异常、边界三种场景？
  • 每条用例是否只验证一个明确目标？
  • 预期结果是否可客观验证？
  • 用例优先级（P0-P3）是否合理？

参考资源

  • references/design-methods.md — 10种设计方法详解 + 复杂场景覆盖
  • references/coverage-and-quality.md — 覆盖维度 + 覆盖评估 + 质量指标
  • references/review-standards.md — 需求文档要求 + 用例评审标准
  • ISTQB测试术语标准 / ISO/IEC/IEEE 29119 / Google Testing Blog

评论

加载中…