错误跟踪器软件的核心基本功能是什么？

Question

  

可能重复：
  What should a good BugTracking tool be capable of?

尽管bug跟踪器可以提供大量功能，但我觉得它有点矫枉过正，并且正在考虑推出自己的解决方案。话虽如此，我不想删除任何可能经常用于现有解决方案的核心功能。

到目前为止我能想到的： - 制造错误 - 分配错误 - 关闭错误 - 添加对错误的描述

谢谢！

Answer 1

• 开发人员与用户之间的沟通。
• 用户能够分配某些信息，例如严重性（该bug与其相关程度）。
• 开发人员可以覆盖该优先级，并在可能的情况下提供理由。
• 能够将任务分配给开发人员。
• 能够在错误，增强和功能请求之间进行排序。增强功能和功能请求之间的区别非常微妙，但非常重要。
• 能够附加文件（例如屏幕截图）
• 能够拥有自定义字段（例如能够选择哪个操作系统，哪个Service Pack级别，应用程序版本等）。
• 能够拥有自定义用户配置文件，该配置文件还提供有关其硬件的详细信息。能够拥有用户电话号码（如果他们在您的LAN上）也很好，这样您就可以提出问题，如果需要的话。
• 隐私。某些项目（如安全漏洞或处理财务信息的信息）需要保密。甚至OSS也会不时地做到这一点，直到他们能够准备好补丁。每个人都有自己的规则。
• 能够显示修订版之间的更改，以便您可以通过电子邮件发送更改日志，以便用户知道您拥有和未执行的操作。
• 提醒您哪些项目未撤消且已分配给您/未分配。

这就是我所能想到的......

Answer 2

1. 制作错误
2. 关闭错误

这足以在'bug'实体的生命周期内完成关闭。它是否适合您的目的是另一回事。

查看Mantis的功能，选择您需要的功能，计算编写它们所需的时间，然后将时间花在更有用的内容上除非你绝对必须创建自己的。 ; - ）

Answer 3

一个优秀的搜索引擎。

令人惊讶的是，花费数千美元的多少bug追踪产品却出现了可怕的错误。

如果没有真正体面的搜索，您的错误跟踪更像是“错误记录” - 记录和遗忘 - 系统几乎没用。

Answer 4

错误跟踪器只不过是需要完成的事情列表。

它可以像软件目录中的文本文件一样简单到一个拥有数百名用户的完全成熟的bug跟踪器。

从您需要使用的内容开始，然后根据需要进行扩展。

Answer 5

使用Jira，你会得到很好的帮助。

Answer 6

对于大多数系统（如跟踪错误的系统），通常不会创建或编辑使系统有用的数据。这一切都归结为在收集数据之上，您可以轻松地将信息导航到“增值”。

考虑将使用系统的人员，程序员，经理等。对于每一组人来说，什么类型的信息会让他们一次又一次地回到系统是值得的。如何让他们更容易获得这些信息？

收集信息很容易，增加价值是困难的部分。

保罗。

Answer 7

以下是一些重要功能：

• 为bug指定优先级（例如，关键，主要，中等，次要，无关紧要）
• 将错误分配给将要修复的特定版本
• 观察者功能（因此您可以在状态更改时通过电子邮件发送）
• 工作流程（即谁正在处理它，状态如何）

Answer 8

FWIW：当我们推出自己的请求跟踪系统时，我们围绕procmail和我们现有的内部Web身份验证系统构建它，因为我们希望它非常不引人注意地使用：我们只是向开发人员发送电子邮件（使用组别名）如果我们想要）并向主题添加“[t]”以打开票证。收件人会收到包含原始请求的修改后的电子邮件以及显示该票证的网页的附加链接，并允许他们通过单击鼠标将其关闭。因此，最常见的任务是通过电子邮件客户端执行（打开，请求更多信息，回复......），尽管还有一个简单的Web界面供搜索等。

只用了几个小时就写了，在7年左右的时间内发出超过34000张请求票，我想可以声称它只有基本的核心功能：

• 创建一张票（通过带有标记主题的电子邮件）
• 关闭一张票（点击电子邮件中的链接，然后点击“完成”）
• 所有通讯都通过电子邮件进行，而不是通过网络界面（！）
• 原始电子邮件的收件人或发件人（开票）会收到有关已关闭的门票的通知（“主题：＆lt;旧主题＆gt;由＆lt; someone＆gt;关闭”+正文中的票证链接，足够的信息对于大多数人来说，他们不必去看看哪个票/错误等。）
• 一个简单的网络界面为自己/开放/发送/团队门票提供搜索功能

值得注意的缺席可能需要更大的开发团队/更强烈的软件开发：

• 门票的灵活状态（dupe，wontfix，重新开放等）
• 优先级
• 明确地重新分配门票（在我们的开发团队中，电子邮件只会被发送给不幸的人，而且必须这样做）
• 向未向所有人发送的故障单添加评论
• 将错误分配给特定版本的软件

YMMV，但到目前为止它对我们来说效果非常好，包括错误和发送者想要跟踪的简单请求。

Answer 9

分类，优先级和标准化。

以及简单的查询方式，以便您可以在上述三项工作中获得丰厚的回报。

此外，请确保您所做的一切都是可扩展！我们总是决定在项目期间根据需要/火灾添加/编辑我们的错误模板。

那里有很多很棒的解决方案，你可能不需要自己动手......但无论哪种方式，你都必须做出同样的决定。我们使用一种解决方案，允许我们推出自己的模板，因此在每个项目的开始时我们都会重新讨论同样的讨论。

Answer 10

定义错误。

考虑到这一点很可能会让你意识到你会花很多时间“自己动手”。

Answer 11

这可能会超出您的想法，但对我来说，与源代码控制的集成是必须的。能够查看与错误/问题相关的版本之间的差异非常方便。

Answer 12

请请不要花费太多时间“滚动自己”。花在研究和学习使用真实跟踪系统上的时间更长。

有些人要看

Trac，Bugzilla和FogBugz。最后一个为小型（一个或两个人的商店？）公司提供免费托管解决方案。

SO有很多关于这个主题的主题。

尽管只是单词doc或电子表格，但请尽量不要自己动手。任何时候你自己花钱都是浪费。

修改

既然你不会被劝阻，那么我可能会添加一些别人没有提到过的东西。

您需要报告功能 - 用户需要能够运行查询，并且他们应该能够选择他们想要“查看”的字段。

缺陷的工作流程/生命周期也是一个很好的特性。 （基本上是缺陷将通过的状态机状态。）实际上，这是一个有用的练习，可以定义所有用例和功能。鉴于你在大学并且没有开始作为CS专业，我怀疑你会自己想出很多。花一些时间浏览现有产品的功能列表和演示。

能够将电子邮件发送给各方感兴趣的人。

匿名用户能够看到他们输入的SPECIFIC缺陷

不同的访问级别和权限（管理员，经理，开发人员，测试人员，最终用户）

Answer 13

我们的错误跟踪系统是我公司与客户之间的两个必要链接之一（“实时”产品评论鼓励现有客户建议改进和用户界面调整为另一个）。

错误跟踪系统首先必须鼓励与客户进行可跟踪的“对话”。它必须回答“你有没有解决我已经拥有的问题（广泛定义）？”

它必须（没有特别的顺序）：

1. 问题或功能请求的简短描述（标题）
2. 扩展说明的空间
3. 附加文件/图像的能力（截图）
4. 确定错误/功能优先级的能力
5. 将条目分类为错误，功能，查询等的能力
6. 向区域（UI，数据库，文档等）分配错误/功能的能力
7. 他能够为产品分配错误/功能（我们跟踪五种产品上的错误）
8. 为版本分配错误/功能的能力（“将在5.1版本中修复”）
9. 向人（开发人员/编写者）分配错误/功能的能力
10. 向客户（记者）分配错误/功能的能力
11. 重新分配给其他人（开发者）的能力
12. 解决错误/功能的能力（将其标记为已完成并准备好进行测试）
13. 标记分辨率状态的能力（已修复，无法修复，无法再现等）
14. 关闭错误/功能的能力（在解决和测试后将其从列表中删除）
15. 重新打开错误/功能的能力（如果测试失败，则恢复为“打开”）
16. 通知客户该错误的能力已经解决（例如通过电子邮件）
17. 每一步的日期和时间戳（打开，解析，关闭，重新打开）
18. 报告Open bug数量的能力！ （我们有多接近发布？）
19. 显示错误报告与解决方案的能力
20. 按日期，优先级，产品，人员等搜索错误/功能的能力
21. 能够列出和排序错误以便于扫描！

这些是我们通常在我们的系统中使用的东西（FogBugz）。虽然这可能看起来很长，但我们确实使用了我在此列出的所有功能！