求一个Bug跟踪管理系统的Bug重复判断的方案
自己公司用的一个管理系统，其中包括Bug和需求跟踪管理的功能，两者很类似，所以这里就寻求Bug跟踪和管理的问题。
一个产品，Bug的来源可能是客户提出，也可能是自己公司的测试部门发现的，而且一个产品可能实施于多个客户，版本也可能不完全一致。
客户提出的Bug由公司的不同客服人员记录到管理系统中。
测试人员发现的Bug也由不同测试人员记录到管理系统中。
这里就可能出现重复记录的问题。
另外一个产品在整个生命周期中，可能有多个版本。一个Bug可能在1.0版本中出现，并得到修正。但可能运行很久之后，在2.0版本中再次出现。这里也可能出现重复问题。
我们希望看到Bug重复出现的次数。这样在测试部门安排测试工作的时候，会对同一个Bug出现几率高的功能模块给予更多的关注。而且也提供了另外一个角度来观察编码质量。
所以我关注两个问题
1、如何更快捷的判断Bug记录已经存在？
2、如何记录Bug重复出现的次数？
我现在能想到的笨的办法就是：
1、在客服人员或者测试人员录入Bug记录之前，先根据Bug描述的关键词进行检索，如果Bug已经存在，则
1.1、如果Bug还属于未处理状态，则不记录。
1.2、如果Bug以前已经修正或者属于不同版本，现在再次出现，则创建新的Bug记录，并在原有Bug记录和新创建的Bug记录中累加Bug次数。
问题：A: 对每条Bug记录都需要填写关键词，比较繁琐。
B：每填写一条Bug，都要先进行检索，效率很低。
C：如果重复判断错了，还要有途径取消Bug次数累加。
2、即使通过方法1进行判断，因为大家描述Bug的文字习惯不一样，还是有可能将某个实际上重复的Bug当作新的Bug记录到系统中，则在管理人员或者具体开发人员处理的时候，会人为判断出是一条重复Bug，此时：
2.1、如果之前Bug还属于未处理状态，则设置状态为“不处理”，即让本条Bug失效。
2.2、如果之前Bug已经修正或者属于不同版本，则将该Bug归结到以前的某条Bug上，并将原有Bug和本条Bug累加Bug次数。
问题：同1。
3、因为管理人员和具体开发人员的认真程度不同，可能还是有实际上重复出现的Bug，但并没有做重复判断的处理，此时就只能认为是一条新的Bug进行处理了。
也考虑过在输入Bug描述的过程中，就开始进行检索，就像CSDN发贴输入标题时能自动检索一样，但那样太有技术难度了，还要搞词法分析。
我想这个问题肯定大家都遇到过，而且应该已经有成熟的解决方案，还望大家不吝赐教，谢谢。
我公司的那个管理系统是B/S结构的。
关键点就是要便捷，高效，直观。
[解决办法]
对于1，检索其实是很不靠谱的。客户的窗口与测试团队的沟通更重要。客户的窗口，他要很清楚客户提出的所有的bug，也要清楚测试团队报出的这个客户的所有的bug。
我们的做法，客户的窗口，他登记bug，是不先搜索的，每次都全部登记。他登记完之后，bug先到测试团队，由测试工程师先复现，测试团队先要确认客户报的bug是可以复现的，才会提交给相应的研发团队，PIC到具体的研发人员。不会客户窗口登记后直接到研发人员。
对于1.1，如果测试团队发现有一些bug是之前测试人员报过，重复的，并且还处于“未处理”状态，可以选择删去一个。
对于1.2，我们是不去计数的。从已经CLOSED的bug里把它找出来是很费劲的。
对于问题A，我觉得关键词不大靠谱。原因就是你说的第2点。
对于问题B，前面说了，客户窗口登记bug的时候是不搜索的；测试人员登记的时候，也只是人工在处于“未处理”状态的bug里看一看是否已经有了。
对于2，大家描述bug的习惯不一样，不好统一。就算你在公司内部统一了，那些客户的窗口们接触的是为数众多的不同的客户，他们收集来的bug描述又是千差万别，难不成在登记的时候先翻译成公司统一的语言？不可能，因为他们还要和客户review这些bug，不可能翻译来翻译去。
计数不大可取。统计出来也没什么用，还是打消这个念头吧。
[解决办法]
重复就重复了吧
很大关系吗？
接受处理的时候，判定一下是不是重复的就可以了，bug管理工具可以将bug归类为重复啊？
不理解
你是不是要对测试人员进行绩效考核啊？
[解决办法]
1、如何更快捷的判断Bug记录已经存在？
功能模块细化+关键字检索，快速定位bug是否重复
2、如何记录Bug重复出现的次数？
我这里使用quality center在Defect中有一个关键字段就是bug重复次数
