第3章 功能验收测试执行步骤：冒烟检查、功能覆盖、边界测试、结果记录
功能验收测试是上线前最后一道质量闸门，通过四个递进阶段——冒烟检查、功能覆盖、边界测试、结果记录——逐层验证版本质量。本章给出每个阶段的具体执行方法、判定标准与输出要求，确保验收过程可重复、可追溯、可度量。
适用场景
- 开发完成提测，测试环境部署稳定并通过健康检查（服务存活、中间件连通）
- 功能测试用例已通过评审，覆盖全部验收需求，且冒烟测试用例已标定
- 需要进行正式验收测试的版本迭代节点，如 Sprint 结束、Release Candidate 发布、紧急修复版本提测
- 验收测试由测试工程师主导，产品经理与开发工程师协同确认最终结果
前置条件
- 提测版本已部署至测试环境，环境健康检查通过（服务运行正常、依赖中间件可用、网络连通）
- 功能测试用例已通过评审，覆盖全部验收需求，冒烟测试用例已标定，通过标准已确认
- 测试数据已准备，包括正常业务数据与边界测试数据（最大/最小值、空值、超长值、特殊字符集）
- 冒烟测试通过标准已确认：核心主流程用例通过率必须为 100%
- 缺陷跟踪系统（如 Jira、禅道、Tapd）已配置，项目与版本信息正确，缺陷模板已就绪
- 测试环境与生产环境配置差异清单已评审，不影响验收结论
操作步骤
步骤1：冒烟检查（Smoke Test）
冒烟检查的目标是快速验证系统核心主流程是否可用，避免将存在致命缺陷的版本带入后续深度测试。执行冒烟检查时，只运行预定义的冒烟测试用例集，不展开全量用例。
- 执行动作：按冒烟测试用例顺序，逐条执行核心业务流程（如登录、创建、提交、查询、导出）；使用生产模拟数据或脱敏后的真实数据
- 判定标准：所有冒烟用例必须全部通过（通过率 100%）；任一用例失败即判定为冒烟失败，停止后续测试
- 失败处理：标记版本为“冒烟失败”，在缺陷系统中登记阻塞性缺陷，版本退回开发团队修复后重新提测
- 产出：冒烟测试执行记录、冒烟通过/失败结论
步骤2：功能覆盖（Functional Coverage）
功能覆盖阶段按照评审通过的验收测试用例，逐项验证需求规格中约定的功能行为，确保所有功能点均被覆盖且结果符合预期。
- 执行动作：按照测试用例的模块分组，逐条执行功能验证；每条用例独立记录实际结果与预期结果的对比
- 覆盖度要求：验收用例执行覆盖率达到 100%（含正向与反向用例），不允许跳过或遗漏未执行
- 结果标记：通过（Pass）/ 失败（Fail）/ 阻塞（Blocked）；失败用例必须关联缺陷编号，阻塞用例注明阻塞原因
- 产出：功能测试执行记录表、功能覆盖通过率统计
步骤3：边界测试（Boundary Testing）
边界测试聚焦于输入字段的临界值、数据长度边界、枚举值边界以及异常输入场景，验证系统在极限与异常条件下的行为是否符合预期。
- 执行动作：针对每个输入字段（文本、数值、日期、文件大小等），执行最小值、最大值、略超最大值、空值、超长值、特殊字符、SQL 注入字符等测试
- 重点关注区域：用户输入框、API 请求参数、文件上传大小与格式、分页边界（第1页、最后1页、超范围页）、并发边界
- 判定标准：系统不崩溃、不泄露敏感信息、错误提示友好且准确；不允许出现未捕获的异常堆栈或白屏
- 产出：边界测试执行记录、边界缺陷清单
步骤4：结果记录（Result Recording）
结果记录阶段将前三阶段的执行数据汇总，形成完整的验收测试报告，并对缺陷进行分类定级，输出验收结论。
- 执行动作：汇总冒烟检查、功能覆盖、边界测试的全部执行记录；核对缺陷列表中每个缺陷的状态（新建/已修复/已关闭）
- 数据完整性检查：每条用例必须有执行结果，每个失败用例必须关联缺陷编号，每个缺陷必须有优先级和责任人
- 报告生成：输出《功能验收测试报告》，包含测试范围、执行概况、通过率统计、缺陷分布、遗留风险、验收结论
- 产出：功能验收测试报告、缺陷清单（按优先级排序）、验收结论（通过 / 有条件通过 / 不通过）
实操要点：冒烟检查通过是继续执行的前提条件，严禁在冒烟失败的情况下进入功能覆盖阶段。边界测试应在功能覆盖全部通过后再执行，避免因基本功能缺陷干扰边界验证的效率。
输入与输出物
| 类别 | 内容 | 责任方 |
|---|---|---|
| 输入 | 需求规格说明书、功能测试用例（含冒烟用例与边界用例） | 产品经理 / 测试工程师 |
| 输入 | 提测版本说明（含版本号、变更清单、依赖组件版本） | 开发工程师 |
| 输入 | 测试环境部署确认单、环境健康检查报告 | 运维 / 测试工程师 |
| 输出 | 功能验收测试报告（含执行概况、通过率、缺陷分布） | 测试工程师 |
| 输出 | 缺陷列表（按优先级排序，含状态与责任人） | 测试工程师 |
| 输出 | 验收结论（通过 / 有条件通过 / 不通过） | 测试负责人 |
责任边界
| 角色 | 职责 | 产出物 |
|---|---|---|
| 测试工程师 | 执行冒烟检查、功能覆盖、边界测试；记录结果；提交缺陷 | 测试执行记录、缺陷单 |
| 开发工程师 | 修复缺陷；修复后重新提测；提供版本变更说明 | 修复版本、缺陷修复说明 |
| 测试负责人 | 审核测试报告；组织验收评审；输出验收结论 | 验收结论、评审纪要 |
| 产品经理 | 确认功能实现与需求一致；对验收争议进行裁决 | 验收签字 / 需求变更确认 |
记录材料
每轮功能验收测试必须留存以下记录，作为版本发布的可追溯依据：
- 功能验收测试记录表：包含用例编号、模块、用例名称、预期结果、实际结果、状态（通过/失败/阻塞）、缺陷编号、执行人、执行时间
- 缺陷跟踪单：与缺陷系统对应，包含缺陷标题、复现步骤、优先级、责任人、状态、修复版本
- 验收测试报告：汇总上述数据，形成版本级质量结论
以下为测试记录表的字段结构示例（实际执行时建议使用缺陷管理系统或电子表格）：
功能验收测试记录表（模板字段）
版本：v2.3.1 | 测试日期：2025-01-15 | 测试人：XXX
| 用例编号 | 模块 | 用例名称 | 预期结果 | 实际结果 | 状态 | 缺陷编号 |
| TC-001 | 登录 | 正常登录 | 登录成功 | 登录成功 | 通过 | - |
| TC-002 | 登录 | 错误密码 | 提示错误 | 提示错误 | 通过 | - |
| TC-003 | 登录 | 密码为空 | 提示必填 | 提示必填 | 通过 | - |
| TC-004 | 订单 | 创建订单 | 创建成功 | 创建成功 | 通过 | - |
| TC-005 | 订单 | 订单金额为0 | 提示无效 | 提示无效 | 通过 | - |
| TC-006 | 订单 | 订单金额超限 | 提示超限 | 系统报错 | 失败 | BUG-023 |异常处理
| 异常类型 | 处理方式 | 责任方 | 处理时限 |
|---|---|---|---|
| 冒烟失败（核心主流程不可用） | 立即停止测试，版本打回；开发团队修复后重新提测，重新执行冒烟检查 | 开发工程师 | 2小时内响应 |
| P0 缺陷（阻塞后续测试） | 暂停当前模块测试，等待修复；修复后回归该模块全部用例 | 开发工程师 + 测试工程师 | 4小时内修复 |
| P1 缺陷（影响主要功能） | 记录缺陷并继续测试；修复后补充回归 | 开发工程师 | 24小时内修复 |
| 环境异常（服务宕机、数据丢失） | 暂停测试，由运维修复环境；环境恢复后重新执行受影响用例 | 运维 / 测试工程师 | 按SLA执行 |
| 测试数据不足或错误 | 补充或修正测试数据后继续执行；已执行用例不受影响 | 测试工程师 | 自行控制 |
关键提醒：冒烟失败或出现 P0 缺陷时，严禁以“赶进度”为由跳过修复直接进入下一阶段。验收测试的核心目标是守住质量底线，任何绕过行为都会将风险带入生产环境。
验收标准
功能验收测试全部执行完毕后，必须同时满足以下标准方可进入发布评审节点：
- 冒烟测试通过率 = 100%，且所有冒烟用例均为“通过”状态
- 功能覆盖通过率 ≥ 95%（通过用例数 ÷ 总执行用例数 × 100%）
- 无 P0 / P1 级未关闭缺陷；P2 及以下缺陷已确认修复方案或已在缺陷列表中明确标记为“已知风险”
- 边界测试全部通过，无未处理的边界异常
- 功能验收测试报告已生成并经测试负责人审核签字
- 所有记录材料（测试记录表、缺陷清单、验收报告）已归档至版本发布目录