这是一个相当难以解决的问题，因为错误报告通常是从观察者的角度编写的，而不是根本原因。标签/关键字是个好主意。

我要做的一件事是尝试让相关开发人员快速分析错误报告，他们会添加关于根本原因的评论，通常还有其他可能的症状。这样，其他人搜索他们所看到的错误是否已被报告（您的团队首先搜索，对吗？）有更好的机会找到现有的错误报告。

也就是说，我不太担心重复的错误报告。将它们标记为重复项并将它们链接到原始错误报告并不难（至少在 Bugzilla 中并不难）。

而且我更希望错误被过度报告，而不是报告不足！

我想要重复。

好吧，我宁愿从不同的人那里复制，也不愿根本不抚养他们。

在流程方面，我使用每日错误分类，我们审查所有已提出的新错误，以将它们识别为重复并立即关闭它们。

如果测试人员是屡犯者，我会简单地进行一次聊天，教他们如何更有效地使用错误跟踪工具中的搜索。

如果它是开发人员或最终用户，则永远不会被提及，除非他们注意到他们的错误已作为副本关闭，并带有指向另一个问题的链接。

从多个角度针对同一个根本原因问题的错误报告实际上对开发过程是有益的。不同的视角给出了受 bug 影响的应用程序不同区域的横截面。一份错误报告可能会引用数据库查询的 GUI 显示。如果您只需要这样做，开发人员可能会花时间尝试修复显示以正确显示查询返回的内容，或者可能会花时间尝试修复查询以获得正确的数据。

同时，另一个错误报告进来说数据库记录不正确。现在我们知道问题不在于 GUI 或查询，而在于数据库中的记录。所以，现在我们开始研究数据是如何进入那里的，针对数据运行了哪些计算或流程等等。

最后，另一个错误报告说用于数据输入的完全不同的 GUI 错误地将数据存储在临时表中。恰好临时表是用来创建在另一个 GUI 中显示的数据库记录的。

根本原因是数据输入 GUI 在持久化数据方面存在问题。现在，开发人员实际上有一条代码检查路径，他们可以通过该路径来确保 a) 数据持续存在，b) 数据被正确处理，c) 数据的查询和显示正确出现。修复 a、b 或 c 中的任何一个而不考虑其他任何一个都不会承认对整个系统的级联影响。

此外，测试人员现在知道要运行更好的端到端测试场景，以便在纠正完成后正确验证纠正，以确保软件的所有受影响区域都得到正确解决。

使用文档相似度，就像 stackexchange 一样。

这是一个关于它是如何完成的视频：

http://vancouverdata.blogspot.com/2010/11/text-analytics-with-rapidminer-part-4.html

基本上，您将每个错误报告视为一个文档。把它们分解成文字。计算词频。按词频比较文档。您甚至可以使用字母频率。这可以非常准确。

如果错误报告与之前的报告非常相似，请询问用户是否要合并它们。