例如，一个可以看到设备崩溃，另一个可以看到通信丢失，而第三个可以看到她无法为该设备安装驱动程序。
在想办法解决这个问题时，我的主要想法是在找到根本原因后向错误添加某种标记，这些标记应包括其他可能的功能或与之相关的现象。
这是远非完美，最大的缺点是每个标签都将很快附加许多错误，从而使不熟悉根本原因的人无法关联，使用上面的示例崩溃将与无休止的错误相关。
#1 楼
这是一个很难解决的问题，因为错误报告通常是从观察者的角度写的，而不是根本原因。标签/关键字是个好主意。我要做的一件事是试图让相关开发人员快速分析错误报告，该开发人员会添加有关根本原因的注释以及其他可能出现的症状。这样，其他正在寻找是否已经报告他们所发现的错误的人（您的团队会首先搜索，对吗？）更有机会找到现有的错误报告。
，我不必过多担心重复的错误报告。将它们标记为重复并将它们链接到原始错误报告并不难（至少在Bugzilla中并不难）。
我更希望错误报告过多，而不是报告不足！
评论
通常这不是一个真正的问题，但是有时症状会很严重，从而导致不必要的极端反应，例如，代码合并问题导致在交付产品的死胡同之前出现了show stopper bug。甚至在有人有机会进行初步调查之前，都已紧急给人们打电话。要回答您的问题，是的，我们确保添加对每个错误的分析，并在每次出现新错误时都在数据库中进行搜索，大多数情况下，搜索是虚拟的，因为许多错误和错误报告足以显示根本原因。
–Rsf
2011年5月25日在12:45
#2 楼
我想要重复。好吧，我宁愿从其他人那里得到重复，也不愿根本不提出。
从过程的角度来看，我使用每日错误分类，在此我们审查所有错误提出了新的bug，以将其标识为重复的bug，并立即将其关闭。
如果测试员是重复犯规者，我将简单地聊天，教他们如何在bug中使用搜索跟踪工具更有效。
如果是开发人员或最终用户，就永远不会被提及，除非他们注意到他们的错误已被重复关闭，并带有指向其他问题的链接。
#3 楼
对于相同的根本原因问题，从多个角度进行的错误报告实际上对开发过程有益。不同的观点给出了受错误影响的应用程序不同区域的横截面。一个错误报告可能引用数据库查询的GUI显示。如果仅此而已，开发人员可能会花费时间尝试修复显示以正确显示查询返回的内容，或者可能会花费时间尝试修复查询以获得正确的数据。同时，另一个错误报告出现，表示数据库记录不正确。现在我们知道问题不在于GUI或查询，而在于数据库中的记录。因此，现在我们开始研究数据如何到达那里，对数据进行了哪些计算或处理，等等。
最后，另一个错误报告说，使用了完全不同的GUI用于数据输入的错误地将数据存储在登台表中。恰好碰巧临时表是用来创建要在另一个GUI中显示的数据库记录的。
根本原因是数据输入GUI存在持久化数据的问题。现在，开发人员实际上已经有了一条代码检查路径，以确保他们可以通过以下步骤确保a）数据持久存在，b）数据受到正确的处理，并且c）数据查询和显示正确进行。修复a，b或c中的任何一个而没有考虑其他任何一个，并不意味着对整个系统的级联影响。
此外，测试人员现在知道可以运行更好的端到端测试方案为了在完成更正后正确验证更正，以确保正确解决了软件的所有受影响区域。
#4 楼
使用文档相似性，就像stackexchange一样。这里有一个有关其工作方式的视频：
http://vancouverdata.blogspot.com/2010/11/text-analytics-with-rapidminer-part-4。 html
基本上，您将每个错误报告都视为一个文档。把他们说出来。计算单词频率。按词频比较文档。您甚至可以使用字母频率。这可能是非常准确的。
如果错误报告与先前的报告非常相似，请询问用户是否要合并它们。
评论
这是行不通的，从定义上讲，从其他角度描述某些内容时，单词不太可能重复。
–Rsf
2011年5月26日下午6:18
@Rsf：这可能会或可能不会。那是一个众所周知的词汇缺口问题。同样，上面批准的标签/关键字解决方案可能会受到相同的限制。而且我不认为建议的文档化相似性度量方法在这里是最有效的（信息检索知道更好的方法）。但是我很高兴看到实际操作中除了简单的关键字搜索之外还支持在BTS中查找重复项的方法。
– dzieciou
2012年2月12日在21:16
@el Chief：您的方法要求测试人员在找到重复项之前先发出票证：-)然而，毕竟找到错误重复项可能很有趣，例如，将同一错误的重复项归为一类。
– dzieciou
2012年2月12日在21:26
#5 楼
唯一可以做的是尝试使人们养成在添加新问题之前先检查跟踪器是否存在问题的习惯，如果在人们经常工作的领域，我发现这种情况通常不是如此。不过，如乔所述，如果您要检查报告的到来情况，并以一致的方式对其进行分类，则通常可以限制这些报告，并在它们有新注释时将它们合并。我不知道一旦让人们在飞跃之前查看一下，我们系统中的骗子太多了，我发现这限制了这些问题。
#6 楼
团队中很少有最佳实践来避免重复出现的问题让同行对问题进行一次审查，以便测试人员可以确保其他人可以理解该问题并且不会重复还有其他问题。
在团队中创建缺陷经理角色，可以在分配给开发团队之前先对问题进行分类。
质量保证站立-团队可以讨论所报告的问题，并发现是否有重复。
/>可以合并不同浏览器中的同一问题，并可以解决重复问题。
将功能所有权角色分配给团队成员，这样他们就可以照顾自己的功能，并确保没有重复问题。
#7 楼
例如，一个可以看到设备崩溃，另一个可以看到通信丢失，而第三个可以看到她无法为该设备安装驱动程序
您的测试人员能否通过进一步调查确定根本原因？如果他们出于任何原因无法进行调查，那么有可能以工具或类似形式提供支持吗？
但是，如果您无法以这种方式提供支持，则无法进一步允许您的测试人员缩小问题的根源，那么以下方法可能会提供一些减少跟踪器中重复项的方法。减少重复，但是在搜索测试人员是否仍然不确定是否重复之后，最好将其放入以防万一。
如果大量测试人员针对一个问题进行过度报告，则可能会成为问题，但是如果发现问题存在于多个领域，则可以通过测试人员之间的有效沟通来避免应用程序。
这并没有考虑到根本原因可能是多个问题，而不仅仅是一个问题，而是给开发人员一些时间来研究问题，然后将问题反馈给测试团队。每次出现错误（带有某种约束，每个对话，任务，元素）或单个问题。
利用此信息，测试团队还可以更有效地解决问题。
另一种方法是统一测试团队用来描述问题的术语，也许以每个组件为基础。
这是以在整个开发周期中可能基于不断变化的功能来设置术语以及使整个团队保持最新状态为代价的。
评论
按目标分类，产生允许重现缺陷的方案，使用通用步骤和语言。将它们重新绑定到原始功能测试。