最近在梳理版本测试流程时，发现很多刚接触测试的人都会有一个疑问：
开发给了一个新版本，已经部署到测试环境了，测试人员到底应该先测什么？
是先测新功能？
还是先验证之前的 Bug？
还是直接把老功能全部测一遍？
测完以后，又怎么判断能不能升级到生产环境？
这篇文章就用比较通俗的方式，把一个新版本从测试环境到生产发布前的测试流程讲清楚。
一个新版本部署到测试环境后，测试流程一般不是：
直接把所有功能从头到尾测一遍。
更合理的顺序是：
新版本部署到测试环境
↓
1. 冒烟测试
↓
2. 历史 Bug 验证
↓
3. 新功能测试
↓
4. 核心功能回归测试
↓
5. 新 Bug 修复验证
↓
6. 发布前风险评估
↓
7. 升级到生产环境简单来说就是：
先确认版本能不能测，再确认以前的问题修没修好，再测本次新增功能，最后看老的核心功能有没有被影响。
冒烟测试就是新版本部署完成后，先快速检查系统最基本的功能能不能用。
它不是详细测试，而是判断这个版本有没有资格继续往下测。
通俗理解就是：
先看系统有没有“冒烟”、有没有一上来就炸。
比如一个系统刚部署完，测试人员先看：
如果这些最基础的功能都不行，比如系统打不开、登录不了、首页报错，那就没必要继续测新功能，也没必要测老功能了。
这时候应该直接反馈开发：
冒烟测试不通过，当前版本不可测，请修复基础问题后重新提测。
新版本部署到测试环境后，可以先冒烟检查：
只要这些核心入口都正常，才说明这个版本具备继续测试的条件。
历史 Bug 验证，也叫缺陷复测。
意思是：之前测试人员提过的 Bug，开发说这个版本已经修复了，那么测试人员要重新验证一遍，看它到底是不是真的修好了。
比如之前有一个 Bug：
新注册用户无法登录。
开发在新版本里说已经修复了。
测试人员就要重新操作一遍：
如果能登录，说明这个 Bug 修复成功，可以关闭。
如果还是不能登录，说明修复失败，需要重新打开 Bug，让开发继续修。
因为新版本通常包含两类内容：
如果开发明确说某些 Bug 已经修复，那测试人员应该尽早验证。
如果历史 Bug 根本没修好，说明这个版本质量存在问题，应该尽快反馈开发，而不是等所有功能都测完才发现。
这两个概念很容易混淆。
Bug 验证是看：
这个 Bug 本身有没有修好。
回归测试是看：
修这个 Bug 的过程中，有没有影响其他正常功能。
比如修复的是：
用户修改密码不生效。
Bug 验证只需要看：
但回归测试还要顺带看：
所以，Bug 验证关注的是“问题本身是否解决”，回归测试关注的是“有没有引入新的问题”。
新功能测试就是测试本次版本新增、修改、优化的功能是否可用。
比如 AI应用开发系统 8 月版本新增了：
知识库支持批量上传文件。
那测试人员就要围绕这个新功能设计测试场景，比如：
如果新功能测试过程中发现问题，就需要提 Bug。
比如：
批量上传 PDF 文件后，页面一直转圈，没有成功提示。
这就是新功能测试过程中发现的新缺陷。
因为新功能是这次版本的重点，也是最容易出问题的地方。
如果你一上来就做大量老功能回归，结果最后发现本次新增功能根本不可用，那前面很多测试工作可能就浪费了。
所以一般建议：
先测本次版本变化的地方，再测老功能有没有被影响。
回归测试就是：
开发修复 Bug 或新增功能后，测试人员重新检查已有功能，确认原来正常的功能没有被改坏。
软件开发中经常会出现这种情况：
修好了 A 问题，结果把 B 功能弄坏了。
所以每次版本发版前，都需要做一定范围的回归测试。
不一定。
回归测试分很多种范围：
如果只是修了一个小 Bug，就只需要测这个 Bug 本身以及相关功能。
比如只修了：
新建会话报错。
那回归范围可以是：
不需要把知识库、智能体、用户管理、系统配置全部完整测一遍。
如果是月度版本发布，一般需要做核心功能回归。
也就是把系统中最重要、最常用、最影响用户使用的功能测一遍。
以 AI应用开发系统 为例，核心功能可以包括：
这种不是所有细节都测到，但核心主流程必须保证可用。
全量回归测试就是把系统所有旧功能都按照测试用例重新测一遍。
这种成本比较高，不是每次版本都做。
一般在这些情况下才做全量回归：
对于普通月度版本来说，比较常见的是：
核心功能回归测试。
也就是说，不一定把所有老功能全部测一遍，但要把核心流程、常用功能、重要模块测一遍。
在新功能测试和核心功能回归过程中，测试人员可能会发现新的 Bug。
比如测试 AI应用开发系统 新版本时发现：
这些问题提给开发后，开发修复完会再次发版或更新测试环境。
测试人员这时候要做两件事：
比如 Bug 是：
PDF 文件上传失败。
开发修复后，测试人员要重新上传 PDF 文件，看是否可以正常上传和解析。
这叫：
Bug 验证 / 缺陷复测。
不能只看 PDF 上传好了没有，还要看相关功能有没有被影响。
比如还要顺带测：
这叫：
小范围回归测试。
很多人会以为：
所有 Bug 必须全部修完，才能升级生产。
实际项目中不一定是这样。
能不能升级生产，不是只看 Bug 数量，而是看 Bug 的严重程度和影响范围。
比如：
这种问题必须修复，不修不能上线。
比如：
这种问题一般也要修复后再上线。
除非有明确的规避方案，并且项目负责人、产品负责人或领导接受这个风险。
比如：
这种问题可以记录到遗留问题清单中，后续版本再修复。
比如：
这种一般不影响上线。
测试完成后，不是简单说一句“测完了”。
一般需要输出一个测试结论或发布建议。
可以包含以下内容：
1. 本次版本测试范围
2. 冒烟测试结果
3. 新功能测试结果
4. 历史 Bug 验证结果
5. 核心功能回归结果
6. 当前遗留 Bug 列表
7. 遗留问题影响说明
8. 是否建议升级生产比如测试结论可以这样写：
本次 AI应用开发系统 8 月版本已完成测试环境验证，冒烟测试通过；本版本新增知识库批量上传功能已完成测试，主流程可用；历史缺陷已完成复测，核心功能回归通过。当前遗留 2 个一般问题，不影响系统主流程使用，建议记录风险后升级生产环境。
如果测试不通过，可以这样写：
本次 AI应用开发系统 8 月版本已完成冒烟测试和部分功能测试，但知识库问答存在严重问题，影响核心功能使用；同时普通用户权限存在异常，存在数据越权风险。当前版本不建议升级生产，建议开发修复后重新提测。
一个版本要升级到生产环境，至少要满足以下条件：
1. 冒烟测试通过
2. 本次新增功能主流程测试通过
3. 历史严重 Bug 已验证关闭
4. 核心老功能回归通过
5. 不存在致命或严重未解决问题
6. 一般问题已有记录和后续处理计划
7. 发布风险已经说明并被确认
8. 生产升级方案、回滚方案准备完成特别要注意，生产升级不是测试人员一个人决定的。
一般需要测试、开发、产品、项目负责人一起确认。
测试人员提供的是：
版本质量情况和上线风险说明。
最终是否上线，需要项目负责人或相关负责人拍板。
测试通过后，进入生产升级阶段。
生产升级一般要关注这几件事：
比如：
生产升级前一定要备份重要数据。
比如：
这样如果升级失败，还能回退。
生产升级不能只考虑成功，也要考虑失败怎么办。
比如：
生产升级最好选择用户少的时间段。
比如：
生产环境升级完成后，还需要再做一次生产冒烟测试。
注意，这里的生产冒烟测试不是全量测试，而是快速确认生产环境核心功能是否正常。
比如：
如果生产冒烟通过，说明生产升级基本成功。
如果生产冒烟失败，就要根据情况回滚或紧急修复。
一个新版本从测试到生产，大概可以按下面流程理解：
开发提交新版本镜像
↓
部署到测试环境
↓
冒烟测试
↓
历史 Bug 验证
↓
新功能测试
↓
核心功能回归测试
↓
新发现 Bug 提交开发修复
↓
Bug 修复后再次验证和小范围回归
↓
整理测试结果和遗留问题
↓
评估是否可以发布
↓
确认升级方案和回滚方案
↓
升级生产环境
↓
生产冒烟验证
↓
版本发布完成新版本测试不是一上来就把所有功能全测一遍，也不是只测新功能。
更合理的做法是：
新版本部署后，先做冒烟测试，确认版本可测；然后验证本版本修复的历史 Bug；再测试本次新增和修改功能；之后对核心老功能做回归测试，确认没有被本次改动影响；测试完成后根据缺陷严重程度和遗留风险判断是否可以升级生产。生产升级前要准备备份和回滚方案，升级后还要做生产冒烟验证。
这样才能保证：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。