功能测试的流程

一、拿到提测版本后，第一件事是干什么？

当我们拿到提测版本后，第一件事上来不是直接进行测试，而是要先做冒烟测试。

冒烟测试的目的：判断这个版本值不值得测试

二、功能测试的基本流程

2.1 需求分析

先搞清楚需求是什么

要看什么	目的
需求文档	明确功能规则
原型图	确认页面展示和交互
接口文档	知道前后端如何传数据
业务流程	理解用户真实使用路径
验收标准	判断什么叫通过

2.2 测试设计

把需求描述变成可以执行的测试点

需求举例：

python 复制代码

购物车满 100 减 10 元
购物车满 200 减 20 元
购物车满 300 减 30 元

测试用例：

测试场景	测试数据	预期结果
不满 100	99 元	不优惠
刚好满 100	100 元	减 10
100 到 199.99	150 元	减 10
刚好满 200	200 元	减 30
刚好满 500	500 元	减 100
超过 500	800 元	减 100

2.3 环境搭建

测试前要确认：

检查项	示例
测试环境	Beta、Test、Demo Box、预发布环境
版本号	v1.2.3、commit id、构建号
测试账号	普通用户、会员用户、管理员
测试数据	商品、订单、优惠券、库存
配置开关	功能开关是否打开
依赖服务	支付、短信、库存、物流接口是否可用

2.4 执行测试

测试要一边测试一边记，留痕，不要用脑子记

python 复制代码

测试⽤例是否通过
实际结果是什么
失败时的截图
失败时的⽇志
失败时的测试数据
失败时的操步骤

2.5 缺陷提交：让开发可以快速定位问题

高质量缺陷报告应该包含：

内容	示例
缺陷标题	支付页面点击"微信支付"按钮无响应
所属模块	支付模块
测试环境	Beta 环境，Chrome 120
版本号	v1.2.3，构建号 20260115
前置条件	用户已登录，购物车已有商品
复现步骤	1. 提交订单 2. 选择微信支付 3. 点击支付
期望结果	跳转到微信支付页面
实际结果	点击按钮后页面无任何响应
严重程度	S1
优先级	P1
附件	截图、视频、接口日志、控制台报错

三、bug的生命周期

bug 从发现到关闭的流程图

3.1 新建 New

重点不是写上去，而是要写清楚

python 复制代码

是什么问题
怎么复现
影响什么功能
在哪个环境出现
有没有截图和⽇志

3.2 分配给 Assigned

功能测试全流程

核心流程： 接手提测版本 → 测试执行 → 缺陷跟踪 → 验证修复 → 保障质量

一、接到提测版本后，第一件事是什么?

提测后的第一步------冒烟测试

当开发把一个版本提交给测试时，测试人员不要一上来就开始详细测试。第一件事应该是：先做冒烟测试。

冒烟测试的目的不是测得很细，而是先判断：这个版本值不值得继续测。

比如一个电商系统提测了新版本，你至少要先看：

冒烟检查项	说明
系统能不能正常打开	页面不能打开，后面不用测
用户能不能登录	登录失败，很多功能都无法继续
核心流程能不能跑通	如浏览商品、加购物车、下单
主接口有没有大面积报错	如果核心接口500，版本质量很差
页面有没有明显阻断问题	如按钮点不了、菜单打不开

强调： 冒烟测试没通过，说明版本不具备继续测试的条件，应该直接打回开发。

案例：

开发提测一个商城系统，你一打开系统发现：

登录页面打不开
订单页面 500 报错
支付按钮点击没反应

这种情况下不要继续细测优惠券、积分、订单筛选这些内容。

正确做法是：

冒烟失败 → 记录严重问题 → 打回开发 → 等修复后重新提测

重点： 冒烟测试是测试工作的第一道门槛。它的价值是尽早拦截低质量版本，避免后面大量测试白做。

二、功能测试的基本流程

1. 需求分析：先搞清楚"应该是什么样"

不要直接打开系统乱点。测试前先看：

要看什么	目的
需求文档	明确功能规则
原型图	确认页面展示和交互
接口文档	知道前后端如何传数据
业务流程	理解用户真实使用路径
验收标准	判断什么叫通过

重点： 测试不是找茬，而是验证系统是否符合需求。如果你连需求都没看懂，后面发现的问题可能不是 Bug，而是你理解错了。

2. 测试设计：把需求变成测试用例

测试设计就是把"需求描述"变成"可执行的测试点"。

例如需求是：

购物车满 100 减 10
满 200 减 30
满 500 减 100

测试点应该包括：

测试场景	测试数据	预期结果
不满100	99元	不优惠
刚好满100	100元	减10
100到199.99	150元	减10
刚好满200	200元	减30
刚好满500	500元	减100
超过500	800元	减100

强调： 功能测试最怕只测"正常情况"。真正容易出问题的是边界值、异常场景和组合场景。

3. 环境准备：确认你测的是正确版本

真实项目中，经常出现这种问题：

开发说修好了
测试说没修好
最后发现测试环境部署的还是旧版本

所以测试前要确认：

检查项	示例
测试环境	Beta、 Test、 Demo Box、预发布环境
版本号	v1.2.3、 commit id、构建号
测试账号	普通用户、会员用户、管理员
测试数据	商品、订单、优惠券、库存
配置开关	功能开关是否打开
依赖服务	支付、短信、库存、物流接口是否可用

重点： 很多问题不是代码 Bug，而是环境、数据、配置不对。测试人员要有环境意识和版本意识。

4. 执行测试：边测边记录，不要靠记忆

执行测试时要记录：

测试用例是否通过
实际结果是什么
失败时的截图
失败时的日志
失败时的测试数据
失败时的操作步骤

提醒： 不要想着"我一会儿再记"。真到提 Bug的时候，很容易忘记当时用了哪个账号、哪条数据、哪个环境。

5. 缺陷提交：让开发能快速定位问题

发现问题后，不是直接在群里说一句："支付有问题，你看一下。" 这种说法开发很难处理。

高质量缺陷报告应该包含：

内容	示例
缺陷标题	支付页面点击"微信支付"按钮无响应
所属模块	支付模块
测试环境	Beta环境, Chrome 120
版本号	v1.2.3, 构建号20260115
前置条件	用户已登录，购物车已有商品
复现步骤	1.提交订单 2.选择微信支付 3.点击支付
期望结果	跳转到微信支付页面
实际结果	点击按钮后页面无任何响应
严重程度	S1
优先级	P1
附件	截图、视频、接口日志、控制台报错

重点： 好的 Bug报告不是"证明开发错了"，而是帮助团队更快解决问题。

三、缺陷生命周期

Bug从发现到关闭的流程图：

新建 (New)： 测试人员发现问题后，在缺陷管理工具中创建 Bug。
- 重点不是"把问题写上去"，而是写清楚：是什么问题、怎么复现、影响什么功能、在哪个环境出现、有没有截图和日志。
分配 (Assigned)： Bug 被分配给对应开发人员。
- 举例：登录问题→分配给账号模块开发；支付问题→分配给支付模块开发；订单问题→分配给订单模块开发。
修复中 (In Progress)： 开发开始定位和修改代码。
- 测试人员这时候不是完全等待，可以关注：开发是否能复现、是否需要补充账号或数据、是否需要提供日志、是否影响测试计划。
待验证 (Fixed/Pending Retest)： 开发修复完成后，把 Bug 状态改成待验证。
- 这时测试人员要做两件事：先按原步骤验证 Bug 是否修好；再做相关功能的回归测试。
重新打开 (Reopened)： 如果验证时发现问题仍然存在，不能直接新提一个一模一样的 Bug。
- 应该：在原缺陷单补充最新验证结果；附上新的截图或日志；将状态改为重新打开；退回开发继续修复。
- 课堂话术： 重新打开不是挑刺，而是说明问题还没真正解决。
关闭 (Closed)： 只有当满足下面条件时，才可以关闭：
- 原问题已解决
- 相关功能回归通过
- 没有引入明显新问题
- 测试环境和版本确认无误
推迟 (Deferred)： 有些问题当前版本可以不修，但不能假装不存在。
- 例如：按钮样式在小屏手机上略微偏移、文案显示不够美观、非核心页面排序不符合习惯。
- 如果不影响主流程，可以推迟到后续版本。但要写清楚：为什么推迟、影响范围是什么、计划哪个版本处理、是否存在上线风险。
无法重现 (Not Reproducible)：
- 既然无法重现，为什么不直接关闭？无法重现不等于问题不存在。它可能是偶发问题，也可能和环境、数据、缓存、网络、并发有关。
- 正确做法：先不要马上关闭；保留缺陷单；补充当时环境、账号、日志、截图；在后续版本持续观察；一两个版本都没有再出现，再评估关闭。
- 接地气解释： 这其实是对测试和开发双方的保护。如果你马上关闭，后面线上又出现同样问题，就很难追踪当初发生过什么。保留缺陷单，至少说明团队知道这个风险，并且持续观察过。
无效/拒绝 (Rejected/Invalid)：
- 不是所有测试提出的问题都是 Bug。可能是：测试账号权限不对、测试环境数据异常、需求本来就是这样设计、测试人员理解错了需求、操作步骤不符合业务规则。
- 但即使被拒绝，也不能只写一句："不是 Bug"。应该写明原因：该账号无支付权限，所以按钮置灰是符合需求的。
- 强调： 缺陷被拒绝并不丢人，关键是要复盘原因，避免下次重复误报。

四、缺陷修复与验证

Bug验证不是只点一下：

确认版本
确认环境
按原步骤复现
验证原问题是否解决
检查相关功能是否受影响
通过 → 关闭
失败 → 重新打开

修复验证步骤：

执行原复现步骤，验证缺陷是否解决（在相同环境下验证修复）。
检查修复细节，理解修改点（覆盖正常+异常场景）。
结果判断：
- 结果通过 → 继续回归测试（关注影响范围，防止连带问题）。
- 结果不通过 → 重新打开缺陷（与开发保持沟通，及时反馈）。

1. 验证前先确认环境和版本

测试人员经常遇到这种情况：

开发说：我修好了，你再测一下。
测试说：我这边还是不行。
开发说：你测的是新包吗?

所以验证前一定要确认：

环境是否正确
版本是否正确
代码是否部署成功
配置是否生效
缓存是否清理
测试数据是否一致

你可以把这句话讲给学生：验证 Bug 前，先确认自己测的是"开发修复后的版本"，否则测半天没有意义。

2. 先验证原问题

按照当初提交 Bug 的步骤重新执行。

例如原 Bug 是：点击微信支付按钮无响应。

验证时不能只看页面能不能打开，而要完整执行：

提交订单
进入支付页
选择微信支付
点击支付按钮
观察是否跳转
确认订单状态是否正确

3. 再做相关回归

Bug 修复可能影响周边功能。

例如支付按钮修复后，还要关注：

支付宝支付是否正常
银行卡支付是否正常
订单状态是否更新
库存是否扣减
优惠券是否退回
支付失败后能否重新支付

重点： 修复一个 Bug，有可能带来另一个 Bug。所以验证不是只看"原问题消失了没有"，还要看相关功能有没有被影响。

五、回归测试怎么做更落地

回归测试范围选择：

本次修改的功能
相关联功能
核心业务流程
历史高发 Bug 区域
高风险模块

回归测试不是全部重测

很多学生会误以为：回归测试就是把所有测试用例重新跑一遍。实际工作中，时间通常不允许这么做。更合理的做法是按风险选择范围：

回归范围	示例
修改点本身	支付按钮是否可点击
相关功能	支付成功后订单状态
上下游流程	下单、库存、优惠券
核心流程	登录、下单、支付
历史问题区域	以前经常出 Bug的支付回调
高风险模块	金额计算、权限、数据同步

六、如何提交高质量缺陷

好 Bug报告的四个标准： 说得清、可复现、可验证、有价值。

1. 缺陷标题要具体

不好的标题： 支付有问题、页面不对、系统报错。
好的标题：
- 支付页面点击"微信支付"按钮后无响应
- 订单提交成功后订单状态仍显示"待支付"
- 购物车满 200 元时优惠金额计算为 10 元
标题公式： 模块 + 操作 + 问题表现

2. 复现步骤要完整

不好的写法： 进入支付页面，点击支付，有问题。
好的写法：
1. 使用账号 test001 登录系统
2. 选择商品 A，加入购物车
3. 进入购物车，点击结算
4. 提交订单
5. 在支付页面选择微信支付
6. 点击"立即支付"按钮

3. 期望结果和实际结果要分开写

不要只写：支付不正常。
应该写：
- 期望结果： 点击"立即支付"后跳转到微信支付页面。
- 实际结果： 点击按钮后页面无响应，控制台出现 JS 报错。

4. 附件要能帮助定位

建议附加：

截图
录屏
控制台日志
接口请求和响应
后端报错日志
测试账号
测试数据
版本号
环境信息

课堂提醒： 一张清晰截图、一段关键日志，可能比一大段文字更有用。

七、严重性和优先级怎么区分

严重性 VS 优先级

严重性： 问题有多严重
优先级： 问题有多急着修

示例讲解：

缺陷	严重性	优先级	原因
支付失败	高	高	核心业务不可用
首页 Logo 显示错位	低	中/高	如果明天发布会演示，可能急着修
管理后台偶发报错	中	中	影响内部人员使用
用户数据丢失	高	高	严重影响业务和用户信任
文案少了一个标点	低	低	不影响功能

重点： 严重性看影响程度，优先级看修复顺序。两者相关，但不是一回事。

八、测试工作中的沟通技巧

这个章节建议新增，因为真实工作中很重要，也更接地气。

测试与开发沟通闭环：

发现问题
先自查环境和数据
提交清晰缺陷
和开发确认复现
跟进修复状态
验证并反馈结果

不建议的沟通方式：

你这个功能有 Bug。
怎么又坏了?
我这边就是不行。
你自己看吧。
这些表达容易引发对立。

建议的沟通方式：

我在 Beta 环境 v1.2.3 版本发现一个支付问题。
使用账号 test001，提交订单后点击微信支付按钮无响应。
我附了录屏和控制台日志，你看下是不是前端按钮事件没有触发。

九、测试报告怎么写

测试报告应包含：

内容	示例
测试版本	v1.2.3
测试环境	Beta环境
测试范围	登录、购物车、订单、支付
执行情况	80条用例，通过75条，失败5条
缺陷统计	P1: 0个, P2: 2个, P3: 3个
遗留问题	2个低优先级UI问题
风险说明	不影响主流程，可后续修复
上线建议	建议上线/不建议上线

强调： 测试报告不是简单写"测完了"。它要告诉团队：这个版本质量怎么样，风险在哪里，能不能上线。

十、案例：支付功能提测

案例背景

开发提测商城支付功能，版本号：v1.2.3

测试人员需要完成：

冒烟测试
功能测试
缺陷提交
缺陷验证
回归测试
测试报告

流程

第一步：冒烟测试

检查：

系统能否打开
用户能否登录
商品能否下单
支付页面能否进入
如果支付页面打不开：
冒烟失败，版本打回

第二步：执行功能测试

测试点：

微信支付
支付宝支付
余额支付
优惠券支付
支付成功
支付失败
取消支付
重复支付
支付后订单状态
支付后库存变化

第三步：发现 Bug

发现问题：

点击微信支付按钮无响应

第四步：提交 Bug

缺陷标题：

支付页面点击"微信支付"按钮后无响应
复现步骤：
使用账号 test001 登录 Beta 环境
选择商品 A，加入购物车
提交订单
进入支付页面
选择微信支付
点击"立即支付"
期望结果：
跳转到微信支付页面
实际结果：
页面无响应，控制台出现 JS 报错
附件：
录屏
截图
控制台日志
接口请求信息

第五步：开发修复后验证

验证内容：

原问题是否解决
微信支付是否能跳转
支付成功后订单状态是否更新
支付宝支付是否受影响
取消支付是否正常
重复点击是否会生成多笔订单

第六步：回归测试

回归范围：

支付流程
订单流程
库存扣减
优惠券使用
支付失败处理
退款入口

第七步：测试报告

结论示例：

本次测试覆盖登录、下单、支付、订单状态流转等核心流程。
共执行 45 条测试用例，通过 43 条，失败 2 条。
遗留 2 个低优先级 UI 问题，不影响支付主流程。
建议上线，但需在下个版本修复遗留问题。

十一、总结

接到提测版本，先做冒烟测试。
冒烟不过，及时打回，不要硬测。
提 Bug 要清楚、可复现、有证据。
修复验证要先测原问题，再测相关功能。
回归测试不是全量重测，而是按风险选择范围。
无法重现的 Bug 不要急着关闭，要持续跟踪。
测试报告要说明质量结果和上线风险。