修改以前的商品后台管理系统，新建商品时会选择品牌，品牌由于前端错误展示的是禁用的品牌，但是商品可以创建成功，这里后台没有做处理。但是商品新增后是可以继续在商城小程序上购买不影响流程，这个品牌只有在后台商品列表搜索时有用。开发时没发现这个问题，这种算提测失败吗？
如果 op 描述的有问题 v 友们可提出

个人猜测，前端写错了逻辑，导致产生错误数据，你把 bug 提给后端，后端认为和他没关系，和你开撕

这不就是 bug 吗?提测失败是什么鬼。

业务的验证都应该是后端是做的。

看你和测试关系，和流程的严格程度

按照测试的逻辑是,给商品添加品牌时,被禁用的品牌应该无法选中或不显示,所以不给过.

算体侧失败，打回去吧

后端的锅，创建、列表、购买都没验证

前端是品牌这个接口以前参数 1 是启用 0 是禁用这次修改了 0 是启用 1 是禁用，前端开发的时候没注意没改，并没有开撕，就页面来说是前端的问题

测试直接说提测失败。不理解所以来问问

对后端验证没做，但是前端这里传的参数也不对，可以看下 8 楼的恢复，理论时和后端验证了就没这个问题了。

刚来公司没多久。
是只显示了禁用的品牌，还创建成功了
好的
归根结底是后端的问题。

作为一个后端, 涉及到敏感安全的, 总要时刻想着"总有刁民想害朕", 想着前端会故意传各种错误或者特殊构造的参数来祸害你.你要做好万全的防御来抵制这些前端小人.

是说有提测准入, 然后因为这个 case 判断为提测准入失败被打回吗? 不过说真的, 如果这么极端的 case 都要求提测前覆盖到, 那还要测试干嘛, 全都研发自测得了

提测之后，测试会根据冒烟测试用例走一遍， 有阻塞或者关键流程失败， 则算提测失败，计入开发绩效里面
冒烟用例通过之后， 正式进入测试

这想都不用想，后端功能没做校验。接锅吧！不能啥都依赖前端校验传值

哈哈 我是前端，但是我不会故意害人的，我只是忘记改了，可以看下上面的回复

那这种应该不算没通过吧 我觉得

那是测试不通过， 提个 bug 得事情，也不能算提测失败吧。
得是测试拿到提测后，连整个测试环境都跑不起来的，没办法开展测试的，才叫提测失败呀。

既然你们公司有提测流程，那么在提测前务必按照测试用例跑一遍，如果测试用例没写就不算提测失败

品牌接口以前是 1=enable, 0=disable. 现在变成了 0=enable, 1=disable

那么，所有提交给后端的是请求都是成功的，此时这个参数是 0 还是 1 ？如果是 0 ，那后端没有问题，你试试 1 的请求能不能过。 能过那就是后端的锅，没校验；不能过那就是前端的锅，一个参数没改整个业务逻辑反转了。

关键在于后端做没做校验，后端只要有校验，那怎么甩这个锅都是前端的。如果后端没做校验，那两个人都有问题，但后端的锅占 80%

后端 1 和 0 都没校验，前后端肯定都是有锅的，其实我不是来分锅的，就是想知道提测算不算失败，之前没遇到过提测失败。

这就是 bug 呀, 后端有一条信念就是不相信前端判断过的数据. 所以一定要自己验证一边. 前端判断是为了过滤, 为了减压和用户体验.

嗯嗯了解，谢谢回复！
好的谢谢回复！

我们这这种不算提测失败，提测失败一般就重大缺陷流程走不下去，这种就算个 bug 。

这不是 bug 么, 什么叫做提测失败, 是指冒烟没过么

取决于在不在给的冒烟 case 中吧，如果小需求小优化不给冒烟 case ，那肯定算提测成功，当 bug 解。
如果大需求不给冒烟 case ，那是测试有问题。
如果给了冒烟 case ，但不包括这个问题，那只要冒烟 case 都过了就提测成功吧

好严格啊。提测失败==bug ？

＃21 0 ，1 都没校验是啥意思，enable 的品牌不需要被 block 吧？你看看前端修改正确参数之后，disable 的请求还能进后端吗？

假设没问题，那就是前端的锅。有问题，就是后端的锅。

提测失败就是因为你们这个开发上最基本的业务逻辑都不满足，说明开发都没自测，unit test ，integration test 都没做，才会导致这个问题。

这种就是 bug 呗,又不影响主流程,不能算冒烟失败

后端应保证能处理任何输入，再不济，后端程序可以挂，但不能产生脏数据

先回答问题：算提测失败吗？算！！！！
第一个问题：前端显示禁用品牌，要求是不显示禁用品牌？那么问题来了，前端的品牌数据哪里来的，如果是前端自己写的，那么前端背锅，如果后端给的，那么后端全锅。第二，禁用的品牌为什么后端可以创建成功？后端不做校验么？