昨天提测出现了问题，问下这种算提测失败吗

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

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

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

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

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

算体侧失败，打回去吧

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@xiaoshan5733 嗯嗯了解，谢谢回复！
@justfindu 好的谢谢回复！

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

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

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

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

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

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

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

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

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

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