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?楼主让我想起了某宁的测试,详情请点击

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

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

我觉得测试的核心技能不是自动化，也不是点点点。而是要知道为什么要去点这个按钮，为什么不用去点那个下拉框。

知道为什么点这个按钮的背后可能需要你做很多功课，比如对业务的深耕，或者是对行业、竞品的了解，又或者是对产品架构、设计的熟悉，研发随便改了什么地方，你掐指一算就知道该去点哪儿。

所以懂编程能自动化也只是你的工具。测试的定位我觉得是比产品更懂技术，比研发更懂产品。说白了测试又不是一个盈利的角色，而是更加偏向提升效能和节约成本的角色。

是的，但是我也感觉，python 一般是测试用来写脚本的，包括自动化，压力测试啥的。好像也不需要太清楚源码啥的。基本知道会用差不多了。不比 java，java 学的深是很有必要的，

好像回复不能修改 touch-tough

楼主几个问题：
公司的规模，技术部规模，测试组规模，专职测试技术方向的几个人？

我的背景，民企，外企，创业，现在在 bat，关于自动化的几个思考：
1、项目属性基本决定测试玩法，纯业务还是中后台产品
2、团队规模或者说用户数决定了测试的深度
3、是否有支撑整个产品研发流程的 CI/CD 体系，如果有的话，自动化是非有不可，不仅仅是自动化测试而是全流程自动化
4、回到个人做自动化的目的？证明自己的 coding 能力，还是想帮助到项目，不管是发现 bug 还是提升效率
5、如果我是你的话，我会怎么做？

• 不求大而全的自动化，针对效率低的点让机器去完成，比如生成测试数据
• 如果在业务团队，全力发现业务的 bug，深究 bug 出现的原因定位到具体的出错点，然后再告诉开发你这样写错了，应该怎么写，说的时候委婉点，没有必要每个 bug 都看
• 建立自己的技术品牌，请开发配合你，一起来完善质量体系
• 这是个 touch 的过程，意味着你要了解技术架构，技术实现细节，调优策略
• 不抱怨，有阳谋，加油！

祝你以后能遇到能遇到更好的 leader 吧。我打算留下来死磕了。