4、字符串边界测试：空字符串、长度限制、字符集边界
字符串边界测试，说白了就是看看你的程序对输入字符串的“底线”和“极限”处理得怎么样。我个人习惯把这部分测试分成三类：空字符串、长度限制、字符集边界。每一类做扎实了，很多线上事故就能提前拦住。
你想想看，一个用户注册页面的用户名输入框，要是空字符串没处理好，系统直接报500，这体验得多糟糕？所以，这块内容值得你花时间好好梳理。
4.1 空字符串：最容易被忽略的输入
空字符串是所有字符串边界里最基础，也最容易踩坑的点。很多开发觉得“用户总不会什么都不填吧？”——嗯，还真会。不仅用户会，程序调用接口时传个空参也很常见。
测试要点
- 直接提交空字符串：最常见的场景，看系统是否崩溃或报不明错误。我建议接口层就应该有断言校验，而不是等到数据库层报错。
- 只包含空格：很多人觉得空字符串就是`""`，其实`" "`也是问题高发区。我在项目中遇到过，用户输入了三个空格，系统没做trim()，结果数据库里存了一堆空白记录，排查了半天。
- 特殊空白字符：比如`\t`、`\n`、`\r`、`\u00A0`（不间断空格）。这些字符肉眼看不见，但程序会当成有效内容处理。避坑指南：我曾经被`\u200B`（零宽空格）坑过，前端显示正常，后端校验死活过不去，查了整整一个下午。
核心原则：所有字符串输入，第一层校验必须是“是否为空或仅包含空白”。这层没过，后面的长度和字符集校验根本没意义。
def validate_string(input_str: str) -> bool:
# 先检查空字符串
if not input_str or input_str.strip() == "":
return False
# 再检查长度
if len(input_str) > 100:
return False
# 最后检查字符集
# ...
return True
4.2 长度限制：不仅仅是最小值和最大值
长度边界测试，很多人的第一反应就是测最小长度和最大长度。这当然没错，但如果你只做这两点，线上大概率会出问题。
我建议的测试维度
| 测试维度 | 描述 | 案例 |
|---|---|---|
| 最小值边界 | 长度为0或最小允许长度 | 密码最少6位，测6位和5位 |
| 最大值边界 | 长度为最大允许长度 | 用户名最长20个字符，测20和21 |
| 溢出长度 | 远超最大长度 | 提交10万个字符，看接口是否会超时或OOM |
| 截断边界 | 数据库字段或显示区域有固定长度时 | varchar(50)，提交51个字，看是报错还是静默截断 |
关于截断问题，我想多说两句。不同的数据库和框架处理方式不一样。MySQL严格模式下会报错，宽松模式会静默截断。我记得有一次生产事故，就是因为截断导致数据丢失，客户投诉才发现的。所以，一定要在业务代码里主动做长度校验，不要依赖数据库行为。
长度溢出攻击：攻击者可能通过提交超长字符串，尝试触发缓冲区溢出或拒绝服务攻击。我建议接口层要设置合理的最大长度限制，过长的请求直接拒绝，不要做任何处理。
4.3 字符集边界：Unicode 和多语言场景
字符集边界测试，这就更有意思了。很多人只测 ASCII 字符，觉得够用了。实际上，现代应用如果面向全球用户，不测 Unicode 字符，简直就是给自己埋雷。
常见问题类型
- 多字节字符：中文字符（UTF-8下3字节）、emoji（4字节）、生僻字。我曾经遇到过用户注册用了“𠀀”（CJK扩展区B的汉字），结果数据库字符集不是utf8mb4，直接存不进去。
- 组合字符：比如带变音符号的拉丁字母（é、ü），或者韩文组合字。这些字符在Unicode里可以由单个码点构成，也可以由基础字符+组合符号构成。
- 零宽字符：零宽空格、零宽连接符等。这些字符在显示上不可见，但会影响字符串长度计算和校验逻辑。
- 控制字符：ASCII 0-31号字符，比如空字符、退格、换页等。这些字符在某些场景下会导致协议解析异常。
# 测试用例：不同字符集的字符串
test_cases = [
"Hello", # 纯ASCII
"你好世界", # 中文
"こんにちは", # 日文
"안녕하세요", # 韩文
"👋🌍🌟", # emoji
"á", # 组合字符
"a\u0301", # 分解表示的组合字符
"\u200B", # 零宽空格
"\x00\x01\x02", # 控制字符
]
面对这些字符集问题，我的做法是：先确定业务上允许的字符范围，然后用正则或白名单做过滤。不要依赖黑名单，因为Unicode字符集太大了，总有你没想到的字符。
4.4 综合测试流程与SVG框架
前面说了三种边界类型，实际测试的时候，我建议把这三者结合起来测。比如一个字符串，可能同时是“超长+空字符+控制字符”。这种组合攻击往往能突破单一的校验逻辑。
下面这张图，梳理了我个人常用的字符串边界测试流程：
从图上你可以看到，三个维度是并行校验的，互不依赖。但我个人的习惯是：先过空字符串，再过长度，最后做字符集校验。因为空字符串的校验最轻量，能快速过滤掉无效输入，减轻后续校验的压力。
4.5 实战建议与避坑指南
到这里，我把字符串边界测试的核心内容都讲完了。最后再分享几个实践中容易忽略的地方：
我的建议：在项目早期就建立字符串测试的模板化用例。把空字符串、最小长度、最大长度、Unicode字符、emoji、控制字符写好通用用例。每个接口直接复用这些用例，能省不少事。
- 注意编码转换：前端传过来的是UTF-8，后端接口接收后内部转码，这个过程中可能丢失字符。我曾经因为编码不一致，导致emoji字符被转成了问号，用户反馈说表情发不出去。
- 测试自动化：手点点不完这么多组合的。我建议用参数化测试框架，把所有边界用例列出来，批量跑。每次改到字符串处理逻辑时，一键回归。
- 全局处理 vs 局部处理：我更喜欢在Web框架层面做统一的字符串过滤，而不是每个接口都自己写一遍。这样代码干净，也不容易遗漏。
注意：不同编程语言对字符串长度的计算方式不同。Python的len()是按Unicode码点数计算的，但数据库的varchar长度可能按字节数。这种不一致，是字符串边界Bug的高发区。
字符串边界测试，看起来基础，但做扎实了，能挡住绝大多数跟输入相关的线上故障。别偷懒，把这三层校验都测透了，你的系统会感谢你的。