AI赋能软件测试之生成功能测试用例

AI技术的普及为软件测试行业带来了新的生产力工具。对测试人员而言,善用AI生成功能测试用例,能够有效压缩基础用例的编写时间,从而将更多精力聚焦于用例评审与质量分析。这种从“编写”到“评审”的工作模式优化,是提升项目整体测试质量的关键一环。

环境条件说明

AI-IDEA:TRAE v3.3.36

Model:MiniMax M2.5

编写规则文件

可以通过制定规则来规范 AI 在 TRAE 内的行为,包括代码风格、语言与框架、交互方式等,使 AI 的输出更符合你的个人偏好和项目要求

编写规则能够让AI交互规范过程更符合个人日常测试习惯亦或者团队规范化,其中个人规则适用于所有项目,项目规则仅适用于当前项目

规则可以是手动编写,也可以通过ai对话去生成你需要的规则(推荐)

config.jpg

以下是我习惯使用的个人规则:

【基本信息】
- 身份:软件测试工程师
- 操作系统:Windows
- 语言:始终使用中文回答(包括术语解释,必要时可附加英文原文)

【回答风格】
- 回答结构清晰,优先使用分点或步骤说明。
- 在涉及技术操作时,给出具体示例或代码片段(适用于 Windows 环境)。
- 如果问题与软件测试相关,请从测试工程师的视角补充测试要点、注意事项或潜在风险。

【格式偏好】
- 使用 Markdown 格式,代码块标明语言。
- 列表、表格有助于提升可读性。

【其他】
- 避免使用过于口语化或不正式的表述。
- 如果问题需要较长篇幅,请先给出摘要或结论。

生成产品需求设计规则

产品需求文档的严谨性,直接决定了AI生成测试用例的质量。为规避因需求表述模糊导致的测试用例缺陷,测试人员应该建立标准化的需求评审规则。此举不仅是保障产品质量的关键防线,更是实现AI高效、精准生成测试用例的必要前提。

AI-Prompt:

生成一份用于针对产品模块级别需求文档设计的规则,要求格式为markdown,内容严谨逻辑正确,符合软件产品设计的规范准则,规则生成完检查一下规则是否存在漏洞或者注意事项

经过多次修改后得到的规则文件:

# 产品需求文档(PRD)设计规则

> **适用说明**:本规则适用于模块级别的产品需求文档设计

## 1. 文档概述

### 1.1 目的与范围

| 要素 | 说明 |
|------|------|
| 文档目的 | 明确模块需求定义,为设计、开发、测试提供统一的需求基准 |
| 适用范围 | 适用于产品功能模块的需求管理 |
| 目标读者 | 产品经理、开发人员、测试工程师、项目经理、UI/UX设计师 |

### 1.2 术语定义

- **PRD**:Product Requirements Document,产品需求文档
- **MVP**:Minimum Viable Product,最小可行产品
- **UML**:Unified Modeling Language,统一建模语言

### 1.3 模块信息

| 要素 | 说明 |
|------|------|
| 模块名称 | [模块名称] |
| 所属产品 | [所属产品名称] |
| 模块版本 | [版本号] |

---

## 2. 文档结构规范

### 2.1 必要章节

模块级PRD文档应包含以下核心章节:

```
1. 文档概述
   ├── 1.1 目的与范围
   ├── 1.2 术语定义
   └── 1.3 模块信息

2. 模块概述
   ├── 2.1 模块定位
   ├── 2.2 模块目标
   └── 2.3 与其他模块的关系

3. 用户需求
   ├── 3.1 用户故事
   └── 3.2 用户场景

4. 功能需求
   ├── 4.1 功能列表
   ├── 4.2 功能详细描述
   └── 4.3 业务流程

5. 非功能需求
   ├── 5.1 性能要求
   ├── 5.2 安全性要求
   ├── 5.3 兼容性要求
   └── 5.4 可用性要求

6. 数据需求
   ├── 6.1 数据模型
   ├── 6.2 数据字典
   └── 6.3 数据流

7. 约束与假设
   ├── 7.1 技术约束
   ├── 7.2 业务约束
   └── 7.3 假设条件

8. 风险与依赖
   ├── 8.1 项目风险
   └── 8.2 依赖项

9. 评审与变更
   ├── 9.1 评审规则
   ├── 9.2 变更规则
   └── 9.3 需求追踪

10. 验收标准
    ├── 10.1 验收条件
    └── 10.2 验收流程

11. 注意事项
    ├── 11.1 常见遗漏项
    ├── 11.2 常见逻辑错误
    └── 11.3 质量检查清单
```

### 2.2 版本控制

| 版本号 | 日期 | 修改人 | 修改说明 |
|--------|------|--------|----------|
| V1.0.0 | YYYY-MM-DD | 修改人 | 初始版本 |

---

## 3. 需求描述规范

### 3.1 功能需求描述规则

#### 3.1.1 功能命名规范

- 功能名称应使用动宾短语,如「用户登录」「订单创建」
- 保持命名的一致性,同一功能在文档各处使用相同名称

#### 3.1.2 功能描述模板

```markdown
### 功能编号:F-XXX

**功能名称**:[功能名称]

**功能描述**:[简要说明功能的目的和作用]

**前置条件**:
- 条件1
- 条件2

**后置条件**:
- 结果1
- 结果2

**业务流程**:
1. 步骤1
2. 步骤2
3. 步骤3

**业务规则**:
- 规则1
- 规则2

**验收标准**:
- [ ] 标准1
- [ ] 标准2

**优先级**:P0/P1/P2/P3

**所属子模块**:XXX子模块
```

#### 3.1.3 优先级定义

| 优先级 | 定义 | 说明 |
|--------|------|------|
| P0 | 阻塞 | 必须实现,否则模块无法上线 |
| P1 | 高 | 重要功能,影响核心业务流程 |
| P2 | 中 | 重要但非关键功能 |
| P3 | 低 | 锦上添花功能,可后续迭代 |

### 3.2 用户故事规范

#### 3.2.1 用户故事模板

```
作为 [角色],我希望 [功能],以便 [收益]

验收标准:
- [ ] 标准1
- [ ] 标准2
```

#### 3.2.2 用户故事示例

```
作为注册用户,我希望通过手机验证码登录,以便快速安全地进入系统

验收标准:
- [ ] 用户输入有效手机号后可接收验证码
- [ ] 验证码有效期为5分钟
- [ ] 验证码输入错误3次后账户被锁定30分钟
- [ ] 登录成功后跳转至首页
```

---

## 4. 业务流程规范

### 4.1 流程图绘制规则

- 使用标准UML活动图或流程图符号
- 流程图应包含:开始/结束节点、活动节点、决策节点、流程线
- 流程图应有清晰的标题和图例
- 异常流程必须标注

### 4.2 流程描述要求

- 主流程:描述正常业务流程
- 备选流程:描述替代或分支流程
- 异常流程:描述错误处理和边界情况

### 4.3 流程图示例结构

```
┌─────────────┐
│   开始      │
└──────┬──────┘
       ▼
┌─────────────┐
│  用户输入   │──────┐
└──────┬──────┘      │
       ▼             ▼
  ┌───────┐    ┌──────────┐
  │验证通过│    │验证失败  │
  └──┬────┘    └─────┬────┘
     ▼              ▼
┌─────────┐    ┌─────────┐
│ 执行操作 │    │ 提示错误 │
└────┬────┘    └────┬────┘
     └──────┬───────┘
            ▼
     ┌─────────────┐
     │    结束     │
     └─────────────┘
```

---

## 5. 非功能需求规范

### 5.1 性能要求

| 指标 | 要求 | 说明 |
|------|------|------|
| 响应时间 | ≤3秒 | 常规操作 |
| 响应时间 | ≤5秒 | 复杂查询 |
| 并发用户 | ≥1000 | 峰值并发 |
| 系统可用性 | ≥99.9% | 月度可用率 |

### 5.2 安全性要求

- 用户密码必须加密存储,使用不可逆加密算法
- 敏感数据传输必须使用HTTPS加密
- 必须实现身份认证和权限控制机制
- 必须记录关键操作日志
- 必须防范SQL注入、XSS等常见安全攻击

### 5.3 兼容性要求

| 类型 | 要求 |
|------|------|
| 浏览器兼容 | Chrome、Firefox、Safari、Edge 最新版本 |
| 移动端兼容 | iOS 12+、Android 8+ |
| 后向兼容 | 新版本应兼容上一版本数据 |

### 5.4 可用性要求

- 关键功能必须提供用户引导和帮助文档
- 错误信息必须清晰明确,指导用户如何操作
- 必须支持键盘快捷键操作
- 必须考虑无障碍访问(WCAG 2.1 AA标准)

---

## 6. 数据需求规范

### 6.1 数据模型要求

- 必须包含实体关系图(ER图)
- 必须说明实体属性、数据类型、约束条件
- 必须标注主键和外键关系

### 6.2 数据字典模板

| 字段名 | 字段中文名 | 数据类型 | 长度 | 约束 | 说明 |
|--------|------------|----------|------|------|------|
| user_id | 用户ID | VARCHAR | 32 | PK | 系统生成唯一标识 |
| username | 用户名 | VARCHAR | 50 | NN,UQ | 登录账号 |
| password | 密码 | VARCHAR | 128 | NN | 加密存储 |
| created_at | 创建时间 | DATETIME | - | NN | 创建时自动生成 |

### 6.3 数据约束说明

| 约束类型 | 说明 |
|----------|------|
| NN | Not Null,非空 |
| PK | Primary Key,主键 |
| FK | Foreign Key,外键 |
| UQ | Unique,唯一 |
| CK | Check,检查约束 |
| Default | 默认值 |

---

## 7. 评审与变更规范

### 7.1 评审规则

- 必须经过产品内部评审
- 必须邀请技术、测试、设计相关人员参与评审
- 评审发现的问题必须记录并跟踪解决
- 评审通过后必须相关干系人签字确认

### 7.2 变更规则

- 需求变更必须提交变更申请
- 变更申请必须包含:变更原因、变更内容、影响范围
- 重大变更必须经过评审和审批
- 变更必须更新文档版本号和版本记录

### 7.3 需求追踪矩阵

| 需求ID | 需求描述 | 来源 | 优先级 | 状态 | 对应功能 | 测试用例 |
|--------|----------|------|--------|------|----------|----------|
| REQ-001 | 用户登录功能 | 用户访谈 | P0 | 已实现 | F-001 | TC-001 |

---

## 8. 验收标准规范

### 8.1 验收条件

- 所有P0优先级需求必须100%实现
- P1优先级需求实现率应≥90%
- 所有已实现功能必须通过测试

### 8.2 验收流程

```
需求确认 → 开发实现 → 测试验证 → UAT验收 → 产品上线
```

### 8.3 验收文档要求

- 必须包含功能验收清单
- 必须记录验收过程中的问题
- 必须有验收结论和签字

---

## 9. 注意事项与常见漏洞

### 9.1 常见遗漏项

1. **边界条件未明确**:未说明最大值、最小值、空值等边界情况
2. **异常流程缺失**:只描述正常流程,忽略异常处理
3. **权限定义模糊**:未明确不同角色的功能权限
4. **性能指标缺失**:未定义响应时间、并发数等性能要求
5. **数据迁移忽视**:未考虑新旧系统数据兼容问题

### 9.2 常见逻辑错误

1. **需求自相矛盾**:不同章节的需求描述不一致
2. **前置条件缺失**:功能依赖关系未说明
3. **假设条件未验证**:基于未确认的假设进行设计
4. **用户故事与功能脱节**:用户故事未转化为可实现的功能需求

### 9.3 质量检查清单

- [ ] 文档结构完整,所有必要章节齐全
- [ ] 需求描述清晰,无歧义
- [ ] 功能优先级定义明确
- [ ] 业务流程图完整
- [ ] 数据字典字段完整
- [ ] 非功能需求指标明确
- [ ] 验收标准可测试
- [ ] 术语定义统一
- [ ] 版本记录完整

### 9.4 补充注意事项

#### 9.4.1 模块级文档特殊要点

| 维度 | 说明 |
|------|------|
| 模块定位 | 明确本模块在产品中的角色和价值 |
| 模块边界 | 明确模块的功能边界和职责范围 |
| 模块依赖 | 明确与其他模块的依赖关系和数据交互 |
| 模块接口 | 定义与其他模块的内部接口和调用方式 |

#### 9.4.2 测试工程师注意事项

1. **需求可测试性**:所有需求必须可验证,避免使用模糊词汇如「支持」「优化」「良好」
2. **验收标准量化**:数值类需求必须明确具体指标,如「响应时间≤200ms」而非「响应快速」
3. **边界值测试**:需求中应明确最大/最小值、超时时间、次数限制等边界条件
4. **兼容性覆盖**:明确支持的系统版本、浏览器版本范围
5. **异常场景覆盖**:错误提示、权限不足、网络异常等场景的预期行为
6. **数据一致性**:明确数据创建、修改、删除后的数据状态和影响范围
7. **模块集成测试**:明确模块间交互的测试场景和预期结果

#### 9.4.3 与开发协同要点

1. **技术可行性确认**:复杂需求需提前与技术团队确认实现方案
2. **模块依赖梳理**:明确模块间的依赖关系和调用顺序
3. **数据库设计评审**:涉及数据存储变更时需DBA参与评审
4. **性能基准定义**:与开发确认性能指标的可实现性
5. **接口定义确认**:明确模块间接口的参数和返回值定义

需求文档AI重新设计

为消除产品文档自身缺陷对测试工作的影响,我们可以借助AI的力量对需求源头进行治理。通过建立标准化的需求设计规则,并利用AI对原始文档进行一致性校验与优化重构,能够有效提升产品需求表达的清晰度与完整性。一份经过AI“洗礼”的产品文档,将更利于后续测试用例的自动生成,从而确保AI辅助测试的效能得以充分发挥。

AI-Prompt:

#产品需求设计规则.md #需求文档.md 根据现有的产品文档内容和产品需求设计规则,生成一份新的需求文档并命名为需求文档(新).md

文件范例附件如下:

需求文档.md

需求文档(新).md

生成测试用例设计规则

测试用例设计规则可以是自己编写,也可以是让AI生成符合自己需要的

AI-Prompt:

生成一份用于功能测试用例设计的规则,要求格式为markdown,内容支持生成csv格式的测试用例文件,用例设计并结合常见的测试用例设计方法,规则生成完毕后检查一下规则是否存在漏洞或者注意事项

经过多次修改后得到的规则文件:

# 功能测试用例设计规则

## 一、测试用例基本信息

### 1.1 测试用例CSV格式规范

| 字段名称 | 字段说明 | 是否必填 | 数据类型 | 示例 |
|---------|---------|---------|---------|------|
| 用例编号 | 用例的唯一标识符 | 是 | 字符串 | TC_001 |
| 用例名称 | 用例的描述性名称 | 是 | 字符串 | 验证用户登录成功 |
| 用例级别 | 用例的重要程度 | 是 | 枚举 | P0/P1/P2/P3 |
| 前置条件 | 执行用例前需要满足的条件 | 是 | 字符串 | 用户已注册且未登录 |
| 测试步骤 | 包含操作步骤和测试数据 | 是 | 字符串 | 1.打开登录页面 2.输入用户名testuser密码Pass123 3.点击登录按钮 |
| 预期结果 | 期望的系统行为 | 是 | 字符串 | 登录成功,跳转至首页 |
| 实际结果 | 实际执行后的系统行为 | 是 | 字符串 | - |
| 用例状态 | 用例的执行状态 | 否 | 枚举 | 未执行/通过/失败/阻塞 |
| 备注 | 其他补充说明 | 否 | 字符串 | - |

### 1.2 用例级别定义

| 级别 | 说明 |
|-----|------|
| P0 | 核心功能冒烟测试 |
| P1 | 主要功能正向路径 |
| P2 | 次要功能及边界条件 |
| P3 | 异常场景及用户界面 |

---

## 二、测试用例设计方法

### 2.1 等价类划分法

**定义**:将输入数据分成若干等价类,从每个等价类中选取少量代表性数据进行测试。

**应用规则**:
- 有效等价类:符合需求规格的输入数据集合
- 无效等价类:不符合需求的输入数据集合
- 每至少选取一个有效值和一个无效值进行测试

**CSV输出示例**:
```csv
用例编号,用例名称,用例级别,前置条件,测试步骤,预期结果,实际结果,用例状态,备注
TC_002,验证年龄输入有效范围,P2,无,"1.打开注册页面 2.输入年龄18 3.点击提交","年龄验证通过",,未执行,有效等价类
TC_003,验证年龄超出上限,P2,无,"1.打开注册页面 2.输入年龄150 3.点击提交","提示年龄超出范围",,未执行,无效等价类
TC_004,验证年龄低于下限,P2,无,"1.打开注册页面 2.输入年龄0 3.点击提交","提示年龄不符合要求",,未执行,无效等价类
```

### 2.2 边界值分析法

**定义**:针对输入或输出的边界值进行测试,通常选取边界值及边界值附近的数据。

**应用规则**:
- 选取最小值(min)、最小值-1(min-1)
- 选取最大值(max)、最大值+1(max+1)
- 选取典型值(正常值)
- 边界值通常与等价类结合使用

**CSV输出示例**:
```csv
用例编号,用例名称,用例级别,前置条件,测试步骤,预期结果,实际结果,用例状态,备注
TC_005,验证用户名长度最小边界,P2,无,"1.打开注册页面 2.输入用户名1个字符 3.点击提交","用户名长度符合要求",,未执行,最小边界
TC_006,验证用户名长度最小边界-1,P2,无,"1.打开注册页面 2.输入用户名0个字符 3.点击提交","提示用户名长度不足",,未执行,min-1
TC_007,验证用户名长度最大边界,P2,无,"1.打开注册页面 2.输入用户名20个字符 3.点击提交","用户名长度符合要求",,未执行,max边界
TC_008,验证用户名长度最大边界+1,P2,无,"1.打开注册页面 2.输入用户名21个字符 3.点击提交","提示用户名长度超限",,未执行,max+1
```

### 2.3 判定表法

**定义**:通过分析输入条件的组合及其对应的输出结果,设计测试用例。

**应用规则**:
- 列出所有输入条件
- 列出所有输出结果
- 列出所有条件组合
- 合并相似的输出结果
- 生成测试用例覆盖每种组合

**CSV输出示例**:
```csv
用例编号,用例名称,用例级别,前置条件,测试步骤,预期结果,实际结果,用例状态,备注
TC_009,验证VIP会员享折扣且积分翻倍,P1,无,"1.选择商品A 2.选择VIP会员 3.确认积分翻倍","折扣生效且积分翻倍",,未执行,条件组合1
TC_010,验证非VIP无折扣但积分正常,P1,无,"1.选择商品A 2.选择普通会员 3.确认积分正常","无折扣但积分正常",,未执行,条件组合2
```

### 2.4 场景法

**定义**:通过分析用户使用场景,设计覆盖主要场景和备选场景的测试用例。

**应用规则**:
- 绘制业务流程图
- 识别基本流(主流程)
- 识别备选流(分支流程)
- 识别异常流(错误处理)
- 基本流每个场景至少一个用例

**CSV输出示例**:
```csv
用例编号,用例名称,用例级别,前置条件,测试步骤,预期结果,实际结果,用例状态,备注
TC_011,验证正常购物全流程,P0,商品A有库存10件,"1.浏览商品A(库存10) 2.加入购物车 3.提交订单 4.支付成功","订单创建成功",,未执行,基本流
TC_012,验证库存不足场景,P1,商品A库存为0,"1.浏览商品A(库存0) 2.加入购物车 3.提交订单","提示库存不足",,未执行,备选流
TC_013,验证支付失败场景,P1,支付方式异常,"1.浏览商品A 2.加入购物车 3.提交订单 4.支付失败(支付方式异常)","提示支付失败",,未执行,异常流
```

### 2.5 正交试验法

**定义**:使用正交表选取代表性组合进行测试,减少测试用例数量。

**应用规则**:
- 确定因素(输入变量)和水平(取值)
- 选择合适的正交表
- 根据正交表生成测试用例
- 补充重要组合的测试用例

**CSV输出示例**:
```csv
用例编号,用例名称,用例级别,前置条件,测试步骤,预期结果,实际结果,用例状态,备注
TC_014,验证浏览器操作系统组合测试1,P2,各环境可用,"1.在Chrome浏览器+Windows系统环境 2.访问网站","页面正常显示",,未执行,正交组合1
TC_015,验证浏览器操作系统组合测试2,P2,各环境可用,"1.在Firefox浏览器+Windows系统环境 2.访问网站","页面正常显示",,未执行,正交组合2
```

### 2.6 错误推测法

**定义**:基于经验和直觉,预测可能存在的错误,设计针对性的测试用例。

**应用规则**:
- 参考历史缺陷数据
- 分析类似系统的常见问题
- 考虑特殊输入值
- 考虑并发/竞态条件
- 考虑数据边界情况

### 2.7 状态转换法

**定义**:将系统视为有限状态机,通过测试状态转换路径来设计测试用例。

**应用规则**:
- 绘制状态图,明确所有状态及状态间转换
- 识别所有有效状态转换
- 识别无效状态转换
- 覆盖所有状态节点
- 覆盖所有转换路径

**CSV输出示例**:
```csv
用例编号,用例名称,用例级别,前置条件,测试步骤,预期结果,实际结果,用例状态,备注
TC_016,验证订单状态正常流转,P1,订单ORDER001状态为待支付,"1.订单ORDER001(待支付) 2.用户完成支付","订单状态变为已支付",,未执行,状态转换
TC_017,验证订单状态异常流转,P2,订单ORDER002状态为已完成,"1.订单ORDER002(已完成) 2.用户申请取消订单","提示无法取消",,未执行,无效转换
TC_018,验证订单状态逆向流转,P2,订单ORDER003状态为已发货,"1.订单ORDER003(已发货) 2.用户申请退款","订单状态变为退款中",,未执行,逆向转换
```

---

## 三、用例设计通用规则

### 3.1 用例编写原则

| 原则 | 说明 | 示例 |
|-----|------|------|
| 独立性 | 每个用例应独立执行,不依赖其他用例的执行结果 | 使用独立测试数据,避免用例间数据依赖 |
| 可重复性 | 用例可以多次重复执行,结果一致 | 前置条件明确,数据固定 |
| 可验证性 | 用例执行结果可明确判断通过/失败 | 预期结果具体明确 |
| 完整性 | 覆盖正向、负向、边界、异常场景 | 不仅测试正常流程,也要测试异常流程 |
| 简洁性 | 用例描述清晰,避免冗余 | 步骤清晰,预期结果明确 |

### 3.2 测试步骤与测试数据设计规则

由于测试数据已合并至测试步骤字段中,设计测试步骤时应包含具体的测试数据值。

**数值类数据**:
- 有效值:正常范围中间值
- 边界值:最小值、最大值
- 无效值:小于最小值、大于最大值、空值、特殊字符

**字符串类数据**:
- 有效值:正常长度字符串
- 边界值:最小长度、最大长度
- 无效值:空字符串、超长字符串、特殊字符、SQL注入、XSS

**日期类数据**:
- 有效值:当前日期、过去日期、未来日期
- 边界值:月份起始/结束日期、闰年2月29日
- 无效值:无效月份、无效日期、格式错误

### 3.3 风险项与注意事项

#### 3.3.1 测试数据相关风险

| 风险项 | 说明 | 规避措施 |
|-------|------|---------|
| 测试数据污染 | 用例执行后数据未清理,影响后续执行 | 每个用例使用唯一标识的数据,或提供数据初始化脚本 |
| 测试数据不足 | 测试数据覆盖不全,遗漏边界条件和异常场景 | 遵循等价类划分和边界值分析原则,确保覆盖各类数据 |
| 测试数据泄露 | 生产环境数据未经脱敏处理用于测试 | 对敏感数据进行脱敏处理,如姓名、手机号、身份证号等 |
| 测试数据状态 | 测试数据状态不符合前置条件要求 | 在前置条件中明确数据状态,必要时先进行数据准备 |

#### 3.3.2 环境与配置相关风险

| 风险项 | 说明 | 规避措施 |
|-------|------|---------|
| 环境依赖 | 用例依赖特定环境配置,不同环境结果不一致 | 明确前置条件,环境配置标准化,记录环境版本信息 |
| 配置差异 | 测试环境与生产环境配置差异导致缺陷遗漏 | 定期对比测试环境与生产环境配置差异 |
| 网络不稳定 | 网络波动导致用例执行失败 | 添加重试机制,区分网络异常与功能缺陷 |
| 第三方服务 | 依赖第三方接口,接口不稳定影响用例执行 | 记录第三方服务状态,必要时使用Mock服务 |

#### 3.3.3 用例设计相关风险

| 风险项 | 说明 | 规避措施 |
|-------|------|---------|
| 数据关联 | 用例间存在数据依赖关系,执行顺序影响结果 | 明确前置条件,避免用例间依赖,保持用例独立性 |
| 权限问题 | 缺少必要权限导致用例无法执行 | 前置条件中明确权限要求 |
| 并发问题 | 多个用例同时执行产生数据冲突 | 设计可并发执行的用例,或串行执行关键用例 |
| 逻辑遗漏 | 测试步骤或预期结果考虑不全 | 使用多种用例设计方法组合,覆盖基本流、备选流、异常流 |
| 断言不足 | 预期结果描述模糊,难以准确判断通过失败 | 预期结果应具体可量化,明确验证点和阈值 |

#### 3.3.4 执行与维护相关风险

| 风险项 | 说明 | 规避措施 |
|-------|------|---------|
| 用例过时 | 需求变更后用例未及时更新 | 建立用例维护机制,与需求变更同步更新 |
| 执行效率 | 用例数量庞大,执行时间过长 | 根据用例级别合理规划执行策略,优先执行P0/P1用例 |
| 结果误判 | 实际结果记录不准确,导致缺陷遗漏 | 实际结果应如实记录,必要时附上截图或日志 |
| 可重现性 | 用例执行结果不可重现,难以定位问题 | 记录执行环境、版本、时间等上下文信息 |

### 3.4 常见功能测试点检查清单

**用户界面(UI)测试**:
- [ ] 页面布局是否符合设计稿
- [ ] 文字、图标、颜色是否正确
- [ ] 响应式布局是否正常(桌面/平板/手机)
- [ ] 页面加载时间是否在可接受范围

**输入验证测试**:
- [ ] 必填项是否进行了非空校验
- [ ] 输入格式是否符合要求(邮箱、手机号、日期等)
- [ ] 输入长度是否有限制
- [ ] 特殊字符是否正确处理

**功能流程测试**:
- [ ] 所有功能路径是否可正常执行
- [ ] 业务流程是否正确
- [ ] 数据是否正确保存和显示
- [ ] 状态变更是否符合预期

**异常处理测试**:
- [ ] 网络异常时是否有友好提示
- [ ] 系统错误时是否有错误页面
- [ ] 空数据时界面是否正常显示
- [ ] 权限不足时是否有适当提示

**数据完整性测试**:
- [ ] 数据保存后是否正确持久化
- [ ] 数据删除后是否真正删除
- [ ] 数据修改后是否正确更新
- [ ] 关联数据是否同步处理

**兼容性测试**:
- [ ] 不同浏览器(Chrome/Firefox/Edge/Safari)是否正常显示
- [ ] 不同操作系统(Windows/macOS/Linux)功能是否正常
- [ ] 不同屏幕分辨率下布局是否正常
- [ ] 不同移动设备(iOS/Android)功能是否正常
- [ ] 向前兼容旧版本数据格式

---

## 四、CSV用例生成模板

### 4.1 基础模板

```csv
用例编号,用例名称,用例级别,前置条件,测试步骤,预期结果,实际结果,用例状态,备注
```

### 4.2 完整示例

```csv
用例编号,用例名称,用例级别,前置条件,测试步骤,预期结果,实际结果,用例状态,备注
TC_001,验证用户登录成功,P0,用户已注册,"1.打开登录页面 2.输入用户名testuser密码Pass123 3.点击登录按钮","登录成功;跳转至首页;显示用户名",,未执行,
TC_002,验证用户登录密码错误,P1,用户已注册,"1.打开登录页面 2.输入用户名testuser密码wrongpass 3.点击登录按钮","提示密码错误",,未执行,
TC_003,验证用户登录用户名为空,P2,无,"1.打开登录页面 2.不输入用户名直接点击登录按钮","提示用户名不能为空",,未执行,
TC_004,验证用户登录密码为空,P2,无,"1.打开登录页面 2.输入用户名testuser不输入密码 3.点击登录按钮","提示密码不能为空",,未执行,
TC_005,验证登录页面SQL注入,P2,无,"1.打开登录页面 2.输入特殊字符作为用户名testuser' or '1'='1 3.输入任意密码 4.点击登录按钮","提示登录失败",,未执行,安全测试
```

---

## 附录:常用测试数据参考值

### 用户名
- 有效:字母数字组合3-20位,如 `testuser01`
- 无效:空字符串、特殊字符、超长

### 密码
- 有效:6-20位字母数字组合,如 `Pass123`
- 无效:空字符串、过短、过简单

### 邮箱
- 有效:`user@example.com`
- 无效:格式错误、缺少@、缺少域名

### 手机号
- 有效:11位数字,如 `13800138000`
- 无效:位数不足、包含字母、超长

---

## 附录二:CSV格式使用注意事项

| 注意事项 | 说明 | 示例 |
|---------|------|------|
| 字段分隔符 | 测试步骤内部使用空格分隔多个步骤 | "1.打开登录页面 2.输入用户名密码 3.点击登录" |
| 字段值含逗号 | 如字段值包含逗号,需用双引号包裹 | "预期结果:登录成功;跳转到首页" |
| 字段值含引号 | 字段值中的引号需要转义处理 | "测试步骤:输入用户名test'user" |
| 编码格式 | 建议使用UTF-8编码,避免中文乱码 | - |
| 换行处理 | 字段值内的换行需替换为指定字符或移除 | 将换行替换为空格 |

生成功能测试用例

AI-Prompt:

#需求文档(新).md #测试用例设计规则.md 根据现有的需求文档和测试用例设计规则,生成一份新的测试用例文件,文件路径为./testcases/testcase.csv

文件范例附件如下:

需求文档(新).md

testcase.csv

评论