说到测试用例写不对，我猜你肯定遇到过这种场景：用例写了一大堆，执行起来也没啥问题，结果上线后还是被用户抓到了 Bug。这时候复盘一下，十有八九是边界没厘清。
边界这东西，听起来抽象，其实就藏在你日常写的每一个输入框、每一个下拉菜单、每一个计算逻辑里。今天咱们不聊那些教科书式的定义，就聊聊一个真实的故事，以及怎么通过“边界思维”把测试做得更扎实。
那个让用户抓狂的“登录失败”
先说个最近听到的真实案例。
某 App 的登录模块，测试同学按照常规思路写用例：
- 正确账号+正确密码，预期成功；
- 正确账号+错误密码，预期失败；
- 错误账号+正确密码，预期失败；
- 空账号+空密码，预期失败。
用例通过，提测，上线。
结果上线第三天，用户反馈：“我用户名输对了，密码也输对了，但提示‘账号不存在’！”
开发懵了，测试也懵了。最后排查发现，问题出在用户名的大小写边界上。有些用户注册时用了全小写，登录时手抖输成了首字母大写。后端在做用户校验时，没有做大小写忽略处理，直接把“ZhangSan”当成了“zhangsan”。
这个 Bug 的本质是什么？是逻辑边界没厘清。
登录失败的边界，不仅仅是“对/错”这两个状态，还包括：
- 输入内容的格式边界（大小写、空格、特殊字符）；
- 系统响应的提示边界（到底提示“密码错误”还是“账号不存在”，这涉及到信息安全，也涉及到用户感知）；
- 异常场景的状态边界（账号被封禁、密码过期、系统维护时，登录行为的边界）。
测试同学只覆盖了“明文输入”的边界，没覆盖“格式差异”的边界。所以，用例写得再标准，也测不出这个洞。
数据溢出：当输入突破“常规”的天花板
如果说登录失败是“逻辑边界”的坑，那数据溢出就是“容量边界”的坑。
另一个案例，某金融 App 的金额输入框。测试用例里写了：
- 输入 0，预期正确；
- 输入 100，预期正确；
- 输入 999999999，预期正确（因为觉得正常人不会输这么多）。
结果上线后，有用户输入了 9999999999（10个9），系统直接崩溃，报错“NumberFormatException”。
开发一看，说：“这不是正常用户的输入啊，谁会输10位数？”
但测试同学反驳：“边界测试的目的，就是测那些‘不正常’的输入。”
这里的问题，是数据类型边界没搞清楚。金额字段如果是 int，最大值是 21 亿；如果是 long，最大值是 900 多亿。但很多开发在写前端校验时，只做了“最大值限制”，没做“溢出处理”。一旦用户通过 F12 绕过前端校验，直接发请求，后端接收到超大数据，就会崩。
这个案例告诉我们：边界测试，不能只信前端校验，后端也必须有自己的边界防御。
功能边界的三个维度
聊了这么多案例，咱们来提炼一下。功能边界，到底怎么厘清？我总结为三个维度：输入边界、状态边界、逻辑边界。
1. 输入边界：那个“刚刚好”的临界点
输入边界是最直观的。比如：
- 输入框长度为 10，你测 10 吗？测 11 吗？测 0 吗？
- 金额字段，你测 0.01 吗？测 -1 吗？测 999999999 吗？
- 日期字段，你测 2023-02-30 吗？测 1900-01-01 吗？
这些“临界值”，就是输入边界。测试时，要围绕临界值，上下各延伸一个单位。
比如，最大值是 100，那就要测 99、100、101。
2. 状态边界：那个“切换”的瞬间
状态边界，是指系统从一种状态切换到另一种状态时的边界。比如：
- 优惠券从“可用”变成“已使用”；
- 订单从“待支付”变成“已支付”；
- 账号从“正常”变成“封禁”。
这些切换瞬间，就是状态边界。测试时，要覆盖状态切换前后的所有组合。
比如，优惠券“已使用”后，还能不能再领？还能不能再抢？这些边界，必须测到。
3. 逻辑边界：那个“隐藏”的坑
逻辑边界，是最难发现的。它往往藏在业务规则里。比如：
- 满 100 减 20，那你输入 99.99，预期是减 0 还是减 20？
- 积分兑换，你积分正好够换 1 个，但兑换后积分变成 0，还能再换吗？
- 权限控制，普通用户能不能访问管理员接口？
这些逻辑边界，需要深入理解业务规则，才能发现。
怎么练边界思维？
边界思维，不是天生就会的，得练。我给你几个方法：
1. 画“边界图”
拿到一个功能，先别急着写用例，先画个图。把输入、状态、逻辑，都列出来，然后标记出“临界值”。
比如，登录模块，画个图：
- 输入：用户名（0~30字符）、密码（0~20字符）；
- 状态：账号正常、账号封禁、密码错误、验证码错误；
- 逻辑：连续错误 5 次锁定。
然后，围绕这些临界值，设计用例。
2. 问“如果……会怎样？”
测试时，多问自己几个问题：
- 如果用户输入空字符，会怎样？
- 如果用户输入超长字符，会怎样？
- 如果网络突然断开，会怎样？
- 如果并发请求，会怎样？
这些问题，能帮你发现很多隐藏的边界。
3. 参考“错误模式”
每个系统，都有常见的错误模式。比如：
- 输入校验不全；
- 状态切换丢失；
- 权限控制遗漏。
测试时，可以针对这些常见错误模式，设计专项用例。
4. 复盘线上 Bug
线上出 Bug 了，别光顾着修，要复盘。复盘时，问三个问题：
- 这个 Bug，属于哪类边界问题？
- 为什么测试时没测到？
- 以后怎么避免？
通过复盘，你能逐渐形成自己的“边界雷达”。
边界测试，不等于“测死”
最后，我想说，边界测试，不是为了把系统“测死”，而是为了让系统更稳健。
好的测试，不是找 Bug，而是帮产品找到那个“刚刚好”的平衡点。输入边界，既要限制非法输入，又要保证用户体验；状态边界，既要保证状态切换的准确性，又要保证系统性能；逻辑边界，既要遵循业务规则，又要防止逻辑漏洞。
所以，写用例时，别只盯着“正常路径”，多想想“如果用户这么做，系统会怎样”。边界，往往就藏在那个“如果”里。
下次再写用例，不妨先问自己一句：这个功能的边界，到底在哪里？