楼上有俩说非要和开发刚的,还非说是 bug,还不匿名不知道哪里来的自信

不是 bug，接口重构本来就不应影响旧流程。如有安全问题，应该建个紧急技术需求

我觉得专家应该这个样子：测试基本功、技术、项目、对某些领域有独特见解，能够解决团队或者其他测试人员提出的问题，外加对已有事物的融合和创新。

把问题指给产品

我觉得这算是优化，优先级比较低，可改可不改

我是楼主，我觉得各位说得都有道理，开发也不是不好说话的人，就是太忙了觉得这个问题修改优先级不高，但是 bug 每天必须要处理，所以给我回了个 “设计如此”，关闭了 bug，我有点纠结，这算是把球踢回来了么

自己动手，丰衣足食

1. 这是不是 bug ？
   从楼主的描述来看，是后端改了接口的参数规则。 一般这种修改是属于需求变更，需求变更里应该也要考虑接口调用方的修改。
   因此我觉得不属于 bug ，是需求变更。 要么在需求评审的时候提出来，要么在事后提给产品，由他去推动完善他的需求。

2. 如果开发不配合修改 bug ，怎么办？
   这应该是面试时很大机会问到的老问题吧？ 一般的答案： 按流程沟通，如果不配合，由开发上级或需求沟通决定。

3. 现实中的具体问题具体分析

4. 后端为什么要修改这个接口？ 会不会现在暂时不接收，以后会重新接收 BCD ？ 从设计角度看，前端是有保留这几个参数的可能的。 毕竟后台改规则相对简单，重新部署就行了； 而前端的规则如果发生改变，需要新增参数，可能会涉及重新出包的流程（如果是 app ）。

5. 参数安全性？ 如果涉及敏感信息，就按规定加密；如果只是一个普通信息，可以忽略。

6. 要不要刚到底？ 测试人员有原则是好事，但也是要有个度的。 假如 BCD 只是一些无关紧要的信息，说实话暂时不改问题不大，完全没有上升到 “刚” 的层面。 团队需要有一个共同的目的，优先度高的事情是需要先照顾的。

1.这个肯定是 bug，属于建议性 bug
2.不是说所有 bug 立刻都要修掉，不紧急的，考虑时间影响可以放到以后修复

根据上面各位讨论的结果，我觉得这个问题需要拆分成两个：

1. 定义这个是不是 bug 。
2. 如果开发不配合修改你提的 bug ，怎么办。

可是楼上说这样是自我麻痹啊

不说语言，不说框架，这个肯定是后端的 bug，随随便便什么参数都可以传，传了还不报错

说那么多没用，直接重新打开缺陷就好了，不改可以，好好说，理由充分，邮件抄领导发过来，没问题。否则刚到底。

你给 spring 提 bug 吧,springMVC 就是这样

老铁,当心被前端勒脖子

你这个 BUG 应该提给后端，为什么接收 bcd 参数不报错？后端改了之后，那就是前端的 bug 了，不改也得改

纠正下 好非常客气 -> 要非常客气, 考虑面试 -> 考虑面子

遇到这种问题,楼主可以提 bug 平台但是要备注是待优化的点并不是 bug 并且好非常客气的和前端沟通,你如果直接和前端说是 bug,前端或许考虑面试不会去怼你,但是心里肯定会鄙视你骂你是个煞笔.

楼主这类只是一个需求变动，开发不肯改可以拉上产品、开发、测试三方协调。

咱们平时提 bug 平台上有的问题根本就是完善的点,不算是 bug,提平台只是为了标识下防止忘记,你说这是 bug 是不太合适的

它只能说是一个待完善的点罢了,你直接给人家前端提 bug,前端会怎么想?你考虑过吗?

我觉得这是个 bug，但没必要立刻就改，因为优先级不太高，不影响使用及啥安全性。如果开发真忙，可以先不去改的。但是从代码逻辑严谨上来说，后面闲下来了，肯定要把这个改掉啊。

开发是不是傻子我不知道，我认为这就是个 Bug，你可以不修，我就是要提。

@ 胖虎 这算 bug?来你说说影响用户什么了?暴露什么信息了?要你这么说之前 4 个参数的时候接口就是不安全的了?隐私信息肯定是会加密传输的,你当开发是傻子吗?要你这么说,所有接口都一个字段然后拼接起来再加密,多安全!

你们公司的前端可能之前传过类似的接口,所以上述思想已经形成了.另外这个又不响应用户使用,为啥非要提 bug?楼主让我想起了某宁的测试,详情请点击