testing-test-case-writer

name testing-test-case-writer description 测试用例编写助手 - 专业的测试用例设计与编写专家。适用场景： (1) 测试用例设计（等价类/边界值/决策表/状态迁移） (2) 测试场景分析与用例拆解 (3) 边界值与异常场景测试用例 (4) 功能测试用例编写（正向/反向/异常） (5) API接口测试用例设计 (6) 测试用例评审与优化 (7) 用例模板设计与规范制定 (8) 测试数据设计与准备 触发关键词：测试用例、用例设计、边界值、等价类、测试场景、测试数据、用例评审、测试步骤 测试用例编写助手 专业的测试用例设计与编写专家，确保测试用例的完整性、有效性和可执行性。 核心工作流程 1. 测试用例设计方法 等价类划分法： 等价类划分 ├── 有效等价类：符合规格的输入 │ └── 示例：年龄输入 18-60 ├── 无效等价类：不符合规格的输入 │ ├── 边界外：<18, >60 │ ├── 类型错误：字母、特殊字符 │ └── 空值/null └── 设计原则 ├── 每个有效等价类至少1条用例 └── 每个无效等价类单独1条用例 边界值分析法： 边界值选取（假设范围 1-100） ├── 最小值边界 │ ├── 0（刚好小于最小值） │ ├── 1（最小值） │ └── 2（刚好大于最小值） ├── 最大值边界 │ ├── 99（刚好小于最大值） │ ├── 100（最大值） │ └── 101（刚好大于最大值） └── 特殊边界 ├── 空值/null ├── 最大长度 └── 数据类型边界 决策表法： 决策表结构 ├── 条件桩：列出所有条件 ├── 动作桩：列出所有操作结果 ├── 条件项：条件的取值组合（Y/N/-） └── 动作项：对应的期望结果 示例：登录功能 | 条件 | R1 | R2 | R3 | R4 | |------|----|----|----|----| | 用户名正确 | Y | Y | N | N | | 密码正确 | Y | N | Y | N | | 结果 | 登录成功 | 密码错误 | 用户不存在 | 用户不存在 | 状态迁移法： 状态图 → 测试用例 ├── 识别所有状态 ├── 识别状态转换条件 ├── 绘制状态转换图 └── 导出测试路径 ├── 覆盖所有状态 ├── 覆盖所有转换 └── 覆盖异常转换 2. 测试场景分析 场景分析框架： 业务场景分析 ├── 核心业务流（Happy Path） │ └── 用户正常操作完成业务目标 ├── 分支流程（Alternative Flow） │ └── 业务的其他合法路径 ├── 异常流程（Exception Flow） │ └── 错误处理、边界情况 └── 并发场景 └── 多用户、多操作同时进行 技术场景分析 ├── 数据场景 │ ├── 空数据 │ ├── 大数据量 │ └── 特殊字符 ├── 网络场景 │ ├── 网络断开 │ ├── 网络延迟 │ └── 网络恢复 ├── 权限场景 │ └── 不同角色权限 └── 兼容场景 ├── 浏览器兼容 └── 设备兼容 用例优先级划分： 优先级 定义 覆盖范围 P0 核心功能-必须执行 冒烟测试、主流程 P1 重要功能-高优先 主要功能分支 P2 一般功能-中优先 次要功能、边界 P3 次要功能-低优先 异常、极端场景 3. 测试用例结构 标准用例要素： 用例基本信息 ├── 用例ID：唯一标识（模块-功能-序号） ├── 用例标题：简明描述测试目的 ├── 所属模块：功能模块归属 ├── 优先级：P0/P1/P2/P3 ├── 前置条件：执行用例前需满足的条件 ├── 测试步骤：详细操作步骤 ├── 测试数据：输入数据 ├── 预期结果：期望的系统响应 └── 实际结果：执行后填写 用例编写原则： SMART原则 ├── Specific：明确具体 ├── Measurable：可度量验证 ├── Achievable：可执行 ├── Relevant：与需求相关 └── Time-bound：有明确边界 3C原则 ├── Correct：准确无歧义 ├── Clear：步骤清晰 └── Complete：信息完整 4. 功能测试用例 用例分类： 正向测试用例 ├── 正常输入正确数据 ├── 按正确流程操作 └── 预期得到正确结果 反向测试用例 ├── 输入无效数据 ├── 操作顺序错误 └── 验证错误提示正确 边界测试用例 ├── 最大/最小值 ├── 临界点测试 └── 极限值测试 异常测试用例 ├── 网络中断 ├── 服务不可用 ├── 数据异常 └── 并发冲突 常见测试点checklist： 输入验证 □ 必填字段为空 □ 超出长度限制 □ 特殊字符处理 □ SQL注入字符 □ XSS脚本字符 □ 数据类型不匹配 □ 格式不正确（邮箱/手机等） 业务逻辑 □ 权限控制 □ 状态流转 □ 数据一致性 □ 计算逻辑 □ 业务规则 UI交互 □ 页面加载 □ 按钮状态 □ 提示信息 □ 表单验证 □ 分页功能 5. API接口测试用例 接口测试维度： 功能测试 ├── 正常请求响应 ├── 参数验证 ├── 业务逻辑 └── 数据正确性 异常测试 ├── 缺少必填参数 ├── 参数类型错误 ├── 参数值越界 ├── 非法Token └── 接口不存在 性能测试 ├── 响应时间 ├── 并发请求 └── 大数据量 安全测试 ├── 认证授权 ├── SQL注入 ├── 越权访问 └── 敏感信息 接口用例模板： | 字段 | 说明 | |------|------| | 接口名称 | | | 请求URL | | | 请求方法 | GET/POST/PUT/DELETE | | 请求头 | Content-Type, Authorization等 | | 请求参数 | 参数名/类型/必填/说明 | | 请求体示例 | JSON格式 | | 预期响应码 | 200/400/401/500等 | | 预期响应体 | JSON格式 | 6. 测试数据设计 测试数据策略： 数据来源 ├── 手工构造：小规模测试 ├── 脚本生成：批量数据 ├── 生产脱敏：真实场景 └── 第三方工具：Faker等 数据类型 ├── 基础数据：用户、配置 ├── 业务数据：订单、交易 ├── 边界数据：极值、特殊值 └── 异常数据：错误格式、非法值 数据管理 ├── 数据隔离：环境独立 ├── 数据清理：用后即清 ├── 数据版本：与用例版本对应 └── 数据安全：脱敏处理 常用测试数据： 数据类型 有效值示例 边界/无效值 手机号 13812345678 1381234567, 138123456789 邮箱 test@example.com test@, @example.com 身份证 110101199001011234 11010119900101123X 金额 100.00 -1, 0, 999999999.99 日期 2024-01-01 2024-13-01, 2024-02-30 输出模板 测试用例模板 ## 用例信息 | 项目 | 内容 | |------|------| | 用例ID | TC-[模块]-[功能]-[序号] | | 用例标题 | [简明描述测试目的] | | 所属模块 | [模块名称] | | 优先级 | P0/P1/P2/P3 | | 执行方式 | 手工/自动化 | | 编写人 | | | 编写日期 | | ## 前置条件 1. [条件1] 2. [条件2] ## 测试步骤 | 步骤 | 操作 | 测试数据 | 预期结果 | |------|------|----------|----------| | 1 | [操作描述] | [输入数据] | [期望结果] | | 2 | ... | ... | ... | ## 执行记录 | 执行人 | 执行日期 | 结果 | 缺陷ID | |--------|----------|------|--------| 测试用例集模板 # [模块名称] 测试用例集 ## 概述 - 功能描述：[简要描述] - 测试范围：[测试边界] - 用例总数：X条 ## 测试用例清单 ### 功能1：[功能名称] #### TC-001 [用例标题-正向场景] **优先级** ：P0 **前置条件** ： - 用户已登录 **测试步骤** ： 1. 打开XX页面 2. 输入有效数据：[数据] 3. 点击提交按钮 **预期结果** ： - 提示"操作成功" - 数据正确保存到数据库 --- #### TC-002 [用例标题-反向场景] **优先级** ：P1 **前置条件** ： - 用户已登录 **测试步骤** ： 1. 打开XX页面 2. 不输入必填字段 3. 点击提交按钮 **预期结果** ： - 必填字段显示红色边框 - 提示"请填写必填字段" --- ### 功能2：[功能名称] ... 接口测试用例模板 ## 接口信息 | 项目 | 内容 | |------|------| | 接口名称 | [接口名] | | 请求URL | /api/v1/xxx | | 请求方法 | POST | | Content-Type | application/json | ## 请求参数 | 参数名 | 类型 | 必填 | 说明 | 示例值 | |--------|------|------|------|--------| | userId | string | 是 | 用户ID | "123" | | name | string | 否 | 用户名 | "张三" | ## 测试用例 ### TC-API-001 正常请求 **请求体** ： ```json { "userId": "123", "name": "张三" } 预期响应 ： 状态码：200 响应体： { "code" : 0 , "message" : "success" , "data" : { ... } } TC-API-002 缺少必填参数 请求体 ： { "name" : "张三" } 预期响应 ： 状态码：400 响应体： { "code" : 1001 , "message" : "userId is required" } ### 测试矩阵模板 ```markdown ## 测试矩阵：[功能名称] ### 输入条件 | 条件 | 取值 | |------|------| | 用户类型 | 普通用户/VIP用户/管理员 | | 账户状态 | 正常/冻结/未激活 | | 操作类型 | 查看/编辑/删除 | ### 测试组合 | # | 用户类型 | 账户状态 | 操作 | 预期结果 | |---|----------|----------|------|----------| | 1 | 普通用户 | 正常 | 查看 | 成功 | | 2 | 普通用户 | 正常 | 编辑 | 成功 | | 3 | 普通用户 | 正常 | 删除 | 无权限 | | 4 | 普通用户 | 冻结 | 任意 | 账户已冻结 | | 5 | VIP用户 | 正常 | 查看 | 成功 | | 6 | VIP用户 | 正常 | 编辑 | 成功 | | 7 | VIP用户 | 正常 | 删除 | 成功 | | 8 | 管理员 | 正常 | 任意 | 成功 | 最佳实践 需求追溯 ：每条用例关联需求，确保全覆盖 独立可执行 ：用例之间无依赖，可独立运行 数据驱动 ：分离测试逻辑与测试数据 可维护性 ：用例描述清晰，便于更新维护 评审机制 ：用例编写后需同行评审 持续优化 ：根据缺陷反馈优化用例设计