3. 输入域边界：数值、字符串与文件大小的实战挖掘
聊完枚举和状态，咱们进入一个更“硬”的话题——输入域边界。说白了，就是程序能接受的数据到底有多宽、多长、多大。我见过太多线上事故，都是因为开发觉得“用户不会这么输入”而埋下的雷。嗯，边界测试就是专门拔这些雷的。
3.1 数值输入边界：不只是最大最小值
很多人觉得数值边界就是测个最大值、最小值，再试个溢出就完事了。其实不然。我个人习惯把数值边界拆成三层：合法边界、非法边界、临界转换。
| 边界类型 | 测试值示例（int32） | 关注点 |
|---|---|---|
| 合法边界 | -2147483648, 2147483647 | 系统能否正常处理极限值 |
| 非法边界 | -2147483649, 2147483648 | 溢出后是否崩溃或返回合理错误 |
| 临界转换 | -1 → 0, 0 → 1, 99 → 100 | 跨符号、跨阈值时的逻辑分支 |
核心原则：数值边界不是一条线，而是一个“带”。边界两侧各延伸一个单位，往往就能暴露问题。
我在项目中遇到过这样一个案例：一个金融系统对交易金额做了 int32 限制，最大值 21 亿。测试时只测了 21 亿和 21 亿+1，都正常。结果上线后，用户连续交易导致累计金额溢出，变成了负数。为什么？因为开发只在单笔输入做了校验，没做累计值的边界保护。所以，数值边界要关注“输入时”和“运算后”两个阶段。
3.1.1 溢出测试的三种手法
- 直接溢出：输入超过类型最大值的值，比如给 byte 类型赋 128。
- 运算溢出：两个合法值相加/相乘后溢出。比如 100 万 × 100 万，结果超出 int32 范围。
- 转换溢出：浮点转整型、大数转小数时的精度丢失或溢出。比如 3.1415926535 转 float 会丢精度。
注意：很多语言对整数溢出是静默处理的（比如 C/C++ 的 unsigned int 溢出会回绕）。测试前一定要确认语言的溢出行为，是抛异常、截断还是回绕。
3.2 字符串长度边界：空串、最大长度与截断
字符串边界测试，我总结了一个“三字经”：空、满、破。
- 空：空串 ""、纯空格串 " "、null 值（如果语言支持）。
- 满：恰好等于最大长度、最大长度-1、最大长度+1。
- 破：超长字符串、含特殊字符的字符串（如 emoji、SQL 注入 payload）。
举个例子，一个用户名输入框限制 20 个字符。你会怎么测？
// 测试用例设计
// 1. 边界值：0、1、19、20、21 个字符
// 2. 特殊值：全角字符（每个占2字节）、emoji（占4字节）
// 3. 组合场景：20个emoji + 1个英文字母我曾经遇到一个坑：系统用 varchar(20) 存用户名，前端限制 20 个字符，后端也限制 20 个字符。但前端传的是 UTF-8 编码，一个中文占 3 字节，20 个中文就是 60 字节，直接撑爆了数据库字段。嗯，这里要注意：前端限制的“字符数”和后端限制的“字节数”往往不是一回事。
避坑指南：我曾经在测试一个国际化产品时，发现日文片假名和中文汉字在同一个字符串里，长度计算完全混乱。后来我养成了一个习惯：字符串边界测试必须覆盖单字节、双字节、四字节字符的混合场景。
3.3 文件大小边界：0字节与超大文件的博弈
文件上传是边界问题的重灾区。我把它分成四个维度：
| 维度 | 测试值 | 典型问题 |
|---|---|---|
| 零大小 | 0 字节文件 | 程序是否认为“空文件”是有效输入 |
| 最小有效 | 1 字节、1 KB | 极小文件能否正常解析 |
| 最大合法 | 限制值、限制值-1MB | 接近上限时性能是否下降 |
| 超限 | 限制值+1字节、限制值+1GB | 超限后是拒绝还是崩溃 |
你想想看，一个 0 字节的图片文件，上传后会发生什么？我见过有的系统直接返回“上传成功”，但预览时白屏；有的系统直接报 500 错误；还有的系统把空文件写进了数据库，导致后续所有查询都卡死。所以，0 字节文件必须作为独立测试用例，不能和“未选择文件”混为一谈。
3.3.1 大文件测试的隐藏陷阱
- 超时问题：大文件上传耗时过长，触发网关或负载均衡的超时断开。
- 内存溢出：如果后端把整个文件读入内存再处理，2GB 文件直接撑爆堆内存。
- 分片上传的边界：分片大小、分片数量、最后一片是否小于分片大小。
- 并发上传：多个用户同时上传大文件，磁盘 I/O 和带宽是否扛得住。
实战建议：文件边界测试不要只测“上传”环节。下载、预览、删除、重命名这些操作也要用边界文件去测。我曾经遇到一个系统，上传 2GB 文件没问题，但下载时直接 OOM，因为下载模块用了 ByteArrayOutputStream 缓存整个文件。
3.4 边界挖掘的“三维模型”
讲了这么多，我画了一张图来总结数值、字符串、文件大小这三类边界的核心逻辑。你可以把它当作边界测试的“检查清单”。
3.5 组合边界：1+1 > 2 的陷阱
单独测每个边界都过了，但组合起来就崩。这是最让人头疼的。我列几个常见的组合场景：
- 数值 + 字符串：年龄字段输入“-1”和“999岁”，系统怎么处理？
- 字符串 + 文件：文件名超长（255字符）的文件上传，系统是截断文件名还是拒绝？
- 数值 + 文件：文件大小刚好等于内存缓冲区大小，上传后处理是否触发边界条件？
重要提醒：组合边界测试不要贪多。优先覆盖“业务上最可能出现的边界组合”。比如电商系统，订单金额最大值 + 商品数量最大值 + 优惠券折扣最大值，这种组合往往能炸出意想不到的 bug。
好了，数值、字符串、文件大小这三类边界，说白了就是“程序能接受的数据到底有多宽”。测试时别只盯着单点，要把它们放在业务流程里去看。边界不是孤立存在的，它和业务逻辑、系统架构、第三方依赖都有关联。嗯，记住这一点，你的边界测试就不会只是走过场了。