除非是涉及到流量或者安全的问题，否则冗余三个字段问题也不大。

这不算 bug 吧?在有的公司里可能一个接口完成多个功能,根据前端传的参数不同来进行区别,前端会有冗余的字段,只要后端不接受就不算 bug.

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

我觉得提 Bug 修改没什么不对。
1.如果此时不改，BCD 参数已经无意义了，等这位前端离职之后交接给其他人，接手人能通过什么地方知道 BCD 到底要不要传吗？
2.从另外的角度来看，前端调用服务端传参，越少越好，把 3 个没必要暴露给用户的信息暴露出来了，谁能保证没有安全的风险？

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

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

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

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

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

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

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

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

顶！说得对！
不改找你领导来说服我，最讨厌那种抱着所谓的跟开发好好说的自我麻醉了，到后来还不是测试自己背锅吗，大家都很忙，你现在不改，我改天忙其他项目去了谁来跟进？说白了就是对自己的看法并不确定或者根本就跟开发一样不负责任，留着个坑坑后人，要么无耻要么无能！
这个版本可以不改，你告诉我你计划啥时候完成，如果下个月就滚蛋我就不缠你了，呵呵~

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

老铁,当心被前端勒脖子

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

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

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

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

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

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

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

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

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

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

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

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

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

自己动手，丰衣足食

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

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

把问题指给产品

如果是我不改。
从版本兼容性来看，改的风险比较大。
一般都是只允许加字段，不允许减字段吧？
为功能多传 3 个字段新做一个接口不值得。
多测测版本兼容性，如果没问题，这个我觉得最好不要改。

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

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

• 我用飘柔，就是这么自信，呵呵，就算不自信也不用像老鼠一样藏着，不匿名应该不丢人吧，这都能成你的槽点？

• 我猜想你们已经适应了快餐式开发，留几个无用的参数都不用管，反正赚一波薪水就跑路（扣帽子、贴标签很不对，但是忍不住，抱歉，你敢实名我就跟你单独道歉）。后来的人接手，遇到相关改动要跟后端撕逼撕半天，然后看代码看半天；测试的人为了确保无虞，单参数和多参数都要验证一下——除非你就选择相信开发说的 “我没改动”，整天狂吹要盯着开发代码的可测性，但事到临头又是咋做的？

• 楼主说得清清楚楚，后端改了规则，改了规则——要么就是业务逻辑变更要么就是系统优化，从哪个角度去看前端不需要同步修改的？

• 或者你认为前端可能不知晓这个事情，所以前端就不用跟着改了？因为还可以跑的通就不算 bug？测试发现的问题没有理由和义务去自己提个 request，要记录和跟进问题就只能提 BUG，如果 bug 都可以用 “忙不过来” 去搪塞，然后测试也就不了了之了，那这个公司的薪水领的是真轻松啊

• 另外别跟我说换位思考，我现在就是 coder……我不喜欢跟盲从自己的测试合作，否则我自己就测完了，还要专职的测试干啥~

我非常赞同楼上的观点。不过当我今天再次和开发聊的时候，他告诉我，公司几乎所有的接口，都存在着冗余字段的情况时。我沉默了，也许这就是为什么我们经常重构的原因吧，人事变动频繁，新来的人根本看不懂前任留下的代码，只能重构

然而重构大部分时间都是重写……

你牛逼,我是怂惯了........

所以你要提几百个 bug 吗?他们不改就拿鼠标线勒他们脖子,哈哈哈哈

个人观点：
自己回就好，每个人有每个人的角度和观点。没必要接着我写的回。
位置不同，想法不同。我不想怼人，只是表达我的观点。
回归一切，都是价值和成本。
PS：楼上说后续接手人看不懂的，麻烦约束一下项目整体的接口文档规范化和代码规范化。

开年第一怼帖，我感觉我又可以吃瓜了，这种其实只是沟通上的问题，有辣么困难吗？去看看测试流程相关的文章都写的一清二楚，如何推动 bug 修复

我不知道你们公司是否有开发名下的 bug
不是说后端重构一次，前端就得背个 bug 的
然后最后却是测试和前端撕逼，明显就应该建个技术需求，单独提测

根据开发名下 bug 影响绩效

问题不在于是否前端要改，而是怎么驱动前端去改
重构看不懂代码，说明交接和文档沉淀有问题
你们后端重构接口，难道直接上？没有通知接入方和测试？
流程引起的问题，应该从流程上解决，而不是 bug 推动或者撕逼

就事论事，解决当前的问题之后再去复盘流程问题，还是应当遵从传说中的 “大处着眼，小处着手” 吧
一眼就看出流程有问题是好事，但是一开始就从流程上去改，你觉得会不会有可能触发整个流程的重构呢，这是旷日持久的战斗

问这问题，感觉测试水平也不高阿，明显变通能力欠缺呢。
不影响接口功能，多传参数怎么了？有什么问题吗？会有什么影响吗？

他没时间就不改呗，反正又不影响，他改了你还要测一遍
我没想多传到会有什么安全，或者什么其他问题，楼上说的举个例子看看？？？？？？？

不改直接警告，再不改 dismiss。

感觉说了那么多，其实解决办法么有两个，一个是改，一个是不改。改的话，就好说了。不改嘛，反正提到平台，先记录，如果需要上线时，你把这个 bug 和负责人确认需不需要修复，需要那就让上层老大去对话吧。你只要做到了发现 bug 记录 bug，而上线需不需要解决 bug，让上层老大去决定吧，因为你没这么大的权限。如果你是测试部老大，你要让他们改，那就找产品找项目管理找开发老大一起开个会呗。

bug 写上 爱改不改 出事别找我