如果超过 200 个字符，会报错吗？ 还能正常保存吗？

如果因为超过 200 个字符导致页面直接崩掉了，你们运营人员可以忍受吗？

需求设计的时候，产品非常明确的说过，填写的内容是绝对不会超过 200 个字符的。所有的假定在这个基础上。

边界值不仅有意义还很重要。一个写请求，如果字段过长，后台 DB 可能会直接报数据库异常；另一方面，既然是确认过的需求，功能测试的用例设计当然要符合规格

如果是我，这种问题还是会提 bug。 产品说的这句话其实是不负责任的，没理由把系统的健壮性交给用户的使用习惯来保障。

无论从前台还是后台来说都要能给用户一个有效的反馈,而不是用户执行了某项操作得到一个错误界面,所以我认为前后端都需要做相关的保证. 前端是给用户良好的提示,后端是对系统良好的保障

楼主，是不是 bug 是测试来决定的，bug 的优先级，重要程度取决于产品当前的情况

看了楼上各位的发言，其实我也比较认同。但现在的现实情况是，公司使用的后台系统的标准就是：能用。只要不会出现类似系统崩溃的问题，都可以接受。而在系统迭代过三，四个版本之后，类似的边界值问题所提的 bug 全部以 “没时间修改” 的理由全部驳回了，而产品的态度也无所谓。在这种情况下，类似的设计到底还有没有必要？

小公司就是这样，能用就行，你可以求同存异，但是 bug 要打回去，不要留在你的名下，让开发改完再打回来

感同身受。
确实有一些内部系统或者后台管理系统，确实对这些没多少限制和处理。
理由都是正常情况下，不会出现那种刚好触发边界值的情况。

小公司测试更要整理一套测试流程出来，版本测试完毕时类似边界引起的问题会产生何种风险，这些都可以记录形成版本测试报告。以后由这种风险引起的损失。才不会是 “测试没测”

看完这些书你就觉得 200 不那么重要了 🤧

我司也有类似情况，一定要提，因为后面运营/产品可能会提需求，原来定的长度不够，要扩展，如果当时没解决，就 gg 了；

我还是选择看抖音

如果说边界值有没有意义，当然是有意义的。

至于意义有多大，相关问题是否需要修复，就要按照优先级来了。技术人员需要重点关注产品的核心功能，如果核心功能都没法保障，那边界值问题自然不会被重视。

另外，我理解任何系统对于一个输入值的大小一定是有限制的，比如 UI、接口（如 nginx 限制单个请求大小，http url 最大长度限制）、数据库（字段长度）。超出长度就会出现问题，可以看看这个机制的极限值是多大，是否能满足产品需要（建议重点看看数据库字段长度），超过极限值程序会如何处理（直接截取？报错？）。之前我们曾经出现过一次由于超出极限值系统直接截断而没有报错的问题，导致原始数据缺失，影响还是很大的。

如果不满足，那就明确提出和要求更改。

从需求上开始扯 任何未被定义的边界值 都是一次需求上的遗漏

边界值的意义 从测试的角度上来说 边界值法只是减少 “抽样”，提高测试执行效率的一种方式

从产品的角度讲 能用就行 不够用了在补 这是在推脱责任 需求中一句话能提的事 开发加个前端或后端限制 做一名合格优秀 CV 战士 也花不了多少时间

很有意义！

除了功能
边界值 200 个字符在前端页面的展示上有时候也是很奇葩的

其实问题没有上升到边界值有没有意义的程度，既然是内部项目，后台系统。有一些标准是可以放松的（前提是产品认同的情况下）。建议发送风险报告，告知边界值带来的风险，比如 DB 是否能接受大于 200 的字符串，是否会出其他问题等等。如果是对外的项目，是必须要提 bug,且产品不理会也要告知产品问题的严重性，不可以把系统的健壮性抛给外部用户

比如有个接口，字段的有效性在前台输入的时候客户端进行了校验，所以后台接口就没对字段有效性、边界值校验，那么在做接口测试的时候，有必要提接口没有边界值校验的 bug 吗

我们假设下，比如我们开发个页面给自己使用，需要各种校验字段长度吗？

几个问题：
1.体验相关的边界值，产品一般都会限定吧。
2.边界值无论前后端都要考虑，需要验证判定限制，必须修改。
3.如果客户是内部运营的，不是真实用户体验的，那没办法，爱改不改。。。。
PS:内部用户的需求除非用不了，傻子才花人力给你改。。。。

怼回去，必须改，否则产品文档不要写这些边界，不然让他们以后自测，让产品测~
话说增加个边界的限制，又不是什么难事，还能没时间，奇了怪了

对于没有需求文档或者需求文档根本没有任何关于边界值的需求定义，这种测试的时候如何处理呢？

不同公司，不同团队，不同阶段，优先级不一样 。

对于急忙赶工，软件实现了就行，
或者内部员工使用的，
也许不是那么重要 。

但是，
对于庞大的、C 端用户的产品，边界值，意义重大，必须得关注 。