第四章 功能验收检查表：字段完整性、逻辑正确性、边界值覆盖、异常分支验证
适用场景
本流程适用于任何涉及功能验收的交付物（Web页面、后端接口、移动端功能、嵌入式界面等），需要从数据质量和逻辑质量两个维度对功能进行系统性审查的场景。当验收团队需要对功能的正确性、健壮性和边界表现做结构化评估时，使用本检查表可确保无遗漏。
前置条件
- 已完成功能冒烟测试，无阻断性缺陷。
- 已确认功能需求文档（PRD/用户故事/接口规范）处于基线状态。
- 验收人员具备业务逻辑理解能力，持有最新版本的功能验收检查表模板。
- 测试环境已部署待验收版本，数据准备就绪。
操作步骤
功能验收检查表分为四个检查域，按以下顺序依次执行：
提示：每个检查域都应独立记录发现，避免跨域干扰。建议使用统一的检查表模板（参见下文输入输出物）。
步骤一：字段完整性检查
- 核对界面/接口中所有字段是否与需求文档一一对应（无缺失、无多余）。
- 验证必填字段是否启用非空校验，选填字段是否允许不传或为空。
- 检查字段类型（字符串/数字/日期/枚举）与需求定义一致。
- 检查字段长度、精度、字符集（如允许中文/特殊字符）是否满足规格。
- 检查默认值、格式化规则（如日期格式、千分位）是否正确。
步骤二：逻辑正确性检查
- 基于业务流程图或状态机，验证功能在正常流程下的行为是否符合预期。
- 检查条件分支（if/else、switch、规则引擎）的覆盖：每个条件分支至少执行一次。
- 验证计算逻辑：数值计算、折扣、税率、积分等是否与公式一致。
- 检查状态流转：允许的状态转换是否全部实现，禁止的转换是否被阻止。
- 验证跨模块联动逻辑（如订单状态变更影响库存、通知等）。
步骤三：边界值覆盖检查
- 对输入数字/日期/长度字段，测试最小值、最大值、略小于最小值、略大于最大值。
- 测试空字符串/0/null/undefined/空列表等特殊边界输入。
- 测试列表/表格记录的边界：0条、1条、最大条目数、达到最大后增加。
- 测试并发边界：快速连续点击、大量数据同时提交。
- 测试时间边界：跨日、跨月、跨年、闰年、2月29日、23:59:59等。
步骤四：异常分支验证
- 测试网络中断、超时、服务端500/404/503错误时前端/客户端的处理（友好提示、重试机制、数据不丢失）。
- 测试非法输入（超出范围、格式错误、SQL注入字符）是否被合理拦截并给出明确提示。
- 测试权限异常：未登录、无权限操作时是否阻断并提示。
- 测试数据依赖异常：关联数据被删除后操作的错误处理（如引用已删除的父记录）。
- 测试后端异常及降级：接口返回异常码时客户端是否按约定处理（如显示兜底文案、静默重试）。
输入输出物
| 输入物 | 输出物 |
|---|---|
| 功能需求文档（PRD/用例/接口定义） | 功能验收检查表（已签署） |
| 功能验收检查表模板（空白） | 检查缺陷清单（含严重等级） |
| 测试环境可执行版本 | 功能验收报告（截屏/日志/数据快照） |
| 测试数据准备脚本 | 验收结论：“通过 / 有条件通过 / 不通过” |
检查表示例结构（JSON/YAML）：
{
"checklist_id": "FUNC-ACCEPT-004",
"module": "用户注册",
"fields": [
{"name": "用户名", "required": true, "type": "string", "min_len": 2, "max_len": 20, "status": "pass"},
{"name": "密码", "required": true, "type": "string", "min_len": 8, "max_len": 32, "status": "pass"},
{"name": "手机号", "required": true, "type": "string", "pattern": "^1\\d{10}$", "status": "fail"}
],
"logic_cases": [
{"test": "已注册手机号应提示'账号已存在'", "result": "pass"},
{"test": "密码强度不足时显示弱密码提示", "result": "fail"}
],
"boundary": [
{"input": "", "expect": "非空提示", "actual": "非空提示", "verdict": "pass"},
{"input": "a", "expect": "用户名太短", "actual": "系统无响应", "verdict": "fail"}
],
"exception": [
{"scenario": "网络断开点击注册", "expect": "网络连接失败提示", "actual": "提示正确", "verdict": "pass"}
]
}责任边界
- 验收负责人：组织检查，签字确认检查表，对检查结果的完整性和准确性负责。
- 开发小组：提供验收所需的测试版本、接口文档、环境说明；配合修复检查中发现的缺陷。
- 测试团队（可选）：辅助准备边界测试数据和异常场景模拟，但不替代验收人员的业务判断。
- 产品经理：争议需求理解时的最终裁定方。
记录材料
- 完整签署的功能验收检查表（含字段、逻辑、边界、异常各域）。
- 每个失败项的缺陷证据（截屏/日志/操作回放文件）。
- 边界值和异常测试的原始输入/输出记录（如CSV或截图）。
- 会议纪要（若存在争议或需要签字豁免的情况）。
常见陷阱：验收人员容易跳过“异常分支验证”或只测典型错误忽略并发/资源耗尽/第三方依赖异常。请务必在检查表中提前规划异常清单。
异常处理
- 发现阻断性缺陷：立即暂停验收，打回开发修复，修复后重新执行该功能的所有检查域。
- 发现非阻断性缺陷（如提示语不准确）：记录缺陷，可继续验收，但终签前必须确认修复或获得豁免签字。
- 检查表模板不匹配当前功能：由验收负责人调整模板并同步团队，调整项须在记录材料中注明。
- 测试环境数据污染：重新准备干净数据后从受影响步骤开始重测。
验收标准
- 所有四个检查域的检查项 100% 执行（不允许跳过或仅抽样）。
- 无 P0（阻断性）缺陷；P1 缺陷 ≤ 1 项且无替代方案风险；其余缺陷 ≤ 5 项。
- 每个失败项必须关联明确的证据和修复方案（或豁免签字）。
- 检查表签署后归档至项目配置库，作为版本交付的必要附件。