我正在寻找有关您使用每个系统的原因和时间以及哪些功能可以区分错误与问题跟踪应用程序的解释。
问问题
18086 次
14 回答
45
问题跟踪系统通常更多地与客户和客户问题集成。问题可能是“帮我安装这个”或“我如何让 fubar 进入 flim flam”。它们甚至可以是“我需要您的软件的评估密钥”之类的东西。
错误跟踪系统可帮助您跟踪程序中错误或遗漏的内容。
在查看 Web 系统时，关注点通常存在很大差异，要么帮助客户，要么跟踪软件问题。
于 2009-06-02T19:48:43.413 回答
39
从以下示例中可以更清楚地看出差异。
假设您今天遇到了一个影响 5 个客户的生产问题，但它是由一个软件缺陷引起的。
在您的问题跟踪系统中，您打开了 5 张工单并开始跟踪每个客户报告的内容、与他们沟通的内容、应用软件补丁的时间等。您可以为每个客户单独跟踪此类内容。
在您的错误跟踪系统中，您为软件缺陷创建了 1 个条目，开始跟踪诸如重现步骤、代码更改等内容。
只要客户的问题得到了客户满意的补救，就可以关闭客户问题，这可能涉及也可能不涉及修复软件。修复并重新测试后，可以关闭该错误。
两个系统，外向和内向，跟踪两种不同的事物，每种事物都有自己的生命周期。
于 2009-06-02T20:10:39.127 回答
11
像Trac这样的错误跟踪系统旨在为程序固有的每个问题提供一张票，因此可以通过修改程序关闭一张票。
像IssueTrackerProduct这样的客户支持工单系统旨在为每个遇到某种情况的客户提供一张工单，因此通过为该客户解决情况（可能通过修改程序）来关闭工单。
有关每个示例，请参阅 Wikipedia 的问题跟踪系统比较
于 2009-06-02T19:58:07.047 回答
10
错误是问题的子类。所有错误都是问题，但并非所有问题都是错误。
通常，错误是代码库中的缺陷。这不同于一个不完整/尚未实现的功能，或者更难确定的东西，比如开发人员开一张票来处理一项技术债务，或者对 UI 的关注。从语义上讲，所有这些都是“问题”。
一个通用问题，当不属于其他类别时，通常代表最终用户报告的某些内容。在大多数系统中，此报告的问题本身作为错误报告处理。我敢说这是一个错误。
棘手的部分是有时多个问题可能与其他问题有关。它可能与同一个错误、多个错误或实际上是一个功能请求有关。也就是说，问题之间可以存在多对多的关系。
为什么区分很重要？嗯，内部有一棵天然树——解决一个问题可以间接完成（或有助于完成）一百万个其他问题。它还对解决问题的方式产生了影响。缺陷本身可以通过修改代码来解决，或者使其无关紧要。如果是用户投诉，可以通过向他们发送解决方案来解决，然后在原始缺陷解决后留待跟进。
以有用的方式更好地表示和处理这些细微差别的功能确实是在票务跟踪系统中寻找的东西。
在某些时候，您谈论的过程和方法比实际的票务系统更多，事物的实际名称应该开始变得无关紧要。主流和面向企业的解决方案倾向于在 ITIL 等流行的系统上运行，但如果团队中的每个人都对客户服务需求有很好的了解，你就可以摆脱临时的东西。我个人将其视为瀑布 (ITIL) 与敏捷 (DevOps)的情况。
于 2009-06-02T20:46:40.647 回答
5
这只是语义。一个错误就是一个问题，一个问题就是要做的事情。它们在其他方面大致相同。
于 2009-06-02T19:46:07.553 回答
4
它充其量是一条模糊的线。问题跟踪系统可能被认为是两者中更通用的。因为所有错误跟踪系统都是问题跟踪系统，但不一定相反。
来自我们的朋友维基百科
错误跟踪系统是一种软件应用程序，旨在帮助质量保证和程序员跟踪他们工作中报告的软件错误。它可以被视为一种问题跟踪系统。
于 2009-06-02T19:47:12.573 回答
4
在代码中发现了一个错误
问题可以在任何地方、流程、硬件和人员中找到。
至于定义的含义，这取决于您采用的开发过程。
于 2009-06-02T19:47:33.977 回答
3
我相信错误是可以在代码中修复的东西，而问题更多的是可用性问题。
例如，登录表单。登录表单中的错误将是登录完成后表单重定向错误。虽然一个问题是整个登录过程太慢，或者没有选择通过电子邮件发送忘记的密码。
于 2009-06-02T19:46:05.290 回答
3
这并不是您问题的完整答案，但在与客户打交道时，我也遇到过类似的问题。我认为在最高级别上，错误跟踪系统似乎通常更侧重于开发人员。也就是说，开发人员正在尝试跟踪代码中的问题。一个函数没有返回正确的值，应该做更多的验证，等等。
与代码完美集成的系统的一个很好的例子是Trac。
问题跟踪系统似乎更加以客户为中心。例如，能够让客户说“当我点击‘确定’时出现错误”。这可能是用户培训，可能是功能，或者实际上可能是错误。
因此，在我参与的许多项目中，我们保持这些不同。我们有一个高级问题跟踪系统，它可能会也可能不会导致在错误跟踪系统中创建实际错误。但是，许多错误是在内部跟踪的，而没有在问题跟踪系统中创建任何“问题”。
我在这两者之间看到的问题是，对于没有经验的用户来说，将工单输入到Trac之类的东西确实不是很容易，因为他们被技术术语弄糊涂了。但是，高级问题跟踪系统并未与代码紧密集成，因此对开发人员来说毫无用处。
无论如何...我的 0.02 美元。
于 2009-06-02T19:49:54.440 回答
3
要回答这个问题，它需要上下文，从它的外观来看，艾伦的回答是针对您的上下文。
在软件测试的世界中，我们对问题和错误的区分之一是：错误是威胁产品价值的任何东西，而问题是威胁测试价值（或项目价值和特别是测试的价值）。 快速软件测试告诉我们这一点。
根据我的经验，跟踪系统允许您在两者之间做出任何您想要的区分。如何使用特定的跟踪系统取决于您。
于 2012-03-30T00:22:36.237 回答
2
我不认为有一个明确的答案，但我通常只是认为问题跟踪只是一个更通用的术语，它不仅仅对应于“错误”。只使用“Bug Tracking”这个词有点像鸽子洞，它与软件中的缺陷有关。
问题跟踪器不必与软件绑定，甚至 BugZilla 也不仅仅跟踪错误，还跟踪新的增强/功能请求、投票等。这样，我认为“问题”只是一个某人想要“完成”的单个感兴趣的项目。
最近工作项跟踪也有所增加（例如在Visual Studio和IBM/Rational Jazz中），它比“问题”级别更低——其中一个问题可以被视为需要 N 个较小的工作项来完全的。在更高的层次上，您可能还会看到类似于BugZilla中的里程碑的东西。
于 2009-06-02T20:21:36.140 回答
1
错误是特定于软件开发人员的。问题更普遍，可以包括所有团队成员在项目上的进度，包括平面设计师、系统管理员、公司高管等。
问题跟踪器会根据要做的事情来说话，并且可以在需要时将项目归类为错误。
这大多只是愚蠢的词，但我使用“问题跟踪器”，因为我与许多不是程序员的人一起工作，我们需要通过一个通用的生产力工具说一种通用的语言，让我们知道彼此在做什么.
您可以使用错误跟踪器，但它只会让非开发人员感到困惑，尤其是当他们不得不将他们的任务视为错误时。
我想说，对于程序员来说，区分 bug 和问题也很好，因为 bug 通常是现有代码的问题，而问题可能是新功能请求。
于 2009-06-02T20:06:21.443 回答
0
嗯......除了一个问题不仅仅是一个错误之外，没有什么区别。它可以是一项任务、一项新功能，或者仅仅是一项改进。错误通常被视为不正确的系统行为，而问题具有更广泛的定义。不仅仅是“它不起作用”......
于 2009-06-02T20:29:53.190 回答