哪些错误统计信息最有用？为什么？

#1 楼

除了向joshin和user246发出通常的“他们说的话”之外，我还要补充一点：不能保证错误被重新打开的次数将为您提供任何有用的信息。原因如下：


涉及多个错误，但是它们都有相同的症状。在这里，可能有人以相同的问题重新打开了该错误，但它是具有相同症状的另一个问题。您无法知道是否重新激活错误报告是其中之一。
有人针对相同的问题创建了一个新的错误报告，并且不会将其检测为重复报告。这在大型，复杂的系统中尤为常见，在该系统中，问题的表现可能会因用户的配置而异，或者每个人向同一系统报告问题。
激活了错误报告，以便向后集成修复程序

基本上，在任何具有足够复杂性以生成...有趣的错误的情况下，人为差异都会使错误报告跟踪虚假警报中的演习。您可能会得到的最具体的信息是系统中哪个区域产生最多的问题，而那是您不需要错误跟踪器的原因-每个与系统一起工作的测试人员都可以快速了解问题区域。

此外，正如joshin指出的那样，存在不正当激励措施的风险。开发人员因引入错误而受到惩罚的公司通常会开发一个完全非正式的错误报告系统，以便测试人员不会感觉到他们通过报告问题来伤害程序员。大量重新打开的错误可能不是错误修复的问题，也不是问题被误解的地方。这可能是一个间歇性问题，其中第1轮涉及添加日志以尝试在问题发生时进行跟踪，第2轮根据从第1轮派生的信息添加更多日志，第3轮提供了可能的解决方法，但由于问题无法解决，由团队转载，如果修复不正确，还有更多日志记录，依此类推。

#2 楼

这取决于您认为有用的内容。如果您以某些指标（重新打开的次数，每个开发人员的错误数等）开始跟踪错误，则可能会无意中开始为特定行为创建诱因。例如，如果您开始跟踪每个开发人员的错误，则可能会发现报告的错误的数量和严重性发生了巨大变化。跟踪需要重新打开错误的次数可能会引起对经常重新打开的错误的更多关注。根据您的情况，这可能是一个好目标，也可能不是一个好目标。

所以我的答案是跟踪（您认为）与您的项目相关的度量。我怀疑总体指标在每种情况下都有用，但是可能有些指标通常会很有帮助。

还请记住，您花每一分钟来决定哪些指标有用，而使用哪一分钟却并没有真正发现bug和改进软件。人们如此轻易地忘记了机会成本的概念。

#3 楼

关于问题的一部分“您如何确定要跟踪什么和忽略什么？”我现在正在重新评估指标的中间过程中，我的方法是询问利益相关者对他们有价值的东西。询问开发人员，询问项目经理，询问高层管理人员，询问最终用户/客户，询问您自己和测试团队的其他成员。不同的指标对不同的受众而言很有价值。

指标可以分为几类：


衡量测试状态的指标

％已执行的测试数量
已完成％测试计划


衡量测试有效性的度量标准

测试环境的可用性
缺陷年龄
>发布后发现的缺陷数量与发布前发现的缺陷数量


度量质量的度量标准

测试覆盖率的百分比
测试通过率的百分比
发现的缺陷数量
缺陷的严重程度


度量资源的度量标准

有几个可以归为一类。并不是说分类很重要。我只列出了多个类别，让您考虑不同的受众如何看待不同的指标。

#4 楼

在我的只有三个开发人员和一个测试人员的小公司中，我们跟踪的唯一错误统计总数是该版本中已修复的错误总数。由于存在大量bug的可能原因有很多，因此我们不仅仅基于该数目来做出决定。我们还跟踪了每个开发人员和每个功能区域的错误数量。我使用这些统计数据来向具有良好声誉的开发人员施加压力，以检查错误代码。回想起来，我应该更加谨慎地使用这些统计数据。错误跟踪统计信息众所周知是草率的，以错误的方式使用这些统计信息可能会不公平地损害某人的职业。

跟踪重新开放很有趣，因为它们表明存在误解。您必须花更多的精力来确定误解的根源以及误解的原因。

#5 楼

正如Joshin所提到的，任何度量标准都可以“为特定行为创造诱因”。使用度量标准时，团队中的每个人都必须清楚使用度量标准的预期目的。指标应始终是有助于改进开发/测试过程的工具。我发现有用的度量标准是缺陷趋势报告，例如一段时间内打开的缺陷数量，关闭的缺陷数量。