内部和外部错误跟踪设置[关闭]答案

【问题标题】：Internal and External Bug-Tracking Setup [closed]内部和外部错误跟踪设置[关闭]
【发布时间】：2010-03-16 08:00:56
【问题描述】：

你们中的大多数人肯定会使用某种错误跟踪器。也许仅限于内部，一旦客户通过电子邮件或电话提交错误，您就可以自己添加新票。有时，每周的项目会议可以成为新票的重要来源，最好是桌子另一边的 PM 喜欢维护和追随你的 Excel 表格。

更高级（和透明）的版本：允许客户将他的错误直接提交（并查看进度）到您的错误跟踪器中。 JIRA 等系统允许您使用配置文件来获得某些访问权限等。

但是现在问题：用户提出的错误不一定会转化为特定模块/方法/EJB/类中的 1 个错误。他使用的（您的）Web 应用程序的版本不会转换为导致错误的类的版本。您如何使用所有讨厌的技术细节维护票证的内部部分，同时让用户感觉良好的票证（需要更多信息，接受，正在进行中，..）？为内部和外部创建 2 张票？链接它们？

有什么聪明的食谱可以分享吗？

【问题讨论】：

标签： bug-tracking ticket-system

【解决方案1】：

将您的错误系统与您的客户支持跟踪系统分开，并允许它们之间的链接。

错误可能涉及零张、一张或多张客户支持票。
客户支持票证可能涉及零错误（例如，客户的问题与您的软件无关）、一个错误（以防它确实是您的软件中的问题）或多个错误（发生错误）。李>

进行如下查询：

哪些客户正在等待错误 X 的解决方案
哪些客户正在等待开放的严重错误
用户 Y 已经遇到了哪些错误
...

您还会注意到每个数据库都有自己的“速度”。在我的情况下，我的客户支持电话比真正的 bug 多 4 倍。

【讨论】：

【解决方案2】：

最明智的方法是拥有两个系统，或者为最终用户提交错误的替代机制（通过电子邮件）。主要问题不在于错误不一定会转化为类中的一种方法，而主要是如果您有多个用户，人们不会阅读现有的错误并且比“按钮不起作用”更深入地思考。

如果您隔离真正的事件系统（将其公开，但只读），您的员工可以筛选传入的错误，确保它们是可重现的并有重现案例，检查现有的错误，并且通常在您发现错误后发现一个明确的错误输入它，并且不难理解可能有意义也可能没有意义的混乱，并且是同一个错误的另一个条目已经输入了另外 30 次。

【讨论】：

【解决方案3】：

JIRA 中的每条评论都有一个“查看者”字段，允许您设置评论可见的组或项目角色。你可以用它来隐藏“讨厌的技术细节”。

另外，当您说创建两个问题并将它们链接起来时，您可能走在正确的轨道上。这还有一个额外的好处，那就是对客户隐藏您的内部工作流程。

【讨论】：

【解决方案4】：

一个用于（外部）帮助台和（内部）问题跟踪的系统。只要您可以完全控制工单/问题的可见性，并且可以在外部/内部项目之间建立链接，那么这没什么大不了的。

【讨论】：