跳转至

1.5 测试与部署：让图书管理系统真正可用

代码写完之后，才是项目交付的开始

为什么功能看起来能用，仍然不能算完成

你在浏览器里点了一次“借阅成功”，并不代表系统已经可靠：接口参数可能有问题，普通用户可能仍能访问管理功能，重复点击可能让库存变成负数，换一台电脑也可能无法启动。

  • 接口测试：确认前后端通信和业务规则是否正确；
  • 界面测试：确认用户能否按照真实流程完成操作；
  • 部署验证：确认系统不是只能在开发环境运行；
  • 测试报告：记录证据，说明你测了什么、发现了什么、结果如何。

只有“能运行、能验证、能说明”的项目，才是可以展示的项目。

本节学习目标

导入 Postman 集合完成 API 测试，使用浏览器完成界面功能测试，填写测试报告，并将系统打包部署到 Tomcat。

🎯 本节要交付什么

完成本节后，你至少应拥有以下成果：

成果 说明
已执行的 Postman 测试 已导入集合，并保存关键接口的请求和响应证据
已完成的 Web 功能检查 用户端与管理端主流程均经过浏览器实际操作
已填写的测试报告 记录实际结果、缺陷和测试结论
可部署的 WAR 包 通过 Maven 构建，并部署到 Tomcat
可访问的系统 在部署地址完成一次登录、查询和借阅验证

不能运行、没有测试证据的功能，不算完成

不要只把 AI 的文字回复、代码截图或“构建成功”当成结果。测试必须有真实请求、页面操作、日志或截图等可复查证据。

🧭 先确定测试依据和顺序

本节基于图书管理系统模板中的现有资料开展测试：

资料 用途
需求分析说明书 确认功能、业务规则和验收标准
系统设计说明书 确认接口、权限、数据库与部署设计
Postman 测试集合 提供 API 测试请求模板
测试报告模板 记录测试过程、结果和缺陷

推荐按照下面的顺序推进：

启动环境 → API 测试 → 浏览器界面测试 → 修复问题 → 回归测试 → 填写测试报告 → 打包部署 → 部署后验证

测试前先对齐文档和实现

如果接口路径、字段名或业务规则与文档不同，不要直接修改测试用例来“迁就代码”。先确认是实现偏离了需求设计，还是设计确实需要调整；然后同步修改代码或文档，并记录原因。

📦 第一步：准备测试环境

测试前，先确认本地环境已正常工作：

项目 推荐环境
JDK 17 或更高版本
Maven 3.8 或更高版本
Web 服务器 Tomcat 11 或更高版本
数据库 MySQL 8.0 或更高版本
浏览器 Chrome 或 Edge
API 测试工具 Postman

启动前检查：

  1. 数据库已创建，表结构和测试数据已准备完成；
  2. src/main/resources/db.properties 中的数据库连接信息与实际环境一致；
  3. 项目已部署到 Tomcat，应用上下文为 /book；
  4. 浏览器能打开 http://localhost:8080/book/user/login.html；
  5. 已准备管理员账号与一个普通测试账号。

先记录初始状态

在改动或测试前，记录数据库名、访问地址、部署上下文、测试账号和当前已知问题。遇到异常时，这些信息能帮助你和 AI 快速复现问题。

🔌 第二步：导入 Postman 集合并配置环境

模板已提供 Postman 集合文件：

1
doc/A-校园图书管理系统.postman_collection.json

在 Postman 中按以下步骤操作：

  1. 点击 Import（导入），选择上述 JSON 文件；
  2. 创建环境，名称设为 A-校园图书管理系统；
  3. 配置环境变量；
  4. 选择该环境，再执行集合中的请求。

环境变量

变量名 初始值 说明
ip localhost Tomcat 所在服务器地址
port 8080 Tomcat 端口
context /book 项目部署上下文
baseUrl http://{{ip}}:{{port}}{{context}} 接口基础地址
bookId 选择一本可借图书的 ID 用于图书与借阅接口
recordId 选择一条借阅中的记录 ID 用于借阅记录相关接口

请求地址一般写为：

1
{{baseUrl}}/api/...

登录顺序不能跳过

系统使用 Session 保存登录状态。先调用登录接口，再测试需要登录的用户接口或管理员接口。切换普通用户与管理员时，先退出登录或清除 Postman 中旧的 Cookie，避免把前一次 Session 当成当前测试结果。

🧪 第三步：按业务流程完成 API 测试

不要随机点击请求。按真实用户路径测试，才能发现前后功能之间的问题。

顺序 测试模块 关键检查
1 认证 注册、正确登录、错误密码、退出与 Session 状态
2 个人中心 查询资料、修改邮箱、修改密码
3 图书查询 列表、详情、书名/作者/ISBN 搜索、分类筛选
4 图书借阅 借阅资格、创建记录、库存减少、当前借阅查询
5 图书归还 只能归还本人未归还记录、状态更新、库存恢复
6 管理端 图书、用户、借阅记录管理及权限校验

借阅模块必须覆盖的业务规则

借阅是本项目的核心流程。至少验证以下情况：

场景 预期结果
可借图书，正常用户 创建借阅记录，可借复本数减 1
已借满 5 本 拒绝借阅，并给出明确提示
有超期未还记录 拒绝借阅，并提示先归还超期图书
可借复本数为 0 不创建记录，不减少库存
重复点击借阅 不产生重复记录或错误库存
正常归还 记录状态变为已归还，可借复本数加 1
重复归还 拒绝操作，不重复增加库存

API 测试时如何判断通过

接口返回不只看 HTTP 状态码，还要检查响应体内容：

1
2
3
4
5
{
  "code": 200,
  "message": "操作成功",
  "data": {}
}

检查时关注：

  • code 是否符合预期；
  • message 是否能说明成功或失败原因；
  • data 是否包含正确字段和数据；
  • 写操作后，相关查询和数据库数据是否同步变化；
  • 无权限或未登录请求是否被正确阻止。

可以在 Postman 的 Tests 标签中加入简单断言：

1
2
3
4
5
6
7
8
pm.test("返回内容是 JSON", function () {
    pm.response.to.be.json;
});

pm.test("业务处理成功", function () {
    const result = pm.response.json();
    pm.expect(result.code).to.eql(200);
});

失败用例和成功用例同样重要

测试“能借书”只能说明主流程可能可用；测试“无库存不能借”“普通用户不能访问管理接口”“重复归还不增加库存”，才能证明业务规则真正被实现。

🖥️ 第四步：在浏览器中测试真实页面

API 正确不代表页面一定可用。启动 Tomcat 后，在浏览器中完成用户端和管理端的真实操作。

用户端检查清单

页面或功能 操作 预期结果
登录与注册 注册账号、正确/错误密码登录 成功后进入对应首页；失败有明确提示
图书首页 查看列表、分类、搜索 图书数据和可借状态正确显示
图书详情 查看信息、点击借阅 显示图书详情；借阅结果与接口一致
我的借阅 查看当前与历史记录、归还 仅显示本人记录；归还后状态和库存更新
个人中心 查看资料、修改邮箱或密码 数据正确显示，修改后有反馈
退出登录 退出后访问受保护页面 Session 失效，不能继续访问业务页面

管理端检查清单

页面或功能 操作 预期结果
管理首页 登录后查看统计卡片 图书、用户、借阅等统计合理显示
图书管理 查询、新增、编辑、删除 列表及时刷新；不满足条件时禁止删除
用户管理 搜索与删除普通用户 管理员不能删除；有未还图书的用户不能删除
借阅管理 查询记录、查看超期、代还 状态、归还日期与库存同步更新
权限校验 普通用户直接访问管理页面 被拒绝访问，不能获取管理数据

页面测试要观察反馈，而不只是点通

同时检查加载状态、空数据提示、表单校验、删除二次确认、错误提示、菜单高亮和浏览器刷新后的登录状态。页面能打开不等于交互是完整的。

保存测试证据

至少保存以下截图或记录：

  1. Postman 登录成功后的 JSON 响应；
  2. 图书列表或搜索接口响应；
  3. 借阅成功或借阅失败的接口/页面结果；
  4. 管理员新增图书的结果；
  5. 用户端图书首页与“我的借阅”页面；
  6. 管理端图书管理与借阅管理页面；
  7. 一个典型缺陷的复现或修复后结果。

将测试截图保存在项目约定的目录中，并在测试报告中引用或说明它们的位置。

🐛 第五步：发现问题后按流程修复

测试不是为了证明“没有问题”，而是尽早找到问题并修复。发现 Bug 后，不要只对 AI 说“这里坏了”。要提供可复现的证据：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
问题：普通用户可以直接访问管理员图书列表接口。

复现步骤：
1. 使用普通用户登录；
2. 请求 GET /api/admin/books?action=list；
3. 接口返回了图书管理数据。

预期结果：应拒绝访问，不能返回管理员数据。
实际结果：返回 code=200 和图书列表。
证据：Postman 请求与响应截图；相关后端日志。

请先阅读 AGENTS.md、需求分析说明书和系统设计说明书中权限控制的要求。
不要立即修改代码。请先说明可能原因、需要检查的文件和验证方案。

修复后必须进行回归测试：不仅重新测试该问题，还要测试紧邻的功能。例如修复权限过滤器后，应同时检查普通用户页面、管理员页面、未登录访问和所有管理接口。

📝 第六步：如实填写测试报告

测试报告模板位于：

1
doc/测试报告.md

填写时不要把“待实测”原样保留。每个用例至少记录：

字段 应填写内容
实际结果 实际响应、页面行为或关键数据变化
是否通过 根据预期结果勾选通过或不通过
缺陷记录 问题描述、复现步骤、严重程度和修复状态
测试结论 用例数量、通过/失败数量、主要问题和是否可演示

可以采用下面的写法：

1
2
3
实际结果：普通用户登录后，借阅《Java Web 开发技术》，接口返回 code=200；
“我的借阅”新增一条 borrowing 记录，图书可借复本数由 3 变为 2。
是否通过：通过。

测试报告不能写成计划书

“预计通过”“理论上可以”“AI 已检查”都不是实际结果。只有你真实运行、真实操作后观察到的现象，才能写进测试报告。

📦 第七步：打包并部署到 Tomcat

完成测试并修复严重问题后，再进行部署。课程项目采用简单的单机部署：浏览器访问 Tomcat，Tomcat 运行 Java Web 应用，MySQL 保存数据。

1. 先构建 WAR 包

在项目根目录执行：

1
mvn clean package

构建成功后，在 target/ 目录中找到生成的 .war 文件。若构建失败，先根据终端日志定位并修复问题，不要跳过错误继续部署。

2. 部署到 Tomcat

  1. 停止正在运行的 Tomcat；
  2. 将 WAR 包复制到 Tomcat 的 webapps/ 目录；
  3. 确认部署后的应用上下文为 /book；
  4. 启动 Tomcat；
  5. 查看 Tomcat 日志，确认应用部署成功且没有数据库连接错误。

部署后访问：

1
http://localhost:8080/book/user/login.html

上下文路径不一致是常见问题

如果你的 WAR 文件名或 Tomcat 配置导致实际路径不是 /book，需要同步修改前端请求的基础地址、Postman 环境变量和访问 URL。不要只改其中一处。

3. 部署后最小验证

部署成功后，至少重新执行一次：

  • 用户登录；
  • 图书列表查询；
  • 图书借阅或归还中的一个完整操作；
  • 管理员登录并进入图书管理页面；
  • 一条 Postman API 请求。

这一步验证的是“部署环境可用”，不能用开发时的测试结果代替。

🚦 本节完成后，你应该能够回答

我的系统在哪个地址运行？我测了哪些功能？借阅上限、超期和库存不足是否被验证？发现了哪些问题并如何修复？部署后是否重新验证？

如果这些问题都有真实答案和记录，你已经完成了从“代码生成”到“可交付项目”的关键一步。

📝 本节小结

  • 测试从 API 开始，再回到页面：先验证接口和业务规则，再验证真实用户操作；
  • Postman 集合是起点：导入集合、配置环境变量，并按认证到管理端的流程执行；
  • 边界场景必须覆盖：借阅上限、超期、无库存、重复操作和权限控制不能遗漏；
  • 测试报告记录真实证据：填写实际结果、缺陷和结论，不保留“待实测”；
  • 部署后必须再验证：WAR 包部署到 Tomcat 后，重新运行关键流程确认环境正确。

返回上一节：开发图书管理系统 返回阶段一目录