错误跟踪和问题跟踪系统有什么区别?

问题跟踪系统 通常更多地与客户和客户问题集成。一个问题可能是“帮助我安装这个”,或者“我如何将Fubar安装到flim flam中”,甚至可能是“我需要一个用于您的软件的评估密钥”。

缺陷跟踪系统 帮助您跟踪程序中错误或丢失的内容。

在查看Web系统时,关注点通常会有很大的不同,既可以帮助客户,也可以跟踪软件的问题。

从下面的例子中可以更清楚地看出这一区别。

假设您今天的生产问题影响了5个客户,但是由单个软件缺陷引起的。

在你 问题 -跟踪系统,你打开5张票,开始跟踪每个客户报告的内容、与他们交流的内容、应用软件补丁时的内容等。你可以为每个客户单独跟踪这类内容。

在你 缺陷 -跟踪系统中,您为软件缺陷输入了1个条目,开始跟踪诸如复制步骤、代码更改等内容。

只要客户的问题得到了客户满意的修复,并且可能涉及或可能不涉及修复软件,就可以解决客户的问题。当修复并重新测试错误时,可以关闭它。

两个系统,外向和内向,跟踪两种不同的东西,每个都有自己的生命周期。

错误跟踪系统 跟踪器 每个都有一张票 程序固有的问题 ,因此通过修改程序关闭票据。

客户支持票据系统 问题跟踪产品 每个都有一张票 客户遇到问题 因此,通过为该客户计算情况(可能通过修改程序)可以关闭票据。

有关每个的示例,请参见维基百科 Comparison of issue tracking systems

bug是问题的一个子类。所有的错误都是问题,但并非所有的问题都是错误。

通常,bug是代码库中的缺陷。这与未完成/尚未实现的特性不同,或是更难以确定的特性,例如开发人员为处理工件技术债务而提交票据,或与UI有关。所有这些都是语义上的“问题”。

一般性问题,当不属于这些其他类别时,往往是最终用户报告的内容的一种表示。在大多数系统中,这个报告的问题本身就是一个bug报告。我冒昧地说这是个错误。

棘手的是,有时多个问题可能与其他问题有关。它可能涉及同一个bug、多个bug,或者实际上是一个特性请求。也就是说,问题之间可以有多对多的关系。

为什么区别很重要?嗯,在内部有一棵天然的树——解决一个问题可以间接地完成(或促成)一百万个其他问题。解决问题的方式也会有所不同。缺陷本身可以通过修改代码来解决,或者使其不相关。如果是用户投诉,可以通过向他们发送一份工作来解决,然后在解决原始缺陷时留下来跟进。

在票务跟踪系统中,能够更好地表示和处理这些细微差别的功能实际上是需要寻找的。

在某种程度上,你所说的过程和方法比实际的票务系统更重要,而事物的实际名称应该开始变得无关紧要。主流和面向企业的解决方案倾向于在一个流行的系统上运行,比如ITIL,但是如果团队中的每个人都对客户服务需求有很好的理解,那么您就可以摆脱即席工作。我个人认为这是 waterfall (ITIL) vs agile (DevOps) 情况。

这只是语义学。错误是一个问题,问题是要做的事情。它们在其他方面基本相同。

最好是模糊线。问题跟踪系统可能被认为是这两个系统中较为普遍的一个。在这一点上,所有的错误跟踪系统都是问题跟踪系统,但不一定是相反的。

来自我们的朋友 Wikipedia

缺陷跟踪系统是一个软件 旨在帮助的应用程序 质量保证和程序员保持 跟踪报告的软件错误 他们的工作。它可以被视为 一种问题跟踪系统。

在代码中发现一个错误

问题可以在任何地方、流程中、硬件中或人身上发现。

它取决于您采用的开发过程,以及定义的含义。

我相信错误是可以在代码中修复的,而问题更多的是可用性问题。

例如,登录表单。登录表单中的错误可能是登录完成后表单重定向错误。但问题是整个登录过程太慢,或者没有发送忘记密码的电子邮件的选项。

这并不是你问题的完整答案,但我在与客户打交道时也遇到过类似的问题。我认为在最高层次上,bug跟踪系统通常更注重开发人员。也就是说,开发人员正试图跟踪代码中的问题。函数没有返回正确的值,应该进行更多的验证等。

与代码完美集成的系统的一个好例子是 Trac .

问题跟踪系统似乎更以客户为中心。例如,能够让客户说“当我点击‘确定’时,我会得到一个错误”。它可能是用户培训,也可能是一个特性,或者实际上是一个bug。

所以在我参与过的许多项目中,我们都保持着这些不同。我们有一个高级的问题跟踪系统,可能会导致或可能不会导致在错误跟踪系统中创建实际的错误。但是,许多错误都是在内部跟踪的,问题跟踪系统中没有创建任何“问题”。

我在这两者之间看到的问题是,对于没有经验的用户来说,把票输入类似 跟踪器 因为他们对技术术语感到困惑。但是,一个高级的问题跟踪系统不能与代码紧密集成,因此对开发人员来说是无用的。

总之…我的0.02美元。

漏洞 :流程中的任何缺陷(应用程序、数据库、报告等),将阻止100%所需功能的发生。也称为缺陷。

问题 :可能是由一个或多个错误引起的,问题是系统中某些形式的功能丧失报告,这些功能将与用户联系在一起。在某些组织中,它们也被称为帮助台票据。

要回答这个问题,它需要上下文,从它的外观来看,艾伦的答案就是你的上下文。

在软件测试领域,我们在问题和bug之间的区别之一是: 错误是任何威胁产品价值的东西。 虽然 问题是对测试价值(或项目价值,尤其是测试价值)的任何威胁。 Rapid Software testing 告诉我们这一点。

根据我的经验,跟踪系统允许你对两者进行任何区分。如何使用特定的跟踪系统取决于您自己。

我不认为有明确的答案,但我通常认为问题跟踪只是一个更通用的术语,它不仅仅是“错误”。只使用术语“bug跟踪”是一种鸽子洞,它与软件缺陷有关。

问题追踪器不必依赖于软件,即使是Bugzilla也不需要跟踪 只有 bug,也包括新的增强/功能请求、投票等。通过这种方式,我认为一个“问题”只是某个人想要“完成”的一个感兴趣的项目。

最近,工作项跟踪(例如 Visual Studio 和 IBM/Rational Jazz ,这比“问题”的级别低得多——在“问题”中,一个问题可能被视为需要一些n个较小的工作项来完成。在更高的层次上,您也可能看到类似于 Milestone 在里面 BugZilla .

错误是特定于软件开发人员的。问题更为普遍,可以包括团队成员在项目中的所有进度,包括图形设计师、系统管理员、公司主管等。

问题追踪器根据要做的事情进行说明,如果需要,可以将项目分类为bug。

这基本上只是一个愚蠢的词,但我使用“问题追踪器”与许多不是程序员的人一起工作,我们需要通过一个共同的生产力工具来讲一种共同的语言,让我们知道对方在做什么。

你可以使用一个bug追踪器,但它只会让非开发人员感到困惑,特别是当他们不得不把自己的任务看作bug时。

我想说,对于程序员来说,在bug和问题之间划一个界限也很好,因为bug通常是现有代码的问题,而问题可能是新特性请求。

好。。。除了一个事实,没有什么不同,一个问题不仅仅是一个bug。它可以是一个任务、一个新特性,或者只是一个改进。错误通常被认为是不正确的系统行为,而问题有更广泛的定义。不仅仅是“它不起作用”…