---
type: testing
keywords: [测试, 验证, 检验, test, 质量保证, qa, 单元测试, 集成测试, 性能测试, 自动化测试]
priority: medium
---

# 测试项目配置

本配置用于各类测试项目，包括功能测试、性能测试、安全测试等。

## 模板路径
templates/testing_template.md

## 核心问题配置

### 问题 1：测试对象

```yaml
question: "需要测试哪个功能或系统？"
type: "text"
prompt: "请描述测试对象，包括功能名称、版本等"
```

---

### 问题 2：测试类型

```yaml
question: "主要测试什么方面？（可多选，或在'其他'中详细描述；需要帮助请输入'需要帮助'）"
options:
  - label: "功能是否正常工作"
    description: "验证功能符合预期"
  - label: "系统性能和速度"
    description: "检查响应时间、承载能力"
  - label: "安全性和数据保护"
    description: "检查是否有安全漏洞"
  - label: "多个功能协同工作"
    description: "验证各模块集成后的表现"
multiSelect: true
```

---

### 问题 3：测试范围

```yaml
question: "需要测试哪些具体场景？"
type: "text"
prompt: |
  请列出关键的测试场景，比如：
  - 用户登录
  - 创建订单
  - 查询历史记录
  - 边界情况（极端输入）
  - 异常情况（网络中断、数据错误等）
```

---

### 问题 4：测试数据

```yaml
question: "测试时需要使用什么数据？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
options:
  - label: "使用真实数据"
    description: "从生产环境或实际业务获取"
  - label: "使用模拟数据"
    description: "自己构造测试数据"
  - label: "两者都需要"
    description: "生产数据 + 模拟数据"
```

---

### 问题 5：测试方式

```yaml
question: "测试是手动进行还是自动化？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
options:
  - label: "手动测试就够了"
    description: "人工操作和检查"
  - label: "希望自动化执行"
    description: "写脚本自动运行测试"
  - label: "部分自动化，部分手动"
    description: "混合模式"
```

---

### 问题 6：性能指标（如涉及性能测试）

```yaml
question: "如果测试性能，什么样的表现算合格？"
type: "text"
prompt: |
  比如：
  - "页面加载时间不超过 2 秒"
  - "支持 100 人同时使用不卡顿"
  - "处理 10000 条数据在 1 分钟内完成"
```

---

### 问题 7：验收标准

```yaml
question: "怎样才算测试通过？"
type: "text"
prompt: |
  请列出具体的通过标准，比如：
  - "所有核心功能无报错"
  - "性能指标达标"
  - "安全扫描无高危漏洞"
  - "覆盖率达到 80%"
```

---

### 问题 8：测试环境

```yaml
question: "在什么环境下进行测试？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
options:
  - label: "开发环境（自己电脑）"
    description: "本地开发环境"
  - label: "专门的测试环境"
    description: "独立测试环境"
  - label: "接近真实的生产环境"
    description: "预生产环境"
```

---

## 通用映射规则

```yaml
# 测试类型 → 测试策略
test_type_mapping:
  "功能测试":
    approach: "测试用例设计"
    tools: ["手动测试", "Selenium", "Cypress", "Playwright"]
    metrics: ["功能覆盖率", "缺陷密度"]

  "性能测试":
    approach: "压力测试 + 监控"
    tools: ["JMeter", "Locust", "k6"]
    metrics: ["响应时间", "吞吐量", "资源占用"]

  "安全测试":
    approach: "漏洞扫描 + 渗透测试"
    tools: ["OWASP ZAP", "Burp Suite", "SonarQube"]
    metrics: ["漏洞数量", "安全评级"]

  "集成测试":
    approach: "接口测试 + 数据验证"
    tools: ["Postman", "pytest", "Jest"]
    metrics: ["接口覆盖率", "数据一致性"]

# 自动化程度 → 实现方式
automation_mapping:
  "手动测试":
    tools: "测试用例文档"
    efficiency: "low"
    cost: "人力成本高"

  "自动化测试":
    tools: "测试框架 + CI/CD"
    efficiency: "high"
    cost: "初期投入高，长期收益大"

  "混合模式":
    tools: "自动化框架 + 手动补充"
    efficiency: "medium"
    best_for: "核心流程自动化，边界场景手动"

# 测试环境 → 准备工作
environment_mapping:
  "本地开发环境":
    setup: "最简单"
    reality: "与生产差异大"
    suitable_for: "单元测试、快速验证"

  "独立测试环境":
    setup: "中等复杂度"
    reality: "接近生产"
    suitable_for: "集成测试、功能测试"

  "预生产环境":
    setup: "复杂"
    reality: "几乎等同生产"
    suitable_for: "性能测试、上线前验证"
```

## 文档结构建议

```markdown
# {功能/系统名称}测试 - 需求文档

## 1. 测试概述
- 测试对象
- 测试背景
- 测试目标

## 2. 测试类型与范围
- 测试类型（功能/性能/安全/集成等）
- 测试范围（包含和排除的部分）
- 测试深度

## 3. 测试场景
- 正常场景
- 异常场景
- 边界场景
- 用户故事/测试用例

## 4. 测试数据
- 数据来源
- 数据量级
- 数据准备方式
- 隐私保护要求

## 5. 测试环境
- 环境配置
- 依赖服务
- 测试工具

## 6. 测试方式
- 自动化策略
- 测试框架和工具
- CI/CD 集成

## 7. 性能指标（如适用）
- 响应时间要求
- 吞吐量要求
- 并发要求
- 资源限制

## 8. 验收标准
- 通过标准
- 覆盖率要求
- 缺陷标准
- 性能基线

## 9. 测试计划
- 测试阶段
- 时间安排
- 人员分工

## 10. 交付物
- 测试报告
- 测试用例
- 自动化脚本
- 缺陷列表
```

## 特殊场景处理

### 性能测试项目
额外关注：
- 性能基线建立
- 压力测试策略（阶梯式/持续/峰值）
- 瓶颈分析工具
- 监控和报警

### 安全测试项目
额外关注：
- OWASP Top 10
- 常见漏洞类型
- 合规要求（等保、PCI-DSS 等）
- 渗透测试授权

### 自动化测试项目
额外关注：
- 测试框架选择
- 测试代码架构
- CI/CD 集成
- 维护成本

### 兼容性测试项目
额外关注：
- 浏览器/设备矩阵
- 操作系统版本
- 第三方依赖版本
- 向后兼容性

## 选项设计规范

### 互斥性原则

**单选问题**（multiSelect: false）：
- ✅ 选项应完全互斥，无重叠
- ✅ 边界清晰，用户能明确判断属于哪一个
- ❌ 避免数量范围重叠（如"1-10人"和"5-20人"）
- ❌ 避免概念包含关系

**多选问题**（multiSelect: true）：
- ✅ 选项可从不同角度切分，允许合理组合
- ✅ 每个选项应代表独立的需求维度
- ❌ 避免选项之间有逻辑依赖

### 维度统一原则

同一问题的所有选项应属于同一分类维度。

❌ **错误示例**（维度混乱）：
```yaml
question: "用户如何使用这个工具?"
options:
  - 输入问题主动调用    # 维度：触发方式
  - 命令行/编程接口      # 维度：交互界面
  - Web界面             # 维度：交互界面
multiSelect: false
```

✅ **正确做法**：拆分为两个问题，或统一到同一维度

### 边界清晰原则

**数量范围**：避免重叠，如"个人使用（1-5人）"、"小团队（6-50人）"
**概念分类**：确保平级，避免包含关系

### 完备性检查

- 2-4个选项应覆盖**80%的常见场景**
- 长尾场景通过"其他"覆盖
- 当不确定时，优先设计偏通用的选项+依赖"其他"