5.2 编写并执行测试：功能、接口与核心流程

让“我已经测试过了”变成可复现的事实

点过一次页面，不等于完成测试

“登录成功了”“按钮能点”“列表能看到数据”只能说明你碰巧完成过一次操作，不能说明项目在错误输入、重复操作、角色切换、异常状态和重新部署后仍然正确。

测试用例要把一次验证写清楚：在什么前提下，由谁操作，输入什么，按哪些步骤执行，预期发生什么，实际发生什么，用什么证据证明。 其他同学拿到用例后，应能复现相同结果。

本节学习目标

将 5.1 的测试计划拆成可执行的测试用例，围绕正常功能、业务失败、权限控制、状态边界和核心业务流程实际运行系统，保存页面、接口、日志和数据证据，形成测试执行记录。

返回上一节：制定测试计划 返回第四篇：项目开发与业务实现

---

🎯 本节完成后，你要交付

成果	要求
测试用例集	每条 P0、P1 测试点都有前置条件、步骤和预期结果
功能测试记录	页面正常、失败和边界操作有实际结果与证据
接口测试记录	使用 Apifox、Postman 或等价工具验证请求、响应和权限
核心流程追踪记录	多角色连续操作到最终结果，记录每一步状态变化
数据验证记录	关键操作后检查数据库或页面结果，证明数据正确保存
问题清单	所有失败、疑问和未完成项均已记录，不隐藏失败结果

本节的结果可以是“不通过”

测试不是为了把表格全部填成“通过”。发现问题并准确记录，远比忽略问题或把失败写成通过更有价值。缺陷修复与回归测试将在下一节完成。

---

一、先把测试计划拆成测试用例

5.1 的测试计划说明“测什么”，本节的测试用例说明“具体怎样测”。

1. 一条合格测试用例应包含什么

字段	说明	示例
用例编号	唯一编号，方便引用与追踪	TC-AUTH-01
所属需求	对应需求编号、业务规则或接口	FR-01 / PR-01
测试目标	本次要验证什么	验证正确账号可以登录
优先级	P0 / P1 / P2	P0
前置条件	账号、数据、登录状态、页面位置	已初始化数据库；存在普通用户账号
测试数据	输入的账号、对象、状态或参数	用户名 student01，正确密码
操作步骤	可以按顺序执行的具体动作	打开登录页 → 输入账号密码 → 点击登录
预期结果	系统应该如何响应、数据应该如何变化	跳转首页；显示当前用户；Session/JWT 生效
实际结果	实际观察到的结果	通过 / 失败，并简述现象
证据	截图、接口响应、日志、数据库记录	TC-AUTH-01-login.png

2. 不合格与合格的对比

不合格写法：

测试登录功能。
结果：正常。

问题是：不知道使用什么账号、操作了什么、什么叫“正常”、谁也无法复现。

合格写法：

字段	内容
用例编号	TC-AUTH-01
测试目标	验证普通用户使用正确账号和密码可以登录
前置条件	已导入初始化数据；系统已启动；未登录
测试数据	用户名：student01；密码：Test@123
步骤	1. 打开登录页；2. 输入用户名与密码；3. 点击“登录”
预期结果	登录成功，跳转首页；页面显示当前用户；请求受限接口返回成功
实际结果	【填写】
证据	【截图或接口响应文件名】

步骤写到同学能照着做

不要只写“提交表单”“验证权限”。要说明从哪个页面、用哪个账号、输入什么数据、点哪个按钮、看到什么结果。

---

二、先写 P0 用例：启动、登录与核心流程

时间有限时，不要从样式和非核心页面开始。先完成最可能阻断项目交付的 P0 用例。

1. 启动与冒烟测试用例

项目测试的第一批用例应确认系统具备基本运行条件。

编号	测试目标	关键步骤	预期结果
TC-SMOKE-01	验证数据库可初始化	使用 SQL 或迁移脚本从空库初始化	表、字段、约束和测试数据创建成功
TC-SMOKE-02	验证应用可启动	按 README 启动后端、前端或 Tomcat	无阻断报错；服务监听预期端口
TC-SMOKE-03	验证首页可访问	浏览器打开项目地址	首页或登录页正确显示，无持续控制台错误
TC-SMOKE-04	验证数据库连接	访问一个读取真实数据的列表或接口	返回实际数据，无连接异常
TC-SMOKE-05	验证部署说明可用	由同学按 README 尝试启动	不需要手改代码或临时口头补充关键步骤

冒烟测试失败时，先不要测试更多功能

项目无法启动、无法登录或无法连接数据库时，后面的功能测试没有可靠前提。记录问题，恢复基础环境后重新执行冒烟测试。

2. 身份认证与权限测试用例

无论采用 JWT 还是 Session，至少验证以下场景：

编号	场景	测试数据	预期结果
TC-AUTH-01	正确密码登录	已注册账号 + 正确密码	登录成功，身份信息正确
TC-AUTH-02	错误密码登录	已注册账号 + 错误密码	登录失败，提示明确，不泄露敏感信息
TC-AUTH-03	不存在账号登录	不存在的账号	登录失败，不自动创建账号
TC-AUTH-04	退出登录	已登录用户	会话或 Token 失效，返回受限页被拒绝
TC-AUTH-05	未登录访问受限接口	不携带登录凭据	后端返回 401/未授权，不产生数据变化
TC-AUTH-06	普通用户访问管理操作	普通用户账号	页面入口受限，接口返回 403/权限不足
TC-AUTH-07	访问其他用户数据	用户 A 修改请求中的对象 ID	后端拒绝或只返回用户 A 有权限的数据

3. 核心流程至少写一条端到端用例

假设项目是“宿舍报修”，核心流程可以写为：

编号	TC-WORKFLOW-01：报修处理闭环
前置条件	学生 A、管理员、维修人员账号存在；报修初始数据可恢复
目标	验证学生提交报修后，管理员分配、维修人员处理、学生确认的完整流程
优先级	P0

步骤	操作角色	操作	预期结果	证据
1	学生 A	提交一条有效报修	创建成功，状态为“待分配”	【填写】
2	管理员	查看待分配列表并分配维修人员	状态变为“处理中”，维修人员可见任务	【填写】
3	维修人员	提交处理结果	状态变为“待确认”，学生可见处理信息	【填写】
4	学生 A	确认维修完成	状态变为“已完成”，流程结束	【填写】
5	学生 A	再次确认同一记录	操作被拒绝，状态不再变化	【填写】

将“宿舍报修”替换为自己项目的核心流程即可，例如：活动报名、图书借阅、预约服务、订单处理、失物认领等。

---

三、覆盖四类必测场景

每一个核心功能或核心流程，至少从下面四个角度设计用例。

1. 正常场景：验证用户能完成任务

正常场景不只是“接口返回 200”，还要验证最终用户能看到正确结果。

输入合法数据
→ 页面提示成功
→ 接口响应正确
→ 数据库或列表数据正确变化
→ 刷新页面后结果仍存在
→ 下一角色可以继续操作

例如“新增活动”：

• 管理员输入完整名称、时间、地点、人数；
• 点击提交后提示创建成功；
• 活动列表出现新记录；
• 刷新浏览器后记录仍存在；
• 普通用户能够看到已发布的活动。

2. 业务失败场景：验证规则真正生效

业务失败不是系统崩溃，而是系统根据规则拒绝不允许的操作。

业务类型	应考虑的失败场景
报名/预约	名额已满、重复报名、时间已截止
借阅/归还	无库存、超过借阅数量、已归还再次归还
订单/购买	库存不足、订单已取消、重复支付
审核/处理	当前状态不允许审核、任务未分配、已处理再次处理
信息发布	必填项缺失、时间范围错误、内容超过限制

业务失败用例的预期结果应同时包含：

请求被拒绝
→ 页面或接口提示具体原因
→ 数据库不产生错误数据
→ 原有状态和统计值不被破坏

3. 权限场景：验证后端不能被绕过

隐藏按钮不等于权限控制。测试时必须绕过页面，直接调用接口。

页面权限验证接口权限验证

以普通用户身份登录，检查：

• 是否看不到管理员菜单；
• 是否不能进入管理员页面；
• 是否没有“发布、删除、审核、分配”等管理按钮；
• 页面提示是否清楚。

以普通用户身份，在 Apifox/Postman 或浏览器开发者工具中直接调用管理接口，检查：

• 返回 401（未登录）或 403（无权限）；
• 数据库没有新增、修改或删除记录；
• 错误信息不暴露数据库、堆栈或敏感配置；
• 换一个对象 ID 后，仍不能访问其他用户数据。

必须验证接口，不只验证菜单

用户可以修改 URL、请求参数或对象 ID。只有后端检查登录身份、角色与数据归属，权限规则才真正成立。

4. 边界与重复场景：验证系统不会被简单操作破坏

至少选择与项目相关的边界场景：

类型	示例
空数据	没有任何活动、订单、报修记录时，列表是否正常显示空状态
分页边界	第一页、最后一页、超过最大页码、每页大小改变
文本边界	必填项为空、超长文本、特殊字符、只有空格
数值边界	0、最小值、最大值、负数、超过库存或名额
时间边界	截止时间前后、开始时间晚于结束时间
重复操作	连续点击提交、重复报名、重复确认、重复删除
状态边界	已取消后继续处理、已完成后再次确认
会话边界	登录过期后提交、退出后浏览器后退访问受限页

---

四、执行页面功能测试：从用户视角保存证据

页面测试不仅验证“按钮有反应”，还要检查任务是否容易完成、提示是否足够清楚。

1. 页面功能测试建议顺序

打开页面
→ 确认初始状态
→ 输入或选择测试数据
→ 执行操作
→ 检查页面提示
→ 刷新页面或跳转页面
→ 确认结果是否仍正确
→ 查看浏览器控制台是否有异常

2. 页面测试记录表

用例编号	页面	操作	预期结果	实际结果	状态	证据
TC-PAGE-01	登录页	输入正确账号密码并登录	跳转首页，显示当前账号	【填写】	通过/失败	【截图】
TC-PAGE-02	【列表页】	输入查询条件并搜索	返回符合条件的数据	【填写】	通过/失败	【截图】
TC-PAGE-03	【表单页】	空提交	必填字段有明确提示，数据不保存	【填写】	通过/失败	【截图】
TC-PAGE-04	【详情页】	刷新页面	数据仍正确显示	【填写】	通过/失败	【截图】

3. 页面证据建议

为每个 P0/P1 用例至少保存一种可定位证据：

• 成功或失败结果的页面截图；
• 浏览器 Network 面板中的关键请求与响应；
• 浏览器控制台错误信息（如存在）；
• 操作前后的列表或详情截图；
• 部署后相同页面的访问截图。

文件命名建议：

test-evidence/
├── TC-AUTH-01-login-success.png
├── TC-AUTH-05-unauthorized-response.png
├── TC-WORKFLOW-01-step-01-create.png
├── TC-WORKFLOW-01-step-04-complete.png
└── TC-WORKFLOW-01-step-05-repeat-rejected.png

不要为了截图好看而修改测试结果。失败截图也是有效证据。

---

五、执行接口测试：验证请求、响应与数据变化

页面测试无法替代接口测试。接口测试可以更直接地验证状态码、参数校验、权限和响应数据。

1. 使用 Apifox 或 Postman 建立集合

建议按模块建立接口集合：

项目接口测试集合/
├── 认证模块
│   ├── 登录
│   ├── 注册
│   ├── 获取当前用户
│   └── 退出登录
├── 【核心模块】
│   ├── 查询列表
│   ├── 查询详情
│   ├── 新增
│   ├── 修改
│   └── 删除或状态操作
└── 【另一角色模块】
    └── 【填写】

为环境配置变量，避免把地址和账号写死在每个请求中：

baseUrl = http://localhost:8080
adminUsername = 【填写】
adminPassword = 【填写】
userUsername = 【填写】
userPassword = 【填写】

对于 JWT 项目，可在登录请求的后置脚本中保存 Token；对于 Session 项目，确认工具能够保持 Cookie，或在请求中携带返回的 Cookie。

2. 每次接口调用至少检查五件事

检查项	问题
请求	URL、方法、路径参数、查询参数、请求体是否符合接口设计？
状态码	成功、参数错误、未登录、无权限、资源不存在时状态码是否合理？
响应结构	code、message、data 等字段是否符合项目约定？
业务数据	返回数据是否与当前登录用户、查询条件和业务状态一致？
持久化结果	新增、修改、删除或状态变化是否真的写入数据库？

3. 示例：新增接口的测试用例

字段	内容
用例编号	TC-API-ITEM-03
接口	POST /api/demo-items（替换为实际接口）
测试目标	验证管理员可创建有效业务对象
前置条件	管理员已登录；数据库可连接
请求体	{"title":"测试数据","content":"用于接口测试","status":"active"}
预期状态码	200 / 201（按项目约定）
预期响应	返回成功 code、对象 ID 和正确业务字段
预期数据变化	数据库新增一条记录，创建人和状态正确
实际结果	【填写】
证据	【接口响应截图、数据库查询结果】

4. 用接口直接验证越权

例如普通用户不应删除活动：

1. 用普通用户登录，获得 Session 或 Token；
2. 直接调用 DELETE /api/activities/{id}；
3. 检查响应是否为 401 或 403；
4. 再查询活动详情；
5. 确认活动仍存在，数据库没有发生删除。

不能只看响应消息

即使接口返回“权限不足”，也要确认数据库没有发生修改。错误的代码可能先更新数据、后返回失败信息。

---

六、验证核心流程后的数据状态

核心流程测试结束后，至少从一个数据角度检查业务结果。可以是数据库查询，也可以是系统中不同角色看到的一致结果。

1. 推荐的验证层次

页面提示正确
→ 接口响应正确
→ 列表 / 详情刷新后正确
→ 数据库记录正确
→ 下一角色看到正确任务或结果

2. 数据验证记录模板

用例编号	操作前状态	操作	操作后预期状态	实际状态	验证方式
TC-WORKFLOW-01-01	报修状态：待提交	学生提交报修	状态：待分配；生成记录	【填写】	页面 / SQL / 接口
TC-WORKFLOW-01-02	状态：待分配	管理员分配	状态：处理中；维修人 ID 已写入	【填写】	页面 / SQL / 接口
TC-WORKFLOW-01-03	状态：处理中	维修人员完成处理	状态：待确认；处理说明已保存	【填写】	页面 / SQL / 接口

如果需要执行 SQL，只查询测试数据，避免误删或误改生产数据：

-- 根据自己的项目表和测试对象替换条件
SELECT id, status, user_id, created_at, updated_at
FROM your_business_table
WHERE id = 【测试对象 ID】;

数据库查询是验证手段，不是流程步骤

可以用 SQL 检查结果，但不能通过手工 UPDATE 把测试对象改到下一状态，再宣称流程已经跑通。

---

七、记录实际结果：通过、失败、阻塞与不适用

不要只用“√”和“×”。建议使用下面四种状态：

状态	含义	后续动作
通过	实际结果与预期一致	保存证据，继续下一条
失败	实际结果与预期不一致	创建缺陷记录，标记影响与优先级
阻塞	环境、账号、依赖或前置功能导致无法执行	记录阻塞原因，恢复后重新执行
不适用	当前项目或版本确实不涉及该用例	说明原因，不要留空

示例：失败记录应怎样写

不合格写法：

报名功能有 bug。

合格写法：

用例编号：TC-REGISTER-03
问题：学生 A 已报名活动 1001 后，再次报名接口仍返回成功。
复现步骤：
1. 以 student01 登录；
2. 调用 POST /api/activities/1001/register 两次；
3. 查询报名列表。
预期：第二次操作被拒绝，报名记录数量保持 1。
实际：第二次返回成功，生成两条报名记录，名额被扣减两次。
影响：P0，导致名额统计错误。
证据：接口响应截图、报名表查询结果。

下一节会将这类记录整理为缺陷清单，完成修复与回归测试。

---

八、不要忽略测试证据和 Git 记录

测试证据不一定要全部提交到代码仓库，但必须可以追溯到测试版本。

1. 建议的证据保存方式

docs/
├── testing/
│   ├── 测试用例.md
│   ├── 缺陷清单.md
│   ├── test-evidence/
│   │   ├── TC-AUTH-01-login.png
│   │   ├── TC-API-ITEM-03-create.json
│   │   └── TC-WORKFLOW-01-complete.png
│   └── 接口测试集合.json
└── 测试报告.md

如果截图过多、文件较大，可保留在课程平台、云盘或项目附件中，但在测试记录中写明访问位置和文件名。

2. 测试中发现问题后不要直接堆改代码

推荐节奏：

执行用例
→ 发现失败
→ 保存证据
→ 创建缺陷记录
→ 判断优先级
→ 修复代码
→ Git 提交
→ 重新执行原用例
→ 记录回归结果

修复提交信息应体现问题，而不是只写“修改代码”：

git commit -m "fix: 阻止用户重复报名活动"
git commit -m "fix: 补充管理员删除活动的接口权限校验"

---

九、填写测试用例与执行记录模板

将以下模板复制到项目的 docs/testing/测试用例.md 或《测试报告》的“测试执行记录”章节。

# 【项目名称】测试用例与执行记录

测试版本：【分支 / 标签 / 提交编号】
测试日期：【填写】
测试人员：【填写】

## 1. 冒烟测试

| 编号 | 测试目标 | 前置条件 | 步骤 | 预期结果 | 实际结果 | 状态 | 证据 |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| TC-SMOKE-01 | 【填写】 | 【填写】 | 【填写】 | 【填写】 | 【填写】 | 通过/失败/阻塞 | 【填写】 |

## 2. 功能与接口测试

| 编号 | 需求或接口 | 角色 | 测试数据 | 步骤 | 预期结果 | 实际结果 | 状态 | 证据 |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| TC-01 | 【填写】 | 【填写】 | 【填写】 | 【填写】 | 【填写】 | 【填写】 | 通过/失败/阻塞 | 【填写】 |

## 3. 核心流程测试

| 编号 | 步骤 | 操作角色 | 操作 | 预期状态或数据变化 | 实际结果 | 状态 | 证据 |
| :--- | :---: | :--- | :--- | :--- | :--- | :--- | :--- |
| TC-WORKFLOW-01 | 1 | 【填写】 | 【填写】 | 【填写】 | 【填写】 | 通过/失败/阻塞 | 【填写】 |

## 4. 权限与异常测试

| 编号 | 场景 | 操作 | 预期结果 | 实际结果 | 状态 | 证据 |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| TC-PERM-01 | 未登录访问受限接口 | 【填写】 | 返回 401，数据不变 | 【填写】 | 通过/失败/阻塞 | 【填写】 |
| TC-PERM-02 | 普通用户访问管理员接口 | 【填写】 | 返回 403，数据不变 | 【填写】 | 通过/失败/阻塞 | 【填写】 |

## 5. 执行结论

- 总用例数：【填写】
- 通过：【填写】
- 失败：【填写】
- 阻塞：【填写】
- 不适用：【填写】
- 需要进入缺陷修复的问题：【填写】

---

十、提交前自查

• 已先执行并记录冒烟测试；
• P0、P1 测试点均已拆成可执行测试用例；
• 每条用例都有前置条件、步骤、预期结果和实际结果；
• 已覆盖至少一条完整核心业务流程；
• 已覆盖正常、失败、权限和边界四类场景；
• 已直接调用接口验证未登录和越权，而非只看页面按钮；
• 已验证关键操作后的页面、接口和数据状态；
• 失败、阻塞和不适用都有真实说明；
• P0/P1 用例保存了可定位证据；
• 没有把未执行的用例写成“通过”；
• 发现的问题已进入缺陷清单或待修复列表。

---

本节小结

编写并执行测试的重点是让项目质量有证据可查：

从测试计划提取用例 → 先验证启动与登录 → 测核心流程正常路径 → 测业务失败、权限与边界 → 保存页面、接口和数据证据 → 如实记录通过或失败。

完成本节后，你应该清楚知道哪些功能真正可靠、哪些问题阻断交付、哪些需要修复。下一节将学习如何管理缺陷、定位影响范围、修复问题并进行回归测试。

下一节：5.3 修复问题：缺陷管理与回归测试 返回上一节：制定测试计划