众所周知，在测试用例设计方法中有一项，非常常用的一项叫：边界值分析。以下摘录自百度百科：
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
在实际的表单提交的测试中，最常用的是输入字数的限制。例如 200 个字符的限制。但是在后台只提供给运营人员使用的情况下，可能开发根本不会做类似限制字数的需求，这个需求实现与否对项目来说根本就不重要。
我举的只是项目中遇到的一个小栗子，实际肯定有很多类似的场景。那请问各位大佬，这种时候边界值设计是否有必要？
如果超过 200 个字符，会报错吗？ 还能正常保存吗？
如果因为超过 200 个字符导致页面直接崩掉了，你们运营人员可以忍受吗？
边界值不仅有意义还很重要。一个写请求，如果字段过长，后台 DB 可能会直接报数据库异常；另一方面，既然是确认过的需求，功能测试的用例设计当然要符合规格
无论从前台还是后台来说都要能给用户一个有效的反馈,而不是用户执行了某项操作得到一个错误界面,所以我认为前后端都需要做相关的保证. 前端是给用户良好的提示,后端是对系统良好的保障
楼主，是不是 bug 是测试来决定的，bug 的优先级，重要程度取决于产品当前的情况
看了楼上各位的发言，其实我也比较认同。但现在的现实情况是，公司使用的后台系统的标准就是：能用。只要不会出现类似系统崩溃的问题，都可以接受。而在系统迭代过三，四个版本之后，类似的边界值问题所提的 bug 全部以 “没时间修改” 的理由全部驳回了，而产品的态度也无所谓。在这种情况下，类似的设计到底还有没有必要？
感同身受。
确实有一些内部系统或者后台管理系统，确实对这些没多少限制和处理。
理由都是正常情况下，不会出现那种刚好触发边界值的情况。
gideon123
回复
小公司测试更要整理一套测试流程出来，版本测试完毕时类似边界引起的问题会产生何种风险，这些都可以记录形成版本测试报告。以后由这种风险引起的损失。才不会是 “测试没测”
我司也有类似情况，一定要提，因为后面运营/产品可能会提需求，原来定的长度不够，要扩展，如果当时没解决，就 gg 了；
如果说边界值有没有意义，当然是有意义的。
至于意义有多大，相关问题是否需要修复，就要按照优先级来了。技术人员需要重点关注产品的核心功能，如果核心功能都没法保障，那边界值问题自然不会被重视。
另外，我理解任何系统对于一个输入值的大小一定是有限制的，比如 UI、接口（如 nginx 限制单个请求大小，http url 最大长度限制）、数据库（字段长度）。超出长度就会出现问题，可以看看这个机制的极限值是多大，是否能满足产品需要（建议重点看看数据库字段长度），超过极限值程序会如何处理（直接截取？报错？）。之前我们曾经出现过一次由于超出极限值系统直接截断而没有报错的问题，导致原始数据缺失，影响还是很大的。
如果不满足，那就明确提出和要求更改。
从需求上开始扯 任何未被定义的边界值 都是一次需求上的遗漏
边界值的意义 从测试的角度上来说 边界值法只是减少 “抽样”，提高测试执行效率的一种方式
从产品的角度讲 能用就行 不够用了在补 这是在推脱责任 需求中一句话能提的事 开发加个前端或后端限制 做一名合格优秀 CV 战士 也花不了多少时间
很有意义！
除了功能
边界值 200 个字符在前端页面的展示上有时候也是很奇葩的
其实问题没有上升到边界值有没有意义的程度，既然是内部项目，后台系统。有一些标准是可以放松的（前提是产品认同的情况下）。建议发送风险报告，告知边界值带来的风险，比如 DB 是否能接受大于 200 的字符串，是否会出其他问题等等。如果是对外的项目，是必须要提 bug,且产品不理会也要告知产品问题的严重性，不可以把系统的健壮性抛给外部用户
比如有个接口，字段的有效性在前台输入的时候客户端进行了校验，所以后台接口就没对字段有效性、边界值校验，那么在做接口测试的时候，有必要提接口没有边界值校验的 bug 吗
几个问题：
1.体验相关的边界值，产品一般都会限定吧。
2.边界值无论前后端都要考虑，需要验证判定限制，必须修改。
3.如果客户是内部运营的，不是真实用户体验的，那没办法，爱改不改。。。。
PS:内部用户的需求除非用不了，傻子才花人力给你改。。。。
gideon123
回复
怼回去，必须改，否则产品文档不要写这些边界，不然让他们以后自测，让产品测~
话说增加个边界的限制，又不是什么难事，还能没时间，奇了怪了
对于没有需求文档或者需求文档根本没有任何关于边界值的需求定义，这种测试的时候如何处理呢？
不同公司，不同团队，不同阶段，优先级不一样 。
对于急忙赶工，软件实现了就行，
或者内部员工使用的，
也许不是那么重要 。
但是，
对于庞大的、C 端用户的产品，边界值，意义重大，必须得关注 。