第五篇：测试、部署与成果交付¶

从“能演示”到“可验证、可部署、可复现”¶

第四篇完成后，你的项目已经具备主要页面、接口和核心业务流程，能够在开发环境中演示。但“自己电脑上能跑”还不等于项目已经完成：别人能否按说明启动？核心流程是否经得起测试？修复问题后有没有破坏其他功能？系统重启后数据是否正确？教师怎样验证你的成果？

第五篇将把项目从一个可以演示的开发版本，整理为一个可以测试、部署、交付和复现的 v1.0 版本。

本篇核心任务

用测试证明项目是否满足需求；用部署证明项目能离开 IDE 独立运行；用 README、脚本、文档和 Git 标签，让他人能够理解、启动和验证你的成果。

一、你现在处于什么阶段¶

完成第四篇后，项目通常处于 v0.5：主要功能已实现，但仍可能存在如下情况：

✅ 能在 IDEA / VS Code 中启动
✅ 能演示主要页面和部分流程
✅ 有初步的数据库与接口

⚠️ 还没有系统测试核心流程、异常和权限
⚠️ 发现问题后没有形成缺陷与回归记录
⚠️ 配置、账号和数据库初始化依赖个人电脑
⚠️ Docker、README 或部署说明无法保证他人复现
⚠️ 没有一个明确、可定位的最终交付版本

本篇结束后，你应形成：

✅ 核心功能、权限和业务流程有测试证据
✅ 关键缺陷已修复并完成回归验证
✅ 数据库、配置、端口和启动方式已整理
✅ 本机 Docker 环境可访问，不依赖 IDE
✅ README、测试报告、部署说明和交付清单完整
✅ Git 中存在可定位的 v1.0 版本标签

二、本篇学习目标¶

完成本篇后，你应能够：

从需求、业务规则、角色权限和状态流程中提取测试点；
编写可执行的测试用例，验证正常、异常、边界和越权场景；
将失败现象记录为可复现、可追踪的缺陷；
按影响优先修复问题，并完成原用例与关联场景回归；
分离开发与部署配置，准备数据库初始化、备份和恢复材料；
使用 Docker Compose 启动项目服务，并排查日志、网络和数据问题；
通过 README、测试报告、部署记录和 Git 标签完成 v1.0 交付。

三、学习路线与小节目录¶

明确测试范围
→ 编写并执行测试
→ 记录缺陷、修复并回归
→ 整理部署配置与数据
→ Docker 部署并验证核心流程
→ 汇总材料，创建 v1.0 版本

小节	核心问题	阶段成果
5.1 制定测试计划	测什么、谁来测、怎样判定通过？	测试范围、测试环境、测试计划与优先级
5.2 编写并执行测试	如何覆盖核心功能、角色、异常与边界？	测试用例、接口测试记录、功能测试证据
5.3 管理缺陷并回归	发现问题后如何记录、修复并确认没有引入新问题？	缺陷清单、修复记录、回归测试结果
5.4 完成部署准备	配置、数据库、端口、环境变量和启动方式是否清楚？	部署清单、配置模板、初始化与恢复材料
5.5 部署验证	如何在不依赖 IDE 的情况下运行并验证系统？	Docker 部署记录、可访问系统、核心流程证据
5.6 整理交付	怎样让他人快速运行、理解和评价项目？	README、测试报告、交付清单、`v1.0` 标签

四、测试不是“把所有按钮点一遍”¶

测试的目标是验证项目是否满足已经确认的需求和业务规则，而不是随机操作页面。

至少应验证四类场景¶

场景	要回答的问题	示例
正常场景	用户按正确步骤操作，能否完成任务？	正确账号登录后成功提交申请
异常场景	参数错误或条件不满足时，系统是否正确拒绝？	名额已满时不能重复报名
权限场景	未登录或无权用户是否被拒绝？	普通用户不能调用管理员删除接口
边界场景	空值、重复、极限数据或非法状态是否正确处理？	重复提交不会产生两条记录

优先测试核心流程

时间有限时，先验证登录、角色权限、核心业务流程、数据正确性和部署后的访问；不要先把大量时间花在边缘样式问题上。

五、两条技术路线的部署目标¶

课程提供不同技术路线，部署验证的目标一致：不用 IDE 运行时，项目仍然可以访问并完成核心流程。

路线	本地开发方式	本篇最低部署验证
Spring Boot + Vue 3	Maven + Node.js / Vite	Docker Compose 启动 MySQL、后端、前端/Nginx
Servlet + HTML + CSS + JS	IDEA + smart-tomcat + Tomcat 11	Docker 运行 MySQL、Tomcat WAR、Nginx（如使用）
自选技术栈	按项目实际技术实现	提供等价的可复现启动方式、配置说明和测试证据

Docker 是最低建议，不是唯一答案

如果你的项目因技术条件无法使用 Docker，也可以使用等价方案完成本机或局域网部署。但必须做到：启动步骤清楚、配置可替换、数据库可初始化、浏览器可访问、核心流程已验证。

六、本篇最低交付标准¶

1. 代码与配置¶

项目可以从当前 Git 提交构建或启动；
数据库可以通过初始化 SQL 或迁移脚本准备；
真实密码、密钥、Token 和私有配置未提交到仓库；
README 中的环境、配置与启动步骤已经实际验证；
代码中没有依赖个人电脑的绝对路径或硬编码开发地址。

2. 测试与质量¶

有测试计划与核心功能测试用例；
已验证登录、核心业务流程、异常处理和角色权限；
失败项已记录为缺陷，P0 问题已修复；
修复后完成原用例和关联场景回归；
测试结果、证据和已知限制如实记录。

3. 部署与交付¶

不依赖 IDE，可在本机或局域网环境启动项目；
浏览器能够访问系统，部署环境完成一次核心流程；
有部署说明、访问地址和测试账号；
README、测试报告、部署记录和项目文档已整理；
当前交付代码已创建 v1.0 Git 标签。

七、本篇建议建立的项目文档结构¶

建议将过程材料放入项目仓库，便于与代码版本对应：

project/
├── README.md
├── sql/
│   ├── init.sql
│   └── migration/                  # 如使用迁移工具
├── deploy/
│   ├── docker-compose.yml
│   ├── .env.example
│   └── nginx/
├── api/
│   └── project.postman_collection.json
├── docs/
│   ├── 01-需求分析说明书.md
│   ├── 02-系统设计说明书.md
│   ├── 03-测试报告.md
│   ├── 04-项目README.md
│   └── testing/
│       ├── 测试计划.md
│       ├── 测试用例与执行记录.md
│       ├── 缺陷清单.md
│       ├── 回归测试记录.md
│       └── 部署验证记录.md
└── deployment-evidence/            # 按课程要求决定是否提交截图/日志

目录不必机械照搬，但应确保需求、设计、测试、部署、代码和版本之间能够相互追溯。

八、AI 在本篇中的正确角色¶

AI 可以帮助你：

根据需求和业务规则补充测试点；
检查测试用例、缺陷记录或 README 是否缺少必要字段；
分析日志、堆栈、接口响应和可能根因；
给出最小修改方案与建议回归范围；
生成 Docker、Nginx、环境变量模板的初稿；
检查 README 启动步骤是否完整、表达是否清楚。

但 AI 不能替代你完成：

实际运行测试、观察页面和接口结果；
判断数据库是否被错误修改；
验证 Docker 容器是否真实启动并可访问；
确认核心流程和权限是否在部署环境通过；
虚构截图、日志、测试结果、访问地址或项目贡献。

不能把 AI 生成的文字当作测试证据

测试结论必须来自真实执行。没有运行过的用例不能标记为“通过”，没有部署过的系统不能写成“已上线”。

九、开始前准备¶

进入 5.1 前，请确认：

第四篇核心功能已基本完成；
至少存在一条能够演示的核心业务流程；
项目可以在开发环境启动；
已有用于测试的角色账号和基础数据；
已将当前代码提交到 Git，记录测试开始时的基线提交；
准备好浏览器开发者工具与 Apifox/Postman（如使用接口测试）；
接受“发现问题并记录”是本篇正常成果，而不是失败。

本篇小结¶

第五篇的重点不是新增更多功能，而是证明已有成果值得交付：

测试确保功能正确，缺陷管理确保问题可追踪，部署确保项目可运行，README 和版本标签确保成果可复现。

完成本篇后，你将拥有一个不只“能在课堂上演示”，而且能够被他人启动、验证和评价的课程项目 v1.0。

开始学习：5.1 制定测试计划返回第四篇：项目开发与业务实现