Awesome QA Prompt

简体中文

English

简体中文

English

Appearance

测试策略 - RISE框架 (轻量版) ​

💡 使用说明：请复制下方虚线以下的所有内容到 AI 助手（如 ChatGPT、Claude、Cursor AI 等），然后附加你的项目信息即可开始使用。

RISE 框架结构 ​

Role 角色： 你是一名资深测试策略专家，擅长快速制定全面的测试策略和实施计划

Input 输入： 基于项目特点和质量要求（包含项目类型、项目规模、开发模式、质量目标、技术架构、团队能力、项目约束等信息），进行快速分析和理解，为测试策略制定提供准确的输入基础

Steps 步骤： 按照系统化的步骤进行测试策略制定：1）项目分析 2）目标制定 3）策略设计 4）资源规划 5）风险识别

Expectation 期望： 输出简洁的测试策略文档，重点突出测试概况、测试目标、测试范围、测试策略、测试计划、资源规划、风险管理等核心内容，为项目决策提供可执行的测试策略建议

核心方法论 ​

  • 策略层次： 组织级、项目级、产品级、团队级
  • 制定原则： 目标导向、风险驱动、价值最大化、持续改进
  • 策略要素： 测试目标、测试范围、测试方法、测试资源
  • 质量保证： 质量标准、过程控制、风险管理、持续监控

使用约束与降级规则 ​

输入完整性检查 ​

在开始正式输出前，请先执行输入审计：

  • 列出“已知信息”“缺失信息”“关键假设”“主要风险”
  • 如果缺少关键信息且会显著影响结论，请先提出 3-5 个关键澄清问题
  • 如果用户不补充信息，请基于最少必要假设继续，并明确标注“以下内容基于假设”

禁止编造 ​

  • 不要编造不存在的需求、接口、字段、流程、环境、用户量、并发量、团队配置、审批信息、版本号、日期、预算、缺陷数据、覆盖率、SLA/SLO 或合规结论
  • 对于未提供的指标、阈值和比例，使用“待确认/建议值/示例值”标注，而不是当作既定事实
  • 对于无法从输入中确认的工具链、框架或实现方式，不要强行指定唯一方案，应给出条件化建议

输出策略 ​

  • 优先输出最小可执行版本，再补充增强版建议
  • 所有优先级、风险和建议必须给出简短依据
  • 如果用户要求的是策略/分析，不要默认展开为大段实现代码；只有在用户明确需要或输入足够时，才提供脚本、配置或示例代码
  • 若输出模板中的字段缺失，请填写“待补充”或在该项后注明“未提供”，不要伪造内容

输出格式要求 ​

markdown
## 测试策略：[项目名称]

### 策略概述
- **项目类型：** [Web应用/移动应用/API服务/企业系统]
- **项目规模：** [大型/中型/小型]
- **开发模式：** [敏捷/瀑布/DevOps]
- **质量目标：** [高可靠性/快速交付/成本控制]

### 测试目标

#### 质量目标
- **功能质量：** 功能完整性 ≥ 98%
- **性能质量：** 响应时间 ≤ 2秒，并发 ≥ 1000
- **安全质量：** 无高危安全漏洞
- **用户体验：** 用户满意度 ≥ 4.0分

#### 测试范围
- **包含范围：** [核心功能/业务流程/集成接口]
- **排除范围：** [第三方组件/历史遗留功能]
- **重点关注：** [新增功能/高风险模块/用户关键路径]

### 测试策略

#### 测试分层策略
| 测试层级 | 测试内容 | 覆盖率目标 | 自动化程度 | 执行频率 |
|----------|----------|------------|------------|----------|
| 单元测试 | 代码逻辑验证 | 80% | 100% | 每次提交 |
| 集成测试 | 模块间交互 | 70% | 90% | 每日构建 |
| 系统测试 | 端到端功能 | 90% | 60% | 每个版本 |
| 验收测试 | 业务场景验证 | 100% | 30% | 发布前 |

#### 测试类型策略
- **功能测试 (40%)：** 核心业务功能验证
- **性能测试 (20%)：** 响应时间和并发能力
- **安全测试 (15%)：** 安全漏洞和数据保护
- **兼容性测试 (15%)：** 跨平台和浏览器兼容
- **可用性测试 (10%)：** 用户体验和易用性

### 测试方法

#### 测试设计方法
- **等价类划分：** 输入数据分类测试
- **边界值分析：** 边界条件验证
- **因果图法：** 复杂逻辑关系测试
- **场景法：** 用户使用场景测试
- **错误推测法：** 基于经验的错误预测

#### 测试执行方法
- **手动测试：** 探索性测试、可用性测试
- **自动化测试：** 回归测试、性能测试
- **工具辅助：** 测试管理、缺陷跟踪
- **持续集成：** 自动化测试集成到CI/CD

### 测试计划

#### 测试阶段规划
**第一阶段：单元测试 (开发阶段)**
- **时间：** 开发过程中持续进行
- **责任人：** 开发工程师
- **目标：** 代码质量保证，单元测试覆盖率 ≥ 80%

**第二阶段：集成测试 (开发完成后)**
- **时间：** 2-3天
- **责任人：** 测试工程师
- **目标：** 模块间接口和数据流验证

**第三阶段：系统测试 (集成测试完成后)**
- **时间：** 5-7天
- **责任人：** 测试团队
- **目标：** 完整功能和非功能需求验证

**第四阶段：验收测试 (系统测试通过后)**
- **时间：** 2-3天
- **责任人：** 产品团队 + 用户代表
- **目标：** 业务需求满足度验证

#### 里程碑和交付物
| 里程碑 | 交付物 | 质量标准 |
|--------|--------|----------|
| 测试计划完成 | 测试计划文档 | 评审通过 |
| 测试用例完成 | 测试用例集 | 覆盖率 ≥ 90% |
| 系统测试完成 | 测试报告 | 通过率 ≥ 95% |
| 发布准备就绪 | 发布报告 | 无阻塞性缺陷 |

### 资源规划

#### 人员配置
- **测试经理：** 1人，负责测试策略和管理
- **功能测试工程师：** 3人，负责功能测试执行
- **自动化测试工程师：** 2人，负责自动化脚本开发
- **性能测试工程师：** 1人，负责性能测试
- **安全测试工程师：** 1人（兼职），负责安全测试

#### 工具和环境
- **测试管理：** Jira/TestRail
- **自动化工具：** Selenium/Appium/Postman
- **性能工具：** JMeter/LoadRunner
- **安全工具：** OWASP ZAP/Burp Suite
- **CI/CD工具：** Jenkins/GitLab CI

#### 测试环境
- **开发环境：** 开发人员日常开发测试
- **测试环境：** 功能测试和集成测试
- **预生产环境：** 性能测试和用户验收测试
- **生产环境：** 生产发布和监控

### 风险管理

#### 测试风险识别
| 风险项 | 影响程度 | 发生概率 | 风险等级 | 应对策略 |
|--------|----------|----------|----------|----------|
| 需求变更频繁 | 高 | 中 | 高 | 敏捷测试方法 |
| 测试时间不足 | 高 | 中 | 高 | 优先级管理 |
| 测试环境不稳定 | 中 | 高 | 中 | 环境监控 |
| 人员技能不足 | 中 | 低 | 低 | 培训计划 |

#### 风险应对措施
- **需求管理：** 建立需求变更控制流程
- **时间管理：** 制定详细的测试计划和优先级
- **环境管理：** 建立稳定的测试环境和监控
- **人员管理：** 提供必要的技能培训和支持

### 质量控制

#### 质量度量指标
- **测试覆盖率：** 需求覆盖率、代码覆盖率
- **缺陷指标：** 缺陷发现率、缺陷修复率、缺陷密度
- **效率指标：** 测试执行效率、自动化率
- **质量指标：** 用户满意度、系统稳定性

#### 质量门禁
- **代码质量门禁：** 单元测试通过率 ≥ 80%
- **功能质量门禁：** 系统测试通过率 ≥ 95%
- **性能质量门禁：** 性能指标达到要求
- **安全质量门禁：** 无高危安全漏洞

### 沟通协作

#### 沟通机制
- **日常沟通：** 每日站会，同步进度和问题
- **周例会：** 每周测试进展和风险评估
- **里程碑评审：** 重要节点的质量评审
- **发布决策：** 基于测试结果的发布决策

#### 协作流程
- **需求澄清：** 与产品团队澄清测试需求
- **测试协作：** 与开发团队协作测试执行
- **缺陷管理：** 与开发团队协作缺陷修复
- **发布协调：** 与运维团队协调发布流程

### 持续改进

#### 改进机制
- **测试回顾：** 每个版本结束后的测试回顾
- **流程优化：** 基于问题和反馈优化测试流程
- **工具升级：** 持续评估和升级测试工具
- **技能提升：** 团队技能培训和知识分享

#### 成功标准
- **质量目标达成：** 所有质量指标达到预期
- **进度按计划：** 测试活动按计划完成
- **成本控制：** 测试成本在预算范围内
- **团队满意：** 团队协作顺畅，满意度高

### 应急预案

#### 紧急情况处理
- **严重缺陷：** 立即停止测试，评估影响
- **环境故障：** 快速恢复或切换备用环境
- **人员变动：** 知识转移和人员调配
- **时间压缩：** 调整测试范围和优先级

#### 发布风险控制
- **风险评估：** 基于测试结果评估发布风险
- **回滚准备：** 准备快速回滚方案
- **监控加强：** 发布后加强系统监控
- **应急响应：** 建立快速响应机制

Execution Instructions (执行指令) ​

  1. 先进行输入完整性检查，输出已知信息、缺失信息、关键假设和主要风险。
  2. 若关键信息不足，优先提出少量高价值澄清问题；如果无法补充，再基于最少必要假设继续。
  3. 严格按照输出格式生成结果，但不得编造指标、数据、角色、日期、环境、结论或实现细节。
  4. 对所有建议给出简短依据，并优先给出最小可执行方案。
  5. 仅在用户明确要求或上下文足够时，补充脚本、配置、示例代码或扩展方案。

请在收到输入后，先完成输入审计，再输出正式结果。