开发修 bug 不算产量的吗，测试多提些，开发稍微一改就修了一大堆 bug，这不是很好吗

反对 1 楼唯 KPI 论，不是做实事的态度

首先，测试的目的最终是为了交付质量。所以对团队来说，发现 bug 不是目的，解决 bug 才是。
在这个前提下：

1. 如果测试能够识别是同样的问题，或者是同类的问题，不应该重复提交。浪费的是团队的生产力
2. 如果是黑盒的原因导致判断不出来是不是同类问题，重复提交也没什么。但是作为专业测试，还是应该尽量提升自己的判断能力
3. 这里的避免重复单，是同样原因、同样现象的问题尽可能提在一单中，但是故障单中还是应该将可能出现的位置尽可能列全（以交付为导向，其实这不应该是个问题）
4. 不同测试针对同样的问题提了不同单。这个没办法规避（但同一阶段测试力气使在一处似乎分工上有些问题），先到先得。

总而言之一句话，和开发其实是一条船。重复单本身不是好事，主观上能规避就规避，真出现的话平常对待就好。

如何界定 bug 是否重复？
----这个要求测试人员具备较强的问题定位能力，知道根源后才好判定是否重复。

如何提高问题定位能力？
以下是个人的看法，仅供参考哈：
1、首先要准确区分问题是哪个端的，这个抓包会很有帮助；
2、条件允许的话，多看代码。看多了也就知道正常后端会做哪些，前端会做哪些；
3、经验积累，收集问题根源。可以问开发，也可以自己尝试定位；

当前端发现问题时候，先去定位问题原因是前端代码问题还是后端接口问题，分开提测 如果是接口的问题给后端开发，如果这样就可以避免你说的问题了，把前后端问题分离 这种也方便开发解决问题

问题是同一个，视为重复，否则认为不是重复。线上用户都是这么做的，谁知道你背后原因是不是同一个。

开发提到的情况，属于问题不一样，但原因是同一个。个人理解这个并非重复，说明这个原因导致了 2 个用户会感知到的问题，都得修复和回归。

如果是同一个接口，只是前端应用场景不一样。
但是开发那边只要加一个参数作为判断就可以了。
那这两个场景需要分别提两个 BUG 嘛，个人觉得完全没必要。
不知道各位大佬是什么见解？