那要判断究竟是不是这些原因喽，打回单子时备注清楚具体原因。

我司统计 BUG 就去掉了重复、设计如此、外部原因等项

给你们 CEOCTOCOOOOO 打电话，就说他是依托答辩，我说的，早晚倒闭

把 leader 叫出来揍一顿然后跑路

只能说，这种设计如此的 bug，是你对需求的不理解，本身就不应该是 bug，这种应该属于需求问题，所以，你不应该提交这种 bug，有这种问题，建议直接找开发沟通，沟通完再提。

我也是，明明就是 bug 需求很明确了，结果修完 bug 后反馈给我的是设计如此。。人麻了。。

如果备注设计如此，重复之类的，就要备注清楚原因。比如设计如此，是否有产品确认设计如此，没有就可以激活；重复 bug 其实很常见，测试的流程 A 引发一个问题，测试流程 B 也引发一个问题，但研发的解决方案都是同一个地方处理，这种按测试的定义来，那就不能是重复；
所以应该开发流程上和公司制度上改变：流程明确 bug 的解决方案，制度可以考虑去除被定义设计如此、外部原因的 bug 不计入绩效

设计如此应该是需求问题了吧，提 bug 之前如果不是很确定的要和开发沟通一下

非 bug 数增加，那么就需要思考为什么会提出此类 bug，是需求改动未通知测试、测试与开发对需求的理解不一致、测试对需求理解有误、开发对需求理解有误等，然后针对具体原因，进行相应改进。

禅道创建的 bug 可以删除的，不知道你们有没有这个权限

设计如此 - 也需要考虑是否设计合理的。如果你把你的度量和产品经理/或者研发设计者沟通过后，人家可能会觉得你更合理呢？
重复 bug-我们这边以前多个人交叉测试的时候，确实遇到过这类问题，因为你不知道别人也报了这个 bug。但单人的时候不会，一般测试也具备一些 bug 定位能力的，开发动到了全局的组件之类的，可能会引起多个地方出现 bug，这种我们一般都是做一个 bug 来报（也是避免理念差异上的扯皮，毕竟开发也有绩效，同时也体现出测试的专业性。开发会更愿意相信你报的是 bug）

有这个权限，甚至我能连接数据库，能进入 zt_bug 表。不敢删除物理表数据，怕影响其他模块

复杂的需求，需求就不完善。业务很复杂。

什么影响绩效听听就得了，线上不出锅你就差不到哪去的，出了锅任你做出花来绩效也高不了，测试作为非营收部门就是这么尴尬

以前在 HP 的时候，无效的 bug（dup，not a defect）会影响绩效的。解决方法就是所有干的 bug 都先汇总到一个对于系统非常熟悉的人那里，由他再过一遍所有的 bug，再进行提交。