错误跟踪和问题跟踪系统有什么区别？
我正在寻找解释为什么以及何时使用每个系统， 以及哪些function区分错误与问题跟踪应用程序。
问题跟踪系统通常将客户和客户问题整合在一起。 一个问题可能是“帮我安装这个”，或者“我怎样才能使fubar陷入尴尬的境地”。 他们甚至可能像“我需要软件的评估键”。
错误跟踪系统帮助您跟踪程序中的错误或丢失的东西。
在查看Web系统时，通常关注点有很大不同，无论是帮助客户还是跟踪软件问题。
从下面的例子中可以看出这个区别。
假设您今天有一个生产问题影响了5个客户，但是是由于一个软件缺陷造成的。
在您的问题跟踪系统中，您打开了5张门票，开始跟踪每个客户的报告内容，传达给他们的内容，应用软件补丁的时间等等。您可以为每个客户分别跟踪这些内容。
在你的bug跟踪系统中，你为软件缺陷做了1个条目，开始跟踪重现，代码更改等步骤。
客户问题可以在客户满意的时候closures，也可能不涉及修复软件。 错误可以在固定和重新testing时closures。
两个系统，向内和向内，跟踪两种不同的东西，每个都有自己的生命周期。
像Trac这样的Bug跟踪系统被devise为针对程序固有的每个问题都有一张票，所以通过修改程序来closures票。
像IssueTrackerProduct这样的客户支持票据系统被devise为每个客户遇到一种情况 ，所以通过为客户制定情况（可能通过修改程序）来closures票据。
有关每个示例，请参阅维基百科的问题跟踪系统比较
错误是问题的一个子类。 所有的错误都是问题，但并不是所有的问题都是错误的。
通常，错误是代码库中的缺陷。 这不同于一个不完整的/尚未实现的特性，或者像开发商投入票据来处理技术债务或者担心用户界面那样更加困难。 所有这些都是语义上的“问题”。
当不属于其他类别时，通用问题通常不是最终用户报告的内容的表示。 在大多数系统中，这个报告的问题本身是作为错误报告处理的。 我冒昧地说这是一个错误。
棘手的部分是，有时多个问题可能与其他问题有关。 它可能涉及相同的错误，多个错误，或者实际上是一个function请求。 也就是说，问题之间可以有多对多的关系。
为什么区分很重要？ 那么内部就有一棵天然的树 – 解决一个问题可以间接地完成（或有助于完成）一百万个其他的问题。 这也是一个问题如何解决的区别。 缺陷本身可以通过修改它的代码更改来解决，或者使其不相关。 如果是用户投诉，可以通过发送解决scheme来解决问题，然后在解决原始问题时留待跟进。
能够更有效地expression和处理这些细微差别的function，实际上是在票据跟踪系统中寻找的。
在某种程度上，你正在讨论的stream程和方法比实际的票务系统更多，事实上的名字应该开始变得无关紧要。 主stream和面向企业的解决scheme倾向于在像ITIL这样的stream行系统上运行，但是只要团队中的每个人都能够很好地理解客户服务的需求，就可以使用特殊的东西。 我个人认为这是一个瀑布（ITIL）与敏捷（DevOps）的情况。
这只是语义。 一个bug是一个问题，一个问题是可以做的。 他们在其他方面是相同的。
它最好是一条模糊的线。 问题追踪系统可能被认为是两者中较一般的。 所有的错误跟踪系统都是问题跟踪系统，但不一定是相反的。
从我们的朋友维基百科
错误跟踪系统是一个软件应用程序，旨在帮助质量保证和程序员跟踪他们工作中报告的软件错误。 它可以被看作是一种问题跟踪系统。
在代码中发现一个错误
一个问题可以在任何地方find，在stream程中，在硬件上，在人身上。
这取决于你所采用的开发过程是什么定义。
我相信一个bug是可以在代码中修复的，而一个问题更多的是可用性的问题。
例如，一个login表单。 login表单中的一个错误是login完成后，表单redirect不正确。 虽然问题在于整体login过程太慢，或者没有select通过电子邮件发送忘记的密码。
这不是你的问题的完整答案，但是我也遇到了与顾客打交道的类似问题。 我认为在最高级别上，错误跟踪系统似乎通常更注重开发者。 也就是说，开发人员正试图跟踪代码中的问题。 函数没有返回正确的值，应该进行更多的validation等等。
Trac是一个与代码很好集成的系统的一个很好的例子。
问题跟踪系统似乎更加以客户为中心。 例如，能够让客户说：“当我点击'确定'时，我得到一个错误”。它可能是用户培训，它可能是一个function，或者实际上可能是一个错误。
所以在我工作的许多项目中，我们保持这些独特的。 我们有一个高层次的问题跟踪系统，可能会或可能不会导致错误跟踪系统中创build一个实际的错误。 但是，在内部跟踪许多错误，而在问题跟踪系统中没有创build任何“问题”。
我在这两者之间看到的问题是，对于没有经验的用户来说，像Trac那样input票据真的不是很容易，因为他们被技术术语弄糊涂了。 但是，高级问题跟踪系统并没有与代码紧密集成，所以对开发人员来说是没有用的。
无论如何…我的$ 0.02。
错误 ：stream程中的任何地方（应用程序，数据库，报告等）的缺陷将会阻止100％的所需function发生。 也被称为缺陷。
问题 ：可能是由一个错误或错误引起的，一个问题是系统中某种forms的与用户绑定的function丧失的报告。 这些也被称为一些组织的帮助台门票。
WIKIPEDIA链接
– 软件错误
– 问题跟踪
我不认为有一个明确的答案，但我通常只是将问题追踪视为一个更通用的术语，不仅仅是“错误”。 只使用术语“Bug跟踪”就是一种与软件缺陷相关的问题。
问题跟踪器不一定要和软件绑定，甚至BugZilla也不只跟踪bug，还有新的增强/function请求，投票等等。这样，我认为“问题”只是一个有人想要“完成”的单个项目。
最近，“工作项目跟踪”（例如Visual Studio和IBM / Rational Jazz ）的水平也比“问题”更低 – 其中一个问题可能被视为需要N个较小的工作项目完成。 在更高的层面上，你也可能会看到类似于BugZilla 里程碑的东西。
要回答这个问题，需要从上下文的angular度来看，Alan的答案就是你的背景。
在软件testing的世界里，我们在问题和错误之间做出的区别之一是： 错误是任何威胁产品价值的 东西，而问题是任何威胁到testing价值的东西（或者项目的价值和特别是testing的价值）。 快速软件testing告诉我们。
根据我的经验，跟踪系统可以让你在两者之间做出任何你想要的区别。 您如何使用特定的追踪系统取决于您。
错误是特定于软件开发者的。 问题更为普遍，可以包括所有团队成员在项目上的进展，包括平面devise师，系统pipe理员，公司高pipe等等。
问题跟踪器会根据需要进行说明，如果需要，可以将某个项目分类为错误。
这主要是愚蠢的话，但我使用“问题跟踪器”，因为我和许多不是程序员的人一起工作，我们需要用一个通用的生产力工具来讲一个共同的语言，让我们意识到彼此在做什么。
您可以使用错误跟踪器，但是它会混淆非开发人员，特别是如果他们不得不把他们的任务看作是一个错误。
我想说，为程序员提供一个错误和一个问题之间的区别也是很好的，因为错误通常是现有代码的问题，问题可能是新的function请求。
那么……除了这个事实之外，没有什么不同，一个问题不仅仅是一个错误。 它可以是一项任务，一项新function，或者简单的改进。 一个bug主要被视为不正确的系统行为，而一个问题有更广泛的定义。 超越只是“它不工作”…
