维护良好的错误数据库的步骤

维护错误数据库对于每个项目都很重要。我习惯将以下内容存储在错误数据库中

• 发行日期时间
• 分配给谁
• 是否已经解决
• 如果解决了，那么解决日期时间

这些足以维护一个良好的错误数据库吗？

一个好的错误数据库可能包含以下内容

//日期时间相关

• 错误的发布日期时间
• 预期的修复/解决日期时间
• 如果解决了，那么解决日期时间

//分配人+收件人

• 分配者（检测到）
• 分配给

//错误行为

• 观察（越野车）行为
• 屏幕截图（可能）
• 完成重现该错误的步骤
• 预期行为

// 优先

• 错误的优先级

//链接，状态和其他

• 相关错误链接
• 错误状态
• 是否已经解决
• 如果解决了，如何解决并说明

编辑：我也想推荐

• 在什么版本/分支中发现了该错误
• 在哪个修订版/分支中修复了该错误

编辑：我喜欢@jgauffin的评论

• 无法修复，不是错误，重复，已解决

编辑：一个好的错误数据库系统也保持

• 责任分配矩阵

可能有一些自定义字段，你可能需要登录，这取决于项目的需要。我提出了以下列表，您可能还需要考虑以下列表：

• 问题DateTime错误/缺陷
• 错误的描述-重新创建的步骤。
• 找到的环境（开发，质量检查，质量控制，分段，产品）
• 问题的屏幕截图
• 谁记录了它（检测到）
• 分配给谁（分配人）
• 错误的严重程度（低，中，高）
• 预期分辨率 DateTime
• 状态分类（建议，进行中，已解决，已结束）
• 错误已关闭DateTime-解决并关闭错误后
• 分配给要测试的人（由测试）

编辑：在Bugzilla之类的软件中对大多数有价值的通用信息进行了很好的描述。Bugzilla是最初由Mozilla项目开发和使用的基于Web的通用Bugtracker和测试工具，并且根据Mozilla Public License-获得许可，并且是免费的。我强烈建议将它们作为主要示例，并将其扩展到您的项目需求上。

大多数有用的字段似乎已经被其他答案覆盖，但是我发现有用的一些是：

• 在哪个版本/分支中发现了错误。
• 在哪个修订版/分支中进行了修复。

这比发现/修复错误的日期/时间更为具体。

如果您的软件在多个平台（操作系统或硬件）上运行，则可能还需要一个字段来列出发生错误的平台。

但是，维护错误数据库所包含的内容远远超出其应包含的字段。您还需要考虑如何使用底座。

尝试将打开的/未解决的错误的数量保持在尽可能低的水平。这似乎很明显，但可能比预期的要困难得多，至少对于大型项目而言。我经常看到人们太害怕解决不可复制的问题，或者原始问题的提交者从未提供过缺少信息的问题。同样，永远存在的漏洞以及在该软件的古代版本中最后一次出现的漏洞也不应遗留。这会使数据库随着可能是或不是实际问题的问题而增长，并减慢了开发速度。

您通常需要查看错误的历史记录-可以解决该错误，然后重新打开，然后再次解决，依此类推。因此，除了已经建议的内容之外，我建议您有一个单独的表来跟踪每次（重新）打开错误历史记录。该表将与错误表具有多对一关系，并且可能具有如下字段：

• 开馆日
• 开启者
• 解决日期
• 解决者
• 所花费的时间
• 如何解决
• 等等

您可能还需要一个类似的表格来跟踪错误的分配人和时间，尤其是在大型团队中工作时。

我还建议您看一下现有系统。IMHO Jira是最好的问题跟踪系统之一。它具有非常丰富的功能，您可以将其中一些功能用作自己系统的指南。

错误跟踪的过程与数据一样重要。也尝试考虑以下几点：

• 用户如何报告错误？
• 谁将错误输入存储库？
• 谁可以确认错误存在？
• 谁可以确认错误已解决？
• 谁通知最终用户该错误已解决？

建立一个RACI图表，以便团队中的每个人（包括最终用户）都知道他们的责任。将其与适当的数据输入技术结合使用，您将花费很少的额外精力就可以看到更多的价值。