4

作为内部研究项目的一部分，我们正在尝试从 Bugzilla 数据库中收集一些指标；我们已经找到了一个工具来帮助我们从中收集一些指标（BugzillaMetrics），但我们现在问自己应该收集哪些指标？

现在，这就是为什么我想问你：

**

您收集了哪些关于错误的指标？

**

在我们的办公室，团队很小（2 到 5 名开发人员），我们考虑了每个开发人员的错误、每个开发冲刺、每个类别的错误（GUI、业务逻辑、数据库）等指标，但我们想听听其他一些想法。

提前感谢=）

4

4 回答 4

4

相关度量之一是在一个时间单位（例如，周、测试迭代等）上发现的缺陷数量。这可能是一个很好的指标，表明何时可以停止测试和修复。当然，这个指标也可以考虑 bug 的优先级（如果每周报告 10 个微不足道的 bug，你可能会比每周报告 1-2 个主要缺陷更不感兴趣）。

您可能会发现另一个有用的指标是修复缺陷的平均时间（报告和修复/关闭错误之间的时间）。

于 2009-04-20T17:34:24.690 回答
2

每个类别的错误肯定。我还会对实际花费的时间进行时间估算。这一点给开发人员一个工具来学习如何做出准确的估计。估计时间是一个出了名的模糊过程，你最好的来源是经验。使用此指标，您可以获得对每个人给出的估计的信心。

但是请注意，您仍然不能只说 Bug X 应该花费 Y 时间，因为它类似于 Z Bug。但是您可以让开发人员贝克查看它，当“需要 2 天才能修复”时，您可以判断他的准确程度。

于 2009-04-20T17:33:14.523 回答
1

我建议以下指标列表：

  • 整个产品中当前未解决的缺陷数。
  • 迭代燃尽图的指标：打开的错误/任务数，为给定迭代计划的已解决错误/任务数
  • 每个产品版本的缺陷检测百分比。该指标显示了在开发和 QA 期间检测到的缺陷与版本已经发布时在 QA 之后发现的缺陷之间的比率
于 2010-08-30T05:48:30.743 回答
1

以下是比较有用的：

  1. 每次迭代发现的 CRITICAL 和 MAJOR 错误的比率，以及解决这些错误所花费的平均时间。例如，对于 CRITICAL，可以在几小时内确定目标，对于 MAJOR，可以在几天内确定目标，可以根据历史数据修改目标，使其具有现实的挑战性。

  2. 发布时产品中剩余的主要错误数。根据产品/行业/客户的不同，发布 3 或 5 或 7 MAJOR 可能是可以接受的。{{ 假设 CRITICAL Bugs = 0 即不可接受。}}。

  3. 高优先级生命周期比率：P1 解决时间与所有优先级的平均解决时间的比率。

  4. Reopened Rate : CRs 重新打开的案例占迭代中已修复案例的百分比。

  5. 2 天内无评论/答案的 CR：创建后 2 天内研发未回复的案例比例。

  6. 严重错误的优先级 阻止程序和关键 CR 的平均优先级

  7. 已解决的案例与解决方案 INVALID 的比率 | 或重复。

苏希尔·贾拉利

于 2012-04-16T12:59:54.590 回答