什么是测试计划
测试计划是一份详细的文档，概述了测试工作的策略、目标、资源、时间表和范围。它是整个 QA 阶段的蓝图——回答了谁测试什么、怎么测试、何时测试，以及"完成"的标准是什么。
你可以把测试计划看作是 QA 团队、开发人员和利益相关者之间的契约。它设定了期望、定义了职责，并为测试执行提供了路线图。无论你是测试一个小型网站还是一个大型企业应用，一份好的测试计划都能让所有人保持一致。
本文提供一份免费、可直接复制的测试计划模板，并附有真实案例，让你能在几分钟内创建自己的测试计划。
测试计划模板（可直接复制）
下面是一份全面的测试计划模板。将其复制到你的文档、电子表格或项目管理工具中，然后根据你的项目进行定制。
测试计划
========
### 1. 引言
1.1 目的
[简要描述为什么需要这份测试计划]
1.2 范围
[测试的内容——包括功能、模块、系统]
1.3 范围外
[不测试的内容——要明确说明]
1.4 参考文档
[需求文档、设计规格、用户故事的链接]
### 2. 测试目标
[通过测试想要达到的目标。例如：]
- 验证所有关键业务工作流程功能正常
- 确保跨浏览器兼容性（Chrome、Firefox、Safari、Edge）
- 验证所有 CRUD 操作的数据完整性
- 签收前测试用例通过率达到 95% 以上
### 3. 测试策略
3.1 测试级别
[ ] 单元测试
[ ] 集成测试（SIT）
[ ] 系统测试
[ ] 用户验收测试（UAT）
3.2 测试类型
[ ] 功能测试
[ ] 回归测试
[ ] 性能测试
[ ] 安全测试
[ ] 可用性测试
[ ] 无障碍测试
3.3 测试环境
- 预发布 URL：[https://staging.example.com]
- 数据库：[PostgreSQL 15，预发布副本]
- 浏览器目标：[Chrome 125+、Firefox 125+、Safari 17+、Edge 125+]
- 移动端目标：[iOS 17+、Android 14+]
- 测试工具：[BugCapturer、Lighthouse、axe DevTools]
### 4. 测试交付物
[ ] 测试计划文档（本文档）
[ ] 测试用例规格说明
[ ] 测试数据（虚拟账户、示例内容）
[ ] Bug 报告（执行过程中记录）
[ ] 测试执行报告（通过/失败汇总）
[ ] UAT 签收文档
### 5. 测试时间表
| 阶段 | 开始日期 | 结束日期 | 时长 |
|------|----------|----------|------|
| 测试规划 | [日期] | [日期] | [X 天] |
| 测试用例准备 | [日期] | [日期] | [X 天] |
| 测试执行（第一轮） | [日期] | [日期] | [X 天] |
| Bug 修复 | [日期] | [日期] | [X 天] |
| 测试执行（第二轮） | [日期] | [日期] | [X 天] |
| UAT | [日期] | [日期] | [X 天] |
| 签收 | [日期] | [日期] | [X 天] |
### 6. 角色与职责
| 角色 | 姓名 | 职责 |
|------|------|------|
| 测试经理 | [姓名] | 规划、协调、报告 |
| QA 工程师 | [姓名] | 编写测试用例、执行测试、记录 Bug |
| 开发人员 | [姓名] | 修复 Bug、支持排查 |
| 产品负责人 | [姓名] | 定义验收标准、UAT 签收 |
| UAT 参与者 | [姓名] | 执行 UAT 场景 |
### 7. 测试用例汇总
| 模块 | 总测试用例 | 自动化率 | 优先级 |
|------|-----------|---------|--------|
| 用户注册 | [XX] | [X%] | 高 |
| 登录/认证 | [XX] | [X%] | 高 |
| 结账 | [XX] | [X%] | 严重 |
| 搜索 | [XX] | [X%] | 中 |
| 管理后台 | [XX] | [X%] | 低 |
### 8. Bug 跟踪流程
1. 测试人员发现 Bug
2. 测试人员记录 Bug 报告，包含：
- 截图或录屏（带标注）
- 复现步骤
- 环境信息（URL、浏览器、操作系统）
- 期望结果 vs 实际结果
3. 测试经理分类并分配优先级
4. 开发人员修复 Bug
5. 测试人员验证修复
6. Bug 关闭
推荐工具：BugCapturer 用于一键生成 Bug 报告，
自动捕获元数据和标注截图。
### 9. 进入与退出标准
9.1 进入标准（测试开始前必须满足的条件）
[ ] 所有关键功能已开发完成
[ ] 预发布环境稳定
[ ] 测试数据已准备就绪
[ ] 测试用例已审查和批准
9.2 退出标准（测试结束前必须满足的条件）
[ ] 所有严重和高级别 Bug 已修复
[ ] 95% 的测试用例已通过
[ ] UAT 已由利益相关者签收
[ ] 性能目标已达成
### 10. 风险与应对
| 风险 | 影响 | 概率 | 应对措施 |
|------|------|------|----------|
| 预发布环境不稳定 | 高 | 中 | 准备回滚计划、备用环境 |
| 第三方 API 变更 | 中 | 中 | 尽早模拟外部服务 |
| UAT 参与者可用性有限 | 高 | 低 | 招募备用测试人员、延长 UAT 窗口 |
| 范围蔓延 | 中 | 高 | 测试开始前冻结需求 |
### 11. 审批
| 角色 | 姓名 | 签名 | 日期 |
|------|------|------|------|
| 测试经理 | [姓名] | | |
| 项目经理 | [姓名] | | |
| 产品负责人 | [姓名] | | |
测试计划示例
下面是一个电商网站上线的填充示例：
项目： AcmeShop.com v2.0 上线 测试经理： 王明 时间线： 4 周（2 周执行 + 1 周 Bug 修复 + 1 周 UAT）
范围：
- 用户注册、登录、密码重置
- 商品浏览、搜索、筛选
- 购物车和结账
- 订单历史与跟踪
- 管理后台订单管理
- 支付网关集成（Stripe）
范围外：
- 第三方库存管理系统（独立供应商）
- 旧版 v1.0 迁移数据验证
- 超过 1,000 并发用户的负载测试
测试用例汇总：
- 总计：245 个测试用例（85 个自动化，160 个手动）
- 模块：认证（32）、商品（48）、购物车（55）、结账（70）、管理后台（40）
- 预期通过率：UAT 前 95%，上线前 98%
关键风险：
- Stripe API 沙箱与生产环境行为不同——通过增加边界情况测试用例来缓解
- UAT 参与者是销售团队成员，可用性有限——招募了 10 名参与者，目标 5 名活跃
Bug 跟踪：
- 所有 Bug 报告使用 BugCapturer
- 严重 Bug：4 小时内修复，立即重测
- 高级 Bug：24 小时内修复，当天重测
- 中级 Bug：上线前修复
- 低级 Bug：上线后待办
测试计划示例：关键部分详解
测试目标
这是最重要的部分。它回答了"我们为什么要测试？"好的目标是具体且可衡量的：- ❌ "全面测试网站"
- ✅ "验证所有 20 个结账流程在 Chrome、Firefox、Safari 和 Edge 上无错误完成"
进入和退出标准
进入标准防止浪费精力（不要在损坏的构建上开始测试）。退出标准防止过早签收（不要在严重 Bug 仍然存在时就说测试完成了）。Bug 跟踪流程
清晰的 Bug 跟踪流程对于顺畅的测试执行阶段至关重要。Bug 报告得越快，修复得越快。在测试执行期间使用像 BugCapturer 这样的工具可以加速反馈循环：- 截图标注——测试人员可以直接在页面上用箭头、矩形和文字高亮问题
- 自动技术元数据——URL、浏览器、操作系统、屏幕分辨率和视口尺寸自动捕获
- 屏幕录制——录制 Bug 发生时的短视频（WebM 格式），然后裁剪并提取关键帧
- 诊断数据收集——控制台错误和失败的网络请求随视觉证据一起捕获
- Excel/TSV 导出——一键复制结构化 Bug 报告行到剪贴板，用于团队跟踪
如何创建测试计划
第 1 步：了解项目
阅读需求，与利益相关者沟通，了解正在构建什么。测试计划的质量取决于你对项目的理解程度。第 2 步：定义范围
明确说明哪些在范围内，哪些不在。模糊的范围是测试计划争议的头号原因。第 3 步：选择策略
确定哪些测试级别和类型适用于你的项目。小型营销网站需要的测试与银行应用不同。第 4 步：估算资源和时间表
使用以前项目的历史数据。如果没有历史数据，在估算中增加 30% 的缓冲。第 5 步：编写计划
使用上面的模板。从模板开始，然后进行定制。不要从头开始写。第 6 步：获取审批
没有人签收的测试计划就是没有人会遵守的测试计划。获得项目经理和产品负责人的书面批准。下载：测试计划模板
上面的模板适用于任何格式：
- Google Docs / Word——使用章节结构作为正式文档
- Confluence / Notion——创建一个测试计划页面，每个部分作为子页面
- Excel / Google Sheets——作为电子表格使用，每个阶段一个标签页
- Markdown——保存在代码仓库中进行版本控制
选择你的团队使用的格式。格式比内容次要——简单文档中的好测试计划胜过花哨工具中的坏测试计划。