测试人员在禅道建立的 bug，如果不是真的 bug，累计数量会影响绩效。
例如我提的 bug，研发的解决方案是：设计如此，外部原因，就会导致测试人员非 bug 数增加。
在 bug 的解决方案上会讨论，增加耗时。搞得我提 bug 都小心翼翼的
那要判断究竟是不是这些原因喽，打回单子时备注清楚具体原因。
我司统计 BUG 就去掉了重复、设计如此、外部原因等项
给你们 CEOCTOCOOOOO 打电话，就说他是依托答辩，我说的，早晚倒闭
把 leader 叫出来揍一顿然后跑路
只能说，这种设计如此的 bug，是你对需求的不理解，本身就不应该是 bug，这种应该属于需求问题，所以，你不应该提交这种 bug，有这种问题，建议直接找开发沟通，沟通完再提。
我也是，明明就是 bug 需求很明确了，结果修完 bug 后反馈给我的是设计如此。。人麻了。。
如果备注设计如此，重复之类的，就要备注清楚原因。比如设计如此，是否有产品确认设计如此，没有就可以激活；重复 bug 其实很常见，测试的流程 A 引发一个问题，测试流程 B 也引发一个问题，但研发的解决方案都是同一个地方处理，这种按测试的定义来，那就不能是重复；
所以应该开发流程上和公司制度上改变：流程明确 bug 的解决方案，制度可以考虑去除被定义设计如此、外部原因的 bug 不计入绩效
设计如此应该是需求问题了吧，提 bug 之前如果不是很确定的要和开发沟通一下
非 bug 数增加，那么就需要思考为什么会提出此类 bug，是需求改动未通知测试、测试与开发对需求的理解不一致、测试对需求理解有误、开发对需求理解有误等，然后针对具体原因，进行相应改进。
禅道创建的 bug 可以删除的，不知道你们有没有这个权限
设计如此 - 也需要考虑是否设计合理的。如果你把你的度量和产品经理/或者研发设计者沟通过后，人家可能会觉得你更合理呢？
重复 bug-我们这边以前多个人交叉测试的时候，确实遇到过这类问题，因为你不知道别人也报了这个 bug。但单人的时候不会，一般测试也具备一些 bug 定位能力的，开发动到了全局的组件之类的，可能会引起多个地方出现 bug，这种我们一般都是做一个 bug 来报（也是避免理念差异上的扯皮，毕竟开发也有绩效，同时也体现出测试的专业性。开发会更愿意相信你报的是 bug）
什么影响绩效听听就得了，线上不出锅你就差不到哪去的，出了锅任你做出花来绩效也高不了，测试作为非营收部门就是这么尴尬
以前在 HP 的时候，无效的 bug（dup，not a defect）会影响绩效的。解决方法就是所有干的 bug 都先汇总到一个对于系统非常熟悉的人那里，由他再过一遍所有的 bug，再进行提交。