错误跟踪和问题跟踪系统有什么区别？
我正在寻找关于为什么以及何时使用每个系统的解释，以及哪些功能可以区分错误与问题跟踪应用程序。
I'm looking for both an explanation of why and when you would use each system and what features differentiate a bug vs. issue tracking application.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
问题跟踪系统通常更多地与客户和客户问题集成。 问题可能是“帮我安装这个”或“如何将 fubar 放入薄膜中”。 它们甚至可能是“我需要您的软件的评估密钥”之类的内容。
错误跟踪系统帮助您跟踪程序中错误或丢失的内容。
在查看网络系统时，焦点通常有很大差异，要么帮助客户，要么跟踪软件问题。
Issue tracking systems usually integrate more with customers and customer issues. An issue could be "help me install this" or "How do I get the fubar into the flim flam." They could even be something like "I need an evalutation key for your software".
Bug tracking systems help you keep track of wrong or missing things from the program.
When looking at web systems, there is usually a big difference in focus, either helping customers or tracking problems with your software.
从以下示例中可以更清楚地看出差异。
假设您今天遇到了一个影响 5 个客户的生产问题，但该问题是由单个软件缺陷引起的。
在您的问题跟踪系统中，您开了 5 张票证并开始跟踪每个客户报告的内容、与他们沟通的内容、应用软件补丁的时间等。您可以单独跟踪此类内容每个客户。
在您的 bug 跟踪系统中，您为软件缺陷创建了 1 个条目，开始跟踪重现步骤、代码更改等内容。
只要客户问题得到修复并达到客户满意的程度，就可以关闭客户问题这可能涉及也可能不涉及修复软件。 当修复并重新测试该错误时，可以将其关闭。
两个系统，面向外和面向内，跟踪两种不同类型的事物，每个事物都有自己的生命周期。
The difference could be clearer from the following example.
Suppose you had a production issue today that affected 5 customers, but was caused by a single software defect.
In your issue-tracking system, you opened 5 tickets and started tracking what each customer reported, what was communicated to them, when the software patch was applied, etc. You can track that kind of stuff separately for each customer.
In your bug-tracking system, you made 1 entry for the software defect started tracking things like steps to reproduce, code changes, etc.
Customer issues can be closed whenever they're remedied to the customer's satisfaction and that may or may not involve fixing the software. The bug can be closed when it's fixed and retested.
Two systems, outward- and inward-facing, tracking two different kinds of things, each with its own life cycle.
像 Trac 这样的错误跟踪系统被设计为针对每个程序固有的问题都有一张票证，因此通过修改程序可以关闭票证。
像 IssueTrackerProduct 这样的客户支持票证系统被设计为每个遇到某种情况的客户都有一张票证，因此通过找出该客户的情况（可能通过修改该程序）。
有关各个示例，请参阅 Wikipedia 的问题跟踪系统比较
Bug tracking systems like Trac are designed to have one ticket for each problem intrinsic to the program, so a ticket is closed by modifying the program.
Customer support ticket systems like IssueTrackerProduct are designed to have one ticket for each customer experiencing a situation, so a ticket is closed by working out the situation for that customer (possibly by modifying the program).
For examples of each, see Wikipedia's Comparison of issue tracking systems
错误是问题的子类。 所有错误都是问题，但并非所有问题都是错误。
通常，错误是代码库中的缺陷。 这不同于不完整/尚未实现的功能，或者更难以确定的东西，例如开发人员提交票据来处理部分技术债务，或对 UI 的关注。 从语义上讲，所有这些都是“问题”。
当不属于其他类别时，一般问题通常代表最终用户报告的内容。 在大多数系统中，报告的问题本身作为错误报告进行处理。 我敢说这是一个错误。
棘手的部分是有时多个问题可能与其他问题相关。 它可能涉及相同的错误、多个错误，或者实际上是一个功能请求。 也就是说，问题之间可以存在多对多的关系。
为什么这种区别很重要？ 嗯，内部有一棵自然树——解决一个问题可以间接完成（或有助于完成）一百万个其他问题。 它还会影响问题的解决方式。 缺陷本身可以通过修复它的代码更改来解决，或者使其变得无关紧要。 如果是用户投诉，可以通过向他们发送解决方案来解决，然后在原始缺陷解决后进行后续处理。
在工单跟踪系统中真正需要寻找的是能够更好地以有用的方式表示和处理这些细微差别的功能。
在某些时候，您谈论的流程和方法多于实际的票务系统，并且事物的实际名称应该开始变得无关紧要。 主流和面向企业的解决方案往往在 ITIL 等流行系统上运行，但只要团队中的每个人都充分了解客户服务需求，您就可以摆脱临时的东西。 我个人将其视为瀑布式 (ITIL) 与敏捷式 (DevOps)< /a> 情况。
A bug is a subclass of issue. All bugs are issues, but not all issues are bugs.
Typically a bug is a defect in the codebase. This is different from an incomplete/yet-to-be implemented feature, or something more hard to pin down like a developer putting in a ticket to deal with a piece technical debt, or a concern with the UI. All of these are 'issues' semantically speaking.
A generic issue, when not falling under those other categories, is more often than not a representation of something reported by the end-user. In most systems, this reported issue is handled as a bug-report in itself. I'd venture to say this is a mistake.
The tricky part is that sometimes multiple issues may be related to other issues. It could be concerning the same bug, multiple bugs, or actually be a feature request. That is to say, there can be a many-to-many relationship between issues.
Why does the distinction matter? Well, there is a natural tree internally - Resolving one issue can indirectly complete (or contribute to completing) a million other issues. It also makes a difference in how an issue is resolved. Defects themselves may be resolved with a code change that fixes it, or makes it irrelevant. If it's a user complaint, it may be resolved by sending them a work around, and then left to be followed up on when the original defect is solved.
Features that work better at representing and working with these nuances in a useful way is really what to look for in a ticket tracking system.
At some point, you are talking about processes and methodologies more than actual ticketing systems, and the actual names of things should start to become irrelevant. Mainstream and enterprise oriented solutions tend to run on a popular systems like ITIL, but you can get away with adhoc stuff provided everyone on the team has a good understanding of customer service needs. I personally see it as a waterfall (ITIL) vs agile (DevOps) situation.
这只是语义。 bug 就是一个问题，一个问题就是要做的事情。 它们在其他方面基本相同。
it's just semantics. A bug is a problem, an issue is something to do. They are otherwise much the same.
它充其量只是一条模糊的线。 问题跟踪系统可能被认为是两者中更通用的一个。 因为所有错误跟踪系统都是问题跟踪系统，但不一定相反。
来自我们的朋友维基百科
Its' a fuzzy line at best. Issue tracking system would probably be considered the more general of the two. In that all bug tracking systems are issue tracking systems, but not necessarily the opposite.
From our Friend Wikipedia
在代码中发现错误
问题可以在任何地方找到，在流程中、在硬件中、在人员中。
定义的含义取决于您采用的开发流程。
A bug is found in code
An issue can be found anywhere, in the processes, in hardware, in people.
It depends which development process you're adopting as to what the definitions mean.
我相信错误是可以在代码中修复的，而问题更多的是可用性问题。
例如，登录表单。 登录表单中的一个错误是登录完成后表单重定向不正确。 但问题是整个登录过程太慢，或者没有选项通过电子邮件发送忘记的密码。
I believe that a bug is something that can be fixed in code, while an issue is more of a problem with usability.
For example, a login form. A bug in the login form would be the form redirecting incorrectly after the login completes. While an issue would be that the overall login process is too slow, or there is no option to email a forgotten password.
这并不是您问题的完整答案，但我在与客户打交道时也遇到过类似的问题。 我认为在最高层面上，错误跟踪系统似乎通常更关注开发人员。 也就是说，开发人员正在尝试跟踪代码中的问题。 函数没有返回正确的值，应该进行更多验证等。
与代码完美集成的系统的一个很好的例子是 Trac。
问题跟踪系统似乎更以客户为中心。 例如，能够让客户说“当我单击“确定”时，我收到一个错误”。这可能是用户培训，可能是一个功能，或者实际上可能是一个错误。
所以在许多情况下我所从事的项目中，我们保持这些不同。我们有一个高级问题跟踪系统，可能会或可能不会导致错误跟踪系统中创建实际错误，但是，许多错误都是在内部进行跟踪的，而没有任何“错误”。在问题跟踪系统中创建了“问题”。
我在这两者之间看到的问题是，对于没有经验的用户来说，将票证输入到诸如 Trac，因为他们对技术术语感到困惑。但是，高级问题跟踪系统没有与代码紧密集成，因此对开发人员来说毫无用处
......我的 0.02 美元。
This isn't really a complete answer to your question, but I've had similar questions come up with dealing with customers. I think at the highest level, a bug tracking system seems usually to be more developer focused. That is, developers are trying to track problems in the code. A function isn't returning the right value, more validation should be done, etc.
A good example of a system that integrates nicely with code is Trac.
Issue tracking systems seem to be more customer-centric. For example, being able to have a customer say "When I click on 'OK" I get an error". It may be user training, it may be a feature, or it may in fact be a bug.
So in many of the projects that I've worked on we keep these distinct. We have a high-level issue tracking system that may or may not result in an actual bug being created in the bug tracking system. However, many many bugs are tracked internally without any "issues" being created in the issue tracking system.
The problem that I see between these two is that it's really not very easy for inexperienced users to enter tickets into something like Trac because they get confused by the technical lingo. However, a high-level issue tracking system does not integrate tightly with code so it's useless to the developers.
Anyway... my $0.02.
错误：流程（应用程序、数据库、报告等）中任何地方的缺陷，这些缺陷将阻止 100% 所需功能的发生。 也称为缺陷。
问题：可能由一个或多个错误引起，问题是与用户相关的系统中某种形式的功能丢失的报告。 在某些组织中，这些也称为帮助台票证。
WIKIPEDIA LINKS
- Software Bug
- Issue Tracking
Bugs: flaws anywhere within the process (application, database, reporting, etc.) that will prevent 100% of desired functionality from occurring. Also known and referred to as defects.
Issues: potentially caused by a bug or bugs, an issue is a report of some form of loss of functionality in the system that would be tied to a user. These are also referred to as help desk tickets in some organizations.
WIKIPEDIA LINKS
- Software Bug
- Issue Tracking
要回答这个问题需要上下文，从表面上看艾伦的答案是针对你的上下文的。
在软件测试领域，我们对问题和错误进行的区分之一是：错误是威胁产品价值的任何事物，而问题是威胁产品价值的任何事物测试的价值（或项目的价值，特别是测试的价值）。 快速软件测试告诉我们这一点。
根据我的经验，跟踪系统允许您在两者之间做出任何您想要的区分。 如何使用特定的跟踪系统取决于您。
To answer this question it requires context and from the looks of it Alan's answer was to your context.
In the world of software testing, one of the distinctions we make between an issue and a bug are: bugs are anything that threatens the value of the product while issues are anything that threatens of the value of testing (or the value of the project and in particular the value of testing). Rapid Software testing teaches us that.
In my experience the tracking systems allow you to make whatever distinction you want between the two. How you use a particular tracking system is up to you.
我不认为有一个明确的答案，但我通常只是认为问题跟踪只是一个更通用的术语，不仅仅对应于“错误”。 只使用“Bug Tracking”这个术语有点像鸽子笼，它与软件缺陷相关。
不过，问题跟踪器不必与软件绑定，甚至 BugZilla 也不仅仅跟踪错误，还跟踪新的增强/功能请求、投票等。这样，我认为一个“问题”只是某人想要“完成”的一个感兴趣的项目。
最近，工作项跟踪也有所增加（例如 Visual Studio 和 IBM /Rational Jazz），它比“问题”级别更低——其中一个问题可以被视为需要一些 N 个较小的工作项来完成。 在更高的级别上，您可能还会看到类似于 里程碑BugZilla 中的 a>。
I don't think there is a definitive answer, but I usually just think of Issue Tracking as merely a more generic term that corresponds to more than just "bugs". To only use the term "Bug Tracking" is kind of a pigeon-hole, which is associated with defects in software.
An issue tracker doesn't have to be tied to software though, and even BugZilla doesn't track only bugs, but also new enhancement / feature requests, votes, etc. In that way, I think of an "issue" as just a single item of interest that someone wants to get "done."
Lately there has also been a rise in Work Item Tracking (in e.g. Visual Studio and IBM/Rational Jazz), which is more lower level than "issues"--wherein an issue could be seen as requiring some N number of smaller work items to complete. At a higher level, you might also see something akin to a Milestone in BugZilla.
错误是软件开发人员特有的。 问题更为普遍，可以包括项目中所有团队成员的进度，包括图形设计师、系统管理员、公司高管等。
问题跟踪器会根据要做的事情进行说明，并且如果需要，可以将项目归类为错误。
这大多只是愚蠢的话，但我使用“问题跟踪器”，因为我与许多不是程序员的人一起工作，我们需要通过拥有一个共同的生产力工具来讲共同的语言，使我们了解彼此在做什么。
您可以使用错误跟踪器，但它只会让非开发人员感到困惑，特别是当他们必须将自己的任务视为错误时。
我想说，对于程序员来说，区分错误和问题也很好，因为错误通常是现有代码的问题，而问题可能是新功能请求。
Bugs are specific to software developers. Issues are more general and can include all team member's progress on a project, including the graphic designers, system administrators, company executives, etc.
An issue tracker speaks in terms of things to do and can categorize an item as a bug if needed.
It is mostly just silly words, but I use an "issue tracker" as I work with many people who are not programmers, and we need to speak a common language by having a common productivity tool that makes us aware of what each other is doing.
You can use a bug tracker but it will just confuse non developers, especially if they have to think of their tasks as being a bug.
I would say it is also nice to draw a difference between a bug and an issue for programmers, as bugs are usually problems with existing code, and issues can be new feature requests.
嗯……除了问题不仅仅是一个错误之外，没有什么区别。 它可以是一项任务、一项新功能，或者仅仅是一项改进。 错误通常被视为不正确的系统行为，而问题则具有更广泛的定义。 除了“它不起作用”之外......
Well... there is not difference besides the fact, that an issue is more than just a bug. It can be a task, a new feature, or simply an improvement. A bug is mostly seen as incorrect system behavior, while an issue has a broader definition. beyond just "it does not work"...