1. 边界测试与验收条件概述
1.1 适用场景
边界测试并非在所有测试任务中都是必须的，但在以下场景中被证明是最有效的质量保障手段：
- 数值输入处理：年龄、金额、温度、传感器读数等连续或离散数值范围。
- 集合与容量限制：数组长度、字符串最大/最小字符数、列表元素个数、并发线程数上限。
- 时间与日期逻辑：有效期起始/截止、超时设定、倒计时归零、跨日/跨月/跨年边界。
- 状态机与条件分支：状态切换的触发阈值、分页查询的页码极限、审批流程的步骤边界。
- 外部接口与协议：API 请求体大小限制、WebSocket 消息帧长度、数据库字段精度溢出。
1.2 前置条件
- 需求文档或技术规格中已明确定义了输入域、输出域或状态转移的条件值。
- 已识别出至少一个可量化的“边界值”（如最小值、最大值、临界点）。
- 测试环境已搭建，能够稳定复现上述边界条件相关的功能点。
1.3 定义与核心价值
边界测试（Boundary Testing）是一种基于“错误很可能发生在输入或输出域的极值附近”这一经验规律而设计的测试方法。它与等价类划分相辅相成，专注于检查等价类边界上的行为是否正确。
其核心价值体现在三个维度：
- 缺陷密度最高：大量实际项目统计数据表明，边界附近的缺陷数量远高于非边界区域。
- 测试效率最优：相比穷举所有合法值，仅检查边界附近值即可覆盖绝大部分边界相关风险。
- 验收条件可量化：边界值天然是精确、可衡量的，能够转化为清晰、无歧义的验收标准。
1.4 常见误区
- 只检查一个边界值：真正的边界测试需要覆盖“边界值本身”、“边界紧邻的下一个值”和“边界紧邻的上一个值”。
- 混淆内部边界与外部边界：用户直接感知的是外部接口边界（如 API 请求上限），而系统内部实现也可能存在私有边界（如缓存大小、线程池容量）。
- 忽略业务语义边界：例如“1个月”在 31 天的月份和 28 天的月份边界值不同；用户登录失败第 5 次锁定与第 5 次成功登录后的行为差异。
- 样本量过大导致无效：边界测试并非等距抽样，不需要在合法区间内均匀取大量值，过度设计会稀释测试收益。
1.5 输入输出物
| 物项类型 | 具体内容 | 责任方 |
|---|---|---|
| 输入物 | 包含边界定义的需求/规格文档、等价类划分结果、接口契约 | 产品经理 / 架构师 |
| 输出物 | 边界测试用例清单（含边界值及上下邻近值）、验收条件矩阵、测试报告 | 测试工程师 |
1.6 责任边界
- 业务分析师：在需求中明确标注潜在的边界区间（如“金额不得超过 10,000 元”）。
- 开发工程师：在代码评审时确认内部边界值的校验逻辑是否正确实现。
- 测试工程师：系统化识别所有可量化的边界，设计覆盖“边界-1、边界、边界+1”的用例，并执行验收。
1.7 记录材料
本章节完成后应产出的记录材料包括：
- 边界测试概念速查卡（定义、价值、误区清单）。
- 业务系统边界初始识别清单（记录已发现的数值/容量/时间/状态边界点）。
1.8 异常处理
异常场景：需求文档中未明确给出任何可量化的边界值。
处理措施：与产品经理、开发共同进行增量边界推导，采用“业务常识 + 行业规范 + 历史缺陷”三角定位法，输出《边界推测补充说明》作为临时依据。
处理措施：与产品经理、开发共同进行增量边界推导，采用“业务常识 + 行业规范 + 历史缺陷”三角定位法，输出《边界推测补充说明》作为临时依据。
1.9 验收标准
- 团队能够区分边界测试与等价类划分的概念差异。
- 能够从任意一份业务需求中至少识别出 3 个显性边界值。
- 能够正确指出边界测试中“只取一个边界值”是错误做法。
讲师提示：边界测试不是孤立的活动，它通常与等价类划分并列出现在功能测试设计阶段。请学员牢记下面这张概念关系图，理解边界在测试设计全局中的位置。
1.10 操作步骤（快速入门）
- 识别边界：从需求/规格中提取所有“至少、最多、不超过、在…之间”的量化条件。
- 定义边界三元组：对每个边界值 B，列出 B-1、B、B+1（注意数据类型精度）。
- 设计对应预期：根据业务规则分别定义三元组中每个值的正确行为（接受/拒绝/转换）。
- 映射验收条件：将三元组写入《验收条件矩阵》，作为需求通过的判定依据。
- 执行并记录：在测试环境中执行用例，将实际输出与预期对比，记录偏差。