一个新版本发布后，测试人员到底应该先测什么？

最近在梳理版本测试流程时，发现很多刚接触测试的人都会有一个疑问：

开发给了一个新版本，已经部署到测试环境了，测试人员到底应该先测什么？
是先测新功能？
还是先验证之前的 Bug？
还是直接把老功能全部测一遍？
测完以后，又怎么判断能不能升级到生产环境？

这篇文章就用比较通俗的方式，把一个新版本从测试环境到生产发布前的测试流程讲清楚。

---

一、先说结论：新版本测试不是上来就全量测

一个新版本部署到测试环境后，测试流程一般不是：

直接把所有功能从头到尾测一遍。

更合理的顺序是：

新版本部署到测试环境
        ↓
1. 冒烟测试
        ↓
2. 历史 Bug 验证
        ↓
3. 新功能测试
        ↓
4. 核心功能回归测试
        ↓
5. 新 Bug 修复验证
        ↓
6. 发布前风险评估
        ↓
7. 升级到生产环境

简单来说就是：

先确认版本能不能测，再确认以前的问题修没修好，再测本次新增功能，最后看老的核心功能有没有被影响。

---

二、第一步：冒烟测试

1. 什么是冒烟测试？

冒烟测试就是新版本部署完成后，先快速检查系统最基本的功能能不能用。

它不是详细测试，而是判断这个版本有没有资格继续往下测。

通俗理解就是：

先看系统有没有“冒烟”、有没有一上来就炸。

比如一个系统刚部署完，测试人员先看：

• 系统能不能打开；
• 登录能不能成功；
• 首页能不能正常显示；
• 核心菜单能不能打开；
• 核心接口能不能正常返回；
• 主流程能不能简单跑通。

如果这些最基础的功能都不行，比如系统打不开、登录不了、首页报错，那就没必要继续测新功能，也没必要测老功能了。

这时候应该直接反馈开发：

冒烟测试不通过，当前版本不可测，请修复基础问题后重新提测。

2. 以AI应用开发系统为例

新版本部署到测试环境后，可以先冒烟检查：

• 系统能否正常访问；
• 管理员能否登录；
• 普通用户能否登录；
• 模型对话能否正常返回；
• 知识库页面能否打开；
• 智能体页面能否打开；
• 用户管理页面能否打开。

只要这些核心入口都正常，才说明这个版本具备继续测试的条件。

---

三、第二步：历史 Bug 验证

1. 什么是历史 Bug 验证？

历史 Bug 验证，也叫缺陷复测。

意思是：之前测试人员提过的 Bug，开发说这个版本已经修复了，那么测试人员要重新验证一遍，看它到底是不是真的修好了。

比如之前有一个 Bug：

新注册用户无法登录。

开发在新版本里说已经修复了。

测试人员就要重新操作一遍：

1. 注册一个新用户；
2. 管理员审核通过；
3. 使用新用户登录；
4. 看是否能正常进入系统。

如果能登录，说明这个 Bug 修复成功，可以关闭。

如果还是不能登录，说明修复失败，需要重新打开 Bug，让开发继续修。

2. 为什么冒烟后建议先做历史 Bug 验证？

因为新版本通常包含两类内容：

• 修复了哪些历史问题；
• 新增或优化了哪些功能。

如果开发明确说某些 Bug 已经修复，那测试人员应该尽早验证。

如果历史 Bug 根本没修好，说明这个版本质量存在问题，应该尽快反馈开发，而不是等所有功能都测完才发现。

3. Bug 验证和回归测试不是一回事

这两个概念很容易混淆。

Bug 验证是看：

这个 Bug 本身有没有修好。

回归测试是看：

修这个 Bug 的过程中，有没有影响其他正常功能。

比如修复的是：

用户修改密码不生效。

Bug 验证只需要看：

• 修改密码是否成功；
• 新密码是否可以登录；
• 老密码是否失效。

但回归测试还要顺带看：

• 普通用户登录是否正常；
• 管理员登录是否正常；
• 修改密码后菜单权限是否正常；
• 修改密码后原有会话是否受影响。

所以，Bug 验证关注的是“问题本身是否解决”，回归测试关注的是“有没有引入新的问题”。

---

四、第三步：新功能测试

1. 什么是新功能测试？

新功能测试就是测试本次版本新增、修改、优化的功能是否可用。

比如 AI应用开发系统 8 月版本新增了：

知识库支持批量上传文件。

那测试人员就要围绕这个新功能设计测试场景，比如：

• 能不能批量上传多个文件；
• Word 文件能不能上传；
• PDF 文件能不能上传；
• Excel 文件能不能上传；
• 上传后能不能正常解析；
• 解析后能不能用于知识库问答；
• 上传失败有没有提示；
• 重复上传有没有处理；
• 大文件上传是否正常；
• 普通用户和管理员权限是否正确。

如果新功能测试过程中发现问题，就需要提 Bug。

比如：

批量上传 PDF 文件后，页面一直转圈，没有成功提示。

这就是新功能测试过程中发现的新缺陷。

2. 为什么要在核心回归前先测新功能？

因为新功能是这次版本的重点，也是最容易出问题的地方。

如果你一上来就做大量老功能回归，结果最后发现本次新增功能根本不可用，那前面很多测试工作可能就浪费了。

所以一般建议：

先测本次版本变化的地方，再测老功能有没有被影响。

---

五、第四步：核心功能回归测试

1. 什么是回归测试？

回归测试就是：

开发修复 Bug 或新增功能后，测试人员重新检查已有功能，确认原来正常的功能没有被改坏。

软件开发中经常会出现这种情况：

修好了 A 问题，结果把 B 功能弄坏了。

所以每次版本发版前，都需要做一定范围的回归测试。

2. 回归测试是不是要把所有老功能都测一遍？

不一定。

回归测试分很多种范围：

第一种：小范围回归

如果只是修了一个小 Bug，就只需要测这个 Bug 本身以及相关功能。

比如只修了：

新建会话报错。

那回归范围可以是：

• 新建会话；
• 历史会话；
• 模型问答；
• 会话列表；
• 不同用户下的会话权限。

不需要把知识库、智能体、用户管理、系统配置全部完整测一遍。

第二种：核心功能回归

如果是月度版本发布，一般需要做核心功能回归。

也就是把系统中最重要、最常用、最影响用户使用的功能测一遍。

以 AI应用开发系统 为例，核心功能可以包括：

• 登录；
• 注册；
• 修改密码；
• 模型对话；
• 新建会话；
• 历史会话；
• 知识库创建；
• 文件上传；
• 文件解析；
• 知识库问答；
• 智能体创建；
• 智能体绑定知识库；
• 用户管理；
• 权限菜单；
• 系统配置；
• 管理端访问；
• 门户访问。

这种不是所有细节都测到，但核心主流程必须保证可用。

第三种：全量回归测试

全量回归测试就是把系统所有旧功能都按照测试用例重新测一遍。

这种成本比较高，不是每次版本都做。

一般在这些情况下才做全量回归：

• 大版本上线；
• 改动范围很大；
• 改了登录、权限、网关、数据库、文件存储等底层能力；
• 系统准备正式交付客户；
• 之前版本质量不稳定；
• 领导要求上线前全面验证。

3. 月度版本一般做哪种回归？

对于普通月度版本来说，比较常见的是：

核心功能回归测试。

也就是说，不一定把所有老功能全部测一遍，但要把核心流程、常用功能、重要模块测一遍。

---

六、第五步：新 Bug 修复验证

在新功能测试和核心功能回归过程中，测试人员可能会发现新的 Bug。

比如测试 AI应用开发系统 新版本时发现：

• PDF 文件上传失败；
• 新建智能体后无法绑定知识库；
• 普通用户能看到管理员菜单；
• 模型对话偶发报错；
• 修改密码后仍然能用旧密码登录。

这些问题提给开发后，开发修复完会再次发版或更新测试环境。

测试人员这时候要做两件事：

1. 验证 Bug 是否修好

比如 Bug 是：

PDF 文件上传失败。

开发修复后，测试人员要重新上传 PDF 文件，看是否可以正常上传和解析。

这叫：

Bug 验证 / 缺陷复测。

2. 做小范围回归

不能只看 PDF 上传好了没有，还要看相关功能有没有被影响。

比如还要顺带测：

• Word 上传是否正常；
• Excel 上传是否正常；
• 文件解析是否正常；
• 知识库问答是否正常；
• 文件列表是否正常显示。

这叫：

小范围回归测试。

---

七、Bug 是否必须全部解决完才能升级生产？

很多人会以为：

所有 Bug 必须全部修完，才能升级生产。

实际项目中不一定是这样。

能不能升级生产，不是只看 Bug 数量，而是看 Bug 的严重程度和影响范围。

1. 致命问题：必须修复

比如：

• 系统打不开；
• 登录不了；
• 核心接口不可用；
• 数据丢失；
• 权限错乱；
• 普通用户能看到管理员数据；
• 模型对话完全不可用；
• 知识库上传完全不可用。

这种问题必须修复，不修不能上线。

2. 严重问题：原则上必须修复

比如：

• 核心功能偶发失败；
• 部分用户无法正常使用；
• 文件上传失败率较高；
• 重要流程无法走完；
• 页面关键按钮不可用；
• 模型调用不稳定。

这种问题一般也要修复后再上线。

除非有明确的规避方案，并且项目负责人、产品负责人或领导接受这个风险。

3. 一般问题：可以评估后上线

比如：

• 提示语不准确；
• 页面样式轻微错位；
• 非核心功能体验不好；
• 边缘场景报错；
• 不影响主流程使用。

这种问题可以记录到遗留问题清单中，后续版本再修复。

4. 建议类问题：可以后续优化

比如：

• 按钮位置不够美观；
• 页面文案可以更友好；
• 操作流程可以再简化；
• 加载速度可以继续优化。

这种一般不影响上线。

---

八、发布到生产前，测试人员要输出什么？

测试完成后，不是简单说一句“测完了”。

一般需要输出一个测试结论或发布建议。

可以包含以下内容：

1. 本次版本测试范围
2. 冒烟测试结果
3. 新功能测试结果
4. 历史 Bug 验证结果
5. 核心功能回归结果
6. 当前遗留 Bug 列表
7. 遗留问题影响说明
8. 是否建议升级生产

比如测试结论可以这样写：

本次 AI应用开发系统 8 月版本已完成测试环境验证，冒烟测试通过；本版本新增知识库批量上传功能已完成测试，主流程可用；历史缺陷已完成复测，核心功能回归通过。当前遗留 2 个一般问题，不影响系统主流程使用，建议记录风险后升级生产环境。

如果测试不通过，可以这样写：

本次 AI应用开发系统 8 月版本已完成冒烟测试和部分功能测试，但知识库问答存在严重问题，影响核心功能使用；同时普通用户权限存在异常，存在数据越权风险。当前版本不建议升级生产，建议开发修复后重新提测。

---

九、生产环境升级前，一般要满足哪些条件？

一个版本要升级到生产环境，至少要满足以下条件：

1. 冒烟测试通过
2. 本次新增功能主流程测试通过
3. 历史严重 Bug 已验证关闭
4. 核心老功能回归通过
5. 不存在致命或严重未解决问题
6. 一般问题已有记录和后续处理计划
7. 发布风险已经说明并被确认
8. 生产升级方案、回滚方案准备完成

特别要注意，生产升级不是测试人员一个人决定的。

一般需要测试、开发、产品、项目负责人一起确认。

测试人员提供的是：

版本质量情况和上线风险说明。

最终是否上线，需要项目负责人或相关负责人拍板。

---

十、升级生产环境时要注意什么？

测试通过后，进入生产升级阶段。

生产升级一般要关注这几件事：

1. 确认升级内容

比如：

• 本次升级哪个版本；
• 使用哪个镜像；
• 升级哪些服务；
• 是否有数据库脚本；
• 是否有配置文件变更；
• 是否有依赖服务变更。

2. 提前备份

生产升级前一定要备份重要数据。

比如：

• 数据库备份；
• 文件存储备份；
• 配置文件备份；
• 当前镜像版本记录。

这样如果升级失败，还能回退。

3. 准备回滚方案

生产升级不能只考虑成功，也要考虑失败怎么办。

比如：

• 新版本启动失败，如何切回旧版本；
• 数据库脚本执行失败，如何恢复；
• 服务异常，如何回退镜像；
• 用户访问异常，如何临时处理。

4. 选择合适升级时间

生产升级最好选择用户少的时间段。

比如：

• 晚上；
• 周末；
• 业务低峰期；
• 约定好的停机窗口。

5. 升级后做生产冒烟验证

生产环境升级完成后，还需要再做一次生产冒烟测试。

注意，这里的生产冒烟测试不是全量测试，而是快速确认生产环境核心功能是否正常。

比如：

• 生产系统能否访问；
• 用户能否登录；
• 首页是否正常；
• 核心接口是否正常；
• 模型对话是否正常；
• 知识库问答是否正常；
• 关键页面是否正常打开。

如果生产冒烟通过，说明生产升级基本成功。

如果生产冒烟失败，就要根据情况回滚或紧急修复。

---

十一、完整流程总结

一个新版本从测试到生产，大概可以按下面流程理解：

开发提交新版本镜像
        ↓
部署到测试环境
        ↓
冒烟测试
        ↓
历史 Bug 验证
        ↓
新功能测试
        ↓
核心功能回归测试
        ↓
新发现 Bug 提交开发修复
        ↓
Bug 修复后再次验证和小范围回归
        ↓
整理测试结果和遗留问题
        ↓
评估是否可以发布
        ↓
确认升级方案和回滚方案
        ↓
升级生产环境
        ↓
生产冒烟验证
        ↓
版本发布完成

---

十二、最后用一句话总结

新版本测试不是一上来就把所有功能全测一遍，也不是只测新功能。

更合理的做法是：

新版本部署后，先做冒烟测试，确认版本可测；然后验证本版本修复的历史 Bug；再测试本次新增和修改功能；之后对核心老功能做回归测试，确认没有被本次改动影响；测试完成后根据缺陷严重程度和遗留风险判断是否可以升级生产。生产升级前要准备备份和回滚方案，升级后还要做生产冒烟验证。

这样才能保证：

• 新功能可用；
• 历史问题已修复；
• 老功能没被改坏；
• 问题能追踪；
• 风险能说明；
• 生产升级更稳妥。