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

Question

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

虽然有一大套的功能，一个bug跟踪系统可以有我觉得这是一个有点矫枉过正，并正在考虑推出自己的解决方案。据说我不想删除可能经常用于现有解决方案的任何核心功能。

我能想到的迄今为止的： - 创建错误 - 分配错误 - 关闭错误 - 添加描述错误

谢谢！

Answer 1

• 开发者和用户之间的通信。
• 用户可以分配特定位信息的能力，如严重性（错误与他们有多大关系）。
• 开发人员可以覆盖该优先级，并在可能的情况下给出原因。
• 能够将任务分配给开发人员。
• 能够在错误，增强和功能请求之间进行排序。增强和功能请求之间的差异非常微小，但非常重要。
• 能够附加文件（如截图）
• 能够自定义字段（如能够选择哪个操作系统，哪个服务包级别，应用程序版本等）。
• 能够拥有自定义用户配置文件，该配置文件还提供了有关其硬件的详细信息。如果能够获得用户的电话号码（如果他们在您的LAN上），那么您也可以在需要时提问。
• 隐私。一些项目，如安全漏洞利用或处理财务信息的信息，将需要保密。即使是OSS也会不时地做这件事，直到他们能够准备好补丁为止。每个人都有自己的规则。
• 能够显示修订之间的变化，以便您可以通过电子邮件发送更改日志，以便用户知道您拥有和未完成的任务。
• 关于哪些项目未完成并且完全分配给您/未分配的提醒。

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

Answer 2

定义错误。

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

Answer 3

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

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

从您需要处理的内容开始，然后根据需要展开。

Answer 4

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

Answer 5

使用吉拉，你会很好的掌握。

Answer 6

对于大多数像错误跟踪的系统，通常不会创建或编辑使系统有用的数据。这一切都归结为您只需收集数据即可轻松浏览信息以“增值”。

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

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

Paul。

Answer 7

请请请不;吨花很多时间“滚动你自己的。”在研究和学习使用真实跟踪系统时，你的时间会更好。

一些看看

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

SO有很多关于此主题的话题。

尽量不要自己滚动，除非它只是一个单词文档或电子表格。任何时候你花费自己的钱是一种总的浪费。

编辑

既然你将不会被劝阻的话，我也许会添加一些东西别人都没有提到。

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

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

电子邮件能够发送给不同的利益相关方。

匿名用户能看到他们进入

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

Answer 8

1. 创建一个错误
2. 关闭特定缺陷一个bug

这足以在'错误'实体的生命周期中关闭。是否有足够的功能为您的目的是另一回事。

看看的Mantis功能，选择你需要的功能，计算它需要多长时间，你给他们写，然后把时间花在更有用的东西除非你绝对要创建自己的。 ;-)

Answer 9

这里有一些重要的特点：

• 分配优先级的错误（如紧急，重要，中，小规模的代码）
• 分配错误的特定版本中，这将是固定
• 守望功能（这样你就可以通过电子邮件发送时的状态变化）
• 工作流（即谁是工作就可以了，有什么地位）

Answer 10

FWIW：当我们推出我们自己的请求跟踪系统，我们建立了它周围的procmail和我们现有的内部网络认证系统，因为我们希望它是非常不显眼的使用：我们只是发送电子邮件给开发人员（使用，如果我们组的别名想要）并添加一个“[t]”到主题以打开票证。收件人得到修改的电子邮件与原始请求和一个额外的链接，该网页显示的车票，并允许他们以1次鼠标点击关闭。所以最常见的任务是通过电子邮件客户端（打开，请求更多信息，回复......）进行，虽然也有用于搜索等

只花了几个小时到一个简单的Web界面写后7年左右超过34000张请求的门票，我想声称它只有基本核心功能，它的确定：

• 创建票证（由具有显着的主题电子邮件）
• 收票（点击电子邮件中的链接，然后点击“完成”点击）
• 所有通信都通过电子邮件，而不是通过（！）的Web界面谁是收件人或原始邮件的发件人
• 人（打开票）通知有关封闭门票（：+链接票“主题<老主题>通过<有人>关闭”身体，足够的信息，对于大多数人来说，这样他们就不必去看看这票/错误，是等）
• 一个简单的Web界面提供的搜索功能为自己/开/发送/团队票

这可能需要一个更大的开发团队/更激烈的软件开发

没有显着的特点：

• 取票（欺骗，wontfix，重开等灵活状态）
• 优先
• 重新分配门票明确（在我们的开发团队，电子邮件只是被重新发送到倒霉的家伙谁拥有这样做）
• 添加注释的票不被发送给大家
• 分配错误的软件

因人而异的特定版本，但它一直对我们非常好，到目前为止，无论是对错误和发送者想要跟踪的简单的请求。

Answer 11

我们的bug跟踪系统是我公司与客户（“活”的产品评论，其中鼓励现有客户提出改进意见和用户界面的调整是其他）之间的两个基本环节之一。

一个bug跟踪系统必须首先是鼓励可追踪的“对话”与您的客户。它必须回答这个问题：“你是否已经解决了我一直存在的问题（广义地定义）？”

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

1. 问题或功能请求的简短描述（标题）
2. 间延长的描述
3. 附加文件的能力/图像（截图）
4. 优先错误的能力/功能
5. 归类条目错误，特征，查询的能力，等等​​
6. 分配错误/功能区（UI，数据库，文档等）的能力
7. 他分配错误/功能的产品（我们跟踪的五种款产品的bug）的能力
8. 分配错误/功能的能力以发行（“被固定在5.1版本”）
9. 分配错误/功能能力的人（开发商/作家）
10. 分配错误/功能给客户的能力（记者）
11. 的能力，重新分配给不同的人（开发商）
12. 到解决的bug /功能（它们标记的能力为完成并准备测试）
13. ，以纪念解决状态（固定，不会解决，不能复制等）的能力
14. 到&分辨率后，关闭错误/功能（把他们赶走列表的功能测试）
15. 能够重新打开错误/功能（如果测试失败，还原为“打开”）
16. 能够通知客户错误已得到解决（例如，通过电子邮件）
17. 每个步骤的日期和时间戳（打开，解决，关闭，重新打开）
18. 能够报告打开的错误数量！ （我们有多接近发布）
19. 能够显示错误报告与分辨率
20. 能够按日期，优先级，产品，人等搜索错误/功能
21. 能够列出和排序错误，以便于扫描！

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

Answer 12

分类，优先化和标准化。

和简单的方法来查询它使您可以收获上述三个辛勤工作的回报。

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

这里有很多很棒的解决方案，你可能不需要自己推出。但是不管怎样，你都必须做出相同的决定。我们使用的解决方案允许我们推出自己的模板，因此在每个项目开始时我们都会重新讨论这个相同的讨论。

Answer 13

一个很好的搜索引擎。

令人惊讶的是，有多少错误跟踪产品花费数千美元就会出现这种可怕的错误。

没有一个真正体面的搜索你的错误跟踪更像是一个“错误日志记录” - 日志和遗忘 - 几乎没用的系统。