测试基础 字段长度前后端是否都需要做限制？
一个保存功能，需求限制 10 个字，目前在小公司只有前端做了限制，按道理来说后端是否也需要做限制呢？
按规范，后端需要做限制。
不能只在前端做，因为可以通过接口直接请求到后端。后端接口才应该是限制加最多的地方，前端限制只是为了用户体验。当然如果没什么质量或者业务风险，倒也无所谓。
抓个包绕过前端限制看看能存进去不，会不会引起安全风险或业务问题。
前端限制=没有限制
前端，后端，数据库
需要限制但是看有没有必要，之前公司 cto 写代码后端没做限制给他说会绕过前端，他说正常人哪会绕过，小公司，用户少，就没这么严格，快速上线就行
理论上要，但实际没必要
我分享个例子： 我们最近在对某个删除的 API 有改动，然后开发用 postman 去验证这个改动的时候不小心传了一个非法的 product ID， 结果正好后台没验证处理这种情况，结果把整个表的数据都给删了… 幸好这是在测试环境发生的，要是在生产环境发生，后果不堪设想。
所以楼上说没必要的，祝你们不会遇到类似的问题
数据库》后端》前端
楼上的估计都是大公司的思维在影响，在小公司，大概率是产品随意给的一个大概的字数的限制，没有很特别的意义，看语义不是很懂保存功能 10 字的限制需求，是 10 个字节还是 10 个字符？，感觉是提交一个 10 字以内的备注一样。这种建表的时候，我估计开发也是随意给个 varchar(50) 留一定量的富余，所以可以提单说下后台没有做数据校验，至于数据库是否要严格限制，我猜开发大概率会给个：没事的
规范的后端限制即可，前端做限制主要是为了用户体验，或者在前端进行数据提交时把后端返回的异常结果映射在提示框
Jerry li
回复
我比较好奇的是，这是个什么的代码逻辑，会现出这种结果？非法的 ID 最多就也不删除，是怎么会引发整个表被删除的？不是很能想明白
CKL的思考
回复
很多 bug 都不能用常理去推测的。 所以作为测试，我们要考虑的是全面的质量保障。 比如这个字段的验证，其实在不同的阶段都可以有办法去预防： 开发正确的使用字段长度的检查（或者使用对应的插件）、单元测试、接口测试、页面自动化测试，等等。
但是如果作为测试，我们都直接帮开发说： 这个没必要测接口，我是真的没办法认同。
https://testerhome.com/topics/37824 可以参考我这个中的代码扫描就是发现此类问题
Jerry li
回复
嗯，本身是要验证的，这个没问题，也确实是需要的，我们团队也会要求前后端都做必要的校验。只是纯粹好奇下这个 bug,的原始逻辑，因为这种情况不太能想明白是怎么个情况
CKL的思考
回复
原始逻辑是真的一言难尽，我大概知道的信息是当这个 ID 包含非法字符的时候，被处理成了 null，然后删除的逻辑里面原本是根据 ID 来锁定要删除的记录，结果因为这个 null 就变成了全表删除…
Jerry li
回复
嗯嗯，我理解是不同层面的问题呢。API 设计问题是 bug，物理删除权限是管理问题呢。
如果没有物理删除的权限，这里不会出现删表嘛，最多是抛异常。
逻辑删除和物理删除需要的恢复时间差别是蛮大的。
前后端都需要做限制，前端是防君子，后端是防小人，懂的都懂，提高被攻击的成本和门槛，也是一种规范
花菜
回复
不是把表给删了，而是删了表里的数据。 所以不管物理删除还是逻辑删除都可能发生吧，区别是操作一条数据还是操作多条数据？
对业务来说，就是数据不可用了
Jerry li
回复
嗯，把表的数据删除也是不能接受的，drop table 那就更加离谱啦。
对业务来说是不可用，逻辑删除，只需要执行一条 update 语句，把逻辑删除 flag 改一下就行。
物理删除讲真，我没有回滚过，难度肯定比执行一条 update 一个量级。
花菜
回复
我了解到的，要么是直接前备份数据库里恢复（可能会有数据丢失），要么是从数据库的 log 里面找出来恢复。具体没做过。
PS 我们那个例子好像真的是物理删除，因为 DBA 说没办法恢复
Jerry li
回复
从 binlog 能恢复，但得知道时间点，操作步骤会比较麻烦，尤其是生产环境不能中断，并且涉及到各种权限问题。
所以应用的 db 账号必须得把删除干掉。
想清楚为啥限制 10 个字吧，是业务需求？还是技术层面考虑数据太多>10 就把数据库打爆了？后端和数据库绝大部分都是一个人做，数据库层会放得很开，一般把 10 这个数字设置成配置中心的变量（类似 Nacos/MSE 之类的），这样产品哪天说改成 20 个字就把配置改成 20 就可以了，代码完全不需要变更
实际情况内部管理系统大部分都是前端限制完全够。
当然要是有开发通过 postman 这种骚操作去修数据由于传参未校验导致的生产问题，测试也是要背锅的