软件测试流程（含项目流程与测试执行细则）

一、项目流程与测试流程的关系

原则：测试活动嵌在项目各阶段中；越早参与需求与设计，返工越少。Bug 分析与质量报告用于驱动流程改进，形成闭环。

二、软件项目流程（通用阶段模型）

最小产出物建议：项目一页纸、需求追溯表（需求↔用例↔缺陷）、接口/环境说明、发布说明与回滚方案、已知问题列表。

三、敏捷/迭代型项目中的“小项目流程”

迭代计划 → 需求澄清 → 设计/任务分解 → 开发与每日集成 → 测试设计并行 → 提测 → 冒烟 → 新需求测试 → 回归 → 演示/验收 → 发布或火车发布

四、测试全流程框架（从计划到收尾）

便于写入制度：每步有输入、活动、输出。

执行顺序（默认）：① 冒烟（不通过则打回，不进入深度测试）② 新需求用例执行 ③ 回归 ④ 性能/安全等专项（按需）。

五、冒烟测试

5.1 什么是冒烟测试

在正式进入本轮系统/新功能深度测试之前，先对待测版本的主要功能、主干路径做一轮快速检查，判断当前构建是否具备可测性。

5.2 如何选择冒烟用例

1. 选择主干流程的正向用例（能代表“系统能跑起来、核心业务能走通”）。
2. 各主要模块都要有覆盖（不必细测每个分支，但模块级入口要有）。
3. 与回归用例的侧重点不同（二者可部分重叠，但目的不同）：

5.3 如何判断冒烟测试通过

团队可约定量化标准，常见做法：

• 冒烟用例通过率 100%（且无不阻塞的致命环境问题），则冒烟通过，进入新需求/系统测试。
• 任一条冒烟失败：打回修复或重新提测，避免在坏构建上浪费大量执行时间。

（若自动化冒烟：还可约定关键任务全部绿等同“通过”。）

5.4 冒烟测试的意义

1. 减少无效重复执行，提高整体测试效率。
2. 开发与测试对提测质量达成一致标准（准入门槛清晰）。
3. 尽早暴露阻塞级问题（崩溃、核心不可用、环境错误等）。

5.5 若没有冒烟测试会怎样

版本集成质量与提测质量缺少统一门槛，容易出现：坏构建占用测试时间、缺陷发现过晚、发布前集中爆雷等情况，整体版本质量风险显著升高。

六、新需求测试

6.1 第一轮及后续轮次

1. 第一轮（及后续轮）新需求测试：按用例执行测试，发现缺陷及时提交 Bug，跟踪修复与验证。
2. 理想情况：新需求开发质量高、缺陷少，核心用例一轮即可测完并通过。
3. 不理想情况：需多轮新需求测试（修复—验证—再测关联），轮次无固定上限，以完成标准为准。

6.2 过程要求

• 每日同步测试进度（已完成范围、阻塞项、风险、次日计划），形式可为站会、日报或协作看板。

6.3 新需求测试完成标准（进入大范围回归/预发前的建议）

同时满足（可按团队裁剪）：

1. 本版本新需求相关开发任务均已完成（或仅剩已确认的轻微项并有豁免）。
2. Bug 收敛到约定标准：例如主干功能均可用；P0 为 0；P1 在可控数量内且均有评估。
3. 计划内新需求用例已执行，通过率满足团队出口约定。

七、回归测试

7.1 定义

验证软件原有功能在代码修改、缺陷修复或需求变更之后是否仍然完整、正确，未被“改坏”。

7.2 回归测试用例的选择

1. 与本版本新需求强关联的模块（接口、数据、页面联动）。
2. 产品全功能中的主干用例（核心用户路径）。
3. 版本兼容、系统兼容、浏览器/机型等兼容性用例（若本版本涉及底层或依赖变更）。
4. 与历史遗留问题相关的用例（防回归）。

7.3 回归测试完成标准

1. 建议在开发主分支上“功能冻结”或“仅允许发布相关修复”之后，安排至少一轮完整回归（团队也可约定每轮修复后再迷你回归）。
2. 完成标准：缺陷达到基本收敛（如 P0 清零、P1 达标）；无未解决的阻塞项；回归用例执行率与通过率满足出口约定。
3. 不理想情况：需多轮回归，直至满足发布准出或项目组明确决策（有条件发布/延期）。

八、Bug 管理

8.1 Bug 单必备属性

8.2 严重级别定义（团队可微调文案，但级别含义建议统一）

（1）致命（P0 / Blocker）

系统无法继续测试或核心不可用，或造成严重稳定性/数据问题，例如：

• 系统崩溃、死机、进程无法启动或异常退出
• 模块无法启动或异常退出导致流程中断
• 用户数据丢失或破坏
• 常用核心功能完全无法使用
• 功能实现与需求严重不符且阻断主流程
• 其他导致测试无法继续的问题（如持续500、核心接口全失败）

（2）严重（P1 / Critical）

主要功能存在严重缺陷，影响功能或操作，但未必整机崩溃，例如：

• 功能未实现或功能错误
• 功能与需求不符（未达到致命程度但影响主流程分支）
• 刷新错误、数据未更新等导致业务错误
• 常用界面严重错位导致无法操作
• 安全性问题（按团队安全规范定级）
• 性能明显低下达到不可用或体验极差（有量化阈值更佳）

（3）一般（P2 / Major）

界面、性能、兼容性等中等影响，例如：

• 边界条件下错误
• 提示信息错误（未提示、文案错误、误导）
• 长时间操作无进度提示
• 光标/焦点跳转异常、定位错误
• 兼容性问题（特定环境）
• 影响功能或界面的错别字、拼写错误（不影响理解的可降级）

（4）建议/提示（P3 / Minor）

易用性、优化类、轻微展示问题，例如：

• 界面格式不规范
• 提示文案优化、文案不一致
• 文字排版轻微问题
• 个别不影响理解的错别字
• 可编辑区与只读区缺少明显视觉区分等体验优化

8.3 书写注意

• 一条 Bug 尽量只描述一个问题，便于指派与验证关闭。
• 注明数据前置条件（账号、订单状态等），避免“无法复现”。

九、Bug 生命周期

9.1 简化的 Bug 生命周期（适合小团队）

适合快速流转、角色较少时使用：

文字等价：新建 → 已确认 → 修复中 → 待验证 →已关闭；验证不通过 →重新打开→ 修复中；非缺陷可走已拒绝。

9.2 经典的 Bug 生命周期（角色与环节更细）

在简化版基础上，常见增加：指派、延期、挂起、待合并、多环境验证等。示意如下（可与 Jira/禅道等工具状态映射）：

落地建议：在缺陷系统中固定状态字典与转移规则（谁可从“修复中”到“待验证”），避免状态混乱。

十、Bug 分析

10.1 为什么要做 Bug 分析

Bug 是测试的重要产出之一，从中可挖掘：

• 版本质量与薄弱模块
• 需求、开发、环境、流程上的系统性问题

用于优化流程、提高后续版本质量，形成闭环。

10.2 Bug 类型（根因/归因维度，便于统计）

1. 需求不明确导致的缺陷
2. 实现与需求不一致
3. 环境/配置/数据问题引起的缺陷
4. 兼容性问题
5. 开发考虑不周（边界、异常、并发等）
6. 其他（网络波动、性能阈值、第三方依赖等）
7. 体验优化（可归为建议类或低优先级缺陷）

流程改进示例：

• 若“需求不明确”占比高 → 加强需求评审与验收标准。
• 若“开发考虑不周”占比高 → 加强开发自测、冒烟用例与 Code Review。

10.3 按软件开发与测试阶段统计 Bug 数量

建议在版本中统计各阶段发现/关闭的缺陷数，例如：

1. 需求评审阶段（评审记录的问题）
2. 开发自测阶段（提测前由开发发现）
3. 功能/新需求测试阶段
4. 回归测试阶段
5. 预发布与正式环境验证阶段

如何解读（示例）：

• 功能测试阶段 Bug 特别多：可能开发自测不足或提测标准过松 → 强化自测清单与冒烟。
• 回归阶段 Bug 高于预期：部分本可在功能期发现 → 测试侧可复盘用例覆盖与探索策略；同时检查变更影响分析是否到位。
• 预发/线上才发现的致命问题：检查环境一致性、发布检查单、监控与灰度策略。

10.4 线上 Bug 分析

对生产环境暴露的缺陷做同样维度的归类与复盘：

• 哪些类型在线上占比高（漏测、监控未发现、灰度未覆盖等）
• 反推测试用例、自动化、发布流程、监控告警的补强点

十一、质量报告应包含的内容

质量报告是发布决策的重要依据之一，建议至少包含：

1. 测试基本情况
   • 测试时间段、被测版本/迭代号、测试范围（在测模块与不在测范围说明）
2. 测试内容与结果汇总
   • 用例执行概况（总数、通过/失败/阻塞、执行率、通过率）
   • 缺陷汇总（按级别、模块、状态）
   • 能否上线的结论：建议发布 / 有条件发布 / 不建议发布
3. 遗留 Bug 与风险分析
   • 未关闭缺陷列表、业务影响、是否豁免及签字人
4. 缺陷统计与分析
   • 与历史版本对比趋势；根因类型分布（见第十节）
5. 项目相关人员与协作说明（可选）
   • 测试投入人天、关键依赖方、阻塞项处理情况
6. 其他（按项目需要）
   • 专项测试结论（性能/安全）、兼容性结论、已知限制说明

可与第十二节「发布准出」核对后定稿。

十二、提测准入、发布准出与发布评审

12.1 提测准入（开发 → 测试）

12.2 发布准出（测试 → 发布）

12.3 发布评审会（短议程）

1. 版本范围与变更摘要（产品/发布经理）
2. 质量报告与残留风险（测试）
3. 运维与监控就绪（运维）
4. 决策：发布 / 灰度 / 延期（纪要或签字）

十三、角色职责（RACI 简化）、时间线与资产清单

13.1 RACI 简化

（R 执行，A 负责，C 协作，I 知会；A 可依组织改为项目经理。）

13.2 瀑布式小版本时间线示例

13.3 建议维护的资产

1. 《测试计划》/《测试一页纸》
2. 用例库 + 需求追溯表
3. 《提测准入 checklist》
4. 《发布准出 checklist》
5. 《质量报告》模板
6. 《发布说明》+《已知问题》
7. 冒烟用例集（与提测标准绑定）
8. 回归用例集（主干 + 影响分析更新机制）