5.1 制定测试计划：明确范围、环境与优先级¶

不要等到项目“差不多完成”才开始随便点一点¶

测试计划不是一张形式表格

第四篇的集成验收已经证明项目能够连续演示，但这不等于全部功能、异常情况和权限规则都经过了系统验证。

测试计划要回答：这个版本测什么、暂时不测什么、怎样测、谁来测、什么结果算通过、发现问题后怎样处理。 先有计划，后面编写测试用例、记录缺陷和部署验证才不会遗漏重点。

本节学习目标

基于需求分析说明书、系统设计说明书和 v0.5 集成版本，确定测试基线、测试范围、测试环境、测试数据、优先级与通过标准，完成一份可以实际执行的《测试计划》。

🎯 本节完成后，你要交付¶

成果	要求
测试基线	明确本次测试对应的需求、设计、代码分支或提交版本
测试范围	列出必测功能、核心流程、权限、异常与边界；同时写明暂不测试内容
测试环境说明	记录系统版本、数据库、浏览器、访问地址、部署方式和测试账号
测试数据方案	说明初始化数据、专用测试数据和数据恢复方式
测试优先级	区分阻断、核心、高优先级和一般优化问题
通过标准	写清每一类测试怎样算通过，哪些问题必须修复
《测试计划》	一份后续可以据此编写测试用例并执行的计划文档

本节不要求马上把全部问题修完

本节的重点是设计可执行的测试工作。发现问题可以先记录；下一节再通过测试用例获取证据，后续小节再修复并进行回归验证。

一、先理解：测试计划、测试用例和测试报告有什么不同¶

很多同学会把三者混在一起。它们分别解决不同问题：

文档	主要问题	编写时机	典型内容
测试计划	为什么测、测什么、怎样组织？	测试开始前	范围、环境、人员、优先级、通过标准、风险
测试用例	某个功能具体怎样操作和判断？	执行测试前或执行中	前置条件、步骤、预期结果、实际结果
缺陷记录	发现了什么问题，怎样复现和处理？	发现问题后	现象、影响、严重程度、复现步骤、状态
测试报告	最后测了什么、结果怎样、还有什么风险？	测试结束后	覆盖情况、通过率、缺陷统计、结论

可以把它们理解为：

测试计划
→ 决定要验证哪些内容、怎样安排
→ 测试用例
→ 逐项执行并保存证据
→ 缺陷记录
→ 修复、回归并记录结果
→ 测试报告
→ 说明系统是否达到交付条件

课程项目的测试重点

课程项目不要求进行大型商业系统的全量性能压测或安全渗透测试，但必须验证：项目能启动、核心流程能闭环、权限不能绕过、异常有明确处理、部署后仍可运行。

二、第一步：冻结本次测试基线¶

测试必须对应一个明确版本。否则今天测的是一套代码，明天修复时又混入新功能，测试结果就无法说明问题。

在《测试计划》开头记录：

项目名称：【填写】
测试版本：【例如 v0.5 / main 分支 / 提交编号】
测试日期：【填写】
测试人员：【填写】
需求基线：《需求分析说明书》V【填写】
设计基线：《系统设计说明书》V【填写】
代码仓库：【填写地址】
技术路线：【Spring Boot + Vue / Servlet + HTML + CSS + JS / 其他】
部署方式：【本机运行 / Docker / 局域网 / 云服务器】

1. 记录代码版本¶

在开始测试前执行：

git status
git log --oneline -5

确认：

当前工作区没有忘记提交的关键代码；
测试版本能够通过分支、标签或提交编号定位；
需求、设计、数据库脚本和代码属于同一阶段；
测试期间不随意合并无关功能；
修复问题后会产生新的提交，便于回归测试。

2. 建议创建测试分支或版本标签¶

个人项目至少在 README 或测试计划中写清提交编号；条件允许时，可建立测试分支或标签：

# 为准备测试的阶段版本打标签
git tag -a v0.5 -m "完成集成验收，进入系统测试"

# 查看标签
git tag

不要测试“脑海中的版本”

如果不能说清当前测试的是哪一个版本，就无法判断某个问题是否已经修复，也无法在部署后复现测试结果。

三、第二步：从需求中提取测试范围¶

测试范围不能只按页面菜单罗列。应从用户、功能、业务规则、权限、状态和验收条件出发，确保测试能够回答“需求是否真正实现”。

1. 先确定必测范围¶

课程项目建议至少覆盖以下六类内容：

范围	必须回答的问题	示例
启动与基础能力	系统能否安装、启动、连接数据库？	初始化脚本能否执行、首页能否打开
身份认证	用户能否正确注册、登录、退出？	错误密码是否拒绝、登录过期如何处理
核心功能	每个必做功能是否完成？	新增、查询、修改、删除、分页
核心业务流程	多角色能否连续完成业务闭环？	学生报修 → 管理员分配 → 维修处理 → 学生确认
规则与状态	非法操作是否被拒绝且数据不被错误修改？	名额已满不能报名、已取消记录不能再次确认
权限与数据范围	用户能否只访问自己有权操作的数据？	普通用户不能调用管理员接口

2. 使用“需求—测试点”对应表¶

把《需求分析说明书》中的必做需求逐项列入。每条需求至少有一个测试点，不能只写“已测试”。

需求编号	需求或规则	用户角色	测试点	优先级	证据类型
FR-01	用户可以使用账号密码登录	所有用户	正确密码成功、错误密码失败、未登录访问限制	P0	页面截图、接口响应
FR-02	用户可以提交【业务对象】	普通用户	必填校验、正常提交、重复提交	P0	页面、数据库记录
BR-03	【状态】后不可重复操作	普通用户/管理员	再次操作被拒绝，数据不变	P0	接口响应、数据库查询
PR-01	管理员才能维护【业务对象】	管理员	普通用户页面与接口均被拒绝	P0	403/401 响应
FR-04	支持条件查询和分页	所有用户	空条件、组合条件、首页、末页、空结果	P1	页面、接口响应

优先级建议：

优先级	含义	处理要求
P0	阻断启动、登录、核心流程、数据正确性或权限安全	必须测试；发现问题必须修复后才能交付
P1	重要功能和常用异常场景	必须测试；严重问题应修复或明确说明限制
P2	体验优化、非核心页面、低频边界	尽量测试；可以放入后续优化清单

先测 P0，再测 P1

如果项目无法登录、核心流程无法闭环或普通用户能修改管理员数据，页面颜色、动画和排版再好也不能算可交付。

四、第三步：围绕核心流程设计测试场景¶

单个 CRUD 功能通过，不代表业务流程正确。对第四篇已经完成的核心闭环，应从开始到结束设计场景。

示例：活动报名系统¶

管理员发布活动
→ 学生查看活动
→ 学生报名
→ 系统检查名额和重复报名
→ 管理员查看报名名单
→ 学生查看报名结果

可提取的测试场景：

场景	前置条件	关键验证点	预期结果
正常报名	活动已发布且有剩余名额	页面、接口、数据库记录、名额变化	报名成功，名单可见，剩余名额减少
重复报名	当前学生已报名	业务规则和数据一致性	操作被拒绝，名额不再减少
名额已满	剩余名额为 0	边界状态	操作被拒绝，给出明确提示
未登录报名	未登录	登录权限	被要求登录，不能写入报名记录
普通用户发布活动	普通用户登录	管理员权限	页面入口隐藏且接口拒绝

核心流程测试问题清单¶

针对自己的项目逐一回答：

核心流程由哪些角色依次完成？
每一步需要哪些前置数据和状态？
成功后哪些表、字段或统计值发生变化？
失败时是否会留下半完成数据？
重复点击或重复请求会怎样？
切换到下一角色后，是否能看到正确任务或结果？
使用不同账号是否会发生越权访问？
重新启动或部署后，流程是否还能完成？

五、第四步：明确暂不测试的内容¶

“范围有限”不是逃避测试，而是明确课程项目的测试边界，防止做出无法证明的承诺。

可以在计划中写：

本次不包含的测试：
- 高并发压测和百万级数据性能验证；
- 第三方支付真实扣款；
- 正式生产环境的渗透测试；
- 未适配的旧版本浏览器；
- 需求文档中明确列为后续版本的功能；
- 不具备测试账号或测试环境的外部服务。

处理方式：
- 在 README 或已知限制中说明；
- 不将“未测试”写成“已支持”；
- 如确实依赖外部服务，使用模拟数据或明确降级方案。

不能把“没有测”写成“没有问题”

例如没有做并发测试，就不能宣称系统支持高并发；没有接入真实支付，就不能在演示中说支付功能已上线。

六、第五步：准备测试环境和账号¶

测试环境要尽量接近最终交付环境，并且能够重复恢复。

1. 环境记录表¶

项目	实际值	说明
操作系统	【填写】	Windows / macOS / Linux
JDK / Node / Tomcat 版本	【填写】	按所选技术路线填写
数据库版本	【填写】	例如 MySQL 8.x
浏览器	【填写】	建议 Chrome 或 Edge 最新版
启动方式	【填写】	IDEA、命令行、Docker Compose 等
前端访问地址	【填写】	例如 `http://localhost:5173`
后端或应用地址	【填写】	例如 `http://localhost:8080`
数据库初始化方式	【填写】	SQL 脚本、Flyway、迁移命令
代码版本	【填写】	分支、标签或提交编号

2. 测试账号至少覆盖角色差异¶

角色	账号	用途	是否可重置
管理员	【填写】	发布、审核、维护、统计等管理操作	是 / 否
普通用户	【填写】	提交、查询、查看个人记录	是 / 否
其他业务角色	【填写】	处理、确认、配送、维修等	是 / 否
未登录状态	不登录	验证受限页面和接口	不适用

不要使用个人真实密码、手机号、邮箱和身份证信息作为测试数据。

3. 测试数据应具备可控状态¶

准备数据时，不要只放几条“看起来正常”的记录。至少准备：

一条可以顺利走完整流程的正常数据；
一条处于中间状态、等待下一角色处理的数据；
一条已经完成或取消的数据，用于验证非法状态操作；
一条属于其他用户的数据，用于验证数据权限；
空列表、最大值或接近上限的数据，用于边界场景；
可以通过 SQL 或迁移脚本恢复的初始数据。

测试后要能恢复

核心流程测试会改变状态。请记录如何重新导入 SQL、清理测试记录或恢复数据库快照，否则后续测试无法重复执行。

七、第六步：定义通过标准和停止条件¶

测试计划不只写“测一测”，还要规定何时可以进入部署和交付。

1. 最低通过标准¶

以下内容建议设为交付前必须满足：

2. 停止测试与返回开发的条件¶

遇到下面情况，不要继续“完成更多测试数量”，而应优先回到开发阶段：

情况	建议处理
项目无法启动或连接数据库	记录为阻断缺陷，修复环境或配置后重新开始冒烟测试
登录不可用	停止后续受限功能测试，优先修复认证链路
核心流程中断	停止扩展功能测试，先定位流程、状态或数据问题
普通用户可调用管理员接口	视为严重权限问题，优先修复后回归
每次测试都需手改数据库	补充页面/接口/脚本，形成可重复流程
需求或设计本身互相矛盾	返回第三篇修订文档，不在代码中临时猜测规则

八、第七步：安排测试执行顺序¶

建议按风险从高到低执行，而不是从菜单第一个页面一路点到最后。

1. 启动与数据库连接
→ 2. 登录、退出与身份识别
→ 3. 核心流程正常路径
→ 4. 核心流程失败与状态边界
→ 5. 权限与数据范围
→ 6. 重要列表、查询、分页和表单校验
→ 7. 特色功能与降级方案
→ 8. 非核心页面和体验优化
→ 9. 部署后重复核心流程

九、填写《测试计划》模板¶

将以下内容复制到项目的 docs/03-测试报告.md 或单独创建 docs/测试计划.md，按项目实际情况填写。

# 【项目名称】测试计划

## 1. 基本信息

| 项目 | 内容 |
| :--- | :--- |
| 测试版本 | 【分支 / 标签 / 提交编号】 |
| 测试日期 | 【填写】 |
| 测试人员 | 【填写】 |
| 需求基线 | 《需求分析说明书》V【填写】 |
| 设计基线 | 《系统设计说明书》V【填写】 |
| 技术路线 | 【填写】 |
| 部署方式 | 【本机 / Docker / 局域网 / 云服务器】 |

## 2. 测试目标

【本次测试重点验证系统的哪些核心能力，例如：登录权限、活动报名核心流程、管理员审核、重复报名限制和部署后访问。】

## 3. 测试范围

### 3.1 必测内容

| 编号 | 功能或规则 | 角色 | 测试点 | 优先级 |
| :--- | :--- | :--- | :--- | :--- |
| T-01 | 【填写】 | 【填写】 | 【填写】 | P0 / P1 / P2 |
| T-02 | 【填写】 | 【填写】 | 【填写】 | P0 / P1 / P2 |

### 3.2 暂不测试内容

- 【填写，并说明原因】

## 4. 测试环境

| 项目 | 实际值 |
| :--- | :--- |
| 操作系统 | 【填写】 |
| 开发或运行环境 | 【填写】 |
| 数据库 | 【填写】 |
| 浏览器 | 【填写】 |
| 启动方式 | 【填写】 |
| 系统访问地址 | 【填写】 |
| 代码版本 | 【填写】 |

## 5. 测试账号与数据

| 角色 | 账号 | 用途 | 初始数据或状态 |
| :--- | :--- | :--- | :--- |
| 管理员 | 【填写】 | 【填写】 | 【填写】 |
| 普通用户 | 【填写】 | 【填写】 | 【填写】 |

数据恢复方式：【SQL 脚本 / 迁移脚本 / 其他】

## 6. 测试策略与顺序

1. 【填写】
2. 【填写】
3. 【填写】

## 7. 通过标准

- 【填写】
- 【填写】

## 8. 风险与应对

| 风险 | 影响 | 应对方式 |
| :--- | :--- | :--- |
| 【填写】 | 【填写】 | 【填写】 |

十、提交前自查¶

本节小结¶

测试计划的价值不在于文档写得多，而在于让后面的测试有明确重点：

先确认版本和范围 → 从需求提取测试点 → 优先验证核心流程与权限 → 准备可重复的环境和数据 → 定义通过标准 → 按风险执行测试。

完成本节后，不要直接宣布项目“没有问题”。下一节将把测试计划拆成可执行的测试用例，实际操作系统、记录结果并保存证据。

下一节：5.2 执行测试：功能、接口与核心流程返回第四篇：项目开发与业务实现

角色	主要工作
开发者本人	准备环境、修复问题、执行接口与数据库验证
同学体验者	按测试步骤操作页面，记录难理解、找不到入口和提示不清的问题
教师或助教	抽查核心流程、需求覆盖和项目真实性
AI 助手	协助从需求提取测试点、生成初稿、检查遗漏；不能虚构测试结果