我希望你能够解释为什么和在什么情况下使用每个系统，以及区分Bug跟问题追踪应用程序的特点。
一个缺陷跟踪系统和一个问题跟踪系统有什么区别？
41
- Aardvark
11
10有些人使用这个词汇是为了显得很商业化。 - cgp
3只是观点问题，以我个人看来。“Bug”这个词有点奇怪，并且根据定义不包括追踪“功能”，但这些信息是有用的，因此在我看来，“问题”更好。 - kenny
4“Bug”比“issue”更具体、更直观。 “Issue”是一个试图让每个人都感到好的软弱词汇。当有疑问时，选择更具日耳曼特色、少一些拉丁语气的词汇，例如“Bug tracking”。 - Nosredna
5我的计算机科学教授曾说过，不存在"bug"这个东西，只有错误。但是我认为没有人销售错误追踪软件。 - Matt Brunell
2“Tracker”是用来指代对象的术语。该对象可用于跟踪问题、功能请求、需求定义等任何您想要跟踪的内容。问题只是要跟踪的特定类型之一。没有必要将其定义为可跟踪实体的总体概念名称。 - altendky
显示剩余6条评论
14个回答
45
问题跟踪系统通常更多地与客户和客户问题集成。一个问题可能是“帮我安装这个”或“如何将fubar放入flim flam中”。甚至可能是类似于“我需要你的软件的评估密钥”。
缺陷跟踪系统帮助您跟踪程序中的错误或缺失问题。
在查看Web系统时，通常会有重点差异，即帮助客户或跟踪您的软件问题。
- Alan Jackson
1
3虽然区别是存在的，但我曾见过将缺陷跟踪系统用作问题跟踪系统，反之亦然。然而，错误地使用通常会导致次优的体验。 - Joachim Sauer
40
以下例子可以更清楚地说明两者的区别。
假设今天出现了一个影响了5位客户的生产问题，但是这个问题只是由一个软件缺陷引起的。
在你的问题跟踪系统中，你打开了5个工单，并开始跟踪每个客户报告的情况、与他们的沟通、软件补丁的应用时间等。你可以为每个客户单独跟踪这种类型的信息。
在你的缺陷跟踪系统中，你仅仅记录了1个关于这个软件缺陷的条目，并开始跟踪如何重现该问题、代码更改等方面的内容。
只要客户满意解决了问题，其问题就可以关闭，这可能涉及到修复软件，也可能不需要。而当缺陷被修复并重新测试后，它就可以被关闭了。
两个系统，一个面向外部，一个面向内部，分别跟踪两种不同类型的事物，每种事物都有自己的生命周期。
- azheglov
3
3感谢您认识到每当客户/用户反馈问题时都会创建问题，并且解决问题并不意味着修复软件中的错误。+1 - molf
1有没有地方可以了解这种问题跟踪的方式？我目前的工作场所需要改进如何处理所有这些问题，我想收集关于如何更好地管理这类工单的信息。 - Ape-inago
@azheglov，我对你的解释还不太满意。您如何事先知道这 5个问题共享相同的错误？此外，当两个不同的漏洞实际上是同一个漏洞时，您如何在事先知道？ - Pacerier
11
像Trac这样的Bug跟踪系统旨在为程序中的每个固有问题创建一个工单，因此通过修改程序来关闭工单。
像IssueTrackerProduct这样的客户支持工单系统旨在为每个遇到情况的客户创建一个工单，因此通过解决该客户的情况（可能通过修改程序）来关闭工单。
有关每种系统的示例，请参见维基百科的问题跟踪系统比较。
- krubo
10
一个bug是问题的子类。所有的bug都是问题，但并非所有的问题都是bug。
通常情况下，bug是代码库中的缺陷。这与未完成/尚未实现的功能不同，或者更难以确定的问题，比如开发人员提交一张票来处理技术债务的一部分或者对UI的关注。从语义上讲，所有这些都是“问题”。
当不属于那些其他类别时，通用问题往往是最终用户报告的某些事物的代表。在大多数系统中，这个报告的问题本身被处理为一个bug报告。我敢说这是个错误。
棘手的部分是，有时多个问题可能与其他问题相关。它可能涉及到同一个bug、多个bug，或者实际上是一个功能请求。也就是说，问题之间可能存在多对多的关系。
为什么这种区别很重要？嗯，内部有一个自然树——解决一个问题可以间接地完成（或有助于完成）一百万个其他问题。这也会影响问题的解决方式。缺陷本身可以通过修复代码来解决，或者使其变得无关紧要。如果是用户投诉，则可以通过发送一个解决方法来解决，然后在原始缺陷解决时进行跟进。
更好地表示和处理这些细微差别的功能确实是在问题跟踪系统中寻找的关键。
在某个阶段，你所说的是流程和方法论，而不仅仅是实际的票务系统，实际名称应该开始变得无关紧要。主流和企业定向的解决方案往往在像ITIL这样的流行系统上运行，但只要团队中的每个人都对客户服务需求有很好的理解，你就可以使用临时方案。我个人认为这是瀑布（ITIL）与敏捷（DevOps）的情况。
- Ape-inago
4
关于你倒数第二段的问题，你使用什么软件？ - Pacerier
@Pacerier 我通常在Trello中设置两个不同的工作流程 - 一个用于用户面向问题，类似于典型的IT帮助台系统，另一个用于内部开发票据，作为ScrumBan - 并广泛使用其互联功能。我还使用一些自定义的东西通过Zapier自动化了一堆操作，以便我可以从表单中获取错误报告，并根据需要拉取GitHub问题，或将分析数据推送到电子表格以供稍后处理。我看到过Autodesk、Team Foundation Server、Freshdesk和Jira做得很好。 - Ape-inago
Trello不是一个“真正”的缺陷跟踪应用程序，对吗？ - Pacerier
一旦您将其与github的问题跟踪器进行交互，它基本上看起来像一个看板。使用粘性笔记在墙上跟踪问题通常使用看板，因此它只是这种方法的数字化版本。有了它的搜索功能，我可以快速找到现有的“错误”和用户报告的问题。而且Trello的API非常灵活-我甚至可以通过记录卡片移动到电子表格中的完成列时的情况来制作燃尽图表。 - Ape-inago
5
这只是语义学上的区别。Bug指的是问题，Issue则指需要解决的事项。除此之外，它们在很多方面都是相似的。
- Alister Bulman
4
2赞同：bug == issue == 需要修复的问题 - hometoast
5问题跟踪系统与缺陷跟踪系统的目的确实不同，有许多其他很好的回答可以看到。 - molf
我认为这不是语义问题...你可能被告知修复错误1、2和5，而你又遇到了一个新的问题，因为数据库出现故障。一个问题可能是一个或两个bug，但不是同一个问题... - RSolberg
1我认为这是语义学问题。根据我的经验，将“问题”放入错误跟踪数据库中不会让人们感到困惑。 - Nosredna
4
这是一个模糊的界限。问题跟踪系统可能被认为是两者中更通用的。因为所有的Bug跟踪系统都是问题跟踪系统，但不一定反之。
来自我们的朋友维基百科
缺陷跟踪系统是一种软件应用程序，旨在帮助质量保证和程序员跟踪报告的软件缺陷。它可以被视为一种问题跟踪系统。
- Matthew Vines
3
1请查看《我们共同的朋友》中的评论：http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems “此页面包含问题跟踪系统和错误跟踪系统。在某些情况下，区分不清，因此当缺少条目时，请同时查看其他类别。” - Aardvark
@Aardvark，@Matthew，请停止引用那些我们应该编辑的不完整文件。请直接引用维基百科使用的实际引用。 - Pacerier
@Pacerier 你知道这个问题在2009年就已经被回答了吗？如果你认为这个答案不符合你的标准，那么现在你应该纠正它。 - Aardvark
4
代码中发现了一个bug。
问题可能出现在任何地方，包括流程、硬件和人员等方面。
关于定义的具体含义取决于您采用的开发流程。
- Peter
3
不确定人们是否可以记录与人有关的问题 :) - shahkalpesh
当然可以。如果开发人员没有遵循公司制定的编码标准，他们就会成为问题和项目风险。 - Peter
@Peter，把与某人的问题称为“bug”并没有什么不对。 - Pacerier
3
我认为bug是指可以通过编程修复的问题，而问题则更多地与可用性有关。
例如，登录表单。登录表单中的一个bug可能是在登录完成后表单重定向不正确。而问题则可能是整个登录过程太慢，或者没有选项来发送忘记密码的电子邮件。
- Soviut
3
这并不是一个完整的回答你的问题，但我曾经遇到过类似与客户打交道的问题。我认为在最高层面上，缺陷跟踪系统通常更加专注于开发人员。也就是说，开发人员正在尝试跟踪代码中的问题。函数没有返回正确的值，需要进行更多的验证等等。
一个很好的与代码集成的系统的例子是Trac。
问题跟踪系统似乎更加以客户为中心。例如，客户能够说“当我点击‘确定’时，我会收到一个错误”。这可能是用户培训、功能或实际上是一个漏洞。
因此，在我参与的许多项目中，我们将它们分开管理。我们有一个高级别的问题跟踪系统，可能不会导致在缺陷跟踪系统中创建实际的缺陷。然而，许多许多缺陷在没有在问题跟踪系统中创建任何“问题”的情况下被内部跟踪。
我看到这两者之间的问题是，对于没有经验的用户来说，很难在像Trac这样的系统中输入工单，因为他们会被技术术语弄糊涂。然而，高级问题跟踪系统与代码集成不紧密，对开发人员毫无用处。
无论如何...这是我的两分钱。
一个很好的与代码集成的系统的例子是Trac。
问题跟踪系统似乎更加以客户为中心。例如，客户能够说“当我点击‘确定’时，我会收到一个错误”。这可能是用户培训、功能或实际上是一个漏洞。
因此，在我参与的许多项目中，我们将它们分开管理。我们有一个高级别的问题跟踪系统，可能不会导致在缺陷跟踪系统中创建实际的缺陷。然而，许多许多缺陷在没有在问题跟踪系统中创建任何“问题”的情况下被内部跟踪。
我看到这两者之间的问题是，对于没有经验的用户来说，很难在像Trac这样的系统中输入工单，因为他们会被技术术语弄糊涂。然而，高级问题跟踪系统与代码集成不紧密，对开发人员毫无用处。
无论如何...这是我的两分钱。
- Andrew Flanagan
1
嘿，Trac自称为问题（而非漏洞）跟踪系统。 - Aardvark
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接