根据开发名下 bug 影响绩效

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

应该具备实名发帖的勇气，不该匿名，哈哈

别曲解我的意思。
我说的是毕业生学习一个月就能上手正式干活了，剩下的就是对业务的熟练度了，人家可能很快就能赶上你的业务能力，所以你不学习点其他的技术怎么能和别人竞争？

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

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

我觉得测试。首先需求分析，业务的敏感性，测试设计，这是基本的。先知道要测什么。然后是怎么测，可以点点点，可以用技术手段，可以用工具。你会的越多，效率越高，可选择性也越多。所以只会点点点，路比较窄。

楼主别生气，其实我是很佩服 “点点点” 的人的，其实 “点点点” 也是很有学问的，很多人点上半天也找不到一个 bug，而有些人一分钟可以点出好几个！还有楼上很多人说一个毕业生学习一个月水平就可以跟老测试一样了，这些人是真的懂 “点点点” 吗？？？？

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

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

楼上有俩说非要和开发刚的,还非说是 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 就是这样

老铁,当心被前端勒脖子